Jmeter(三) - 測試計劃（Test Plan）的元件

1.簡介

上一篇已經教你如何通過JMeter來創建一個測試計劃（Test Plan），那么這一篇我們就將JMeter啟動起來，創建一個測試計劃（Test plan），給大家介紹一下測試計劃（Test Plan）有哪些元件組成的。

2.測試計劃（Test?Plan）要素

本節主要描述測試計劃的不同部分要素。JMeter中一個腳本就是一個測試計劃（Test Plan），也是一個管理單元。JMeter 的請求模擬與并發數(設置線程數，一個線程代表一個虛擬用戶)設置都在腳本文件中一起設置。JMeter 不像 LoadRunner 把腳本與虛擬用戶設置分開。

2.1測試計劃要素如下：

（1）要素一：腳本中測試計劃只能有一個
　　1、Jmeter 測試計劃類似 LoadRunner Controller 中的測試場景，同一時刻場景故然只能有一個，。
　　2、JMeter 腳本在 GUI 中顯示時是樹型結構，測試計劃是根節點，根節點當然只能有一個。
（2）要素二：測試計劃中至少要有一個線程組
　　1、JMeter 負裁是通過線程組驅動的，所以計劃中至少要出現一個線程組。
　　2、JMeter 測試計劃支持多個線程組。
　　3、我們可以在計劃下面建立多個線程組，類似 LoadRunner 中的 Group 方式的場景，我們可以把JMeter 計劃理解成LoadRmmer 中的 Group 方式場景，把不相關聯的業務分布在不同的線程組中( LoadRunner 中的不同 Group)。
（3）要素三：至少要有一個取樣器
　　1、測試的目的就是要模擬用戶請求，沒有取樣腳本就毫無意義。
（4）要素四：至少要有一個監聽器
　　1、測試結果用來衡量系統性能，我們需要從結果中分析系統性能。

3.測試計劃（Test Plan）元件

打開Jmeter頁面：包括測試計劃+工作臺。

注意：最新版的jmeter去掉了工作臺。不要大驚小怪，我的JMeter為什么沒有工作臺，我同事的有工作臺，如果你是在想要就下載一個低版本的JMeter安裝好啟動以后，就可以看到你的JMeter也有工作臺了。

3.1測試計劃（Test Plan）

Test Plan (測試計劃)：用來描述一個性能測試，包含與本次性能測試所有相關的功能。也就說性能測試的所有內容是于基于一個計劃的。
右鍵單擊“測試計劃”彈出菜單：
它用來描述一個測試方案，包含與本次性能測試所有相關的功能。也就說本次測試的所有內容是于基于一個計劃的。

注意：

測試計劃對象具有一個名為“ 函數測試模式 ” 的復選框。如果選擇，它將使JMeter記錄每個樣本從服務器返回的數據。如果您在測試偵聽器中選擇了文件，則此數據將被寫入文件。如果要進行少量運行以確保正確配置JMeter并確保服務器返回預期結果，這將很有用。結果是文件將快速增長，JMeter的性能將受到影響。如果要進行壓力測試，則應禁用此選項（默認情況下處于禁用狀態）。
如果您沒有將數據記錄到文件中，則此選項沒有區別。
您還可以使用監聽器上的“ 配置”按鈕來確定要保存的字段。

3.2線程組Threads?（Users）

線程組元素是任何測試計劃的起點。所有控制器和采樣器必須在線程組下。其他元素（例如，偵聽器）可以直接放置在測試計劃下，在這種情況下，它們將應用于所有線程組。顧名思義，線程組元素控制JMeter將用于執行測試的線程數。線程組的控件使您可以：

設置線程數
設置加速時間
設置執行測試的次數

每個線程將完整地執行測試計劃，并且完全獨立于其他測試線程。多個線程用于模擬與服務器應用程序的并發連接。
加速期告訴JMeter將“加速”到所選線程的總數需要多長時間。如果使用了10個線程，并且啟動周期為100秒，那么JMeter將花費100秒來啟動和運行所有10個線程。每個線程將在上一個線程開始后10（100/10）秒開始。如果有30個線程，啟動周期為120秒，則每個連續線程將延遲4秒。
加速需要足夠長的時間來避免在測試開始時工作量過大，并且還必須足夠短以使最后一個線程在第一個線程完成之前開始運行（除非有人希望這種情況發生）。
從“上升=線程數”開始，然后根據需要向上或向下調整。
默認情況下，線程組配置為在其元素之間循環一次。
線程組還提供了調度程序。單擊“線程組”面板底部的復選框以啟用/禁用其他字段，您可以在其中輸入測試的持續時間，啟動延遲，運行的開始和結束時間。您可以配置持續時間（秒）和啟動延遲（秒）來控制每個線程組的持續時間以及啟動后的秒數。當測試開始時，JMeter將在啟動線程組的線程之前等待啟動延遲（秒），然后運行配置的持續時間（秒）。請注意，這兩個選項會覆蓋“ 開始時間”和“ 結束時間”。
另外，您也可以使用其他兩個字段Start time和End time（盡管不建議這樣做，因為它不太靈活）。測試開始時，如有必要，JMeter將等待直到達到啟動時間。在每個周期的末尾，JMeter會檢查是否已達到結束時間，如果已結束，則運行將停止，否則，將允許測試繼續進行直到達到迭代限制。

線程組的添加路徑：【測試計劃】-【THreads（Users）線程組】

3.2.1添加線程組

選中要添加線程組的測試計劃（Test Plan），右鍵點擊“Add”，選中“Threads（Users）”，我們目前可以看到三個線程組。

雖然有三個添加線程組的選項，名字不一樣，創建之后，其界面是完全一樣的。之前的版本只有一個線程組的名字。現在多一個setUp theread Group 與terDown Thread Group

1) setup thread group
一種特殊類型的ThreadGroup的，可用于執行預測試操作。這些線程的行為完全像一個正常的線程組元件。不同的是，這些類型的線程執行測試前進行定期線程組的執行。
setUp Thread Group類似于lr的init.可用于執行預測試操作。
2) teardown thread group.
一種特殊類型的ThreadGroup的，可用于執行測試后動作。這些線程的行為完全像一個正常的線程組元件。不同的是，這些類型的線程執行測試結束后執行定期的線程組。
tearDown Thread Group類似于lr的end.可用于執行測試后動作。
3) thread group(線程組).
這個就是我們通常添加運行的線程。通俗的講一個線程組，可以看做一個虛擬用戶組，線程組中的每個線程都可以理解為一個虛擬用戶。線程組中包含的線程數量在測試執行過程中是不會發生改變的。

3.2.2線程組界面介紹

這個就是我們通常添加運行的線程。通俗的講一個線程組,，可以看做一個虛擬用戶組，線程組中的每個線程都可以理解為一個虛擬用戶。
Ramp-Up Period：單位是秒，默認時間是1秒。它指定了啟動所有線程所花費的時間。如果你需要Jmeter立即啟動所有線程，將此設定為0即可
循環次數：表示每個線程執行多少次請求。

名稱：就如字面意思，起個有意義的名字就行

注釋：
線程數：這里選擇1
Ramp-Up Period：單位是秒，默認時間是1秒。它指定了啟動所有線程所花費的時間，比如，當前的設定表示“在5秒內啟動5個線程，每個線程的間隔時間為1秒”。如果你需要Jmeter立即啟動所有線程，將此設定為0即可
循環次數：表示每個線程執行多少次請求。

3.3拓展

這個是關于階梯加壓線程組，后期關于這部分會詳細介紹，這里先提一下，有興趣的自己可以研究一下，很簡單的需要給JMeter下載安裝一個插件就可以了。

注意：Stepping Thread Group 可用于模擬階梯加壓！

3.4控制器(Controllers)

JMeter有兩種類型的控制器：采樣器和邏輯控制器。用這些元件來驅動測試的進行。
采樣器告訴JMeter將請求發送到服務器。例如，如果您希望JMeter發送HTTP請求，則添加一個HTTP Request Sampler。您還可以通過將一個或多個配置元素添加到采樣器來自定義請求。有關更多信息，請參見采樣器。
邏輯控制器使您可以自定義JMeter用于決定何時發送請求的邏輯。例如，您可以添加一個Interleave Logic Controller在兩個HTTP Request Samplers之間交替。有關更多信息，請參見邏輯控制器。

3.5采樣器(Samplers)

采樣器也可以翻譯成取樣器；用來模擬用戶的操作，向服務器（被測系統）發出Http請求、WebService（SOAP/XML-RPC Request）請求或者Java請求等。我們可以把Http請求元件看成是一個沒有界面的瀏覽器，它可以發送Http請求，接收服務器的響應數據。采樣器（Sampler）是測試中向服務器發送請求，記錄響應信息，記錄響應時間的最小單元，JMeter 原生支持多種不同的sampler 。如 HTTP Request Sampler 、 FTP Request Sampler 、TCP Request Sampler 、JDBC Request Sampler 等。高版本的jmeter支持更豐富的Sampler。

采樣器的添加路徑：【測試計劃】-【線程組】-【采樣器】。
采樣器告訴JMeter將請求發送到服務器并等待響應。它們按照它們在樹中出現的順序進行處理。控制器可用于修改采樣器的重復次數。
JMeter采樣器包括：
FTP請求
HTTP請求（也可用于SOAP或REST Web服務）
JDBC請求
Java對象請求
JMS請求
JUnit測試請求
LDAP要求
郵件要求
操作系統進程請求
TCP請求
每個采樣器都有幾個可以設置的屬性。您可以通過向測試計劃中添加一個或多個配置元素來進一步自定義采樣器。
如果要將相同類型的多個請求（例如HTTP請求）發送到同一服務器，請考慮使用默認配置元素。每個控制器都有一個或多個Defaults元素（請參見下文）。
切記在測試計劃中添加一個偵聽器，以查看和/或將請求結果存儲到磁盤。
如果您有興趣讓JMeter對請求的響應執行基本驗證，請將Assertion添加到采樣器。例如，在對Web應用程序進行壓力測試時，服務器可能返回成功的“ HTTP響應”代碼，但是頁面上可能有錯誤或缺少部分。您可以添加斷言來檢查某些HTML標記，常見錯誤字符串等。JMeter允許您使用正則表達式創建這些斷言。

3.6邏輯控制器(Logic Controllers)

邏輯控制器使您可以自定義JMeter用于決定何時發送請求的邏輯。邏輯控制器可以更改來自其子元素的請求的順序。他們可以自己修改請求，使JMeter重復請求，等等。
邏輯控制器器的添加路徑：【測試計劃】-【線程組】-【邏輯控制器】。
要了解邏輯控制器對測試計劃的影響，請看一下以下測試樹：

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”的作用。
登錄后，下一個Sampler將加載搜索頁面（我們可以想象一個測試場景：用戶登錄到Web應用程序，然后轉到搜索頁面進行搜索）。這只是一個簡單的請求，不會通過任何邏輯控制器進行過濾。
加載搜索頁面后，我們要進行搜索。實際上，我們要進行兩種不同的搜索。但是，我們希望在每次搜索之間重新加載搜索頁面本身。我們可以通過具有4個簡單的HTTP請求元素（加載搜索，搜索“ A”，加載搜索，搜索“ B”）來實現。相反，我們使用“Interleave Controller”，該控制器每次通過測試都會傳遞一個子請求。它保持子元素的順序（即，它不會隨機傳遞，而是“記住”其位置）。交叉處理2個子請求可能會過多，但很容易會有8個或20個子請求。

注意HTTP請求默認值屬于Interleave Controller。想象一下，“搜索A”和“搜索B”共享相同的PATH信息（HTTP請求規范包括域，端口，方法，協議，路徑和參數以及其他可選項）。這很有道理-都是搜索請求，都命中了相同的后端搜索引擎（例如servlet或cgi-script）。與其在PATH字段中為兩個HTTP Samplers配置相同的信息，不如將這些信息抽象到單個Configuration Element中。當Interleave Controller“傳遞”來自“搜索A”或“搜索B”的請求時，它將使用HTTP default request配置元件中的值填充空白。因此，對于這些請求，我們將PATH字段留空，并將該信息放入配置元素。在這種情況下，這充其量是次要的好處，但可以證明其功能。
樹中的下一個元素是另一個HTTP default request，這次已添加到線程組本身。線程組具有內置的邏輯控制器，因此，它完全如上所述使用此配置元件。它填補了所有通過的請求的空白。因此在Web測試中，將所有HTTP Sampler元件中的DOMAIN字段保留為空白，然后將該信息放入HTTP默認請求元素（添加到線程組中）非常有用。這樣，您只需更改測試計劃中的一個字段即可在另一臺服務器上測試應用程序。否則，您將必須編輯每個Sampler。
最后一個元件是HTTP?Cookie Manager。Cookie Manager應添加到所有Web測試中-否則JMeter將忽略cookie。通過在線程組級別添加它，我們確保所有HTTP請求將共享相同的cookie。
邏輯控制器可以組合使用以獲得各種結果。請參閱內置邏輯控制器列表。

3.7測試片段（Test Fragments）

測試片段元素是一種特殊類型的控制器，它與線程組元素位于同一級別的測試計劃樹上。它與線程組的區別在于，除非被模塊控制器或Include_Controller引用，否則它不會執行。
此元件僅用于測試計劃中的代碼重用。它是一個輔助的組件，在此節點下幾乎可以放置任何JMeter測試元件，但它一般不會被運行，那么它的作用到底是什么了？
（1）在腳本開發的過程中，可以用來備份元件。
（2）可以被模塊控制臺調用，我們可以用它模塊化請求（是不是有點似曾相識的感覺了，沒錯就是程序開發中的，將業務封裝成一個方法供復用）供模塊化控制器調用

3.8監聽器(Listeners)

監聽器提供對JMeter運行時JMeter收集的有關測試用例的信息的訪問。圖形結果聽者曲線在曲線圖上的響應時間。“查看結果樹”偵聽器顯示采樣器請求和響應的詳細信息，并可以顯示響應的基本HTML和XML表示形式。其他偵聽器提供摘要或聚合信息。
此外，監聽器可以將數據定向到文件以供以后使用。JMeter中的每個監聽器都提供一個字段來指示要將數據存儲到的文件。還有一個“配置”按鈕，可用于選擇要保存的字段以及使用CSV還是XML格式。
請注意，所有監聽器都保存相同的數據。唯一的區別在于數據在屏幕上的顯示方式。
可以在測試中的任何位置（包括直接在測試計劃下）添加監聽器。他們將僅從其級別或以下級別的元素收集數據。
JMeter附帶了多個監聽器。JMeter的測試結果需要添加監聽器來收集。

監聽器的添加路徑：【測試計劃】-【監聽器】

3.8.1監聽器的任務

（1）添加監聽結果，并且可以保存測試結果到文件中，這些測試結果可以供再次分析使用。
（2）展示結果，JMeter可以以表格以及圖形的形式展示測試結果，方便測試人員分析測試結果。我們在開發測試腳本的時候，不可避免需要調試，監聽器也提供了輔助（例如：我們查看結果樹，我們在其中可以看到請求與響應的數據）。

3.9定時器（Timer）

默認情況下，JMeter線程按順序執行采樣器而不會暫停。我們建議您通過將可用計時器之一添加到線程組來指定延遲。如果不添加延遲，JMeter可能會在很短的時間內發出太多請求，從而使服務器不堪重負。這就是我們通常說的負載，為了足夠真實的模擬用戶負載，我們有時候會需要模擬這些請求在同一時刻發送，就好像把大家集合在同一起跑線上，然后扣動發令槍的扳機，同時向終點（被測試系統）沖去。
計時器將導致JMeter 在其范圍內的每個采樣器之前延遲一定的時間。
如果您選擇在一個線程組中添加多個計時器，JMeter將使用計時器的總和，并在執行該計時器所適用的采樣器之前暫停該時間。可以將計時器作為采樣器或控制器的子級添加，以限制將它們應用到的采樣器。
要在測試計劃中的單個位置提供暫停，可以使用Flow Control Action Sampler。

定時器的添加路徑：【測試計劃】-【線程組】-【定時器】。

3.10斷言

說到斷言對于我們一個測試來說應該很熟悉了吧。斷言用來驗證結果是否正確，說白了就是用一個預設的結果（期望值、表達式、時間長短等條件）與實際結果匹配，匹配到成功，反之失敗。斷言使您可以斷言有關從被測試服務器收到的響應的事實。使用斷言，您基本上可以“測試”您的應用程序正在返回期望的結果。
例如，您可以斷言對查詢的響應將包含一些特定的文本。您指定的文本可以是Perl樣式的正則表達式，并且可以指示響應包含文本，或者應與整個響應匹配。
您可以將斷言添加到任何采樣器。例如，您可以將斷言添加到HTTP請求中以檢查文本“ </ HTML> ”。然后，JMeter將檢查該文本是否出現在HTTP響應中。如果JMeter找不到文本，則它將標記為失敗的請求。
請注意，斷言適用于其范圍內的所有采樣器。要將聲明限制為單個采樣器，請將該聲明添加為采樣器的子代。
要查看斷言結果，請將“斷言偵聽器”添加到線程組。失敗的斷言還將顯示在樹視圖和表偵聽器中，并將計入錯誤百分比，例如在“匯總”和“摘要”報告中。

3.11配置元件

性能測試中為了模擬大量的用戶操作系統，我們往往需要做參數化，JMeter的參數化可以通過配置元件來完成。例如：CSV Data Set Config，它可以幫助我們從文件中讀取測試數據。另外JMeter也提供了眾多函數（通過函數助手可以查看到，后續會講到，這里只是簡單的提一下）來幫助我們動態的生成數據。當然了配置元件的作用不僅于此，它還可以記錄服務器的返回數據，例如：Http Cache Manager，自動記錄服務器返回的Cache信息，簡而言之就是它為取樣器提供預備數據，然后由取樣器發出請求。配置元素與采樣器緊密配合。盡管它不發送請求（HTTP（S）測試腳本記錄器除外），但是它可以添加或修改請求。
配置元素只能從放置該元素的樹枝內部訪問。例如，如果您將HTTP Cookie Manager放置在簡單邏輯控制器中，則您放置在Simple Logic Controller中的HTTP請求控制器將只能訪問Cookie Manager（請參見圖1）。Cookie管理器可用于HTTP請求“網頁1”和“網頁2”，但不能訪問“網頁3”。
而且，樹枝內部的配置元素比“父”分支中的相同元素具有更高的優先級。例如，我們定義了兩個HTTP請求默認值元素：“ Web默認值1”和“ Web默認值2”。由于我們在循環控制器內放置了“ Web Defaults 1”，因此只有“ Web Page 2”可以訪問它。其他HTTP請求將使用“ Web默認值2”，因為我們將其放置在線程組（所有其他分支的“父級”）中。

圖1-顯示配置元素可訪問性的測試計劃

在用戶定義的變量配置元素是不同的。無論在何處放置，都將在測試開始時對其進行處理。為簡單起見，建議將元素僅放置在線程組的開始處。

配置元件的添加路徑：【測試計劃】-【配置元件】。

3.12前置處理器

預處理器在發出“采樣器請求”之前執行一些操作。如果將預處理器附加到Sampler元素，則它將在該Sampler元素運行之前執行。預處理器最常用于在樣品請求運行前修改其設置，或更新未從響應文本中提取的變量。有關執行預處理器的更多詳細信息，請參見作用域規則。這塊舉一個使用這個元件的測試場景：在測試腳本的開發過程中，我們在請求發送之前可能會做一些環境或者參數的準備工作，那么我們可以在前置處理器中來完成這些工作。例如：我們對數據庫進行操作前需要建立一個數據庫連接，那么前置處理器就可以完成這個功能。

前置處理器的添加路徑：【測試計劃】-【前置處理器】。

3.13后置處理器

后置處理器一般放在取樣器之后，用來處理服務器的返回結果，例如：一個Web應用程序，我們登錄之后會返回一個SessionID，這個SessionID在登錄之后的業務操作過程中會作為驗證條件，驗證用戶是否合法登錄了之后才進行的業務操作。發出采樣器請求后，后處理器將執行某些操作。如果將后處理器附加到Sampler元素，則它將在該Sampler元素運行之后立即執行。后處理器最常用于處理響應數據，經常從中提取值。有關執行后處理器的更多詳細信息，請參見作用域規則。

到此，我們已經簡單了解了jmeter的基本組成原件，我們后序的測試工作也就是使用這些元件來完成測試任務。

3.14執行順序

配置元素
預處理器
計時器
取樣器
后處理器（除非SampleResult為null）
斷言（除非SampleResult為null）
監聽器（除非SampleResult為null）

請注意，計時器，斷言，預處理器和后處理器只有在有適用的采樣器時才被處理。邏輯控制器和采樣器按照它們在樹中出現的順序進行處理。其他測試元素將根據其發現范圍和測試元素的類型進行處理。[在一種類型中，元素按照它們在樹中出現的順序進行處理]。

例如，在以下測試計劃中：

控制器
- 后處理器1
- 采樣器1
- 采樣器2
- 計時器1
- 斷言1
- 預處理器1
- 計時器2
- 后處理器2

執行順序為：

預處理器1
計時器1
計時器2
采樣器1
后處理器1
后處理器2
斷言1預處理器1
計時器1
計時器2
采樣器2
后處理器1
后處理器2
斷言1

3.15范圍鑒定規則

JMeter測試樹包含分層和有序的元素。測試樹中的某些元素嚴格地是分層的（偵聽器，配置元素，后處理器，預處理器，斷言，計時器），而有些則主要是有序的（控制器，采樣器）。創建測試計劃時，您將創建樣本請求的有序列表（通過Samplers），該列表表示要執行的一組步驟。這些請求通常在也已排序的控制器中組織。給定以下測試樹：

示例測試樹

請求的順序將為一，二，三，四。

某些控制器會影響其子元素的順序，您可以在組件參考中閱讀有關這些特定控制器的信息。

其他元素是分層的。例如，斷言在測試樹中是分層的。如果其父項是一個請求，則將其應用于該請求。如果其父級是Controller，則它將影響該Controller的所有后代請求。在以下測試樹中：

層次結構示例

斷言1僅適用于請求1，而斷言2僅適用于請求2和3。

另一個示例，這次使用Timers：

復雜的例子

在此示例中，對請求進行命名以反映其執行順序。計時器＃1將應用于請求2、3和4（請注意順序與分層元素無關）。斷言1僅適用于請求三。計時器2將影響所有請求。

希望這些示例可以清楚說明如何應用配置（分層）元素。如果您想象每個請求都在樹枝上傳遞給它的父級，然后傳遞給它的父級的父級，等等，并且每次收集該父級的所有配置元素，那么您將了解它是如何工作的。

配置元素的標題管理器，Cookie管理器和授權管理器與配置默認元素的處理方式有所不同。“配置默認值”元素中的設置被合并為采樣器可以訪問的一組值。但是，管理器中的設置不會合并。如果在一個采樣器的范圍內有多個Manager，則僅使用一個Manager，但是目前無法指定使用哪個?Manager?。

3.16屬性和變量

JMeter?屬性在jmeter.properties中定義（有關更多詳細信息，請參見入門-配置JMeter）。
屬性對于jmeter是全局的，并且主要用于定義JMeter使用的某些默認值。例如，屬性remote_hosts定義JMeter將嘗試遠程運行的服務器。可以在測試計劃中引用屬性-請參閱功能-讀取屬性?-但不能用于特定于線程的值。

JMeter?變量是每個線程局部的。每個線程的值可以相同，也可以不同。
如果某個變量由線程更新，則僅更改該變量的線程副本。例如，正則表達式提取器后處理器將根據其線程讀取的樣本設置其變量，這些變量稍后可在同一線程中使用。有關如何引用變量和函數的詳細信息，請參見函數和變量

請注意，在啟動時，將使?“?測試計劃”?和“?用戶定義的變量”配置元素定義的值可用于整個測試計劃。如果同一變量由多個UDV元素定義，則最后一個變量生效。線程啟動后，會將初始變量集復制到每個線程。其他元素（例如?用戶參數預處理器或正則表達式提取器后處理器）可用于重新定義相同的變量（或創建新變量）。這些重新定義僅適用于當前線程。

所述的setProperty函數可以用來定義JMeter的屬性。這些對于測試計劃是全局的，因此可以用于在線程之間傳遞信息-如果需要的話。

變量和屬性都區分大小寫。

3.17使用變量對測試參數化

變量不必更改-可以定義一次，并且如果單獨保留，則不會更改值。因此，您可以將它們用作測試計劃中經常出現的表達式的簡寫形式。或對于在運行期間保持恒定但在運行之間可能有所不同的項目。例如，主機名或線程組中的線程數。
在決定如何構建測試計劃時，請記下哪些項目對于運行是恒定的，但在運行之間可能會改變。為此確定一些變量名稱-也許使用命名約定，例如以C_或K_前綴，或僅使用大寫字母將它們與測試期間需要更改的變量區分開。還應考慮哪些項需要在線程本地進行，例如使用正則表達式后處理程序提取的計數器或值。您可能希望對它們使用不同的命名約定。
例如，您可以在測試計劃中定義以下內容：

主機www.example.com
底線10
圈數20

您可以在測試計劃中將它們稱為$ {HOST} $ {THREADS}等。如果以后要更改主機，只需更改HOST變量的值即可。這對于少量的測試工作正常，但是在測試許多不同的組合時變得乏味。一種解決方案是使用屬性來定義變量的值，例如：

主機$ {__ P（host，www.example.com）}
螺紋$ {__ P（threads，10）}
循環$ {__ P（loops，20）}

然后，您可以在命令行上更改某些或所有值，如下所示：

jmeter…-Jhost = www3.example.org -Jloops = 13

4.小結

關測試計劃（Test Plan）的元件就分享到這里，后邊后對這些元件進行詳細的介紹和說明