性能測試面面觀——HP性能測試專家宗剛訪談(2)

　　C、迭代階段：

　　系統不斷的增加新特性、新需求，需要迭代驗證系統的性能與容量

　　D、運維階段：

　　研發人員常常覺得系統交給運維就可以了，由于運維人員對應用本身不夠清楚，所以常常是盲人摸象，抓不住根本。見過業務高峰期，運維人員就看著CPU在往上漲，不知道應該怎么辦，不清楚系統的容量點會在哪里出現，系統宕掉一臺服務器會怎么樣?多長時間能夠恢復?到底能夠支持多少的業務量?什么業務比較消耗時間?怎么優雅降級?在研發環境中，獲得這些數據和手段都是比較容易的，運維人員是研發的第一個客戶，應該多為他們考慮。

　　上面介紹了整個生命周期性能的管理，從廣度角度講。那么從深度角度講，性能管理應該包括：性能測試、性能優化和性能建模容量規劃。

　　性能測試：驗證系統性能是否滿足需求。

　　性能優化：優化性能瓶頸，提升系統處理能力，測試和優化會有若干次的迭代。性能建模容量規劃：生產環境可能出現各種場景，應該怎么預測與預防。

　　如果比喻整個過程為病人看病，那么性能測試就是體檢，性能優化就是對病下藥，性能建模容量規劃就是保健。

　　由于系統總在變化，新業務、擴容、軟硬件版本升級等等，所以需要不斷的迭代，如下圖：

　　問題：你如何判斷性能測試在項目或產品中的實際價值?

　　宗剛：實際價值：

　　A、業務部門：支持業務決策和促銷，提高客戶滿意度

　　B、運維部門：清楚系統容量，提升系統可用性、穩定定，降低硬件采購成本，提前預測預防提高響應速度，睡覺可以安心

　　C、規劃部門：有理有據進行規劃

　　D、研發部門：減少運維部門給研發部門的壓力

　　問題：你覺得高級性能測試專家需要什么樣的個人能力和素質?

　　宗剛：高級性能測試專家需要的能力模型，如下圖所示，成為博學的專家。

　　精通于性能測試分析建模，熟悉系統各層的監控與優化。同時需要較強的溝通能力，為了實施好項目需要有過程領域的知識如敏捷、CMMI等。性能測試技術發展路線參考如下：

　　成為一個高級性能測試人員需要掌握的東西非常多，如何學習這些知識。通過多年的實踐歸納，我的一點學習方法和大家分享：

　　成長=3本書+領域專家+實驗+實戰+持續提升。

　　3本書：1本基礎書籍+1本全面的理論書籍+1本實戰書籍。所有的書一定要經典書籍，我們常常開始學習知識的時候通過論壇的方法，這種方法入門比較容易，但是很難系統，也會占據非常多的時間。為什么要經典書?讀書的最大成本不是買書的錢，而是讀書的時間，所以看書一定要看最經典的書，怎么找經典書?可以到豆瓣、專業論壇、當當上看看評論。每個領域有每個領域的書籍，學習Oracle優化有oracle的書籍，學習loadrunner有loadrunner的書籍，千萬不要以為做性能測試就學3本性能測試的書籍就夠了。

　　領域專家：成長過程中如果有領域專家的支持，就會少走不少彎路。當我開始學習Oracle性能調優的時候，剛好認識一位Oracle調優同事，和他溝通請他推薦一些資料，講講實操的技巧。這里需要注意的一點是不要所有毛皮小事都去找專家，人家也有自己的工作。一些問題可以通過google搜索、或專業論壇就可以解決。前段時間有項目需要用informix數據庫，就請一位informix專家給我指導，大多數技術小問題在技術論壇上都有。如果大家不認識專家，那也沒有關系，通過微博、論壇認識他們，大多數人還是愿意幫忙的。

　　實驗：性能項目不是那么多，所以自己要找一些實驗的內容。技術書籍一般都會有一些實戰的內容，如果不去實際操作一遍往往過一段時間就忘了。當我學習Tuxedo調優的時候，在自己的虛擬機上搭建Tuxedo環境，使用修改后的Demo應用進行壓力測試，設計不同的壓力場景，測試過程不斷去調優應用，這個學習過程成長會很快。我的好多同事為了學習好hp-ux，自己購買退役的小機搭環境，進行實驗調優。很多時候不是技術難，而是沒有機會接觸這樣的環境。有過實驗的經歷，在就職面試的時候也算是經驗啊。

　　實戰：通過實驗之后，基本有經驗了，如果再通過幾個實戰項目，不斷總結歸納，基本就成為一個中級的性能測試人員了。以戰養戰，沒有一個人開始就會所有的東西，每個項目都會用一些新的技術，所以在不同的項目中需要有很強的學習能力，能夠快速學習新的技術并用于實戰。

　　持續提升：想成為高級性能測試人員或專家，就需要不斷更新學習新的知識和技術。通過論壇、活動、微博、讀書等方式不斷提升，也要常常和大家一起分享，分享是非常好的學習手段，還可以提高自己的知名度。

　　問題：如何從業務目標分析得到性能測試需求、性能指標?

　　宗剛：常見的業務需求如下：日交易量支持1.4億，響應時間小于2秒，支持用戶2億。我們需要把這些指標轉化為可以測試的指標和場景。通過分析歷史交易的波峰波谷，把1.4億的交易量折換為每秒鐘的交易量;響應時間也可以分類，比如本地業務多長時間，跨省業務多長時間，跨行業務多長時間等等;我們常常把支持多少用戶作為衡量指標，這是一個誤區，大量用戶導致產生大量的業務才會消耗系統的利用率，所以關鍵是業務量。這里有個例外，如果要驗證支持多少在線用戶，以及長連接的系統就需要考慮支持的用戶數量更精確的說法應該是支持的Session。從業務需求到性能測試需要一般要經歷這些過程：評估性能風險、確定關鍵用例、選擇關鍵性能場景、建立可測試性能目標。

　　性能指標一般會有：交易響應時間、交易成功率、資源利用率、每秒鐘的交易量(TPS)。這幾個指標是相互約束的，如果低成功率下的TPS是沒有意義的。多數運維部門對資源利用率都會有一些硬規定，比如CPU不能高于85%，內存不能高于90%等等，所以在測試之前需要清楚這些約束。除了上面的通用指標，各個應用系統會依據技術特點有一些特殊的指標。更全面的指標應該是分層的，從終端用戶的體驗—>業務流程—>中間件數據庫的響應—>基礎架構的利用。

原文轉自：http://www.blogjava.net/qileilove/archive/2013/04/16/397896.html