?
本篇文章主要介紹Jmeter中下載插件（Jmeter ?Plugins）
如何使用監聽器插件，線程組插件，梯度壓測線程組
測試報告需要去關注的數據，怎么看測試報告圖表
目錄
一：插件下載
1：下載地址
2：插件下載
3：下載兩個插件
（1）監聽器插件
（2）線程組插件
4：下載成功的標志
二：梯度壓測線程組（Stepping?Thread?Group）
1：This? group? will? start
2：First? waitfor
3：Then? start
4：Next? add
5：thread? severy
6：using ramp-up
7：Then hold load for
8：Finally , stop
9：threads every
三：測試報告 重要數據
1：TPS吞吐量
2：響應時間
四：運行結果圖
1：啟動運行
2：退出階段
五：全局觀理解測試圖
六：出具測試報告
1：測試報告
2：測試報告分析
（1）響應時間
（2）錯誤率（可靠性）
（3）吞吐量
一：插件下載
1：下載地址
Install :: JMeter-Plugins.org? 附上下載鏈接地址
在壓測場景中，我們通常為?點?點的逐步增加線程數，因此需要安裝新的插件來?持線程數的配置。
通過插件管理?具下載其他插件：將該jar文件放到exe文件夾中后，此時我們的Jmeter工具就支持安裝插件了，重啟
2：插件下載
下載成功的標志，可以看到這個像蝴蝶一樣的圖標
3：下載兩個插件
（1）監聽器插件
點擊Available
（2）線程組插件
這里臨時修改了一下界面顏色，黑色太高冷了，阿華是屌絲
4：下載成功的標志
我們的監聽器中多了很多選項
我們的線程組中多了很多的選項
二：梯度壓測線程組（Stepping?Thread?Group）
重點理解圖上三個打圈的參數 這里指的是 這個線程組中有20個線程，等待0秒后開始壓力測試，一開始有0個線程，每3秒，增加5個線程進來，這5個線程需要在1s內啟動完畢，
以上圖數據為例
1：This? group? will? start
啟動多少個線程，同線程組中的線程數
2：First? waitfor
等待多少秒才開始壓測，?般默認為0
3：Then? start
?開始有多少個線程數，?般默認為0
4：Next? add
指的是下一次要額外增加的線程數量。例如，當前有 10 個線程在運行，設置 Next add 為 5，那么下一次線程數量會增加到 15 個。
5：thread? severy
一組線程（5個）執行完之后，等待3秒后再啟動下一組線程
指的是在一組線程執行完之后，等待多長時間再啟動下一組線程。也就是相鄰兩組線程啟動之間的時間間隔。
6：using ramp-up
這一組（5個）線程，在1秒內均勻的啟動
設置為 1秒，表示在 1 秒的時間內均勻地啟動指定數量的線程。例如，設置線程數為 10 個，ramp-up period 為 1?秒，那么 Jmeter 會在 1?秒內逐步啟動這 10 個線程，平均每秒啟動 10?個線程?
7：Then hold load for
20個線程啟動完成后，一直運行60s?
8：Finally , stop
9：threads every
解讀——每隔1s，結束5個線程，可以看到這邊是直降，與左邊是有區別的
三：測試報告 重要數據
1：TPS吞吐量
全稱Transactions per Second
2：響應時間
這里通常是一個折線圖?
逆天，有時候并發數可能太多，造成莫名其妙的報錯，那就在run一次
四：運行結果圖
1：啟動運行
活躍的線程數折線圖
響應時間——由低變高
吞吐量——整體比較平穩
2：退出階段
活躍的線程數，逐步下降
響應時間——中間部分比較高
吞吐量 老樣子 四平八穩
五：全局觀理解測試圖
對應過來就是下面這條藍色的線。
看第一個紅色方框——我們的響應時間降低，吞吐量就上升了
再看第二個紅色方框——我們的響應時間增大的時候，吞吐量就下降了。
這里其實可以得出——我們的響應時間和吞吐量呈現負相關的關系
這里細心的老鐵會發現最后結束的的時候，為什么響應時間反而激增了呢？這是因為我們有一個線程請求一直沒有得到響應，我們觀察聚合報告，列表頁，有一個最大的請求時間為59s，圖標中的綠色最高峰也可以看出來。
六：出具測試報告
1：測試報告
JMeter測試報告是?個全??詳細的?檔，它提供了關于測試執?結果的詳細信息，幫助??全?評估系統的性能并進?性能優化。這份測試報告也要交給我們的后端開發同學（如果有異常的話）
1：?成性能測試報告的命令
Jmeter -n -t 腳本?件 -l ?志?件 -e -o ?錄
-n ： ?圖形化運?? ? ? ? ? ? ? ? ? （可以理解成后臺運行，有 點像Linux中的nohup操作！）
-t ： 被運?的腳本
-l ： 將運?信息寫??志?件，后綴為jtl的?志?件
-e ： ?成測試報告
-o ： 指定報告輸出?錄
舉例：
開始執行——等待大概1min左右結束
最后生成一個first.jtl日志文件，這個不是重點
重點去我們創建的first文件中查看測試報告
雙擊index.html
靜態數據，其實可以理解成我們的聚合報告
這里還有很多數據展示，在左邊的菜單欄展開。
總結：我們測試人員，做出來測試報告本質上是從宏觀角度去測試項目，去發現問題，但是不能排查問題，具體去解決問題還是我們后端開發人員去做。
2：測試報告分析
我們測試人員主要去干的事情還是要從這三方面進行分析
（1）響應時間
如果響應時間超過了請求，代表系統到了瓶頸，響應時間發生變化的原因——我們的系統不穩定啊，有時快有時慢，隨著并發壓力變大而慢慢變慢，響應時間變高
（2）錯誤率（可靠性）
高并發場景下，系統能否正常處理業務
要求：99.99%可靠? 99.9999%（也就是我們常說的4個9——10w次請求只能出現一次錯誤）
錯誤率高的原因：
①接口請求錯誤
②服務器無法繼續處理請求，達到了瓶頸
③后端系統限流
④熔斷?
解釋：防止因為某個服務的故障而整體崩潰。可以理解成及時止損——比如說給一個場景，電商用戶支付場景，忽然微信支付失敗率激增，超時嚴重，此時我們就先臨時把微信支付這個方式先熔斷掉，先保證我們整體的這個服務還是完好的（先保大頭）
⑤降級
主動關閉一些非核心功能，以確保核心功能正常運行。比如說，某次大型直播，那么直播間顯示的用戶名稱給成一個統一默認的名字
（3）吞吐量
①吞吐量越大，性能越好；吞吐量穩定或者變低，可能系統達到了性能瓶頸。
②吞吐量變化的規律
吞吐量波動很大的話，說明我們系統的性能不穩定；
吞吐量如果是慢慢變大，再趨于穩定，說明我們的并發量在上升，和并發量是強相關的
如果吞吐量慢慢變低，我們的并發量也在慢慢變低，說明我們的性能測試要結束了。
換一個角度，我們并發量在增，吞吐量變低，一般就是系統處理不過來這么多響應了，造成系統卡頓啊什么的。
