Jmeter實例

       咱們在性能測試過程當中，首先應該去設計測試場景，模擬真實業務發生的情境，而後針對這些場景去設計測試腳本。爲了暴露出性能問題，要儘量的去模擬被測對象可能存在瓶頸的測試場景。

　　我在本地部署了一個項目，能夠用來模擬考勤打卡

性能測試以前咱們要設計一下場景：

業務流程：

打卡首頁--點擊登陸--跳轉項目--打開考勤頁--考勤打卡

業務預期的平常考勤量爲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，和以前咱們本身計算得出的結論幾乎同樣。