-------------------------------------------------------------------

轉載自：北京-巨集哥

https://www.cnblogs.com/du-hong/p/12909175.html

--------------------------------------------------------------------

1.簡介

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

2.測試計劃（TestPlan）要素

本節主要描述測試計劃的不同部分要素。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 (anHTTP 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。
最後一個元件是HTTPCookie 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將應用於請求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）的元件就分享到這裡，後邊後對這些元件進行詳細的介紹和說明，以及會涉及到部分元件的實際應用。灰常感謝您閱讀到這裡，如果您覺得不錯，就幫忙點個推薦唄。