創建測試計劃
一個最小的測試包含測試計劃(test plan)、線程組(thread group)、一個或多個樣例(sampler)。
測試計劃
測試計劃對象裏有個複選框叫“Functional Testing”.如果勾選了，jmeter會記錄每個sample從server端返回的結果。如果在test listeners中選擇了文件，數據會保存到文件裏。如果你正在做一個小例子來確保jmeter是配置正確的，或者說確保server端返回了期待的結果，這種情況下非常有用。不過，勾選的結果就是文件會很快變得很大，jmeter也會遭受性能問題。如果你在做壓力測試，這個選項應該關閉（默認就是關閉的）。
線程組
線程組是任何測試計劃的起點。所有的controller和sampler必須在一個線程組下。另外一些元素，比如listener，也許會直接放在test plan之下，這種情況listener會應用到所有的線程組。見名知意，線程組元素控制了jmeter的線程數量，jmeter用線程組來執行測試。控制線程組可以讓你做：
- 設置線程數量
- 設置啓動週期（ramp-up period）
- 設置執行測試的次數
每個線程都會完全獨立於其它線程執行測試計劃。多線程用來模擬併發連接服務端應用。
ramp-up period告訴jmeter，消耗多長時間跑起來全部線程。如果用10個線程，ramp-up period是100秒，那麼jmeter將會消耗100秒來讓10個線程起來和運行。每個線程會在上一個線程起來之後10秒（100/10）後啓動。如果是30個線程，ramp-up period是120秒，那麼每個成功的線程將會被延遲4秒。
The ramp-up period tells JMeter how long to take to “ramp-up” to the full number of threads chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds.
ramp-up需要足夠長的時間來避免測試開頭過大的負載，也得足夠短，來讓最後一個線程在第一個線程結束之前開始運行。
默認的，線程組會被配置成循環執行一次它的所有元素。
線程組也提供了一個scheduler（調度器）。勾選在Thread Group面板最底下的複選框來啓用/禁用其它項，這些項包括測試執行時間、啓動延遲、啓動和停止的次數。你也可以配置持續時間（duration）、啓動延遲時間（startup delay）來控制每個線程組的持續時間和多長時間後再啓動。當測試啓動了，jmeter會等待startup delay，然後再啓動線程組並運行配置的Duration時間。注意這兩個選項覆蓋start time和end time。
另外，儘管不推薦這樣做，因爲不靈活，你可以使用其它兩個項start time和end time。當test啓動了，如果有必要jmeter會一直等待直到start-time到點了。在每個循環的結尾，jmeter check是否end-time到期了。如果到期了，運行就會被停止，否則test會被允許繼續執行直到達到迭代次數。
控制器
jmeter有兩種類型的控制器：sampler和logical controller。控制器驅動測試進程。
sampler告訴jmeter發送請求給server。比如，增加一個http request sampler如果你想jmeter發送一個http request，你也可以定製一個請求通過增加一個或多個配置元素到sampler。
邏輯控制器讓你定製邏輯，來讓jmeter使用以決定什麼時候發送請求。比如，你可以增加一個插入邏輯控制器來交替執行兩個http request sampler。
樣例
樣例告訴jmeter去發送請求給server並等待響應。他們按照在tree中出現的順序執行。控制器可以用來修改樣例的重複次數。
JMeter樣例包括：
- FTP 請求
- Http 請求
- JDBC 請求
- java 對象請求
- JMS請求
- Junit Test請求
- LDAP請求
- Mail請求
- OS Process請求
- TCP 請求
每個樣例有好幾個屬性，你可以設置他們。通過增加一個或多個配置元素，可以進一步定製樣例。
如果你打算髮送多個同樣類型的請求（比如，http 請求），考慮使用一個默認的配置元素。每個控制器有一個或多個默認元素。
記得要，增加監聽器以來查看或存儲請求結果。
如果你對響應執行基本校驗感情去，把樣例增加一個斷言。比如，在web應用的壓力測中，服務器可能返回一個成功的Http response code，但是這個頁面可能有錯誤或者缺失了一些內容。又可以增加斷言去check某些html標籤、通用錯誤字符串等等。JMeter允許你是用正則表達式創建這些斷言。
邏輯控制器
邏輯控制器允許你定製邏輯，也就是說，你可以用它來控制什麼時候發送請求。邏輯控制器可以更改來自子元素的請求順序。他們自己修改請求本身，以使JMeter重複請求。
爲了理解邏輯控制器在test plan中的作用，考慮下邊的test tree:
- Test Plan
- Thread Group
- Once Only Controller
- Login Request(an Http request)
- Load search page(Http sampler)
- interleave controller
- Search “A”(Http sampler)
- Search “B”(Http sampler)
- http default request(Configuration Element)
- Http default request(Configuration Element)
- Cookie Manager(Configuration Element)
- Once Only Controller
- Thread Group
第一件要考慮的事就是login request只能被執行一次。後續的迭代都會跳過他。這是因爲Once Only Controller的作用。
登陸後，下一個Sampler加載Search Page。這是一個簡單的請求，不會被任何Logic Controller過濾。
加載完search page後，我們想去搜索。實際上，我們想去兩個不同的搜索。然而，我們想去再一次加載search page，在兩個搜索之間。這樣做的話，包含4個簡單的http 請求元素（load search、search A、load search、search B）。然而，我們使用Interleave Controller（每經過這個測試傳入它）。他保持着子元素的順序（他不會隨機傳入，相反會記住位置）。插入兩個子請求也許能客服，但是如果是8/20個自請求將會很簡單。
注意，http request default屬於Interleave Controller。設想search A和 searchB分享了相同的路徑信息（domain、port、method、protocol、path、參數）。這就清晰了：兩個都是搜索請求，集中了相同的後端搜索引擎。不是用相同的信息配置兩個http sampler，而是抽象相同的信息到configuration element。當interleave controller傳入來自search A或者search B請求，它會用http default request的值來填充空白。所以，我們將Path留白，將信息填入Configuration Element。在這個例子中，充其量有一點點好處，但是它舉例了這個特性。
下一個元素是另外一個Http default request，這次增加到Thread Group。Thread Group還有個內置的Logic Controller，並且，它使用Configuration Element就像上邊描述的。它填充傳入請求的空白域。尤其在web測試中將domain留空有用，將信息放入http default request element。這樣做，你可以測試在不同server上的應用僅僅修改一個field。否則，你必須編輯每個sampler的domain。
最後一個元素是Http Cookie Manager。一個Cookie Manager應該被添加到所有web test中，否則JMeter會和忽略cookie。通過在Thread Group中增加它，我們確保所有HTTP 請求會分享相同cookie。
Logic Controller可以被聯合起來完成不同的結果。