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）的元件就分享到這裏，後邊後對這些元件進行詳細的介紹和說明，以及會涉及到部分元件的實際應用。灰常感謝您閱讀到這裏，如果您覺得不錯，就幫忙點個推薦唄。

您的肯定就是我進步的動力。如果你感覺還不錯，就請鼓勵一下吧！記得隨手點波推薦不要忘記哦！！！

別忘了點推薦留下您來過的痕跡