性能測試淺談

　　本文主要針對WEB系統的性能測試。不涉及具體的執行操作，只是本人對性能測試的一點理解和認識。

　　性能測試的目的，簡單說其實就是為了獲取待測系統的響應時間、吞吐量、穩定性、容量等信息。而發現一些具體的性能相關的缺陷(如內存溢出、并發處理等問題)，我認為只是一種附加結果。從更高的層次來說，性能測試最想發現的，是瓶頸。如何能得到所需要的信息，就需要從多方面進行測試。

　　性能測試的內容

　　性能測試種類的劃分與定義這里就不說了，各有各的說法，比如性能測試、負載測試、壓力測試這三個詞，在網上能找到N個版本的定義，大體理解就行了，沒必要在文字層面上較這個真。以下的內容也只是我個人的理解，一些名詞的定義可能和其他資料有所不同，但在我的工作中，這樣是比較形象和容易理解的。

　　在實際工作，一般的應用系統會從這么幾個方面進行性能測試。

　　1.基準測試

　　Benchmark或者Baseline測試。一般為單用戶測試，或者是零數據量環境下的測試。目的在于建立一個可度量的參考標準，為其他測試場景或者調優過程提供對比參考。也可認為是最基礎的性能測試，如果基準測試的結果都不能達到預期要求，那么后續場景也就沒必要測試了

　　2.日常壓力測試

　　在基準測試通過后，應該先進行較小壓力下的測試，首先對系統在日常壓力下的表現進行測試。此壓力需要根據系統使用相關數據得出，如系統平均每天訪問量、平均在線人數、每日完成事務數等。通過此測試，發現一些較表面的性能問題并進行處理。

　　3.峰值壓力測試

　　在日常壓力測試通過后，需要進行更大壓力的測試。此處壓力同樣需要相關數據的支持，一般為未來幾年后的預期壓力?？筛鶕v史日均壓力、日最高壓力等信息，估算出未來幾年的日均以及日最高壓力。再通過一些通用估算方法、如二八原則(80%的工作在20%時間內完成，相當于2小時完成一天8小時的工作量)，將日壓力轉換成峰值壓力。

　　峰值壓力為可預期到的最大負載壓力，通過了此測試，則認為系統有能力滿足未來增長的壓力。

　　4.容量測試

　　驗證了系統是否可滿足預期的壓力后，還需要知道系統能夠承受的最大壓力，也就是容量。一般通過“拐點法”進行測試，逐步增大系統的壓力，直到性能指標不可接受或者出現了明顯的拐點。如下圖，拐點在哪?

　　5.穩定性測試

　　驗證系統是否可長期穩定的運行，是否存在一些短時間內可能無法發現的缺陷(如內存溢出、數據庫連接不釋放等)。為了縮短測試工期，一般可將預期一天的壓力集中在2小時內完成(二八原則)，這樣持續加壓10小時，便相當于系統運行5天。注意監控各種性能指標是否平穩，有無下降。

　　以上幾種類型的測試，是性能測試過程中最多用到的。當然也也其他一些比較常用的類型，如絕對并發測試，測試多用戶對某一功能的瞬時請求，主要用于驗證系統是否存在并發邏輯上的處理問題。此測試也可劃分到不同的壓力測試場景中去，根據不同的用戶壓力，測試相應的絕對并發，一般取在線用戶數的10%進行測試;突發壓力測試，對一些不在預期內的突然壓力進行測試(其實既然想到了，就應該是在預期內了)。以銀行門戶網站為例，可能會由于發布了一條重要消息(政策調整)而導致訪問量激增，這種壓力是否會導致系統宕機或者暫時無法提供服務，就是突發壓力測試需要考慮的了。也有人將此壓力定義為峰值壓力，這就無所謂了，只要考慮到會有這么一個問題就夠了。

　　性能測試的階段

　　上面主要說的是測試內容的劃分，也就是說做性能測試時要考慮到的幾個方面。從實際執行層面來看，測試的過程一般分為這么幾個階段：

　　1.測試確認

　　理解被測系統、尋找測試點、確認測試范圍、測試環境等。一些重要信息需要同PM、需求人員、設計人員討論確認，如用戶最常用哪些功能、最關注哪的性能，程序上哪可能是壓力點，哪些數據需要模擬到真實的量級，大體上需要使用哪種測試方法。

　　2.確定通過標準

　　性能是好是壞、測試是否通過，必須有明確的標準。這個標準，主要從客戶的期望和業務上的需求兩方面來考慮，客戶的期望一般指頁面上的響應時間，業務需求則是系統的處理能力，一般為吞吐量或TPS(每秒完成事務數)。標準制定的不合理，測試結果可能無法反映系統真實的性能表現，或者會讓客戶無法接受我們認為通過的軟件。

原文轉自：http://www.uml.org.cn/Test/201306064.asp