性能測試的劃分與定義
性能測試種類的劃分與定義這里就不說了，各有各的說法，比如性能測試、負載測試、壓力測試這三個詞，在網(wǎng)上能找到N個版本的定義，大體理解就行了，沒必要在文字層面上較這個真。以下的內(nèi)容也只是我個人的理解，一些名詞的定義可能和其他資料有所不同，但在我的工作中，這樣是比較形象和容易理解的。
性能測試的目的，簡單說其實就是為了獲取待測系統(tǒng)的響應(yīng)時間、吞吐量、穩(wěn)定性、容量等信息。而發(fā)現(xiàn)一些具體的性能相關(guān)的缺陷（如內(nèi)存溢出、并發(fā)處理等問題），我認為只是一種附加結(jié)果。從更高的層次來說，性能測試最想發(fā)現(xiàn)的，是瓶頸。
在實際工作，一般的應(yīng)用系統(tǒng)會從這么幾個方面進行性能測試。
1.基準測試
Benchmark或者Baseline測試。一般為單用戶測試，或者是零數(shù)據(jù)量環(huán)境下的測試。目的在于建立一個可度量的參考標準，為其他測試場景或者調(diào)優(yōu)過程提供對比參考。也可認為是最基礎(chǔ)的性能測試，如果基準測試的結(jié)果都不能達到預(yù)期要求，那么后續(xù)場景也就沒必要測試了。
2.日常壓力測試
在基準測試通過后，應(yīng)該先進行較小壓力下的測試，首先對系統(tǒng)在日常壓力下的表現(xiàn)進行測試。此壓力需要根據(jù)系統(tǒng)使用相關(guān)數(shù)據(jù)得出，如系統(tǒng)平均每天訪問量、平均在線人數(shù)、每日完成事務(wù)數(shù)等。通過此測試，發(fā)現(xiàn)一些較表面的性能問題并進行處理。
3.峰值壓力測試
在日常壓力測試通過后，需要進行更大壓力的測試。此處壓力同樣需要相關(guān)數(shù)據(jù)的支持，一般為未來幾年后的預(yù)期壓力。可根據(jù)歷史日均壓力、日***壓力等信息，估算出未來幾年的日均以及日***壓力。再通過一些通用估算方法、如二八原則（80%的工作在20%時間內(nèi)完成，相當于2小時完成一天8小時的工作量），將日壓力轉(zhuǎn)換成峰值壓力。
峰值壓力為可預(yù)期到的***負載壓力，通過了此測試，則認為系統(tǒng)有能力滿足未來增長的壓力。
4.容量測試
驗證了系統(tǒng)是否可滿足預(yù)期的壓力后，還需要知道系統(tǒng)能夠承受的***壓力，也就是容量。一般通過“拐點法”進行測試，逐步增大系統(tǒng)的壓力，直到性能指標不可接受或者出現(xiàn)了明顯的拐點。如圖：
5.穩(wěn)定性測試
驗證系統(tǒng)是否可長期穩(wěn)定的運行，是否存在一些短時間內(nèi)可能無法發(fā)現(xiàn)的缺陷（如內(nèi)存溢出、數(shù)據(jù)庫連接不釋放等）。為了縮短測試工期，一般可將預(yù)期一天的壓力集中在2小時內(nèi)完成（二八原則），這樣持續(xù)加壓10小時，便相當于系統(tǒng)運行5天。注意監(jiān)控各種性能指標是否平穩(wěn)，有無下降。
以上幾種類型的測試，是性能測試過程中最多用到的。當然也也其他一些比較常用的類型，如絕對并發(fā)測試，測試多用戶對某一功能的瞬時請求，主要用于驗證系統(tǒng)是否存在并發(fā)邏輯上的處理問題。此測試也可劃分到不同的壓力測試場景中去，根據(jù)不同的用戶壓力，測試相應(yīng)的絕對并發(fā)，一般取在線用戶數(shù)的10%進行測試；突發(fā)壓力測試，對一些不在預(yù)期內(nèi)的突然壓力進行測試（其實既然想到了，就應(yīng)該是在預(yù)期內(nèi)了）。以銀行門戶網(wǎng)站為例，可能會由于發(fā)布了一條重要消息（政策調(diào)整）而導(dǎo)致訪問量激增，這種壓力是否會導(dǎo)致系統(tǒng)宕機或者暫時無法提供服務(wù)，就是突發(fā)壓力測試需要考慮的了。也有人將此壓力定義為峰值壓力，這就無所謂了，只要考慮到會有這么一個問題就夠了。
上面主要說的是測試內(nèi)容的劃分，也就是說做性能測試時要考慮到的幾個方面。從實際執(zhí)行層面來看，測試的過程一般分為這么幾個階段：
1.測試確認
理解被測系統(tǒng)、尋找測試點、確認測試范圍、測試環(huán)境等。一些重要信息需要同PM、需求人員、設(shè)計人員討論確認，如用戶最常用哪些功能、最關(guān)注哪的性能，程序上哪可能是壓力點，哪些數(shù)據(jù)需要模擬到真實的量級，大體上需要使用哪種測試方法。
2.確定通過標準
性能是好是壞、測試是否通過，必須有明確的標準。這個標準，主要從客戶的期望和業(yè)務(wù)上的需求兩方面來考慮，客戶的期望一般指頁面上的響應(yīng)時間，業(yè)務(wù)需求則是系統(tǒng)的處理能力，一般為吞吐量或TPS（每秒完成事務(wù)數(shù)）。標準制定的不合理，測試結(jié)果可能無法反映系統(tǒng)真實的性能表現(xiàn)，或者會讓客戶無法接受我們認為通過的軟件。
至于具體如何去設(shè)定，是需要同業(yè)務(wù)負責人（一般為PM）和技術(shù)負責人（一般為設(shè)計人員）共同確認的，業(yè)務(wù)負責人了解用戶的實際需求和期望，技術(shù)負責人了解具體的實現(xiàn)，可以判斷哪些是不可達到的要求。
一旦達成了共識，那么測試就要嚴格的按照標準去執(zhí)行。
3.測試設(shè)計
主要從上面提到的幾個方面進行分析，針對系統(tǒng)的特點設(shè)計出合理的測試場景。為了讓測試結(jié)果更加準確，這里需要很細致的工作。如建立用戶模型，只有知道真實的用戶是如何對系統(tǒng)產(chǎn)生壓力，才可以設(shè)計出有代表性的壓力測試場景。這就涉及到很多信息，如用戶群的分布、各類型用戶用到的功能、用戶的使用習慣、工作時間段、系統(tǒng)各模塊壓力分布等等。只有從多方面不斷的積累這種數(shù)據(jù)，才會讓壓力場景更有意義。***將設(shè)計場景轉(zhuǎn)換成具體的用例。
測試數(shù)據(jù)的設(shè)計也是一個重點且容易出問題的地方。生成測試數(shù)據(jù)量達到未來預(yù)期數(shù)量只是最基礎(chǔ)的一步，更需要考慮的是數(shù)據(jù)的分布是否合理，需要仔細的確認程序中使用到的各種查詢條件，這些重點列的數(shù)值要盡可能的模擬真實的數(shù)據(jù)分布（數(shù)據(jù)統(tǒng)計信息、執(zhí)行計劃相關(guān)的內(nèi)容，此處就不細說了），否則測試的結(jié)果可能是無效的。
此外，性能測試執(zhí)行過程中，需要監(jiān)控收集的各種指標數(shù)據(jù)，也需要明確下來。
4.測試環(huán)境準備
部署測試環(huán)境，生成測試數(shù)據(jù)，環(huán)境預(yù)調(diào)優(yōu)等等。
5.測試執(zhí)行、監(jiān)控
準備測試腳本，執(zhí)行之前設(shè)計好的各個用例，監(jiān)控并收集需要的數(shù)據(jù)。
6.問題分析定位、調(diào)優(yōu)
發(fā)現(xiàn)問題或者性能指標達不到預(yù)期，及時的分析定位，處理后重復(fù)測試過程。
性能問題通常是相互關(guān)聯(lián)相互影響的，表面上看到的現(xiàn)象很可能不是根本問題，而是另一處出現(xiàn)問題后引起的反應(yīng)。這就要求監(jiān)控收集數(shù)據(jù)時要全面，從多方面多個角度去判斷定位。
調(diào)優(yōu)的過程其實也是一種平衡的過程，在系統(tǒng)的多個方面達到一個平衡即可。
7.性能報告
將測試過程中記錄的各種數(shù)據(jù)匯總成報告，將各方面需要的結(jié)果清楚的展現(xiàn)出來。
上面所有內(nèi)容中，如果排除技術(shù)上的問題，性能測試中最難做好的，就是用戶模型（或者叫系統(tǒng)使用模型）的分析。它直接決定了壓力測試場景是否能夠有效的模擬真實世界壓力，而正是這種對真實壓力的模擬，才使性能測試有了更大的意義。可以說，性能測試做到一定程度，差距就體現(xiàn)在了模型建立上。
至于性能問題的分析、定位或者調(diào)優(yōu)，很大程度是一種技術(shù)問題，需要多方面的專業(yè)知識。數(shù)據(jù)庫、操作系統(tǒng)、網(wǎng)絡(luò)、開發(fā)都是一個合格的性能測試人員需要擁有的技能，只有這樣，才能從多角度全方位的去考慮分析問題。
當然，對于測試人員來說，技術(shù)能力只是輔助手段，測試思想才是最根本的。敏銳的嗅覺、嚴謹?shù)倪壿嫛⒑侠淼耐茰y、大膽的實踐是一個合格測試工程師的必備要素。
原文鏈接：http://www.cnblogs.com/twocats/archive/2012/02/14/2351748.html
【編輯推薦】
