Jmeter(三) - 從入門到精通 - 測試計劃（Test Plan）的元件（詳解教程）

1.簡介

上一篇中宏哥已經教你如何經過JMeter來建立一個測試計劃（Test Plan），那麼這一篇咱們就將JMeter啓動起來，建立一個測試計劃（Test plan），而後宏哥給你們介紹一下測試計劃（Test Plan）有哪些元件組成的。

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

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

2.1測試計劃要素以下：

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

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執行順序

0. 配置元素
1. 預處理器
2. 計時器
3. 取樣器
4. 後處理器（除非SampleResult爲null）
5. 斷言（除非SampleResult爲null）
6. 監聽器（除非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將應用於請求二、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）的元件就分享到這裏，後邊後對這些元件進行詳細的介紹和說明，以及會涉及到部分元件的實際應用。灰常感謝您閱讀到這裏，若是您以爲不錯，就幫忙點個推薦唄。

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

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