很多朋友接觸效能測試是從工具開始的，比如流行的JMeter、Loadrunner等。熟悉一個測試工具，有助於對效能測試的過程、方法和機制有個直觀的理解。
我們知道，無論是什麼型別的測試，其目標不外乎兩個，一是為了證明系統滿足當初的定義（Requirement）；二是儘可能早、儘可能多地發現潛在的問題（Defect）。工具是為解決特定問題而服務的，其使用是相對簡單和可控的，在效能測試中，方案設計則顯得更為關鍵。
通常，我們在做效能測試方案設計時，會從以下幾個角度去思考。需要知道的是，它們之間並不是割裂的，會有交叉，界限也並不那麼明顯。
| 編號 | 名稱 | 描述 |
|---|---|---|
| 1 | 效能指標 | 系統在常規的工作負荷下，各項效能指標是否滿足當初界定的要求。比如響應時間不能超過多少等。 |
| 2 | 資料容量 | 可預期的未來時間內，資料量的大幅增長可能引發的效能瓶頸。 |
| 3 | 能力評估 | 單位資源、時間內，系統可處理的業務訪問量。可用於測試（模擬）環境到生產（實際）環境的軟硬體資源按比估算。 |
| 4 | 壓力測試 | 驗證系統在超正常負載情況下的效能表現，發現哪裡最容易產生問題。可據此評估系統效能短板和不同型別軟體硬體資源的配比。 |
| 5 | 疲勞測試 | 長時間施加一定量的負載，驗證系統是否會出現諸如記憶體洩漏、網路擁堵等長效才會激發的問題。 |
| 6 | 強度測試 | 驗證系統在高強度、資源極度匱乏的情況下，依然可以正常工作，未發生崩潰、重啟，處理能力急劇下降，以及資料不一致等嚴重問題。 |
講到測試場景的設計，就離不開業務上的分析，可嘗試回答以下幾個問題：
- 系統的使用者規模有多大？
- 在可預期的未來，資料量會到達多少？
- 各業務子系統、功能模組，分別需承受多大訪問量？
- 在特定的日期或時間，是否存在某些業務的峰值？
- 按照現有的架構設計和資源配比，可能的瓶頸在哪裡？
在效能測試設計的過程中，需逐步明確和落實以下幾個方面的內容：
- 確定測試系統中的註冊使用者和同時線上使用者數；
- 通過註冊和同時線上使用者數，推匯出併發虛擬使用者數；
- 不能確定的，三個使用者數之間可先按十分之一的比率來演算；
- 選擇測試的介面，確定各自所需支援的每秒訪問量；
- 設計3個以上綜合業務場景，包括其中各介面請求量的佔比；
- 針對資源消耗大的業務，如檔案讀寫、網路傳輸、AI訓練等，重點進行測試；
- 根據經驗預測容易出問題的地方，單獨設計測試場景；
- 確定各場景下的思考時間、執行時長、加壓策略等測試引數配置；
- 綜合考慮服務環境因素，如硬體、網路、（微）服務例項數、是否有負載均衡等；
- 確定測試工具和環境，如加壓機器數量、測試工具配置等。
最後，確定測試中需要度量的效能指標，可包括：
- 吞吐量(Throughput)
- 每秒查詢率（QPS）
- 響應時間(RT)，包括平均、最大、最小、正態分佈的值。
- 請求失敗率、超時率、業務處理錯誤率
- 系統指標，如CPU、記憶體、網路等