jmeter測試計劃元件

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)
  - 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使用變量對測試參數化

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

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

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