如何做WEB端壓力測試?不少答案都提到了測試工具，LoadRunner、PerformanceRunner、Jmeter，這些都是可以的。其實大家選擇工具時可以思考以下幾個問題：什么樣的壓力測試工具能夠在腳本中讓你模擬業務場景中一個用戶的行為？什么樣的工具能夠在場景中讓你模擬業務場景中一群用戶的行為？什么樣的工具能夠讓你模擬用戶所處于的使用環境？什么樣的工具能夠讓你比較方便、快捷的通過它的性能圖表了解Web應用的大致性能表現？

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

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

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

<2秒響應，優秀

<5秒響應，良好

<8秒響應，較差

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

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

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

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

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

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

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

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

測試環境的業務基礎數據必須合理（0年到N年的基礎數據）

測試場景所產生的負載必須合理（代表峰值的負載？代表1.5倍峰值的負載？代表促銷活動的負載？）

一般都是使用工具，可以模擬多用戶 同時/異步地進行比較好的工具，能自動生成圖形報告。這樣你就能判斷出服務器的瓶頸在哪里。是需要增加內存還是提高處理器性能，或者增加硬盤。

推薦閱讀：

實施全鏈路壓測的關鍵點有哪些？全鏈路壓測流程詳解

WEB性能測試怎么做？常用的WEB性能測試工具有哪些？

性能測試工具PerformanceRunner與LoadRunner有什么區別？

案例分享：使用性能測試工具PR對某訪問平臺進行壓力測試