JMeter-03-主要功能介紹（依據官方標準腳本）

1.怎麼打開JMeter

上一篇博文講了，JMeter不需要安裝，所以開啓的時候，有10種方法：

1. 去“\apache-jmeter-5.1.1\bin\”的目錄下，找到ApacheJMeter.jar即可開啓。
2. bin下，找到ApacheJMeter.jar，然後建立桌面快捷方式（老哥我懷疑你在強行湊數，但我沒有證據。。。）
3. bin下，找到jmeter.bat即可開啓（GUI模式）。
4. bin下，找到jmeterw.cmd即可開啓，此方式不會打開Windows Shell（GUI模式）。
5. bin下，找到jmeter-n.cmd即可開啓，但是會刪除jmx腳本（非GUI模式）。
6. bin下，找到jmeter-n-r.cmd即可開啓，但是會刪除jmx腳本（非GUI的遠程模式）。
7. bin下，找到jmeter-t.cmd即可開啓，但是會刪除jmx腳本（GUI模式）。
8. bin下，找到jmeter-server.bat，可開啓服務器模式。
9. bin下，找到jmeter.sh即可開啓（GUI模式）。
10. 使用cmd控制檯開啓，先cd到ApacheJMeter.jar所在的路徑，然後通過“java -jar arg”命令開啓，如下圖：
    
    注意看，啓動時，JMeter會提示“Don‘t use GUI mode for load testing.”，意思其實是說，JMeter是支持無界面運行的，因爲有界面的模式會影響壓力或負載測試的準確度。但是爲了做下文的演示，我還是開啓GUI模式，非GUI模式會在之後的博文中進行介紹。

2.開始之前的設置

JMeter對於中文支持得已經很棒了，所以，我們把語言設置成中文，可以方便大家理解，如下圖：

就可以設置成簡體中文了。

3.官方標準腳本模板

上來就巴拉巴拉說一大堆功能組件什麼的，大家肯定會暈，所以我覺得官方的腳本模板就是一個很好的切入點，這樣即可以看看一個標準的、結構清晰、功能完備的腳本長啥樣，也可以初步認識下主要的功能組件。JMeter自帶腳本在哪呢？如下圖：

以Web test plan爲例，JMeter會生成一個標準的測試腳本模板，如下圖：

4.腳本里用到的主要功能組件

4.1測試計劃（Test Plan）

測試計劃是一項測試的根節點，用於描述整個的性能/功能測試，包含本次測試的所有相關功能。

4.2配置元件（Configuration Elements）

簡單來說配置元件就是對於請求做各種配置的一系列組件，它是與取樣器（發請求的東東）聯繫最緊密的組件，雖然它不能發送請求，但是它可以添加或修改請求。

4.2.1HTTP請求默認值（HTTP Request Defaults）

這麼理解這個元件會簡單些：該元件，用於設置其他HTTP請求取樣器能用到的默認的值。例如，如果你的測試計劃下面有很多請求都是指向相同的服務器地址/URL路徑/端口號/請求參數等，那麼你可以將這些數據保存在“HTTP請求默認值”元件中，然後再在其下方創建的任何HTTP請求取樣器，如果不單獨指定這些數據，那麼它們都可以直接繼承“HTTP請求默認值”元件中的服務器地址/URL路徑/端口號/請求參數。如下圖：

4.2.2用戶定義的變量（User Defined Variables）

這個元件，真香，因爲它是實現腳本參數化的最重要的元件。當你的測試步驟非常多，又用到了很多重複的數據時，一定要把這些數據作爲參數提取出來，配置到“用戶自定義的變量”元件中，這樣在後期維護腳本的時候，會節省很多的時間。如下圖：

上圖中這個參數host，在本文上一節的“HTTP請求默認值”元件中被設置爲默認值，當然也可以在其他任何地方通過${host}這種格式進行調用，很方便。

4.2.3HTTP Cookie管理器（HTTP Cookie Manager）

當你的請求頭Request Header需要包含Cookie，或者需要捕獲響應Response返回的Cookie時，就需要用到此元件。它主要分爲兩種功能：

1. 自動存儲併發送Cookie，就像一個真正的瀏覽器一樣。
2. 可手動設置Cookie值，然後JMeter發送請求時就會帶上所填寫的Cookie值。

作爲自動存儲器時，如果捕獲並存儲了Cookies，則HTTP Cookie管理器會將Cookies自動添加到該元件作用域內（也可以理解爲“之後的”）所有對該站點所發起的請求上面，也就是說，在這之後創建的“HTTP請求取樣器”都會默認添加Cookie管理器所保存的Cookie。在JMeter內部，每個線程Thread都有其自己的Cookie存儲區域（Cookie Storage Area），假如Cookie中包含session信息，那麼每個Thread都會有自己的session。注意，自動保存的Cookie信息在界面上是不顯示的，但是可以在監聽器（例如“查看結果樹”元件）中看到結果。
JMeter默認不保存跨域的Cookie，如果想要保存的話，找到bin下的jmeter.properties文件，修改其中的屬性爲“CookieManager.check.cookies=false”。
你也可以將存儲的Cookie信息保存爲參數，首先找到bin下的jmeter.properties文件，修改其中的屬性爲“CookieManager.save.cookies=true”，然後JMeter會自動將Cookie中的信息保存成名字以“COOKIE_”爲開頭的格式的參數，例如“COOKIE_SESSIONID”。
作爲Cookie設置器時，你就可以手動設置Cookie值，例如sessionid、uid或token之類的。注意，如果有多個Thread，那麼所有的線程都會使用當前設置的Cookie信息。

圖中還有一項功能：Cookie策略。默認的是Standard，這個在大多數情況下是適用的。至於其他策略，本人沒有細研究過，所以不在這班門弄斧，上一張官網的解釋吧，如下圖：

4.2.4HTTP信息頭管理器（HTTP Header Manager）

HTTP信息頭管理器其實就是用於爲發送的請求配置其Request Header信息的，就像下圖中的這些信息：

可以爲整個線程組中所有的HTTP請求配置公共的請求頭，如官方腳本中這樣：

或者也可以爲每一條請求設置單獨的Header，如我自己的腳本：

4.2.5CSV數據文件設置（CSV Data Set Config）

在做壓力測試時，例如檢查登錄操作的壓力，爲了儘量擬真，一般都會爲每個線程都設置不同的用戶名密碼，此時“CSV數據文件設置”元件就成了最好的選擇。JMeter把CSV文件作爲一個數據池，當測試需要大量的相同用途的數據，或者獲取“隨機抽取的數據”，就可以通過該元件設置的讀取規則，來讀取CSV中的數據。由於官方腳本中該元件是空的，不便於說明，因此我用自己的腳本來演示，如下：

默認情況下，即使有多個線程，此CSV都只會被讀取一次（一個線程讀取一次還得了？），然後各個線程都會讀取不同的行的數據（後臺邏輯是，挨行讀取，哪個線程先到了就先給哪個線程）。如果線程數多於行數，則意味着部分線程需要共享相同的數據，也意味着JMeter要循環讀取CSV，因此千萬要記得將“遇到文件結束符再次循環？”的選項置爲True，如上圖。

4.3線程（Thread）

如果把一套測試的各個步驟想象成一條工廠流水線的話，那麼JMeter中的一個線程，就相當於這條測試流水線從開始到結束的傳送帶。在JMeter中，一個線程是測試的最小粒度，跟LoadRunner中的虛擬用戶是一個概念，可以想象爲，執行測試的一個小人兒，或者執行腳本的一條生產線。

4.3.1線程組（Thread Group）

線程組是一組虛擬用戶的集合（或者說一組流水線的集合）。線程組是任何測試計劃的起點，也就是說，一項測試在執行之前，我必須定義流水線是什麼樣的，例如流水線的數量（線程數），流水線的準備時間、循環次數，流水線遇到異常了是跳過，還是停止，還是重來？等等，如下圖。

每個線程將完全獨立地執行測試計劃。多個線程用於模擬與服務器應用程序的併發連接。
Ramp-Up準備時間是告訴JMeter要花多長時間才能“加速”到選擇的全部線程數。如果使用10個線程，並且準備時間是100秒，那麼每個線程會間隔10(100 / 10)秒開始執行。如果有30個線程並且準備時間是120秒，則每個線程的啓動間隔時間是4秒。注意，這個“準備時間”的目的是避免系統在測試開始時工作負載過大，所以一定要拿捏好這個時間，不能太短（否則系統負載很大），也不能太長（否則第一個線程都結束了，靠後的線程還沒開始，你說尷不尷尬）。
線程組還提供了一個調度器，用來配置整個線程組的持續時間（到了規定時長就停止運行）和啓動延遲（等待多長時間開始線程組）。

4.4取樣器（Sampler）

取樣器是向服務器發送並接收請求的單元。JMeter的取樣器包括：

1. FTP請求
2. HTTP請求(也可以用於SOAP或REST Webservice)
3. JDBC請求
4. Java對象請求
5. JMS請求
6. JUnit測試請求
7. LDAP請求
8. 郵件請求
9. 操作系統進程請求
10. TCP請求

由於取樣器只是一個向服務器發送並接收請求的單元，所以它需要與其他元件進行配合才能更好的完成測試：例如，如果爲請求添加Cookie，則需要在測試計劃中添加HTTP Cookie管理器；如果請求的header需要一些特殊的參數，則需要爲取樣器配置單獨的HTTP信息頭管理器；如果要查看並保存請求結果，則需要在測試計劃中添加一個監聽器，用於監聽所有的發出和收到的請求的詳細結果；還需要爲每個取樣器單獨配置一個斷言，用於判斷返回的請求結果是否符合預期（比如，某個接口返回的請求的狀態碼雖然是200 success，但是實際報文中的結果與預期不符，甚至還有報錯，如果不添加針對性的斷言的話，JMeter會默認只檢查狀態碼而判斷此次請求是成功的）。

4.4.1HTTP請求（HTTP Request）

最常用的是HTTP請求取樣器，如下圖：

下面我舉個例子，例如登錄操作，一般情況下，在接口層面會包含兩步操作：
1.GET登錄頁面，包括各種頁面資源，如下圖：

2.POST用戶名密碼，服務器驗證通過後返回登錄成功的響應，如下圖：

因此可以使用兩個HTTP取樣器，一個GET一個POST，來實現這兩個步驟，如下圖：


關於HTTP請求取樣器的詳細用法我會再開一篇博文進行描述，這裏就不佔用過多的篇幅了。

4.4.2測試活動（Flow Control Action/Test Action）

官方翻譯爲“測試活動”其實容易讓人產生歧義，個人覺得翻譯爲線程執行邏輯控制器更爲恰當。而測試活動雖然被劃分到取樣器分類裏，但它完全沒有取樣器的功能，它最常見的用法是置於其他取樣器後面，當作一個暫停線程執行等待的工具，如下圖所示：

4.5斷言（Assertion）

斷言是用於更高精度地判斷測試結果的方式，用於判斷響應數據是否符合指定的預期。類似於Load Runner中的檢查點，可以爲取樣器添加多個斷言，提高測試的精確度。
注意，斷言的作用域是與其同級的所有取樣器，所以如果想要爲某一取樣器添加斷言，則必須把斷言作爲子節點，放置於採樣器下面。
一般我用的最多的是響應斷言。

4.5.1響應斷言（Response Assertion）

響應斷言主要用於判斷請求/響應報文中是否包含/等於指定的字符串，如下圖：

注意，這裏的Apply to有四個選項：

1. Main sample and sub-samples
2. Main sample only
3. Sub-samples only
4. JMeter Variable Name to use

我看了很多博客，大部分，全都把這裏翻譯成“主取樣器和子取樣器”。。。錯得簡直離譜（就像小時候和同學一起抄作業，一個人抄錯，後面的人越抄越錯。。。）。所以我要在這裏明確說明下：
Sample（取樣）和Sampler（取樣器）完全不是一碼事。取樣器沒有父子的關係。而取樣的main和sub，指的是某一取樣器，在發送和接收請求時，如果跟隨了重定向的請求，然後取樣到了一連串的請求，那麼，取樣器會將最後一個請求作爲最終結果，也就是主取樣結果，而所有跳轉過程中產生的請求，作爲子取樣結果。 如下圖：

所以前條的意思就很明確了：

1. Main sample and sub-samples（斷言範圍爲當前取樣器收到的所有請求）
2. Main sample only（判斷範圍僅爲當前取樣器收到的主請求）
3. Sub-samples only（判斷範圍僅爲當前取樣器收到的子請求）

至於第四條“JMeter Variable Name to use”，其意思是“取指定name的JMeter參數的值，進行斷言”。其可能用於如下場景，例如：取樣器A的response中含有需要提取的值a，取樣器B的response中含有需要提取的值b，那麼在AB執行完後，使用正則表達式提取器，將a、b的值提取出來，然後使用BeanShell後置處理程序，定義一個新變量var x = a + b，這時候如果需要判斷x的值是不是等於y，那麼就需要在斷言的“JMeter Variable Name to use”這裏，填入x，然後“測試字段”選擇“文檔（文本）”，“匹配規則”選擇“相等”，最後“測試模式”填寫y即可。

4.6定時器（Timer）

定時器主要用於在操作之間設置等待時間。不過定時器需要額外注意的是：

• 定時器是在每個sampler（取樣器）之前執行的，而不是之後。是的，你沒有看錯，不管這個定時器的位置放在sampler之後，還是之下，它都在sampler之前執行；
• 定時器是有作用域的，當執行一個sampler之前時，所有當前作用域內的定時器都會被執行。如果希望定時器僅應用於其中一個sampler，則把該定時器作爲子節點加入；
• 如果希望在sampler執行完之後再等待，則可使用Test Action；

4.6.1統一隨機定時器（Uniform Random Timer）

名字嚇唬人的定時器，哈哈。功能其實很簡單，就是讓線程隨機等待一段時間，時間範圍是：Constant Delay Offset <= 等待時間 <= Constant Delay Offset + Random Delay Maximum。如下圖：

統一（Uniform）的意思就是，延時時間在指定範圍內且每個時間點的取值概率相同，每個時間間隔都有相同的概率發生，總的延遲時間就是隨機值和偏移值之和。

4.6.2高斯隨機定時器（Gaussian Random Timer）

又是個名字嚇唬人的定時器，功能也很簡單，即讓線程隨機等待一段時間，總延遲 = 高斯分佈值（平均0.0和標準偏差1.0）* 指定的偏差值 + 固定延遲偏移（計算參考：Math.abs((this.random.nextGaussian() * 偏差值) + 固定延遲偏移)）。如下圖：

高斯隨機定時器和統一隨機定時器的區別在於，高斯的延遲時間的分佈概率，是屬於正態分佈（高斯分佈）的。

4.7後置處理器（Post-Processors）

後置處理器一般置於取樣器之後，用於處理取樣器所接收到的response信息，比如提取響應文本中的特定信息（例如我在CSDN寫了文章，接口返回了我的文章列表及文章實體的屬性，我需要通過文章名稱提取某篇文章的id）。而如何提取，則根據報文的格式來選擇，如果是JSON，則選用“JSON提取器”；如果是HTML，則選用“XPath提取器”；或者都使用“正則表達式提取器”，因爲其適用範圍最廣。
注意，後置處理器的作用域是與其同級的所有取樣器，所以如果想要爲某一取樣器添加後置處理器，則必須把後置處理器作爲子節點，放置於採樣器下面。

4.7.1正則表達式提取器（Regular Expression Extractor）

正則表達式提取器如下圖：

正則表達式提取器的“Apply to”跟“響應斷言”一樣：

1. Main sample and sub-samples（提取範圍爲當前取樣器收到的所有請求）
2. Main sample only（提取範圍僅爲當前取樣器收到的主請求）
3. Sub-samples only（提取範圍僅爲當前取樣器收到的子請求）
4. JMeter Variable Name to use（取指定name的JMeter參數的值，再進行提取）

“要檢查的響應字段”：

• 主體（Response Body）：響應報文的主體，最常用；
• Body（unescaped）：Body是替換了所有的html轉義符的響應主體內容，注意html轉義符處理時不考慮上下文，因此可能有不正確的轉換，不太建議使用；
• Body as a Document：從不同類型的文件中提取文本，注意這個選項比較影響性能；
• 信息頭（Response Headers）：響應信息頭；
• Request Headers：請求信息頭；
• URL：請求URL；
• 響應代碼（Response Code）：響應狀態碼，如200、500等；
• 響應信息（Response Message）：響應信息，如OK；

“引用名稱”：提取出的數據的名稱，其他功能可以使用${名稱}的格式進行調用。
“正則表達式”：使用正則表達式解析響應結果。
“模板”：正則表達式的提取模式。如果正則表達式有多個提取結果，則結果是數組形式，模板$1 $ ，$2 $等等，表示把解析到的第幾個值賦給變量。若只有一個結果，則只能是$1 $。
“匹配數字”：正則表達式匹配數據的結果可以看做一個數組，表示如何取值：0代表隨機取值，正數n則表示取第n個值（比如1代表取第一個值），負數則表示提取所有符合條件的值。
“缺省值”：匹配失敗時候的默認值，我一般都設置爲null。

4.8監聽器（Listener）

監聽器也是壓力/接口測試過程中一個非常重要的組件，它主要用於存儲和可視化展示測試的結果。
一般來說，爲整個線程組添加一個於其同級的監聽器即可，它便可以記錄整個線程組的測試結果以及詳情。
注意，JMeter有GUI模式和無GUI的CLI（Command Line Interface）模式，在這兩種模式下，監聽器的保存數據的邏輯略有差別：

• GUI模式：監聽器只能臨時保存測試詳情及結果，即，重啓JMeter後所有的測試結果都會丟失。所以如果想查看以往的數據，必須在監聽器中選擇“將所有數據寫入文件”（文件格式爲xml、jtl或csv），將數據保存到本地文件中。
• CLI模式：監聽器不保存測試詳情及結果，因爲沒有GUI，看不了可視化的結果，並且保存數據會影響壓測性能，所以JMeter也不會處理並保存測試結果。所以如果想保存數據，需要在監聽器中選擇“將所有數據寫入文件”（文件格式爲xml、jtl或csv），將數據保存到本地文件中。

4.8.1查看結果樹（View Results Tree）

“查看結果樹“是最常用的監聽器之一，因爲其可以按照執行順序，將各個取樣器及斷言的結果呈樹狀展示出來。如下圖（由於官方的腳本無法運行出結果，所以樹是空的）：

運行我自己的腳本，可以看到結果樹的樣子，如下圖：

注意，JMeter爲了性能優先，默認情況下即使保存結果到本地文件，也只會保存”取樣器結果“這一欄的數據（數據量小，對效率影響小），所以在我們調試的時候，如果想把取樣器結果、request headers、request body、response headers和response body這些數據全部保存下來，則需要在”配置“選項中，進行修改，如下圖：