一、測試需求：測試20個用戶訪問網站在負載達到30QPS時的平均響應時間
二、QPS：Query Per Second 每秒查詢率。（一臺查詢服務器每秒能夠處理的查詢次數，作爲域名服務器的性能經常用每秒查詢率來衡量）
三、測試步驟
1、添加線程組（線程數+準備時長+循環次數）
1）線程數：虛擬用戶數，一個虛擬用戶佔用一個進程或線程（設置多少個虛擬用戶=設置多少個線程）
2）準備時長（s）：設置的虛擬用戶數需要多長時間全部啓動。eg：線程數爲20，準備時長爲10，則說明需要10秒鐘啓動20個進程。
3）循環次數：每個線程發送請求的次數。eg：線程數爲20，循環次數爲5，那麼每個線程發送5次請求，總請求數爲20*5=100
————————————————
版權聲明：本文爲CSDN博主「學習那點事兒」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/u010013191/article/details/80957278
2、添加HTTP請求
3、設置QPS限制：控制給定的取樣器發送請求的吞吐量
4、添加監視器-聚合報告、察看結果樹
5、運行腳本
6、聚合報告解析（響應時間單位：毫秒）
1）Label：每個Jmeter的element都有一個Name屬性，這裏顯示的就是Name屬性的值
2）#Sample：表示你這次測試中一共發出了多少個請求，如果模擬10個用戶，每個用戶迭代10次，那麼這裏顯示100
3）Average：平均響應時間-默認情況下是單個Request的平均響應時間當使用了Transaction Controller 時，也可以以Transaction爲單位顯示平均響應時間
4）Median：中位數，50%用戶的響應時間
5）90%Line：90%用戶響應時間
6）Min：最小響應時間
7）Max：最大響應時間
8）Error%：本次測試中出現錯誤的請求的數量/請求的總數
9）Throughput：吞吐量-默認情況下白石每秒的請求數
10）KB/sec：每秒從服務器端接收到的數據量
當然，報告中的吞吐量是10QPS，並沒有達到30QPS，小白我猜測：Constant Throughput Timer只有在線程組中的線程產生足夠多的request 的情況下才有意義，因此，即使設置了Constant Throughput Timer的值，也可能由於線程組中的線程數量不夠，或是定時器設置不合理等原因導致總體的QPS不能達到預期目標。