3.測試計劃中的元素（elements of a test plan）
本節描述測試計劃不同的部分。
最小測試將包括測試計劃、線程組和一個或多個採樣器。
3.0 測試計劃（Test Plan）
測試計劃對象有一個叫 “功能測試” 的複選框，如果選擇了，它將導致JMeter記錄從服務器返回的每個示例的數據。如果您在測試監聽器中選擇了一個文件，那麼這些數據將被寫入文件。如果您正在執行一個小的運行，以確保JMeter的配置正確，並且您的服務器正在返回預期的結果，那麼這將非常有用。其結果是，文件將快速增長，JMeter的性能將受到影響。如果您正在進行壓力測試(默認情況下是off)，則該選項應該關閉。
如果您沒有將數據記錄到文件中，則該選項沒有任何區別。
您還可以使用偵聽器(listener)的 配置 按鈕來決定要保存哪些字段。
3.1 線程組（Thread group）
線程組元素是任何測試計劃的起點。所有控制器和採樣器必須在線程組下。其他元素，例如偵聽器，可以直接置於測試計劃之下，在這種情況下，它們將適用於所有的線程組。顧名思義，線程組元素控制JMeter用來執行測試的線程的數量。線程組的控件允許:
- Set the number of threads： 設置線程數
- Set the ramp-up period：設置過渡時期
- Set the number of times to execute the test：設置執行測試的次數
每個線程將完全獨立地執行測試計劃，完全獨立於其他測試線程。多個線程用於模擬與服務器應用程序的併發連接。
這個過渡時期告訴JMeter要花多長時間才能“加速”到選擇的全部線程數。如果使用10個線程，並且過渡時期是100秒，那麼JMeter將花費100秒來啓動所有10個線程並運行。在前面的線程開始後，每個線程將開始10(100 / 10)秒。如果有30個線程和一個上升週期120秒，則每個連續線程將延遲4秒。
需要足夠長的時間來避免在測試開始時工作負載過大，足夠短的時間，最後的線程在第一個線程完成之前就開始運行(除非有人希望發生這樣的情況)。 從增加的線程數開始，根據需要調整向上或向下。
默認情況下，線程組被配置爲通過它的元素循環一次。
線程組還提供了一個 調度器 。單擊線程組面板底部的複選框，以啓用/禁用額外的字段，在該字段中您可以輸入測試持續時間、啓動延遲、運行的開始和結束時間。您可以配置 持續時間（秒） 和 啓動延遲（秒） 來控制每個線程組的持續時間和啓動後的秒數。當開始測試時，JMeter會等待 啓動延遲（秒） 之前啓動的線程組的線程和運行配置的持續時間（秒）的時間。注意，這兩個選項覆蓋了 開始時間 和 結束時間 。
或者(儘管不建議不是很靈活)，您可以使用其他兩個字段 開始時間 和 結束時間。當測試開始時，JMeter將在必要時等待，直到到達開始時間。在每個循環的末尾，JMeter檢查是否已經到達了結束時間，如果是，則停止運行，否則測試將繼續運行下去，直到達到迭代限制。
3.2 控制器（Controllers）
JMeter有兩種控制器：採樣器和邏輯控制器。這些驅動測試的處理。
採樣器告訴JMeter發送請求到服務器。例如，如果你想要JMeter發送http請求添加一個HTTP請求取樣器。您還可以通過向採樣器中添加一個或多個配置元素來定製請求。更多信息，參見：採樣器。
邏輯控制器讓你自定義JMeter決定要發送請求時用什麼樣的邏輯。例如，您可以在兩個HTTP請求採樣器之間添加交錯邏輯控制器。有關更多信息，參見：邏輯控制器。
3.2.1 採樣器（Samplers）
採樣員告訴JMeter向服務器發送請求並等待響應。它們按照它們在樹中出現的順序進行處理。控制器可用於修改採樣器的重複次數。
JMeter採樣器包括：
- FTP請求
- HTTP請求(也可以用於SOAP或REST Webservice)
- JDBC請求
- Java對象請求
- JMS請求
- JUnit測試請求
- LDAP請求
- 郵件請求
- 操作系統進程請求
- TCP請求
每個採樣器都有幾個可以設置的屬性。您可以通過在測試計劃中添加一個或多個配置元素來自定義採樣器。
如果要將同一類型的多個請求（例如HTTP請求）發送到同一服務器，請考慮使用默認配置元素。每個控制器都有一個或多個Defaults元素（見下文）。
請記住在測試計劃中添加一個偵聽器，以查看和/或將請求的結果存儲到磁盤。
如果您有興趣讓JMeter對您的請求的響應進行基本驗證，那麼向sampler添加一個 斷言 。例如，在壓力測試web應用程序時，服務器可能返回一個成功的“HTTP響應”代碼，但是頁面可能有錯誤，或者可能缺少部分。您可以添加斷言來檢查某些HTML標記、常見的錯誤字符串等。JMeter允許使用正則表達式創建這些斷言。
3.2.2 邏輯控制器（Logic Controllers）
邏輯控制器讓您自定義JMeter決定要發送請求時的邏輯。邏輯控制器可以改變來自子元素的請求順序。他們可以自己修改請求，導致JMeter重複請求，等等。
要了解邏輯控制器對測試計劃的影響，請考慮以下測試樹:
- 測試計劃
- 線程組
- 僅一次控制器
- 登錄請求(一個HTTP請求)
- 加載搜索頁面(HTTP採樣器)
- 交替控制器
- 搜索“A”(HTTP取樣器)
- 搜索“B”(HTTP取樣器)
- HTTP請求默認值(配置元件)
- HTTP默認請求(配置元件)
- Cookie管理器(配置元件)
這個測試的第一件事是，登錄請求將僅在第一次執行。隨後的迭代將跳過它。這是由於Once Only Controller（只有一次控制器）的影響。
登錄後，下一個採樣器加載搜索頁面(想象一個用戶登錄的web應用程序，然後進入搜索頁面進行搜索)。這只是一個簡單的請求，沒有經過任何邏輯控制器的過濾。
加載搜索頁面後，我們要進行搜索。實際上，我們想做兩種不同的搜索。但是，我們希望在每次搜索之間重新加載搜索頁面本身。我們可以通過4個簡單的HTTP請求元素(加載搜索、搜索“A”、加載搜索、搜索“B”)來實現這一點。相反，我們使用Interleave Controller控制器每次通過測試傳遞一個子請求。它保持了排序(即它不會隨機地傳遞一個，而是“記住”它的子元素的位置)。插入兩個子請求可能會被過度使用，但是可能會有8個或20個子請求。
注意，HTTP Request Defaults屬於Interleave Controller。假設“Search A”和“Search B”共享相同的路徑信息(HTTP請求規範包括域、端口、方法、協議、路徑和參數，以及其他可選項)。這是有意義的——兩者都是搜索請求，命中相同的後端搜索引擎(比如servlet或cgil - script)。我們可以將這些信息抽象爲單個配置元素，而不是在路徑字段中使用相同的信息配置兩個HTTP Samplers。當Interleave控制器“傳遞”來自“Search A”或“Search B”的請求時，它將從HTTP默認請求配置元素的值中填充空白。因此，我們將這些請求的路徑字段留空，並將這些信息放入配置元素中。在這種情況下，這充其量只是一個小的好處，但它展示了這個特性。
樹中的下一個元素是另一個HTTP默認請求，這個時間添加到線程組本身。線程組有一個內置的邏輯控制器，因此，它使用這個配置元素，就像上面描述的那樣。它填入經過的任何請求的空格。在web測試中，將所有HTTP Sampler元素中的域字段保留爲空是非常有用的，相反，將這些信息放入HTTP默認請求元素中，添加到線程組中。通過這樣做，您可以通過改變測試計劃中的一個字段來測試您在不同服務器上的應用程序。否則，你必須編輯每一個採樣器。
最後一個元素是HTTP Cookie管理器。所有web測試都應該添加一個Cookie管理器——否則JMeter將忽略Cookie。通過在線程組級別添加它，我們確保所有HTTP請求將共享相同的cookie。
邏輯控制器可組合實現各種結果。請參閱內置邏輯控制器列表（ built-in Logic Controllers.）。
3.2.3 測試片段（Test Fragments）
測試片段元素是一種特殊類型的控制器，它存在於與線程組元素相同級別的測試計劃樹中。它與線程組不同，因爲它沒有被執行，除非由 模塊控制器 或 包含控制器 引用。
此元素純粹用於測試計劃中的代碼重用。
3.3 偵聽器（Listeners）
當JMeter運行時，偵聽器提供對測試用例的信息JMeter的訪問。圖的結果是監聽器將響應時間繪製在圖上。“視圖結果樹”偵聽器顯示了sampler請求和響應的詳細信息，可以顯示響應的基本HTML和XML表示。其他偵聽器提供彙總信息或聚合信息。
此外，偵聽器可以將數據直接引導到文件中以供以後使用。JMeter中的每個監聽器都提供一個字段來指示要存儲數據的文件。還有一個配置按鈕，可以用來選擇保存哪些字段，以及是否使用CSV或XML格式。
注意，所有偵聽器都保存相同的數據;唯一的區別在於數據在屏幕上呈現的方式。
可以在測試的任何地方添加監聽器，包括直接在測試計劃下。他們只從他們的水平或低於他們水平的元素收集數據。
JMeter這裏有些監聽器。
3.4 定時器（Timers）
默認情況下，JMeter線程在不暫停的情況下依次執行samplers。我們建議您通過向線程組添加一個可用的計時器來指定延遲。如果您不添加延遲，JMeter會在很短的時間內發出太多的請求，從而使服務器不堪重負。
定時器將導致JMeter在每個採樣器在其範圍內延遲一定的時間。
如果您選擇將多個計時器添加到線程組，JMeter將使用計時器的總和，並在執行計時器所應用的samplers之前暫停此時間。計時器可以添加爲samplers或控制器的子元素，以限制應用程序的採樣器。
爲了在測試計劃中提供一個單獨的位置，可以使用Test Action採樣器。
3.5 斷言（Assertions）
斷言允許你斷言你正在測試的服務器返回的結果。通過使用斷言，你基本上可以斷定你的程序返回的結果是否是你期望的值。
例如，你可以斷言一個查詢的返回結果將包含一些特定的文本，特定的文本可以是perl語言的正則表達式，也可以是返回結果中的一部分，或者整個返回值。
你可以爲任何Sampler(取樣器)添加斷言，例如，您可以向“HTTP請求”中添加一個斷言，用來檢查文本 “< / HTML >” 。然後，JMeter將檢查文本‘< / HTML >’是否存在於HTTP響應中。如果JMeter不能找到文本，那麼它將標記爲請求失敗。
注意：斷言適用於所有的取樣器，但是要將斷言限制到具體的某一個取樣器上，要將斷言作爲取樣器的子元素添加。
要查看斷言結果，請向線程組添加一個“斷言結果”，斷言失敗的也會現在樹視圖和表偵聽器中，並將統計到彙總、彙總報告的誤差率裏面。
3.6 配置元件（Configuration Elements）
一個配置元件與採樣器緊密合作。雖然它不發送請求(HTTP(S)測試腳本記錄器 除外)，但它可以添加或修改請求。
一個配置元件只能從放置元素的樹分支中訪問，例如，如果你把一個“HTTP Cookie管理器”放在一個簡單控制器中，只有在簡單控制器內，Cookie管理器纔可以訪問HTTP請求控制器(參見圖1)。Cookie管理器可以訪問HTTP請求“頁面1”和“頁面2”，而不是“頁面3”。
此外，樹分支中的配置元件的優先級高於“父”分支中的相同元素，例如，我們定義二個“HTTP請求默認值”元件：”HTTP請求默認值 1”和”HTTP請求默認值 2”,由於我們將”HTTP請求默認值 2”放在一個循環控制器中的，故只有”頁面2”可以訪問它。其他HTTP請求將使用“HTTP請求默認值 2”，因爲我們將它放入了線程組(所有其他分支的“父”)。
圖1 測試計劃顯示了配置元件的可訪問性
注意：配置元件中的”用戶定義的變量”與其它元件是有區別的。它是在測試開始時進行處理的，而不管我們將它放在哪裏。爲了簡單起見，建議將它放在線程組的開始處。
3.7 前置處理器（Pre-Processor Elements）
預處理器在執行Sampler(採樣器)請求之前執行一些操作。如果一個預處理器被附加到一個採樣器元件上，那麼它就會在這個採樣器元件運行之前執行。預處理程序通常用於在運行前修改採樣品請求的設置，或者更新不是從響應文本中提取的變量。有關何時執行預處理器的詳細信息，請參閱3.10小節。
3.8 後置處理器（Post-Processor Elements）
在採樣器請求完成後，後處理器執行一些操作。如果一個後處理器被附加到一個採樣器元件上，那麼它將在Sampler元件運行後執行。後處理器通常用於處理響應數據，通常是從它提取值。有關何時執行後處理程序的詳細信息，請參閱3.10小節。
3.9 執行順序（Execution order）
0.配置元件 1.前置處理器 2.定時器 3.採樣器 4.後置處理器(假設採樣器結果不爲空) 5.斷言(假設採樣器結果不爲空) 6.監聽器(假設採樣器結果不爲空)
請注意，定時器、斷言、預處理器和後處理器只在有一個他們應用的採樣器的情況下進行處理。邏輯控制器和採樣器
按它們出現在樹中的順序進行處理。其他測試元件根據被發現的範圍和測試元件的類型進行處理。[在一種類型中，
元素按其出現在樹中的順序進行處理]。
例如：在下面的測試計劃中：
- 控制器
- 後置處理器 1
- 採樣器 1
- 採樣器 2
- 定時器 1
- 斷言 1
- 前置處理器 1
- 定時器2
- 後置處理器 2
執行順序是：
前置處理器 1
定時器 1
定時器2
採樣器1
後置處理器1
後置處理器2
斷言1
前置處理器1
定時器1
定時器2
採樣器2
後置處理器1
後置處理器2
斷言1
3.10 範圍規則（Scoping Rules）
JMeter測試樹包含分層和有序的元素。測試樹中的有些元件是嚴格分層的(監聽器、配置元件、後置處理器、前置處理器、斷言、定時器),而有些元素是有序的(控制器、採樣器)。當您創建測試計劃時，您將創建一個有序的採樣請求列表(通過採樣器)，它表示將要執行的一系列步驟。這些請求通常都是在控制器中進行組織的，它們也是有序的。例如，給定以下測試樹:
圖：測試樹示例
請求順序將是：網頁1，網頁2，網頁3，網頁4
一些控制器影響其子元素的順序，您可以在組件參考文獻中瞭解這些特定的控制器。
其他元素是分層的。例如，斷言在測試樹中是分層的。如果它的父元素是一個請求，那麼它將被應用到該請求。如果它的父節點是一個控制器，那麼它將影響到該控制器的後代的所有請求。在以下測試樹中:
圖：分層的示例
斷言1只應用於網頁1，而斷言2應用於網頁2和3。
另一個例子，這次使用計時器:
圖：複雜的例子
在這個例子中，請求的命名可以反映它們將被執行的順序。定時器1將應用於網頁2、3和4(注意順序如何與分層元素無關)。斷言1只適用於網頁3。定時器 2將影響所有網頁。
希望這些示例能清楚地說明如何配置應用到的(分層)元素。如果你想象成每個請求都被傳遞到了樹分支、再到其父節點、最後到父節點的父節點等等，並且每次都收集父節點的所有配置元件，你將明白它是如何工作的。
配置元件中的頭管理器、Cookie管理器和授權管理器的處理方式與配置默認元件不同。配置默認元件的設置
被合併到一組採樣器可以訪問的值中。但是，管理器的設置並沒有被合併。在一個採樣器的範圍內，如果不止
一個管理器，但是隻使用到了一個管理器，目前沒有辦法確定使用了哪個管理器。
3.11 屬性和變量（Properties and Variables）
JMeter屬性在JMeter.屬性中定義(查閱 開始-配置JMeter獲得更多細節)。
屬性是jmeter的全局屬性，主要用於定義一些jmeter使用的默認值。例如，屬性 remote_hosts 定義了JMeter將試圖遠程運行的服務器。屬性可以在測試計劃中引用（參見函數—讀取屬性），但不能用於線程特定的值。
JMeter變量僅僅侷限於每個線程。每個線程的值可能相同，也可能不同。如果一個變量被一個線程更新，那麼只有變量的這個線程副本被更改。例如，正則表達式提取器後置處理器將根據線程讀取的採樣器來設置變量，這些變量後面可以被相同的線程使用。有關如何引用變量和函數的詳細信息，請參見函數和變量。
注意，測試計劃定義的值和用戶定義變量的配置元件在啓動時可用於整個測試計劃。如果同一個變量被多個UDV元素定義，那麼變量等於最後一次設置的值。一旦線程啓動，變量初始集將被複制到每個線程。其他元素，如用戶參數預處理器或正則表達式提取器後置處理器可能被用來重新定義相同的變量(或創建一個新變量)。這些重新定義只適用於當前線程。
可以使用setProperty函數來定義JMeter屬性。這些在測試計劃中是全局的，因此可以用於在線程之間傳遞信息——應該是需要的。
變量和屬性都是大小寫敏感的。
3.12 使用變量來參數化測試（Using Variables to parameterise tests）
變量不是一定要改變值，它們可以定義一次，如果單獨使用，則不會改變值。因此，您可以使用它們作爲在測試計劃中頻繁出現的表達式的短手，或者是在運行期間的一個常量，但在運行期間可能會有所改變。例如，主機名，或線程組中的線程數。
在決定如何構建一個測試計劃時，要注意運行時哪些項是常量，哪些項在運行期間可能會發生變化。爲這些常量取一些變量名稱（可以使用命名約定），比如：用C_或K_來作爲前綴或者全使用大寫字母，來與在運行期間會發生變化的變量進行區分。還要考慮哪些項目需要本地的線程——例如使用正則表達式後處理器提取的計數器或值。您可能希望使用不同的命名約定。
除此之外，你需要考慮哪些項目僅僅侷限於一個線程，例如使用”正則表達式“後置處理器提取的計數器或值。您可能希望使用不同的命名約定。
例如，您可以在測試計劃中定義以下內容:
HOST www.example.com
THREADS 10
LOOPS 20
您可以在測試計劃中用類似$ { HOST} 、 $ { THREADS }來引用這些變量，如果您後面想要更改主機，只需更改主機變量的值。對於少量的測試，這樣做很好，但是在測試許多不同的組合時就變得單調乏味了。因此，可以使用屬性來定義變量的值，例如:
HOST ${__P(host,www.example.com)}
THREADS ${__P(threads,10)}
LOOPS ${__P(loops,20)}
然後你可以在命令行，用如下命令來更改部分或全部值，如下:
jmeter … -Jhost=www3.example.org -Jloops=13