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

[[320893]]

一、線程組介紹

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

通俗理解：

• 線程組：就是一個線程組，里面有若干個請求;
• 線程：一個線程就是一個“虛擬用戶”;
• 請求：一個線程組里面有若干個請求。

對應關系：

例如：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：

參數解釋：

• Start Threads Count：一共要啟動的線程數。圖中本次測試一共啟動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即可使用，可拓展線程組需要下載特定的插件進行安裝和配置，雖麻煩但是配置好的線程組功能是比較強大的，且可滿足多種類型的用戶和需求場景，值的感興趣的小伙伴一試!

【本文是51CTO專欄機構“AiChinaTech”的原創文章，微信公眾號( id: tech-AI)”】

戳這里，看該作者更多好文