(1)測試應用程序的可靠性
在系統崩潰后總結之前失敗的壓力測試時，我忽視的第一個要點就是沒有測試出應用程序在壓力下的可靠性。壓力測試除了對每個單獨的組件進行壓力測試外，更應該對帶有其所有組件和支持服務的整個應用程序進行集中壓力測試，以檢查在巨大的工作負荷時，應用程序在峰值情況下是否可靠的執行操作。例如，當實際情況是平均每秒出現1個或2個中斷的情形下，應當對每秒出現10個中斷的情形來進行特殊的測試;又或者把輸入數據的量提高一個數量級來測試輸入功能是否可靠的響應。從本質上來說，壓力測試是想要看在最大極限時程序是否可靠的運行。
(2)測試應用程序的并發性能
進行壓力測試需要對實際的并發訪問量有一個正確的預期估算，否則在負載遠遠大于事前預測的壓力下系統將脆弱得不堪一擊。導致系統崩潰的因素有很多，處理能力、存儲速度、響應時間、網絡帶寬等無論哪部分出現短板擁堵、后果都可能導致全盤崩潰。
現在我明白，哪怕硬件條件達到了，如果軟件的并行處理能力不足將會導致等候隊列過長，響應時間變慢，系統崩潰也只是時間問題。簡單說就是：壓力測試是考察當前軟硬件環境下系統所能承受的最大并發負荷，并幫助找出軟件程序的瓶頸所在。
(3)測試應用程序的最大負載能力
壓力測試的目的之一是找出應用程序能夠支持的最大客戶端數。通過多次的運行和對測試結果中正在運行用戶數與錯誤用戶的對比，然后根據可接受錯誤率就可得到該功能的最大負載訪問的用戶數。最大負載壓力測試用來評估在超越最大負載的情況下系統將如何運行，這時的目標是要發現在高負載的條件下應用程序的缺陷(Bug)，例如內存泄漏等。因此，最大負載能力不但是應用程序一個重要的技術指標，也是客戶評估和驗收軟件的一個關鍵指標。
如何進行高效的壓力測試?
軟件測試有兩句通俗的話：開發是盡可能地讓程序通過;而測試則是盡可能地讓程序通不過。對于壓力測試而言，測試效果好不好，測試計劃的好壞是關鍵。所以，針對不同的情況，分析后有針對的進行測試，比起拿槍亂打、無的放矢顯然要高效得多。
進行一次切實可行的壓力測試并不像乍看之下那么簡單，遇到的問題也可能非常微妙。例如，我的測試團隊就經常遇到諸如“客戶端每小時將要處理100個客戶訂單請求”等此類的需求，于是測試團隊就試圖把該需求轉化為某種測試需求，執行這種測試需求的常見方法就是以死循環的形式對服務器進行反復請求，然后靜觀其效。然而，通常事情進行得并不順利，原因在于這只是把需求表面化了，沒有分析出測試需求的本質。高效的壓力測試應遵循以下這幾個步驟：
(1)確定測試目標
在確定壓力測試目標中，我們要定義測試的對象，并對每一個測試對象給出清晰說明，也要定義測試結束的目標。為控制測試的有效性以及完成程度，必須定義準則和策略。準則必須是客觀的，可量化的，而不能是經驗或感覺。例如壓力測試目標可能是測定終端用戶處理事務的響應時間，它可能隨用戶的增加而增加，但要定義一個可接受時間。在確定壓力測試目標過程中，最好能邀請客戶、設計人員等一同對測試目標進行評審。
(2)制定壓力測試計劃
測試計劃內容包括：定義測試資源、制定測試進度表、選擇測試工具等。制定測試計劃的目的是使壓力測試有章可循并得到人力、物力等各方面的保證;在制定測試進度表時應考慮和開發進度相互協調;對于測試工具的選擇應以滿足測試目標為前提。所以，這并不是說測試工具提供的功能越多就越好，在實際的選擇過程中適用才是根本。
(3)編寫測試案例和設置測試數據
測試人員一般是根據測試案例進行實際的測試工作，因此測試案例的編寫應做到客觀全面、重點突出，也就是要求編寫的測試案例應該盡可能模擬真實的負荷，不遺漏重要的測試內容。為了讓所有的測試順利執行，可采取數據驅動方式進行，同時應該對測試數據進行參數化。另外，一般不提倡在開發環境中進行壓力測試，最好是另外構建測試環境。
(4)結果分析及測試報告
壓力測試運行結束后，應把所有的數據匯總并記錄到文件中，以方便對測試結果進行分析和得出結論。若測試失敗，應先分析失敗原因，如果是軟件系統造成的，應返回給設計人員修改。如果測試結果不滿足預期需求，應先對軟件程序進行優化調理，然后再次運行測試，直到可以滿足預期需求或調整已無法改善結果。
最后需要注意的是測試報告。報告應包括測試提要、測試環境和測試結果。提要應簡單說明測試方法、策略、范圍、內容;測試環境應包括資源開銷、環境配置等;測試結果必須包括測試是否通過或拒絕，并要對測試結論進行說明，并對軟件程序的性能做出評價。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
