JMeter的主要元件有
測試計划、
線程組、
取樣器、
邏輯控制器、
配置元件、
前置處理器、
后置處理器、
監聽器、
定時器、
斷言。
其中共有8類可被執行的元件，test plan（測試計划）和thread group（線程組）不屬於可被執行的元件，而sampler（取樣器）是不與其他元件發生交互的作用的元件。
下面我們就來逐一介紹一下這些元件。（這里只做介紹，后面會詳細說明每一個元件）
1、測試計划（Test Plan）
用來描述一個性能/接口測試腳本和場景設計，包含與本次測試所有相關的功能。
也就是說，使用JMeter進行測試的所有內容，都是於基於一個測試計划中。
在換個說法，一個測試計划就對應一個JMeter測試腳本。
在JMeter-GUI中，只能編輯一個測試計划，如果需要新創建一個測試計划，就要開啟一個新的JMeter-GUI窗口界面。
2、線程組<Threads(Users)>
線程組元件是任何一個測試流程的起始點，在一個測試計划中的所有元件都必須在某個線程組下。
JMeter自帶的線程組，如下圖所示：
上圖可以看到，JMeter有三個添加線程組的選項，名字不一樣， 但是創建之后，其界面是完全一樣的。
線程組概括說明：
- 線程組是一個測試流程的起始點。
- 線程組中可以有多個線程。線程組也可以看作是一個虛擬用戶組，線程組中的每一個線程都可以理解為相當於一個“虛擬用戶”。
- 線程組中一個取樣器代表一個請求，一個請求等同於一個線程。
- 每個線程都會獨立的運行測試計划，互不干擾，多個線程用於模仿對服務器的並發訪問。
- 線程組元件可以設置線程數、設置執行測試的次數等操作。
3、取樣器（sampler）
取樣器是用來模擬用戶操作的，向服務器發送請求以及接收服務器的響應數據。
取樣器是線程組內部的元件，也就是說取樣器只能在線程組中添加。
取樣器(Sampler)是性能測試中向服務器發送請求，記錄響應信息，記錄響應時間的最小單元。（取樣器通常要進行這三個工作）
取樣器是按照測試計划樹的順序從上到下執行的。且取樣器配合控制器使用，可以修改取樣器的執行順序和次數。
JMeter自帶的取樣器，如下圖所示：
4、邏輯控制器（Logic Controller）
我們有編程基礎的人都知道，提到邏輯主要就是條件和循環。
JMeter官網對邏輯控制器的解釋是：Logic Controllers determine the order in which Samplers are processed.
意思是說，邏輯控制器可以控制采樣器(samplers)的執行順序。
由此可知，控制器需要和采樣器一起使用，否則控制器就沒有什么意義了。放在控制器下面的所有的采樣器都會當做一個整體，執行時也會一起被執行。
JMeter提供了17種邏輯控制器，它們各個功能都不盡相同，大致可分為2種類型：
- 一類是用於控制
test plan（測試計划）中sampler（取樣器）節點發送請求的邏輯順序的控制器，常用的有If Controller、switch Controller、Runtime Controller、Loop Controller（循環控制器）等。 - 另一類是用來組織可控制的
sampler節點，也就是對測試計划中的取樣器進行分組，方便JMeter統計執行結果，以及運行腳本時的控制操作等。 如Transaction Controller（事務控制器）、Throughput Controller（吞吐量控制器）等。
JMeter自帶的邏輯控制器，如下圖所示：
5、配置元件（Config Element）
JMeter的配置元件（config element）用於提供對靜態數據的配置支持，可以為取樣器設置默認值和變量。
配置元件有很多的功能，讀取文件數據，設置公共請求參數，賦予變量值等，以便后續取樣器使用。
（類似於項目中配置文件的作用，如數據、地址、數據庫鏈接等進行配置）
例如：性能測試中為了模擬大量用戶操作我們往往需要做參數化， JMeter的參數化可以通過配置元件來完成，利用CSV Data Set config（CSV數據文件設置）可以將本地數據文件形成數據池 （Data Pool），它可以幫助我們從文件中讀取測試數據。
另外JMeter也提供了眾多的函數來幫我們生成動態數據。（通過函數助手可以查看到，后續會講到）
再例如，配置元件還可以用來記錄服務器的返回數據，如HTTP Cookie Manager 可以用於對 HTTP Request Sampler 的 cookie 進行管理。
簡而言之，配置元件是為取樣器提供預備數據，然后由取樣器發出請求。
JMeter自帶的配置元件，如下圖所示：
6、定時器（Timer）
用戶實際操作時，並非是連續點擊，而是存在很多停頓的情況，例如：用戶需要時間閱讀文字內容、填表、或者查找需要點擊的鏈接等。為了模擬用戶實際情況，在性能測試中我們需要考慮操作時間。若不認真考慮操作時間很可能會導致測試結果的失真。例如，估計的可支撐用戶數可能會偏小。
在性能測試中，訪問請求之間的停頓時間被稱之為思考時間。
那么如何模擬這種停頓呢？我們可以借助JMeter的定時器元件實現。
JMeter中的定時器一般被我們用來設置延遲與同步（操作之間的等待時間）。定時器的執行優先級高於Sampler（取樣器），在同一作用域（例如控制器下）下有多個定時器存在時，每一個定時器都會執行，如果想讓某一定時器僅對某一Sampler有效，則可以把定時器加在此Sampler節點下。
JMeter自帶的定時器，如下圖所示：
提示：定時器常用於控制客戶端QPS的手段。
7、前置處理器（Per Processors）
前置處理器是在取樣器發出請求之前執行一些操作。即：如果將前置處理器附加到取樣器元件，則它將在該取樣器元件運行之前執行。
前置處理器主要是用來處理，請求在實際發送之前的一些准備工作，比如取樣器參數設置、環境變量設置、腳本預處理等操作。
例如：當URL中有sessionID一類的session信息時，可以通過該處理器填充發出請求實際的sessionID。
JMeter自帶的前置處理器，如下圖所示：
8、后置處理器（Post Processors）
用於對Sampler發出請求后得到的服務器響應進行處理。一般用來提取響應中的特定數據（類似LoadRunner中的關聯）。
例如：我們在做接口測試的時候，難免會遇到一個接口的請求參數是另一個接口的響應結果，這個時候就需要用到后置處理器來處理我們的請求參數。如系統登錄成功后我們要獲取sessionid，在后面業務操作中服務器會驗證這個sessionID，獲取sessionID這個過程，就是用后置處理器中的正則表達式提取器來完成。
后置處理器常用於：處理響應數據，提取某個值。
JMeter自帶的后置處理器，如下圖所示：
9、斷言（Assertions）
斷言是自動化測試中最重要且繞不開的一個概念，讓自己的程序盡可能像人一樣去做判斷，這是自動化測試需要實現的重要功能。
JMeter中的斷言用於檢查測試中得到的響應數據等是否符合預期，Assertions一般用來設置檢查點，用以保證性能測試過程中的數據交互與預期一致。（它的作用和LoadRunner中的檢查點類似）
JMeter中斷言的原理：在Request的返回層面，增加一層判斷機制，因為Request成功了，並不代表結果一定正確。
一個Sampler可以添加多個斷言，根據你的檢查需求來添加相應的斷言，多個斷言屬於並的操作。當Sampler下所有的斷言都通過了，那么才算是請求成功。
JMeter自帶的斷言，如下圖所示：
10、監聽器（Listener）
JMeter中的監聽器，是對測試結果進行處理和可視化展示的一系列組件，能夠顯示取樣器請求和響應的細節以及請求結果，包括消息頭，請求的數據，響應的數據。
常用的監聽器有圖形結果、查看結果樹、聚合報告等。
注意：
- 監聽器放的位置不同，查看的結果也不同。
在線程組下添加監聽器，查看線程組下所有請求的結果；
放在具體某個請求下，只查看此請求的結果；
若放在某個控制器節點下，則查看此控制器下節點執行的結果； - 該監聽器推薦做調試用，在實際運行壓測時，應該禁用。因為大量請求時，啟用監聽器時打印的日志比較多，會造成大IO消耗，影響壓力機性能。
- 不同的監聽器，通過不同的方式，展示服務器響應信息，但是它們原始結果數據都是一樣的。
- JMeter監聽器有兩種方式存儲監聽記錄：
1）默認保存方式：CSV格式。占用磁盤比較少，推薦使用這種方式保存。
2）xml保存方式：保存數據最全面，但是占用內存大。
JMeter自帶的監聽器，如下圖所示：
參考：