怎樣正確做 Web 應用的壓力測試

關於工具的選擇

不少答案都提到了測試工具，但其實工具並不是最重要的，那麼多的測試工具，HP的是LoadRunner、IBM的是Rational Performance Tester、Apache有Jmeter(免費開源)、還有Borland的SilkPerformer，這些都是可以的。有人提到了Apache的AB，AB不是說不行的，但既然問題是"正確的壓力測試"，那麼還是選擇一個那些容易支撐起複雜業務的性能場景的工具吧。

什麼樣的工具能夠在腳本中讓你模擬業務場景中一個用戶的行為?什麼樣的工具能夠在場景中讓你模擬業務場景中一群用戶的行為?什麼樣的工具能夠讓你模擬用戶所處於的使用環境?什麼樣的工具能夠讓你比較方便、快捷的通過它的性能圖表了解Web應用的大致性能表現?答案肯定不會是那些對某個URL不斷施壓的那些工具。

關於場景的設計過程

我所了解的情況來看，過半數的性能測試人員並不了解自己執行的性能測試場景代表的是用戶生產環境中什麼樣的場景。事實上對於我來說，我也很難正確的說清楚「性能測試」、「負載測試」、「壓力測試」、「可靠性測試」、「配置測試」、「疲勞測試」這些測試的概念。

但我知道，任何一個場景的設計都必須首先明確一些相關的性能指標，這些指標的閾值一旦被超出，那麼場景一般是不必繼續執行的。

關於性能指標我們可以幾個角度來看：

首先是用戶視角的性能指標，一般來說這些指標包括了測試事務的平均響應時間、最大響應時間、90%事務的響應時間、事務響應時間標準差，我們通過著一些指標來判斷用戶實際獲得的性能體驗如何。然後是運維視角指標，點擊率、吞吐量、處理能力、各種硬體資源佔用、運維通過這些指標來了解目前應用的處理能力，通過業務增長了解何時需要進行擴容，還有開發視角的指標，鎖競爭。具體要考慮的視角由項目干係人、關鍵角色定義。

採用的指標確定好以後，再開始為這些指標定義閾值，例如事務的響應時間，也許用戶認為請求在2秒以內得到響應是滿意的，5秒以內響應是一般，超出8秒則會感覺太慢，超出10秒會超出了可容忍的上限，那麼對於這一項指標來說，它的閾值可以是：

<2秒響應，優秀

<5秒響應，良好

<8秒響應，較差

>10秒響應，超出可容忍上線

關於用戶性能體驗的指標一般會劃分為4個級別。硬體指標至少也會劃分2個級別。

系統在任何時候都應該為用戶提供優秀的響應體驗嗎?並不總是，在2倍的峰值負載中，我認為良好、甚至較差的響應體驗也是可接受的。那是不是說在正常的峰值負載中，各項指標表現不在優秀範圍內就是不理想呢?也不一定，要看正常的峰值負載持續時間長短是否合理。

場景的設計不合理最終將可能導致我們面對一堆性能缺陷無法確定處理的優先順序。

場景設計中，重點考慮的問題：

腳本測試數據符合典型用戶的數據差異(測試賬號差異、操作數據差異、提交表單參數差異等)

腳本操作次序符合典型用戶的操作差異(思考時間、業務間間隔等)

腳本執行符合典型用戶的使用環境(瀏覽器緩存模擬、帶寬模擬等)