JMeter - 利用 Ultimate Thread Group 的 Threads Schedule 配置壓測場景計劃

性能測試最關鍵的一個方面是可以模擬應用程序的實際負載。可是，肯定目標負載的併發用戶數是不夠的。在測試階段使用的相同目標負載下，通過測試的應用程序可能會失敗。或者當問題是系統中的瓶頸時，應用程序可能會在測試負載下失敗。發生這些事情是由於除了目標負載以外，開發人員和性能測試人員還應該關心在測試執行期間如何分配負載也就是模擬各類負載壓力場景。

JMeter的Ramping-Up

雖然有不少JMeter的參數負責負載分配（好比Number of threads'線程數'，Loop Count'循環次數'或Duration'持續時間'），但其中一個參數可能不是那麼容易理解，而且它的適當值參數可能並不老是很明顯。 此參數稱爲ramp-up斜坡上升。

Ramp-up是JMeter將全部users (threads)"測試用戶（線程)"添加到測試執行所需的時間。 或者換句話說， JMeter開始執行全部線程須要多長時間。

例如：

• 1000個目標線程，加速1000秒：JMeter將每秒添加一個用戶
• 1000個目標線程，持續100秒：JMeter每秒將增長10個用戶
• 1000個目標線程，50秒加速：JMeter每秒將增長20個用戶

在本文中，咱們將重點介紹如何應用JMeter的Rame-up斜坡上升來模擬咱們應用程序的不一樣負載狀況也就是相似Loadrunner中的壓測場景配置。

配置JMeter壓測場景

咱們將測試某一web網站。 咱們將應用具備相同目標線程值的各類負載，但具備不一樣的上升週期組合。

1.建立一個具備目標線程數的線程組（假設爲100）。
右鍵單擊 - >添加 - >線程 - >線程組
將線程數的值更改成100.如今讓咱們假設您要運行咱們的測試5分鐘。 所以，您須要在Duration「持續時間」字段中指定值300。 如今，讓咱們將線程組中的「Ramp-Up Period」字段保持爲空。

 

2.添加一個訪問Web主頁的HTTP Request Sampler "Http請求採樣器"。 
右鍵單擊Thread Group - > Add-> Sampler - > HTTP Request
我將其名稱更改成「BlazeDemo home page」。 添加「blazedemo.com」做爲服務器名稱，並確保將該方法設置爲GET。

 

3.查看包含用戶分佈的圖表。 
這樣的圖表能夠幫助咱們可視化負載模式並檢查咱們要測試的內容。 JMeter不提供開箱即用的這些選項，但您能夠輕鬆安裝「自定義插件包」，其中包含許多有用的偵聽器（可經過Jmeter-GraphsGeneratorListener此連接找到安裝說明）。 其中一個插件被稱爲"Active Threads Over Time"。 添加該偵聽器：
添加 - >監聽器 - > jp@gc - Active Threads Over Time

 

請記住 ，若是您有大量目標線程，則加速期不該爲0。 Ramp-up 0意味着性能腳本將在測試執行開始時當即添加全部線程，所以它會當即給您的應用程序帶來很是嚴重的負載。

固然，有時您可能但願模擬此類負載，例如在Spike performane test "峯值測試"期間，但這是一個單獨的案例，具備單獨的最佳實踐方法（在下面介紹）。 但即便使用峯值測試，咱們一般也不但願全部用戶都在測試的第一秒當即執行。

 

這種狀況看起來並不符合實際狀況，一般這種負載加壓沒有任何意義。 若是您有一個Web應用程序，用戶一般會或多或少地逐漸訪問您的站點，而且您的服務器有足夠的時間進行適當的調整和擴展。

加速分配應根據您的需求而定。 所以，首先須要作的是瞭解您的測試目標。 最好的方法是從生產環境中學習並找出當前網站的負載模式。 但與此同時，在許多狀況下，它足以建立一個線性加速，顯示用戶逐漸進入您的網站或應用程序。

建立線性負載加速

1.返回線程組並將Ramp-Up週期更改成120。

由於測試持續時間是300秒，因此在2分鐘內加速，咱們有3分鐘的保持時間。 重要的是，在加速結束而且全部用戶都啓動並運行以後，有足夠的保持時間。 保持時間確認系統能夠處理負載而且性能保持穩定且不會惡化。

在這個測試中，咱們肯定了3分鐘的保持時間，但在您的狀況下，全部這些值都將基於您的特定需求和您要模擬的場景。

 

2.運行測試，查看活動用戶數量如何逐漸增加2分鐘。

 

這種負載稱爲Linear「線性」。 這種方法適用於主要關注目標負載的許多用戶。 可是,這種方法不是最佳實踐。 爲何？ 由於若是服務器在線性加速期間在某個負載下表現不佳，一般很難隔離並肯定哪一個負載。 咱們不清楚咱們的服務器能夠處理哪些負載以及哪些負載不能處理。

這就是爲何按步驟執行加載要好得多。 因此讓咱們將測試持續時間分紅幾個階段。

建立步進負載加速

咱們仍然想測試100個用戶，但咱們會逐步逐步提高他們。 咱們將從25個持有一段時間負載的用戶開始，看看服務器如何處理它。 以後咱們將增長25個到50個，另外25個到75個，最後25個到100個用戶。 這種方法效果更好，更可靠。

不幸的是，JMeter不支持開箱即用的步進加載步驟。 可是您能夠輕鬆安裝名爲Ultimate Thread Group終極線程組的相應插件。 此插件爲您提供了很是強大的控制線程組加壓負載能力和靈活性，能夠爲您的測試應用程序模擬各類負載場景。

1. Ultimate Thead Group 相似於默認的'Thread Group'JMeter元素，能夠經過如下方式找到：

右鍵單擊左側的元素選項卡 - >添加 - >線程（用戶） - >jp@gc - Ultimate Thread Group

 

2.在建立'Ultimate Thread Group'元素以後，咱們能夠從最初的'Thread Group'複製咱們的'BlazeDemo home page'請求採樣器和'Active Threads Over Time'監聽器。

 

3.Ultimate Thread Group提供了一個'Threads Schedule' 線程計劃表，您能夠在其中配置不一樣的線程組。 您能夠決定線程數量（'Start Threads Count'），每組開始添加到測試執行以前的延遲（'Initial Delay，sec'），線程組的加速期（'Startup Time'） ，sec'），在減速前線程組的持續時間（'Hold Load For，sec'）以及指定全部線程組應該關閉的速度（'Shutdown Time'）。 全部線程組同時啓動，但每一個線程組都有本身的Intial Delay「初始延遲」值，這有助於分別從每一個組中分離用戶。

Ultimate Thread Group「終極線程組」插件的另外一個重要功能是，您能夠在下圖中看到預期的負載分佈，並根據您的須要調整分配值，甚至在運行腳本以前而且沒有考慮到棘手的計算。

讓咱們將測試分爲4個步驟，每分鐘增長25個用戶。 在這種狀況下，咱們的'Threads Schedule' 線程計劃表將以下所示。

 

Spike Testing峯值測試

這種負載靈活性可能有用的另外一個很好的例子是峯值測試。 基本上，峯值測試是一種性能測試，其中應用程序在乎外的增量和負載減小下進行測試，以查看它在這種狀況下的行爲以及是否可以處理這種峯值。 讓咱們調整咱們的'Threads Schedule'來模擬某種峯值測試。 要模擬該模式，咱們須要使用Shutdown Time「關閉時間」列來負責線程減速。

 

總結

這樣利用Ultimate Thread Group的Threads Schedule配置壓測場景計劃,就能夠作到和Loadrunner 同樣的負載加壓策略了

跟你們推薦一個學習資料分享羣：747981058，裏面大牛已經爲咱們整理好了許多的學習資料，有自動化，接口，性能等等的學習資料！人生是一個逆水行舟的過程，不進則退，我們一塊兒加油吧！