場景設計
1.哪些業務需要做壓力測試？
- 比較常用的業務場景（or 功能模塊）
- 單業務場景/或者多業務場景
- 項目要求做的業務場景
2.壓力測試的並發數是多少？
- 有預期的數值？一次性達到？還是逐步達到？有上次性能測試的結果值？（參考上次的數值） ；
- 無預期的數值？只有參考的在線用戶數（如果沒有預期，沒有參數值，那么只有參考在線用戶數，遵循2:8原則：可以用在線用戶數的20%作為參考去測試）
3.關注哪些參數？
- 響應時間：1s 3s 5s/2s 5s 8s 參考值；在性能測試的結果基礎上，進行有必要的調整
- tps ：越高越好，會有極限值，根據這個結果去做進一步的並發數/腳本的調參，去看tps
- 錯誤率：越低越好 正確率99.99% 不可能達成 90%的正確率可以
- cpu和內存/隊列 磁盤的使用情況：cpu占有率最好不要超過80% 內存最好有20%的空余 隊列<1 磁盤讀寫操作頻率不要過高，若過高，響應時間會變長
目標項目的場景設計：
登錄-投資-登出
核心業務是：投資
並發用戶：目標100
如何設置線程線程數：
線程數：就是並發數，目標100 采取疊加的方式去進行添加
啟動時間：每秒啟動多少個（可以根據結果去進行調整），策略，想要服務器壓力大點就時間少點，想要服務器的壓力慢慢增加就時間長點
循環次數：指定次數 or 永遠（跟下面的持續時間配合使用）
調度器：配合永遠使用，去設置持續時間
Jmeter查看壓力測試結果
壓力測試查看結果：添加聚合報告
需要關注的幾個數據：
Average：平均響應時間—默認情況下是單個 Request 的平均響應時間，當使用了Transaction Controller 時，也可以以Transaction 為單位顯示平均響應時間
Median：中位數，也就是 50% 用戶的響應時間
90% line：90% 用戶的響應時間
Min：最小響應時間
Max：最大響應時間
Error%：本次測試中出現錯誤的請求的數量/請求的總數
Throughput：吞吐量—默認情況下表示每秒完成的請求數（Request per Second），當使用了Transaction Controller 時，也可以表示類似 LoadRunner 的 Transaction per Second 數
壓力測試結果分析
使用Assertion對結果進行簡單的分類
響應斷言：通常是用於對每一個request sampler進行額外驗證的工具
響應時間斷言：規定請求的響應時間不能超過多少毫秒
文件大小斷言：單位bytes
