Jmeter簡單壓測
1、壓測常用組件
1.1 線程組
可以看做一組虛擬用戶，線程組中的每個線程都可以理解爲一個虛擬用戶。線程組組件有三部分組成，分別是取樣器錯誤後要執行的動作、線程屬性、調度器
-
取樣器錯誤後要執行的動作
- 繼續：默認設置
- 啓動下一線程循環：假設一次循環中，樣本有兩個請求，第一個請求遇到錯誤，那第二個請求不再執行
- 停止線程：相當暫停錯誤線程參加併發的隊列，現實中就是用戶遇到系統崩潰後，離開系統操作
- 停止測試：遇到錯誤時，停止樣本數繼續執行，已經開始執行的等待完成後停止測試
- 立即停止測試：遇到錯誤整個測試停止
在3秒內啓動10個線程完成，線程命名（線程1-1，線程1-2…線程1-10），每一條線程會執行所有請求各一次，如果有循環次數，每一條線程會執行重複所有請求N次，最後A請求總樣本數10=B請求總樣本數10。各個線程的創建、啓動、調度順序是隨機的（此時四種狀態是創建–啓動–調度–結束，沒有阻塞哦）
線程數-10，Ramp-up-3,循環次數-永遠，調度持續時間30S，線程組有A請求、B請求
在3秒內啓動10個線程完成，線程命名（線程1-1，線程1-2…線程1-10），每一條線程會執行所有請求各一次，線程組會持續執行30S，記得線程併發是調度功能，每一刻只有一個線程在執行。所以A請求總樣本數10不一定等於B請求總樣本數10 -
線程屬性
-
線程數：虛擬用戶數
-
Ramp-Up Period(in seconds):通俗來講，就是運行設置的線程數所花時間。Jmeter會根據線程數/Ramp-Up算出每秒啓動的線程。
最後，我們還是不知道這個數到底怎麼設置。最好的效果就是，最後一個線程開始時第一個線程真正結束了 -
循環次數：一個虛擬用戶重複發送請求。爲了更好的模擬併發情況，
-
場景模擬
1、線程數-10，Ramp-up=5,循環次數=1，線程組有A請求、B請求
![在這裏插入圖片描述]()
1、線程數=10，Ramp-up=2,循環次數=20，線程組有A請求、B請求。如果仔細一看，發現裏面線程執行順序是無序的。因爲循環，由於線程調度執行完成後，又回到啓動狀態，因爲還有請求執行，又等待下次的調度
![在這裏插入圖片描述]()
-
-
調度器
模式是爲了觀察服務器在一個時間段內，維持某種併發的運行情況。循環次數爲了模擬併發，而不是持續。
1.2 http請求
可以看做一組虛擬用戶的操作行爲（一般是指事務）
請求報文格式：
＜ request-line ＞
＜ headers ＞
＜ blank line ＞
[ ＜ request-body ＞]
1.3 斷言
1.4 察看結果樹
顯示所有請求響應的樹，通過它可以查看任何請求的響應。
1.5 分析聚合報告
-
參數的意義
Samples:請求數
Average:平均數反映現象總體的一般水平,或分佈的集中趨勢。如下圖的分佈圖一樣，平均數就是大部分的數據集中的範圍，反應總體的水平
![在這裏插入圖片描述]()
Median:中位數是響應事件快慢排序後的一組數據的中間數，在性能測試中有參考意義，知道一半的數小於中位數，一半的數大於中位數
90% Line:第百分之90的耗時在這個時間以內，剩下10%的耗時至少比這個時間長。
95% Line:百分之95的耗時在這個時間以內，剩下5%的耗時至少比這個時間長。
99% Line：百分之999的耗時在這個時間以內，剩下1%的耗時至少比這個時間長。
Min:最慢的響應時間
Maximum:最大的響應時間
Error %:錯誤的請求
Throughput:吞吐量。吞吐量是指單位時間內系統處理的請求數量，如果直接測試請求數量，沒有實際意義。一般用設置成事務（多個請求）測試吞吐量
Received KB/s:每秒接受服務器的數據量，KB單位
Sent KB/s：每秒發送到服務器的數據量，KB單位 -
聚合報告分析策略
1、平均數可以反應出總體的水平，容易受到個別極端數的影響
2、中位數可以結合最小數，判斷一半數據分佈情況；
3、中位數結合90%、95%、99%Line，可以判斷程序哪個階段極速上升
4、極速上升再結合Maximum -
用表格查看結果
startTime：線程執行時間
Sample Time(ms)：響應時間
Latency：發送第一個請求到第一個響應時間。考慮TCP的重發機制
Connect Time:TCP三次握手時間
壓測演示
壓測的策略壓測不要一上來就負載服務器，不符合現實情況，一般用平均點擊率（程序中埋點獲取這個數據）持續壓測服務器，然後持續加壓
壓測的流程
新建線程組—>新建http請求—>添加斷言—>察看結果樹—>查看聚合報告—>分析聚合報告
需求：