測試工具：jmeter v_5.2
測試對象：某網站的物料獲取接口，需登錄后操作
測試目的：快速定位該接口最大並發用戶數
思路&步驟：
1.模擬一個場景，某天臨近下班，主管突然過來讓你測下你們網站，一個獲取物料接口的性能，撂下一句“找下它最大的並發數，然后扣扣上跟我說下”。你說你怎么辦，要做的很嚴謹嗎（把軟件，硬件，網絡環境，代碼算法邏輯等因素都放進去），可以這么做，但場景設計的越是復雜，影響性能瓶頸的因素就越多，這樣就越難找到自己想要的結果，等你測試完成，網站可能已經被用戶踩塌了，所以引入RBI測試理念，突出快速。
2.按要求先網站登錄，再調用物料獲取接口，你把腳本整理出來了
注意，登錄的線程組是“setup thread group”，獲取物料的線程組是“Ultimate thread group”
前者是把登錄作為測試前准備來看，后者是為了更好控制接口壓力
正則表達式提取器，為了提取token用於后面接口的操作
BeanShell后置處理程序，為了實現跨線程組參數的傳遞
Http信息頭管理器，為了存儲獲取到的token
固定定時器，為了進一步控制接口壓力
聚合報告，為了用來獲取關鍵的測試結果
3.腳本的框架有了，接下去你就要設計測試場景， “幾秒起幾個用戶，持續操作多久，然后停止操作要花幾秒”
start threads count：並發的用戶數
Initial Delay，sec：延遲啟動的時間
Startup Time，sec：啟動線程的耗時
Hold Load For，sec：持續時間
Shutdown Time：關閉線程的耗時
1.先來個，0秒啟動100個並發，持續一分鍾，然后馬上關閉全部線程，結果你發現，響應時間，吞吐量數據都不好看，說不定還有若干請求報錯了。
原因猜測，壓力太大，請求可能堵在客戶機或者服務端，時間過長，就會超時報錯
2.打算降壓，30秒啟動10個並發，持續一分鍾，然后10秒關閉全部線程，結果你發現，響應時間很短，但吞吐量不高。
原因猜測，壓力太小，服務端還沒開始就結束了
3.再次優化，30秒啟動50個並發，持續一分鍾，然后10秒關閉全部線程，結果你發現，吞吐量有個持續走高的過程，會有浮動，且會出現一個峰值
原因猜測，客戶機在不停給服務端施壓，服務器處於逐漸滿負荷運行的狀態
4.現在你有了一個峰值的吞吐量，以及對應的響應時間，就能得出服務器最優狀態下的最大並發用戶數了，
吞吐量（此處的吞吐量假設等於TPS）X 平均響應時間 ≈ 最大並發數
注意事項：
1.由於主動忽略了很多外部環境因素，最后得出的也應該只是一個大致結果
2.很多步驟我都一句帶過，實際自己操作要多理解
3.這個方法完全是自己理解加上散亂的網上知識點所得出，必定有不合理的地方，非常歡迎不同的聲音進行留言