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自帶的監聽器，如下圖所示：
參考：