假設一個內部系統要求響應時間在 3s 以內，支持最大用戶數為4萬。根據二八原則，80%用戶在20%時間使用系統(4w80%)/(24h20%)≈1.9點擊/秒。并發數=TPS（運行時間+思考時間）=1.9（3+0.5+0.3+3+0.5+0.3+0.5+3）=21。

注意：二八原則計算的結果并非是并發數，而是系統要達到的處理能力（吞吐量），初學者容易被誤導，拿著這個數據就去設置并發數，這是錯誤的哦。如果你的系統性能要求更高，也可以選擇一九原則或更嚴格的算法，二八原則比較通用，一般系統性能比較接近這個算法而已，大家應該活用。

基于以上，如果我們通過測試得到的最大吞吐量大于計算出來的吞吐量（TPS≈1.9），且各項性能指標均達標，那么系統就是安全的。如果用戶發帖遵循正態分布，那么并發請求數峰值還肯定會大于上述估算的吞吐量（并發數大于吞吐量）

01場景設計

場景編號：001 - 基準測試

目的：驗證測試環境、驗證腳本，得到系統的性能基準，為后續測試提供參考。

場景編號：002 - 配置測試

目的：優化配置，測試當前軟、硬件配置是否能夠滿足性能指標。

場景編號：003 - 負載測試

目的：分析性能變化趨勢，找出性能瓶頸與風險，對系統進行定容定量。

場景編號：004 - 穩定性測試

目的：長時間（>8小時）運行大量負載，確定系統軟硬件環境是否運行穩定。

02場景實現

1、單線程組實現測試場景

假設業務比例為 “查看詳情(8)：登錄(6)：新建任務(4)：(配置任務)2：(刪除任務)1”。差不多每3個登錄會有4個查看任務，新建2個任務，配置1個任務；每6個登錄，刪除1個任務。

我們使用 If邏輯控制器 + ${__counter(arg1, arg2)}函數來實現。

• 新建任務的If控制器條件：登錄(3)/新建(2)
  ${__counter(true,i)}%2==1||${__counter(true,i)}%3==0
• 配置任務的If控制器條件：登錄(3)/配置(1)
  ${__counter(true,i)}%3==0
• 刪除任務的If控制器條件：登錄(6)/刪除(1)
  ${__counter(true,i)}%6==0
• 查看任務：因為配置和刪除操作包含查看的業務，所以單獨的登錄/查看比為6：(8-2-1)，即6:5。
  ${__counter(true,i)}%5!=0||${__counter(true,i)}%6==0

2、多線程組實現測試場景

多線程組的場景設計需要注意的是業務關聯關系。比如查看任務可以不需要登錄的；新建、配置、刪除任務都需要登錄且并發數的和大于登錄，說明有些場景是登錄后執行了多業務的；查看詳情的并發數小于登錄，所以有部分用戶可能是登陸后只查看了詳情。

按照 “查看詳情(8)：登錄(6)：新建任務(4)：(配置任務)2：(刪除任務)1” 的比例，以及用戶實際使用場景來算，得到如下場景：

• 登錄(2)-新建任務(2)
• 登錄(2)-新建任務(2)-配置任務(2)-查看詳情(2)
• 登錄(1)-查看詳情(1)-刪除任務(1)
• 登錄(1)-查看詳情(1)
• 查看詳情(4)

兩種腳本實現方式的對比：

03測試執行

場景編號：001 - 基準測試

基準測試采用單用戶、單業務場景的執行方式。測試時間盡可能長，盡量執行多次（通常建議3次以上），取相對穩定的結果，目的是統計響應時間的取樣更多，測試結果越準確。對于發現的異常，如果不熟悉就請開發團隊告訴你有哪些作業任務，這些作業任務的頻度是否適中。

基準測試_聚合報告

基準測試_ResponseTime

基準測試_TPS

結論：

滿足性能需求3s以內，事務正確率100%，且CPU、內存、磁盤表現正常（局域網不考慮網絡影響）。測試環境檢查通過，腳本檢查通過，可以考慮對系統進一步的測試。

場景編號：002 - 配置測試

先確定配置測試的目標：

• JVM配置
• Tomcat線程池配置
• 數據庫連接池配置
• 數據庫的一些配置

配置測試場景一般為混合場景（多個業務同時執行）

• JVM Heap大小及不同代的大小指定？Heap回收算法的選擇？（P316）
• Tomcat線程數配置？
• 數據庫緩存、臨時表空間，大表水平切分，主從結構、讀寫分離、主從備份、主主備份等？

配置測試_聚合報告

配置測試_ResponseTime

配置測試_TPS

結論：

隨著并發數的增加，響應時間也逐漸增加，但仍然滿足3s以內的性能指標；事務正確率100%；查看詳情、登錄、新建任務、配置任務、刪除任務各業務之比接近6:8:4:2:1；TPS未出現明顯拐點；CPU、內存、磁盤均正常。性能表現能夠滿足需求，系統性能瓶頸風險在CPU。

場景編號：003 - 負載測試

負載測試在滿足系統性能指標的基礎上進行測試，尋找性能的拐點。負載測試分為單場景與混合場景。

• 單場景有利于分析性能問題，因為排除了其他業務干擾；
• 混合場景更貼近用戶實際使用習慣，是一個綜合的性能評估。

建議先做單場景測試，再做混合場景測試

我們一般采用二分法，如總的線程數遞增為21/42/84，當發現線程增大后性能降低，再對該區間進行二分嘗試，最后對拐點附近精細嘗試得到最大吞吐量

負載測試_聚合報告

負載測試_ResponseTime

負載測試_TPS

負載測試_CPU

結論：

執行過程中，CPU首先出現性能瓶頸，利用率接近100%。響應時間開始大于3s，TPS降低，出現失敗的事務。此時的內存、磁盤、網絡均表現正常。此時應優先解決CPU的瓶頸問題，再反復進行負載測試，直到在沒有硬件瓶頸的條件下找到系統的性能拐點。

場景編號：004 - 穩定性測試

穩定性測試在正常性能閥值下盡量加大負載。什么是閥值呢？

比如響應時間要求3s以內，3秒就是閥值；比如CPU利用率70%以下，70%就是閥值。假設滿足性能要求的負載是B，那么穩定性測試時負載一般是1.5B~2B。

在此案例中我們滿足性能需求的并發量是21，那么在做穩定性測試時，并發量應該是1.521~221即32~42之間。運行時間原則上越長越好，慣例要求不低于8小時。有些隱藏較深的諸如內存溢出的問題是需要長時間運行才能反映出來的。如果各項性能指標都在閥值內，且性能表現平穩，則可以認為通過穩定性測試。

除了分析響應時間、TPS和服務器硬件性能外，我們也要關注JVM內存回收情況，MySQL有無慢查詢等。

原文鏈接：百度安全驗證