Jmeter各類線程組詳解

Jmeter各類線程組詳解

作者:牛劉源

瞭解JMeter的朋友都知道,它不僅能做簡單的接口測試、還支持性能測試,接口類型不僅支持Rest、SOAP,也可擴展WebSocket、Socket等。無論你用Jmeter做哪種測試,哪種接口類型,哪種網絡協議,你都必須添加使用Jmeter線程組,線程組在Jmeter中佔據主導地位,它是任何一個測試計劃的起點,所有的邏輯控制器、採樣器、處理器、報告等都必須放在線程組之下,也就是說你若使用Jmeter做接口測試或性能測試那麼,線程組是必不可少的。本文分爲三個方面爲大家介紹Jmeter的線程組,主要從:線程組介紹、線程組設置、線程組分類三方面來闡述。

一、線程組介紹:

線程組元件是任何一個測試計劃的開始點。在一個測試計劃中的所有元件都必須在某個線程組下。所有的任務都是基於線程組:

通俗理解:

· 線程組:就是一個線程組,裏面有若干個請求;

· 線程:一個線程就是一個“虛擬用戶”;

· 請求:一個線程組裏面有若干個請求。

對應關係:

例如:1個線程組裏面有10個請求,線程數爲10個,跑完後得到:

理解爲:(10個線程數)10個人,每個人都要跑這10個請求,所以:10*10=100:

併發數:100;線程數:10;

PS:線程組也可以看作是一個虛擬用戶組。線程組中的每一個線程都可以理解爲一個虛擬用戶。

二、線程組設置:

我們把線程組的設置分成3個區域:

區域一:在採樣器失敗後怎麼處理(LoadRunner裏面也有類似的運行設置選項,對比去學習):

1、continue:繼續執行接下來的操作;

2、Start Next Thread Loop:開始下一次循環;

3、stop Thread:停止線程,退出該線程(不再執行此線程的操作);

4、stop Test:等待當前執行的採樣器結束後,結束整個測試;

5、Stop Test Now:馬上停止測試;

區域二:線程屬性:

1、Number of Threads(users):線程數,相當於模擬的用戶數量;

2、Ramp-up Period(in seconds):達到指定線程需要的時間,例如線程數爲100,時間設定爲10s,那麼就是10s加載 100個線程,每秒啓動的線程數=100/10=10;

3、Loop Count:如果填具體的數值,就是循環對應的次數;如果選擇“Forever”,則一直執行下去,直到手動停止;

4、Delay Thread creation until needed:延遲線程創建,直到需要才創建。

區域三:調度器配置:

需要選中調度器(scheduler),調度器配置才生效。

【實例】現用一個普通的線程組測試一個簡單的http接口測試,測試前添加設置下線程組及其他元件:

第一步:添加一個線程組,添加後選擇採樣器因接口、報文或外部等原因導致接口執行錯誤後的一個後置行爲,對於各個選項多選一,目前我選擇接口執行錯誤後讓其繼續執行。

第二步:因爲非性能測試所以線程組設置1即可,即是單個“虛擬用戶”。

第三步:關於調度器配置不同版本的Jmeter會有不同的改動,目前Jmeter版本V5.1.1調度器配置在原有的基礎上容易理解和執行,使用調度器器之前需“開啓”調取度按鈕(點擊打勾即可),按照功能提示選擇接口的啓動延遲時間和持續時間。注意:使用調度器後中間循環次數則作廢。

第四步:添加http請求並設置域名、路徑等並填入請求報文;(添加路徑:線程組→添加→取樣器→HTTP請求)

第五步:添加HTTP信息頭管理器,用於存儲request的head部分,並寫入對應接口的request的head部分:(添加路勁:線程組→添加→配置原件→HTTP信息頭管理器)

最後就可以添加察看結果樹,然後點擊運行就可以看到結果了!(添加路徑:線程組→添加→監聽器→察看結果樹)

三、線程組分類:

從系統的角度來看,Jmeter的線程組主要分爲系統原生線程組和可拓展線程組。原生線程組配合調度器、定時器、前後置處理器和邏輯控制器等等已經可以滿足大部分測試的需求,但是若要求多維度來設計用戶併發數,原生線程組已經不能滿足需求。此時,我們可以新增插件的線程組使其更加強大,可自定義設置多種場景等功能,可以更加接近真實用戶的使用場景。

(一)原生線程組

1、thread group(線程組):

這個就是我們通常添加運行的線程。通俗來講一個線程組,可以看做一個虛擬用戶組,線程組中的每個線程都可以理解爲一個虛擬用戶。上文所介紹使用的例子就是此線程組。

2、setup thread group(設置線程組):

一種特殊類型的ThreadGroup的,可用於執行預測試操作。這些線程的行爲完全像一個正常的線程組元件。不同的是,這些類型的線程執行測試前進行定期線程組的執行;類似LoadRunner的init,測試開始時進行初始化的工作。

不同的是執行順序---它會在普通線程組執行之前被觸發。

應用場景舉例:

A、測試數據庫操作功能時,用於執行打開數據庫連接的操作。

B、測試用戶購物功能時,用於執行用戶的註冊、登錄等操作。

3、teardown thread group(拆線組):

一種特殊類型的ThreadGroup的,可用於執行測試後動作。這些線程的行爲完全像一個正常的線程組元件。不同的是,這些類型的線程執行測試結束後執行定期的線程組;類似LoadRunnner的end,測試結束時進行回收工作。

不同的是執行順序---它會在普通線程組執行之後被觸發。

應用場景舉例:

A、測試數據庫操作功能時,用於執行關閉數據庫連接的操作。

B、測試用戶購物功能時,用於執行用戶的退出等操作。

(二)可拓展線程組

1、Concurrency Thread Group(遞增式併發線程組)

這個可以模仿遞增式併發(只能遞增不能遞減),並可設置遞增次數、遞增時長、到達目標遞增數量保持時長等等:

參數解釋:

· Target Concurrency:目標併發(總線程數)

· Ramp Up Time:加速時間(總加速時長)

· Ramp-Up Steps Count:加速步驟計數(總加速/遞增次數)

· Hold Target Rate Time:保持目標速率時間(到達總線程數後持續時長)

· Time Unit:時間單位(分鐘或者秒)

· Thread Iterations Limit:線程迭代次數限制(循環次數)

· Log Threads Status into File:將線程狀態記錄到文件中(將線程啓動和線程停止事件保存爲日誌文件);

現設計這樣一個場景:

這意味着:

3分鐘除以5步,每步0.6分鐘;100個用戶除以5步,每步20個用戶;每0.6分鐘將添加20個用戶,直到達到100個用戶,達到100個線程後,所有這些線程將繼續運行,並一起打到服務器6分鐘;

2、Stepping Thread Group(逐步線程組)

這個可以模仿遞增式併發(不但遞增還可以遞減),並可設置遞增次數、遞增啓動延遲、遞增時長、到達目標遞增數量保持時長等等:

參數解釋:

1、線程組最大用戶數:100個

2、初次加載用戶前等待時間:10秒,此時沒有用戶進入

3、第一次加載用戶數:10個用戶開始

4和5:每隔10秒加10個用戶

6、ramp-up在幾秒內啓動線程組

7、持續壓測60秒,一分鐘

8、和9:退用戶,每10秒退出10個用戶

10、上面各種設置的圖形表示

3、bzm - Arrivals Thread Group(bzm-到達線程組)

跟Concurrency Thread Group線程組功能作用大同小異。參數解釋:

· Target Rate:目標線程數(總線程數)

· Ramp Up Time:所需多少加載時間(總加速時長)

· Ramp Up Steps Count:所需多少個加載梯次(總遞增/加速次數)

· Hold Target Rate Time:持續運行時間(到達總線程數後持續時長)

· Time Unit:可以選擇用分鐘還是秒來做單位

· Thread lterations Limit:線程迭代次數限制。如果我們只需要運行每個用戶一次以模擬用戶的實際行爲,則可能會很有用。在我們的例子中,該字段爲空,因此每個用戶將運行不確定的迭代,直到調度結束。

· Log Thread Status into File:將線程狀態記錄到文件中

· Concurrency Limit:最大併發數限制。以避免出現內存不足的問題。在我們的例子中是1000,這是一個很大的數字。

現設計這樣一個場景:

所以以上設置就等於:3min除以5步,等於每步加速後持續0.6分鐘,100個用戶除以5步,等於每步加速20個用戶,達到100個用戶後持續跑6mn。

4、Ultimate Thread Group(最終線程組)

這個線程就比較難以理解,但是功能也比較強大。它可以對負載中的線程組進行復雜的管理。通過在線程計劃中具有無限數量的行來完成此操作,這可以爲線程組的不同部分啓用不同的配置。該插件跟Stepping Thread Group線程組有些類似,不過這個是多個線程組設置的結合。執行的時候,每個線程組是同時按照自己的規則開始執行的,每一時刻,得到的結果都是兩個線程組的疊加

形象比喻:

併發的用戶就像浪花一波一波的不斷湧入系統,拍打服務器,考驗我們的系統能否頂住壓力並平穩運行

我們的網站正在平穩運行的時候,突然有一波1000用戶同時訪問,我們稱之爲第一浪潮。訪問了30s之後,第一浪潮在15s內逐漸退出系統。

在第一浪潮退出系統的同時,第二波2000用戶在極短時間內又突然湧入網站,我們稱之爲第二浪潮。在訪問30s之後,第二浪潮在15s內也逐漸退出了系統。

在第二浪潮退出系統的同時,第三波3000用戶又突然湧入網站,我們稱之爲第三浪潮。在訪問30s之後,第三浪潮在15s內也逐漸退出了系統。

在第三浪潮退出系統的同時,第四波1000用戶又突然湧入網站,我們稱之爲第四浪潮。在訪問30s之後,第四浪潮在15s內也逐漸退出了系統。

添加單個線程組Row 和 添加多個線程組Row:

圖中本次測試一共啓動100個線 編輯程(用戶/併發)。

· Initial Delay, sec:最開始延遲時間,單位秒。設置爲0,就是點擊了立即執行。

· Startup Time, sec:啓動設置的100個線程併發一共需要的時間,單位秒。圖中設置10秒(線程組的加速期)

· Hold Load For, sec:保持加壓時間,單位秒。圖中10秒。

· Shutdown Time:多久時間內全部釋放關閉,單位秒。圖中10秒。

【實例】

1、需求:要求此接口用戶的訪問量“分波式”訪問,每個時期、每波都有不同用戶量訪問,每波的用戶訪問量呈現出遞增然後逐次遞減的狀態,單波用戶量最大併發不可超過70。

2、分析:根據需求實現具體場景,可得出普通線程組並不能實現,普通線程組一般實現爲“直線式”的需求場景(配合其他元件實現略不同),那麼此時Ultimate Thread Group線程組便可爲之實現:

3、步驟:

第一步:根據需求場景“每個時期、每波都有不同用戶量訪問”現設置添加多Row,每Row的Start Threads Count(開始線程計數),初始用戶的數量爲:10、30、50、70、50、30、10,此時每波用戶訪問量遞增→遞減和單波用戶不可超過70的需求配合關閉時間已經滿足。

第二步:每Row的Initial Delay,sec(延遲啓動時間,單位秒)設置每時間間隔5s:0s、5s、10s、15s、20s、25s、30s,這樣是爲了滿足不同組的啓動延遲時間,若每個線程組不同的用戶都在同一時間節點啓動那不是遞增式併發,那是同步式併發。

第三步:每Row的Startup Time,sec(啓動時間),意指每個線程組的線程在多少s內全部啓動,目前設置爲1s,即是每組線程組的線程數從啓動開始到啓動結束話費時長爲1秒。

第四步:每Row的Hold Load For,sec(持續運行),意指每個線程組的線程在啓動達到設置的線程數後持續運行多長時間,單位秒。此時需求每組線程運行後達到頂峯後呈現出“遞減”狀態,所以持續運行時間應該也是設置爲遞減:30、25、20、15、10、5、0(單位s)。

第五步:Shutwn Time(關閉時間),這個可配合上面四個可設置:0、5、10、15、10、5、0。這樣是爲了滿足“每波用戶訪問量遞增→遞減”的需求

好啦主功能配置已經完成,看下具體線程組效果圖:

此時,運行後爲了確保線程組的變化運行軌跡,添加一個Active Threads Over Time用來查看隨時間變化的活動線程:(添加路徑:線程組→添加→監聽器→jp@gc - Active Threads Over Time)

最後,即可添加察看結果樹、聚合報告、響應時間圖等分析此接口的接口各個返回指標等:

Ultimate Thread Group(最終線程組)實現原理:TA跟Stepping Thread Group線程組有些類似,不過這個是多個線程組設置的結合。執行的時候,每個線程組是同時按照自己的規則開始執行的,每一時刻,得到的結果都是兩個線程組的疊加

總結,對於系統原生Jmeter線程組只要下載安裝並配置環境變量Jmeter即可使用,可拓展線程組需要下載特定的插件進行安裝和配置,雖麻煩但是配置好的線程組功能是比較強大的,且可滿足多種類型的用戶和需求場景,值的感興趣的小夥伴一試!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章