在本系列文章的上一篇中，我們介紹了開源測試工具 JMeter，並以一個簡單的HTTP測試爲例一窺JMeter的能力。在本篇文章中，我們將進一步介紹JMeter豐富的組件，以幫助大家構建複雜場景的測試腳本。
JMeter的測試腳本在界面中以「樹」的形式呈現，保存後的測試腳本jmx文件本身也是xml格式。JMeter腳本樹以測試計劃(Test Plan)爲根節點，所有的測試組件都會被包含在測試計劃中。測試計劃中可以配置被整個測試計劃中的組件調用的自定義變量、線程組運行模式、測試中使用的庫文件等。
在測試計劃中使用多種測試組件，就可以構建豐富的測試場景。JMeter中的測試組件大致有以下幾類：線程組、取樣器、邏輯控制器、監聽器、配置元件、斷言、定時器、前置處理器、後置處理器。接下來將分別介紹，並對主要的組件進行詳細說明。
一、線程組
線程組元件是所有測試計劃的入口。所有的取樣器和控制器必須放在線程組下。一個線程組可以看作一個虛擬用戶池，其中的每個線程都可以理解爲一個虛擬用戶，多個虛擬用戶同時去執行相同的一批次任務。每個線程之間都是隔離的，互不影響的。一個線程的執行過程中，操作的變量不會影響其他線程的變量值。
線程組的界面如下圖：
在線程組界面中可以設置以下數據，進行線程組的控制：
取樣器錯誤後要執行的動作
這幾個配置項控制了「當遇到錯誤的時候測試的執行策略」是否會繼續執行。
- 繼續：忽略錯誤，繼續執行
- 啓動下一進程循環： 忽略錯誤，線程當前循環終止，執行下一個循環。
- 停止線程：當前線程停止執行，不影響其他線程正常執行。
- 停止測試：整個測試會在所有當前正在執行的線程執行完畢後停止
- 立即停止測試：整個測試會立即停止執行，當前正在執行的取樣器可能會被中斷。
線程數
線程數也就是併發用戶數，每個線程將會完全獨立地運行測試計劃，互不干擾。測試中使用多個線程用於模仿對服務器的併發訪問。
ramp-up時間
ramp-up時間用於設置啓動所有線程所需要的時間。例如：線程數設置爲10，ramp-up時間設置爲100秒，那麼JMeter將使用100秒使10個線程啓動並運行，每個線程將在前一個線程啓動後的10秒啓動。
如果ramp-up值設置得很小、線程數又設置得很大，剛開始執行測試時會對服務器產生很大的壓力。
循環次數
設置結束前線程組中每個線程循環的次數。
延遲創建線程直到需要
默認情況下，測試開始的時候，所有線程就全部創建了。如果勾選了此選項，那麼線程在需要用到的時候才創建。
線程組調度器
調度器配置可以更靈活地控制線程組執行的時間
（1）持續時間：控制測試執行的持續時間，以秒爲單位。
（2）啓動延遲：控制測試在多久後啓動執行，以秒爲單位。
二、取樣器
取樣器是用來模擬用戶操作的，是向服務器發送請求、接收服務器響應數據的運行單元。取樣器是包含在線程組內部的組件，因此它必須在線程組中添加。JMeter原生支持多種不同的取樣器，如TCP取樣器、HTTP請求、FTP請求、JDBC請求、Java請求等，每一種不同類型的取樣器根據設置的參數向服務器發出不同類型的請求。
TCP取樣器
TCP 取樣器通過TCP/IP來連接指定服務器，連接成功後向服務器發送消息，然後等待服務器回覆。
界面如圖：
TCP取樣器中可以設置的屬性有：
1.TCPClient classname
表示處理請求的實現類。缺省使用org.apache.jmeter.protocol.tcp.sampler.TCPClientImpl, 使用普通文本進行傳輸。此外JMeter還內置支持BinaryTCPClientImpl和LengthPrefixedBinaryTCPClientImple， 前者使用十六進制報文，後者在BinaryTCPClientImpl的基礎上增加了2個字節的長度前綴。
也可以通過繼承org.apache.jmeter.protocol.tcp.sampler.TCPClient來提供自定義的實現類。
2.目標服務器設置
「服務器名稱或IP」和「端口號」指定了服務器應用的主機名/IP地址和端口號。
3.連接選項
- Re-use connection：: 如果選中，這個連接會一直處於打開狀態，否則讀取到數據後就關閉。
- 關閉連接：如果選中，這個連接在TCP取樣器運行完畢之後就會被關閉。
- 設置無延遲：如果選中，Nagle算法將被禁用，允許小數據包的發送。
- SO_LINGER：用於控制在關閉連接之前是否要等待緩衝區中的數據發送完成。
- 行尾 (EOL)字節值：用於判斷行結束的字節值，如果指定的值大於127或者小於-128，會跳過EOL檢查。比如服務器端返回的字符串都是以回車符結尾，那麼我們可以將該選項設置成10
4.超時時間：
- Connect Timeout：連接超時
- Response Timeout：響應超時
5.要發送的文本
請求發送的報文文本
6.登陸配置
設置連接使用的用戶名和密碼
HTTP請求取樣器
HTTP取樣器向web服務器發送HTTP/HTTPS請求。
1.名稱和註釋
2 .請求協議
向目標服務器發送請求時使用的協議，可以是HTTP、HTTPS或FILE，默認爲HTTP。
3.域名或IP地址
請求發送的目標服務器名稱或IP地址。
4.端口號
Web服務監聽的端口號，HTTP默認端口爲80，HTTPS默認端口443。
5.請求方法
發送請求的方法，常用GET、POST、DELETE、PUT、TRACE、HEAD、OPTIONS等。
6 .路徑
要請求的目標URL路徑（不包括服務器地址和端口）。
7.內容編碼
適用於POST、PUT、PATCH和FILE這幾種請求方式，對請求內容進行編碼的方法
8.更多請求選項
- 自動重定向：重定向不會被視爲單獨的請求，不被JMeter記錄。
- 跟隨重定向：每次重定向都被視爲單獨的請求，都會被JMeter記錄。
- 使用KeepAlive：如果選中，JMeter和目標服務器之間通信時會在請求頭中加入Connection: keep-alive。
- 對POST使用multipart/form-data：如果選中，將使用multipart/form-data 或 application/x-www-form-urlencoded發送請求。
9.參數
JMeter將使用參數鍵值對來生成請求參數，並根據請求方法以不同方法發送這些請求參數。例如：GET，DELETE請求，參數會附加到請求URL。
10.消息體數據
如果希望傳輸JSON格式的參數，需要在請求頭中配置Content-Type爲application/json
11.文件上傳
在請求中發送文件，通常HTTP文件上傳行爲可以通過這種方式模擬。
三、邏輯控制器
JMeter 邏輯控制器可以對元件的執行邏輯進行控制，JMeter 官網是這樣解釋的：「Logic Controllers determine the order in which Samplers are processed」。也就是說邏輯控制器可以控制採樣器(samplers)的執行順序，因此控制器需要和採樣器一起使用。除僅一次控制器外，其他邏輯控制器可以相互嵌套。
JMeter 中的邏輯控制器主要分爲兩類：
- 控制測試計劃執行過程中節點的邏輯執行順序，如：循環控制器、If 控制器等；
- 對測試計劃中的腳本進行分組、方便 JMeter 統計執行結果以及進行腳本的運行時控制等，如：吞吐量控制器、事務控制器。
事務控制器
有時候我們想統計一組相關請求的的整體響應時間，這種情形就需要藉助事務控制器。
事務控制器會對該控制器下所有子節點的取樣器執行消耗時間進行統計。如果事務控制器下定義了多個取樣器，所有取樣器都運行成功時，整個事務才能算成功。
如下圖添加事務控制器：
事務控制器的配置項有：
1.Generate parent sample
如果選中，事務控制器將作爲其他取樣器的父級樣本，否則事務控制器僅作爲獨立的樣本。
例如，未勾選情況下彙總報告如下：
勾選情況下彙總報告如下：
2.include duration of timer and pre-post processors in generated samle：
指定是否包含定時器，如果勾選將在取樣器運行前與運行後加上延時。
僅一次控制器
僅一次控制器，顧名思義就是隻執行一次的控制器，即在線程組下的循環執行過程中對該控制器下的請求只執行一次。對於需要登錄的測試，可以考慮將登錄請求放在僅一次控制器中，因爲登錄請求只需執行一次即可建立會話。
如下圖添加僅一次控制器：
如果我們將線程組循環次數設置爲 2，運行後查看結果樹，可看到僅一次控制器下的請求“HTTP請求3”只執行了1次，其它請求執行了2次
四、監聽器
監聽器是用於對測試結果數據進行處理和可視化展示的一系列元件。察看結果樹、 圖形結果、聚合報告等都是我們經常用到的監聽器組件。
察看結果樹
該組件以樹形結構展示了每一個取樣器的結果、請求內容、響應時間、響應碼、響應內容等信息，查看這些信息可以輔助分析是否存在問題。它提供多種的查看格式和篩選方法，也可以將結果寫入指定文件進行批量分析處理。
五、配置元件
配置元件用於提供對靜態數據配置的支持。它可以定義在測試計劃層級下，也可以定義在線程組或取樣器層級下，定義在不同層級，作用域也不同。配置元件主要有用戶自定義變量、CSV數據文件設置、TCP取樣器配置、HTTP Cookie管理器等。
用戶自定義變量
通過設置一系列的變量，達到在性能測試過程中可以隨機選取變量的目的。變量名可以在作用域內引用，通過${變量名}方式來引用變量。
除了“用戶自定義變量”這個組件外，測試計劃和HTTP請求等多個組件中也可以定義變量：
例如：在HTTP請求中引用了已定義的變量：
查看執行結果，能看到確實獲取到了變量的取值：
CSV數據文件設置
在性能測試過程中我們往往需要一些參數化的輸入參數，比如登錄操作裏面的用戶名密碼。當併發量比較大的時候 ，運行時生成數據會對CPU和內存造成較大的負擔，而CSV數據文件配置可以作爲這種場景下所需的參數來源。
CSV數據文件設置中部分參數的說明如下：
- 變量名稱：定義CSV文件中的參數名，定義後可在腳本在以${變量名}的方式引用
- 遇到文件結束符再次循環：如果設置爲True，允許對CSV文件循環取值
- 遇到文件結束符停止線程：如果設置爲True，則讀取完CSV文件中的記錄後停止運行
- 線程共享模式：設置在線程及線程組間共享的模式
六、斷言
斷言即檢查接口的返回是否符合預期。斷言是自動化測試腳本中舉足輕重的一環，因此要十分重視。
JMeter 常用斷言主要有響應斷言（Response Assertion）、JSON斷言（JSON Assertion）、大小斷言（Size Assertion）、斷言持續時間（Duration Assertion）、beanshell 斷言（Beanshell Assertion）等，這裏我們只介紹經常要用到的 JSON斷言。
JSON 斷言
用於對 JSON 格式的響應內容進行斷言。
下圖在一個HTTP取樣器上添加 JSON 斷言：
JSON斷言配置項有：
- Assert JSON Path exists：需要斷言的 JSON 表達式
- Additionally assert value：如果要根據值去斷言，請勾選
- Match as regular expression：如果要根據正則表達式去斷言，請勾選
- Expected Value：期望值
- Expect null：如果期望是 null 則勾選
- Invert assertion：取反
其中 JSON path 中的「根成員對象」總是被稱爲$，可以通過 「dot–notation」（.號）或 「bracket–notation」（[]號）這兩種不同的風格來表示，比如 $.message[0].name 或 $['message'][0]['name']。
下面以請求 http://www.kuaidi100.com/query 爲例，其中 $.message 表示響應 json 對象的中 message，勾選 Additionally assert value 表示要根據 message 的值去判斷，Expected value 爲 ok 表示判斷 message的值是否爲 ok。
運行腳本，查看結果，可看到斷言是通過的
斷言的判斷條件主要包括：如果響應結果不是 json 格式的，失敗；如果 json path 找不到元素，失敗；如果 json path 找到元素，沒有設置條件，通過；如果 json path 找到元素，但不符合條件，失敗；如果 json path 找到元素，且符合條件，通過；如果 json path 返回的是一個數組，會迭代判斷是否有元素符合條件，有則通過，沒有則失敗。回到“JSON斷言”，勾選 Invert assertion
運行腳本，查看結果，可看到斷言是失敗的
七、定時器
在性能測試中，訪問請求之間的停頓時間被稱之爲思考時間。在實際操作中，停頓時間可以是內容查找、閱讀等花費的時間，而定時器正是用來模擬這種停頓時間。其中：
- 同一作用域下的所有定時器優先於 取樣器之前執行。
- 如果希望定時器僅應用於其中一個取樣器，則把定時器加入到該取樣器的子節點。
JMeter定時器主要包括：固定定時器（Constant Timer），統一隨機定時器（Uniform Random Timer），精準吞吐量定時器（Precise Throughput Timer），常數吞吐量定時器（Constant Throughput Timer），高斯隨機定時器（Gaussian Random Timer），JSR223 定時器（JSR223 Timer），泊松隨機定時器（Poisson Random Timer），同步定時器（Synchronizing Timer），BeanShell 腳本編寫定時器（BeanShell Timer）。
固定定時器
固定定時器，即配置每個請求之間的間隔時間爲固定值。
下圖在一個事務控制器上添加固定定時器：
將線程延遲分別配置爲 100 和 1000後，運行腳本
查看錶格結果中的數據，其中1、2是配置爲 100 毫秒時的運行結果，4、5是配置爲 1000 毫秒時的運行結果，可看到 4、5 的間隔時間明顯比 1、2 的間隔時間長
常數吞吐量定時器:
常數吞吐量定時器用於控制請求按指定的吞吐量去執行。
下圖在一個事務控制器上添加常數吞吐量定時器：
配置目標吞吐量爲 120（注意單位是分鐘），基於計算吞吐量選擇“當前線程組中的所有活動線程（共享）”
運行腳本，查看結果，可看到吞吐量基本維持在 2/每秒（120/60）
八、前置處理器和後置處理器
前置處理器是取樣器請求之前執行一些操作，經常用於在取樣器請求運行前修改參數，設置環境變量，或更新未從響應文本中提取的變量。
同樣的，後置處理器是在取樣器請求之後執行一些操作。有時候服務器的響應數據在後續請求中需要用到，我們就需要對這些響應數據進行處理。比如獲取響應中的jwt token，在後續請求中使用以進行身份驗證，這時就會使用後置處理器。
以上就是JMeter主要的測試組件介紹，大家可以在實戰中嘗試使用。下期文章我們將講解 JMeter 中的 MQTT 插件使用。
版權聲明： 本文爲 EMQ 原創，轉載請註明出處。
原文鏈接：https://www.emqx.com/zh/blog/introduction-to-jmeter-test-components
技術支持：如對本文或 EMQ 相關產品有疑問，可訪問 EMQ 問答社區 https://askemq.com 提問，我們將會及時回覆支持。
更多技術乾貨，歡迎關注我們公衆號【EMQ 中文社區】。