1、線程組
每個測試計劃至少需要包含一個線程組，在測試計劃下面多個線程是並行執行的，也就是說這些線程組是同時被初始化並同時執行線程組下的Sampler的。
屬性詳解：
- 線程數：虛擬用戶數。一個虛擬用戶佔用一個進程或線程。設置多少虛擬用戶數在這裏也就是設置多少個線程數。
-
準備時長： 設置的虛擬用戶數需要多長時間全部啓動。如果線程數爲20 ，準備時長爲10 ，那麼需要10秒鐘啓動20個線程。也就是每秒鐘啓動2個線程。
-
循環次數：每個線程發送請求的次數。如果線程數爲20 ，循環次數爲100 ，那麼每個線程發送100次請求。總請求數爲20*100=2000 。如果勾選了“永遠”，那麼所有線程會一直髮送請求，一到選擇停止運行腳本。
-
除了上面介紹的固定循環次數與永遠外;也可以靈活的選擇設定測試運行時間。勾選“調度器”，進行調度器配置。配置“啓動延遲”時“啓動時間”無效，配置“持續時間”時“結束時間無效”
2、控制器
JMeter有兩種類型的控制器：取樣器(sample)和邏輯控制器(Logic Controller)，用這些原件來驅動處理一個測試。
2.1取樣器(sample)
取樣器(Sample)是性能測試中向服務器發送請求，記錄響應信息，記錄響應時間的最小單元。
一個取樣器通常進行三部分的工作：向服務器發送請求、記錄服務器的響應數據、記錄相應時間信息
HTTP請求配置參數：
名稱：本屬性用於標識一個取樣器，建議使用一個有意義的名稱。
註釋：對於測試沒有任何作用，僅用戶記錄用戶可讀的註釋信息。
服務器名稱或IP ：HTTP請求發送的目標服務器名稱或IP地址。
端口號：目標服務器的端口號，默認值爲80 。
協議：向目標服務器發送HTTP請求時的協議，可以是http或者是https ，默認值爲http 。
方法：發送HTTP請求的方法，可用方法包括GET、POST、HEAD、PUT、OPTIONS、TRACE、DELETE等。
Content encoding ：內容的編碼方式，默認值爲iso8859
路徑：目標URL路徑(不包括服務器地址和端口)
自動重定向：如果選中該選項，當發送HTTP請求後得到的響應是302/301時，JMeter 自動重定向到新的頁面。
Use keep Alive ： 當該選項被選中時，jmeter 和目標服務器之間使用 Keep-Alive方式進行HTTP通信，默認選中。
Use multipart/from-data for HTTP POST ：當發送HTTP POST 請求時，使用Use multipart/from-data方法發送，默認不選中。
同請求一起發送參數 ： 在請求中發送URL參數，對於帶參數的URL ，jmeter提供了一個簡單的對參數化的方法。用戶可以將URL中所有參數設置在本表中，表中的每一行 是一個參數值對(對應RUL中的 名稱1=值1)。
同請求一起發送文件：在請求中發送文件，通常，HTTP文件上傳行爲可以通過這種方式模擬。
從HTML文件獲取所有有內含的資源：當該選項被選中時，jmeter在發出HTTP請求並獲得響應的HTML文件內容後，還對該HTML進行 Parse 並獲取HTML中包含的所有資源(圖片、flash等)，默認不選中，如果用戶只希望獲取頁面中的特定資源，可以在下方的Embedded URLs must match 文本框中填入需要下載的特定資源表達式，這樣，只有能匹配指定正則表達式的URL指向資源會被下載。
用作監視器：此取樣器被當成監視器，在Monitor Results Listener 中可以直接看到基於該取樣器的圖形化統計信息。默認爲不選中。
Save response as MD5 hash? ：選中該項，在執行時僅記錄服務端響應數據的MD5值，而不記錄完整的響應數據。在需要進行數據量非常大的測試時，建議選中該項以減少取樣器記錄響應數據的開銷。
2.2邏輯控制器
包括兩類元件，一類是用於控制test plan 中 sampler 節點發送請求的邏輯順序的控制器，常用的有 如果(If)控制器 、switch Controller 、Runtime Controller、循環控制器等。另一類是用來組織可控制 sampler 來節點的，如 事務控制器、吞吐量控制器
3、配置元件(Config Element)
配置元件(config element)用於提供對靜態數據配置的支持。CSV Data Set config 可以將本地數據文件形成數據池(Data Pool)，而對應於HTTP Request Sampler和 TCP Request Sampler等類型的配製無件則可以修改Sampler的默認數據。(例如，HTTP Cookie Manager 可以用於對 HTTP Request Sampler 的cookie 進行管理)
3.1HTTP請求默認值
配置代理服務器proxy server
4、定時器(Timer)
用於操作之間設置等待時間，等待時間是性能測試中常用的控制客戶端QPS的手端。類似於LoadRunner裏面的“思考時間”。JMeter 定義了Bean Shell Timer、Constant Throughput Timer、固定定時器等不同類型的Timer。
4.1Constant Throughput Timer (常數吞吐量定時器)
該定時器可以方便地控制給定的取樣器發送請求的吞吐量。
Constant Throughput Timer 的主要屬性介紹：
Target throughput(in samples per minute)：目標吞吐量。注意這裏是每分鐘發送的請求數，因此，對應測試需求中所要求的20 QPS ，這裏的值應該是1200 。
Calculate Throughput based on ：有5個選項，分別是：
This thread only ：控制每個線程的吞吐量，選擇這種模式時，總的吞吐量爲設置的 target Throughput 乘以矣線程的數量。
All active threads ： 設置的target Throughput 將分配在每個活躍線程上，每個活躍線程在上一次運行結束後等待合理的時間後再次運行。活躍線程指同一時刻同時運行的線程。
All active threads in current thread group ：設置的target Throughput將分配在當前線程組的每一個活躍線程上，當測試計劃中只有一個線程組時，該選項和All active threads選項的效果完全相同。
All active threads (shared )：與All active threads 的選項基本相同，唯一的區別是，每個活躍線程都會在所有活躍線程上一次運行結束後等待合理的時間後再次運行。
All cative threads in current thread group (shared )：與All active threads in current thread group 基本相同，唯一的區別是，每個活躍線程都會在所有活躍線程的上一次運行結束後等待合理的時間後再次運行。
備註：Constant Throughput Timer只有在線程組中的線程產生足夠多的request 的情況下才有意義，因此，即使設置了Constant Throughput Timer的值，也可能由於線程組中的線程數量不夠，或是定時器設置不合理等原因導致總體的QPS不能達到預期目標。
5、後置處理器(Post Processors)
用於對Sampler 發出請求後得到的服務器響應進行處理。一般用來提取響應中的特定數據(類似LoadRunner測試工具中的關聯概念)。例如，XPath Extractor 則可以用於提取響應數據中通過給定XPath 值獲得的數據。
6、斷言(Assertions)
斷言用於檢查測試中得到的相應數據等是否符合預期，斷言一般用來設置檢查點，用以保證性能測試過程中的數據交互是否與預期一致。
7、監聽器(Listener)
這個監聽器可不是用來監聽系統資源的元件。它是用來對測試結果數據進行處理和可視化展示的一系列元件。 圖行結果、查看結果樹、聚合報告。都是我們經常用到的元件。7.1聚合報告
90%line的解釋
一組數由小到大進行排列，找到他的第90%個數（假如是10），那麼這個數組中有90%的數將小於等於10。
用在性能測試的響應時間也將非常有意義，也就是90%請求響應時間不會超過10 秒。