我們在性能測試過程中，首先應該去設計測試場景，模擬真實業務發生的情境，然後針對這些場景去設計測試腳本。爲了暴露出性能問題，要儘可能的去模擬被測對象可能存在瓶頸的測試場景。
我在本地部署了一個項目，可以用來模擬考勤打卡
性能測試之前我們要設計一下場景：
業務流程：
打卡首頁--點擊登錄--跳轉項目--打開考勤頁--考勤打卡
業務預期的日常考勤量爲400/min,也就是6.6/s
性能需求指標：
計算出需要加載的線程數：
Thread = BC/(60/t) = BC*(t/60)
t：單用戶單次業務消耗時間，儘可能模擬用戶的真實行爲
單次消耗時間=打開主頁(0.5s)+思考時間(3s)+輸入用戶名密碼(1.5s)+主頁響應時間(0.5s)+考勤打卡時間(3s)=8.5s（90%線）
BC： 業務量，本例 BC=400
單次消耗8.5s
需要的線程數=400*（8.5/60）=56(取整數)
利用jmeter的瀏覽器驅動，獲取用戶訪問的響應整體時間：
設計測試腳本模型：
運行腳本，查看聚合報告結果：
最終結果顯示，吞吐量大約在32/s，符合預期值
併發用戶數C=(400*8.5s)/60=56
併發用戶峯值C1=56+(3* 根號56)=78 在預期範圍之內
上面的性能測試案例我們是利用了業務單次消耗時間和預期吞吐量計算出需要併發的線程數，接下來我們換一種線程組來做另一次實驗。
利用Arrivals Thread Group(預期事物通過線程組)來自動釋放線程數
業務場景的測試腳本保持不變，啓動線程組，觀察釋放的線程數
結果顯示，系統根據需要自動釋放的線程數是55，吞吐量是31/s，和之前我們自己計算得出的結論幾乎一樣。
