讓我們考慮以下情況：顯示學生考試結果的系統通過多個自動化功能測試。 性能測試結果也是有充滿希望的。 系統已準備好部署到實時服務器。 但是，當考試結果發佈在系統上時，服務器變慢並停止工作。
發生了什麼？ 考試結果公佈後，所有學生都想盡快查看考試結果。 它們產生了同時非常高的服務器負載，並且服務器無法處理請求。 首先，數據庫機器減慢了。 然後，它沒有爲中間層提供數據，軟件沒有爲這種情況做好準備，所以就停止運行了。
性能測試人員錯過了什麼？ 壓力測試。 除了測試預期的用戶數量之外，壓力測試還會測試系統在強烈負載下的行爲，並檢查如何重新恢復正常使用情況。 壓力測試可以通過像JMeter這樣的開源測試工具輕鬆完成。
Choosing a test scenario
在這篇文章中我們將用於測試的示例應用程序是正在開發的項目管理工具。 目前它有一些基本特點：
- 登錄
- 創建項目並將Github存儲庫鏈接到該項目
- 在創建的項目中創建問題
壓力測試的第一步是確定關鍵場景。 根據自己的業務價值選擇情景（他們對於成功有多重要）和用戶偏好（用戶大部分時間花費的操作）。
在本測試中，我們將檢查網站的登錄頁面和項目詳細信息頁面的響應時間。
響應時間很重要，因爲加載時間是頁面崩掉的主要原因。 隨着互聯網連接速度的提高，用戶的平均耐心正在下降。 如果網站的加載時間超過4秒，大約25％的用戶將離開。
我們選擇了登錄功能，它提供對數據庫的訪問，因爲它是每個系統的重要組成部分。
我們選擇了項目詳細信息頁面，因爲在經過測試的系統中，它從許多表中讀取數據，我們希望用戶將大部分時間花在該頁面上。 因此，我們想確保該頁面是否會在合理的時間內被加載，即使在使用過度的情況下也是如此。
現在我們已經確定了我們的測試目標，我們來描述下他們的測試用例：
測試用例1 - 登錄測試步驟：
- 轉到登錄頁面
- 輸入用戶憑據
- 點擊登錄按鈕
- 等待登錄響應
測試案例2 - 項目詳細信息頁面測試步驟：
- 轉到登錄頁面
- 輸入用戶憑據
- 點擊登錄按鈕
- 加載儀表板頁面
- 點擊現有項目
Creating and recording the test script
在決定測試用例之後，我們可以繼續創建測試腳本。 創建JMeter測試腳本的最快方式是錄製。 您可以使用JMeter錄製或BlazeMeter Chrome擴展程序，這是Chrome商店免費提供的，並且對用戶更加友好，因爲您不必設置代理來使用它，例如使用JMeter刻錄製。
通過Chrome，開始錄製並模擬您決定測試的用戶場景。 完成後，停止錄製。
將文件導出到jmx並在JMeter中打開它，您可以在其中編輯和配置其參數。
Configuring the Thread Group
每個測試都有自己獨特的配置，如csrf令牌，響應斷言和定時器，但幾乎所有壓力測試的相似性都是檢查大用戶量是的系統性能。 您應該根據你的業務目標應確定您正在測試的用戶數。
在這種情況下，我們想測試1000個用戶。
要做到這一點，您需要配置線程組。 線程組最重要的配置是線程數，ramp-up時間和循環數。 線程數設置模擬用戶的數量，ranmp-up時間設置JMeter開始執行所有線程需要多長時間，循環計數是測試場景應執行的次數。
結果顯示，登錄頁面的請求處理時間爲68毫秒，項目詳細信息頁面爲1539毫秒。 因此，我們可以得出結論，在項目頁面加載期間使用了大量資源。
現在，我們可以開始增加我們正在測試的線程數。 我們繼續進行10個線程，0個ramp-up和1個循環。 由於我們仍在測試少量的線程，所以我們可以在GUI模式下使用JMeter，並通過監聽器查看測試。
我們可以看到系統能夠正確處理所有的請求：
所以現在我們將把用戶數量增加到100（目標的10％）。 我們需要更改的腳本中唯一的參數是線程數，我們可以再次運行該腳本。 不要忘記在測試運行之間清理偵聽器，以防萬一你使用它。
之後，將負載增加到目標的50％，在我們的情況下，這是500個用戶。 根據結果，我們可以繼續增加負載（如果測試成功）或下降（如果有錯誤）。 如果我們需要下降，我們應該知道有多少用戶破壞我們的系統，所以我們可以決定如何解決瓶頸。
如果500線程測試的結果都是綠色的，則將線程數增加到1000個用戶的目標。 爲了獲得更準確的結果，我們建議您將測試切換到步進線程組，您可以從JMeter插件管理器添加。
步進線程組允許您配置要啓動多少線程，隨時間推移應該添加多少線程以達到最大值，線程應該保持多長時間以及減速週期多長時間。 由於其ramp-up的能力，步進線程組能完美的檢查系統的恢復力。
該測試開始於我們知道服務器可以處理的500個線程。 然後，我們配置JMeter每30秒增加100個線程。 這樣，如果在達成目標之前有問題，我們可以找出它在哪裏有問題。 我們配置了1000個線程運行2分鐘（120秒）。 要了解系統恢復的情況，有一個ramp-up時間 - 每10秒鐘50個線程將被停止。
在壓力測試期間，在單個機器上可以運行多少線程是有限制的。 但是有幾種簡單的方式來增加這個數字。 嘗試以非gui模式運行JMeter，這在大量線程的情況下是必須的。 我們還應該避免測試計劃中包含監聽器來進一步優化測試運行。 如果這些簡單的調整不夠，請分發多臺機器之間的線程數。 結果可以在測試完成後生成。 當然，您也可以使用CA BlazeMeter，它是雲中的JMeter。
JMeter將爲我們提供響應時間，吞吐量和錯誤率等KPI。 此外，我們還建議您監控服務器性能。 CPU使用率，內存使用量，輸入/輸出和數據庫日誌是確定系統瓶頸的有用參數。
翻譯至：https://www.blazemeter.com/blog/how-perform-stress-test-jmeter