你想要：

• 檢查服務器響應是否包含特定字符串，
• 或驗證服務器返回了HTTP 200 OK，
• 或者檢查json字段的值（使用類似JsonPath$.store..price）。

斷言是要走的路。

問題是：你不知道如何開始。並且可用斷言的數量是壓倒性的。別擔心！

這個關於JMeter Assertion的終極指南通過綜合例子探討了每一個斷言類型。你會明白何時以及如何明智地使用各種斷言。一旦你閱讀了本指南，斷言將不再對你有任何秘密！我們走吧。

一般概念

在本節中，我們將介紹適用於所有斷言的概念。它們都不取決於您要使用的斷言類型。

支持的斷言

JMeter斷言必須對采樣器的結果執行額外的檢查。斷言是後處理器

JMeter提供了各種各樣的斷言，可以在許多不同的場景中使用：

你應該使用哪種斷言？它歸結為你必須檢查的那種反應。

斷言範圍

你應該使用哪個範圍？

斷言範圍定義斷言適用於哪個樣本結果：

• 僅限主樣本：僅適用於采樣器的結果（在大多數情況下是HTTP請求），
• 主樣本和子樣本：一些采樣器可以生成子樣本。例如，Retrieve All Embedded Resources
  在HTTP請求采樣器上啟用時會發生這種情況。每個資源（CSS，圖像，Javascript等...）生成子樣本結果，
• 僅限子樣本：僅適用於子樣本結果，
• JMeter變量：對變量的值應用斷言（如${foo}）。

在大多數情況下，您將需要使用“ 僅主樣本”選項。斷言很少應用於主要結果和子結果。

斷言位置

正如我們之前所說，斷言是一種特殊的後處理器。

斷言適用於在相同級別或以下定義的采樣器。如果不是，則僅適用於父采樣器。

讓我們用一些例子來理解這個概念：

采樣器A下的斷言

• 在上面的例子中，斷言僅適用於采樣器A，

控制器A之後的斷言

• 在這種情況下，斷言適用於采樣器A和采樣器B，

控制器B後斷言

• 在這種情況下，斷言適用於取樣器和采樣乙和采樣?。

我能給出的最好建議是：保持簡單和愚蠢。將斷言定義為采樣器的子項，避免嘗試過於聰明。越容易理解腳本的可維護性越強。

此外，當斷言失敗時，故障將擴散到采樣器周圍的邏輯控制器。這意味著失敗的斷言會導致關聯的控制器也失敗。

性能

您必須意識到大多數斷言都是CPU和內存耗盡。下表定義了每種類型的斷言需要多少資源：

每種顏色都有自己的含義：

• 低：可以自由使用，性能開銷很低，
• 中等：特別是在大服務器響應上使用它們（如數百KB，幾MB），
• 高：主要僅適用於功能測試或非常輕負載（少於10個並發用戶）。

優化斷言用法只是優化JMeter進行大規模測試的一小部分。如果您在負載測試期間看到CPU /內存使用情況通過屋頂並有斷言，請嘗試禁用/刪除不需要的內容。

像Beanshell或JSR223斷言這樣的腳本斷言具有可變的性能：它實際上取決於腳本檢查的內容。此外，由於這些設置沒有任何範圍UI設置，因此您必須手動通過腳本定義腳本應用的樣本結果。

斷言結果

查看斷言失敗的最佳方法是使用“ 查看結果樹”偵聽器。當然，還有許多其他方法可以分析JMeter結果。

斷言失敗說明

在上面的屏幕截圖中，我們可以看到斷言失敗。通過單擊斷言，我們可以看到詳細的錯誤消息：

Assertion error: false
Assertion failure: true
...

在這種情況下，響應包含John Smith但是斷言檢查它包含John Doe。

現在讓我們更詳細地了解每個斷言是如何工作的！

虛擬采樣器

以下所有示例均使用虛擬采樣器進行模擬。

具有JSON響應的JMeter虛擬采樣器

它可以輕松地嘗試各種斷言，而無需使用正確的響應設置遠程端點。親自嘗試一下！

常見斷言

以下斷言是Performance Engineers最常使用的斷言。這些斷言涵蓋了廣泛的用例。了解如何使用它們是正確斷言服務器響應的關鍵。

響應斷言

JMeter響應斷言

JMeter響應斷言文檔

JMeter響應斷言可能是最常用的JMeter斷言之一。它包括以下設置：

• 要測試的字段：可以是文本響應，響應代碼，文檔（文本）等。告訴應該應用斷言的服務器響應的哪一部分，
• 模式匹配規則：包含，匹配，的Equals，子串用Not和Or選項。默認情況下，它會檢查是否驗證了要測試的所有模式。通過檢查Or選項，只有一個要測試的模式必須為true，
• 要測試的模式：必須針對要測試的字段測試的字符串值。

JMeter響應斷言失敗

通常，您希望確保響應包含特定文本。在上面的示例中，我們檢查響應是否包含John Doe。

Assertion error: false
Assertion failure: true
Assertion failure message: Test failed: text expected to contain /John Doe/

這是最常用的斷言，原因如下：

• 合理的性能影響，
• 使用方便。

就個人而言，Contains 模式匹配規則滿足了我95％的需求。我猜其他選項也很有用，但主要是在非常狹窄的用例中。

定制錯誤消息的能力肯定是一個加號。這樣，您可以在結果（如JTL文件）中擁有自己的消息，並更好地了解錯誤。由於適度的 CPU和內存占用，可以謹慎使用此斷言。

持續時間斷言

JMeter持續時間斷言

該期限斷言是非常有用的驗證應用程序滿足一定的性能水平。通常，我會用它來檢查服務器在合理的時間內做出的響應。在以毫秒為單位持續時間字段，您可以輸入超過該限制的預期服務器響應time.Any響應時間會觸發斷言錯誤。

它可以被視為實施SLA（服務水平協議）的一種方式。因此，它更多的是性能警報而不是斷言。

JMeter持續時間斷言文檔

由於不存在性能開銷，這也是我首選的斷言之一。由於響應時間已由JMeter計算，它只是根據指定值檢查響應時間。性能成本幾乎為零！

JMeter持續時間斷言失敗

以下是此斷言失敗時的示例錯誤消息：

Assertion error: false
Assertion failure: true
Assertion failure message: The operation lasted too long: It took 323 milliseconds, but should not have lasted longer than 1 milliseconds.

由於低 CPU和內存占用，這個斷言可以廣泛使用。

大小斷言

JMeter尺寸斷言

當您需要確保服務器響應始終具有特定大小時，大小斷言很漂亮：

• 大小（字節）：預期大小（字節），
• 比較類型：許多可用的運營商，包括=，!=，>，<，>=和<=。

JMeter大小斷言文檔

它使用起來非常簡單。我個人用它來檢查下載文件的大小，如視頻或音樂。我想確保JMeter已經完全下載了該文件。

JMeter大小斷言失敗

如果失敗，您應該看到預期的和實際的響應大小（以字節為單位）：

Assertion error: false
Assertion failure: true
Assertion failure message: The result was the wrong size: It was 17 bytes, but should have been equal to 50 bytes.

由於低 CPU和內存占用，應該廣泛使用此斷言。

JSON斷言

JSON Assertion允許您驗證JSON響應。讓我們以json響應為例：

{
  "firstName": "John",
  "lastName" : "doe",
  "age"      : 26,
  "address"  : {
    "streetAddress": "naist street",
    "city"         : "Nara",
    "postalCode"   : "630-0192"
  },
  "phoneNumbers": [
    {
      "type"  : "iPhone",
      "number": "0123-4567-8888"
    },
    {
      "type"  : "home",
      "number": "0123-4567-8910"
    }
  ]
}

假設我們要檢查第phoneNumbers一種類型是什麽iPhone。我們將使用$.phoneNumbers[:1].type JsonPath Expression。

JMeter JSON斷言

然後我們將在JMeter中將其配置為以下內容：

• 斷言JsonPath存在：$.phoneNumbers[:1].type，
• 附加斷言值：如果選中，則斷言該值等於預期值，
• 預期價值：iPhone。

現在假設我們把Samsung Galaxy在期望值來代替。

JMeter JSON斷言失敗

正如所料，斷言失敗，因為第phoneNumbers一種類型是iPhone。

Assertion error: false
Assertion failure: true
Assertion failure message: Value expected to be ‘Samsung Galaxy‘, but found ‘["iPhone"]‘

有關如何使用JsonPath的更多信息，請參閱有關JMeter Json Path Extractor的文章。它涉及這個主題的更多細節。

此斷言具有高 CPU和內存占用，因為它解析Json響應並將它們轉換為對象表示。

XPath斷言

JMeter XPath斷言

XPath是一種用於從XML文檔中選擇節點的查詢語言。我們能做些什麽呢？它相當於JsonPath，但是對於XML響應。如果您想了解XPath的工作原理，請查看我們出色的XPath Extractor Guide。

此斷言主要適用於SOAP Web服務。

JMeter XPath斷言文檔

與XPath Extractor一樣，它有幾個高級設置，如：

• 使用Tidy：如果XML格式不正確，則啟用它，
• 使用命名空間：必須啟用以驗證節點foo:singer，如下例所示，
• 驗證XML：確保XML格式正確，否則失敗，
• 獲取外部DTD：下載引用的XML 文檔類型定義。

大多數情況下，您可以保留這些設置（全部未選中）。除非斷言的XML無效，否則默認解析器就可以了。

讓我們采用相同的XML文檔作為示例響應：

<root xmlns:foo="http://www.foo.org/" xmlns:bar="http://www.bar.org">
  <actors>
    <actor id="1">Christian Bale</actor>
    <actor id="2">Liam Neeson</actor>
    <actor id="3">Michael Caine</actor>
  </actors>
  <foo:singers>
    <foo:singer id="4">Tom Waits</foo:singer>
    <foo:singer id="5">B.B. King</foo:singer>
    <foo:singer id="6">Ray Charles</foo:singer>
  </foo:singers>
</root>

現在讓我們用XPath Assertion配置XPath斷言：//actor[@id=‘4‘]。已知此表達式失敗，因為沒有id = 4的actor。

JMeter XPath斷言失敗

運行斷言應失敗，並顯示以下消息：

Assertion error: false
Assertion failure: true
Assertion failure message: No Nodes Matched //actor[@id=‘4‘]

此斷言具有高 CPU和內存使用率（特別是對於大型XML響應），因為它解析XML響應並將它們轉換為對象表示。在負載測試期間避免使用它。

JSR223斷言

JMeter JSR223斷言

該JSR223斷言是繼任者的BeanShell斷言。它為腳本語言提供了更大的靈活性（它支持beanshell，groovy，java，jexl和Javascript），並且比beanshell更快。（在使用條件下groovy）

JMeter JSR223斷言文檔

在大多數情況下，您將單獨留下額外的設置（例如Parameters和Script File）。當您需要在多個JMX項目中共享腳本功能時，通常會使用這些功能。在這種情況下，您需要共享腳本，從而通過將公共腳本放在單獨的文件中使它們可重用。

例如，如果我們想用JSR223腳本檢查以前的結果響應時間，我們將執行以下操作：

def response_time = prev.getTime().toInteger();
 
def expected_response_time = 0;
 
if (response_time > expected_response_time) {
 AssertionResult.setFailure(true);
 AssertionResult.setFailureMessage("The expected response time is : " + expected_response_time + "ms but it took: " + response_time + "ms");
}

當然，它會失敗，因為我們想要一個響應時間0ms。

JMeter JSR223斷言失敗

此斷言具有變量，這意味著CPU和內存使用量取決於腳本內部實現的邏輯。一般來說，避免在斷言中進行大量計算。

較少使用的斷言

XML斷言

JMeter XML斷言

XML斷言非常適合檢查響應是否是有效的XML文檔。但是，這是這個斷言的唯一用例。當您需要檢查服務器響應是否格式正確時，它在功能測試中非常有用。

JMeter XML斷言失敗

如果出現錯誤（如無效的XML響應），您應該看到如下錯誤消息：

Assertion error: true
Assertion failure: true
Assertion failure message: Content is not allowed in prolog.

由於高 CPU和內存占用，在負載測試期間應該避免這種斷言。

XML Schema斷言

JMeter XML Schema斷言

此斷言允許檢查XML響應是否符合某個XML Schema DTD。我猜這個用法是有趣的，我個人從來沒用過它。

它可能最適合SOAP Web服務，其中響應必須遵循嚴格的模式。

由於高 CPU和內存占用，它適用於功能測試，但不適用於負載測試。

Beanshell斷言

JMeter Beanshell斷言

BeanShell是Java的輕量級腳本引擎。但是，性能比JSR223腳本差很多。強烈建議使用JSR223腳本。

JMeter BeanShell斷言文檔

例如，您可以使用以下腳本:(非常類似於Java）

Failure = true;
FailureMessage = "This is an Error Message";

結果應該是配置的錯誤消息。

JMeter BeanShell斷言失敗

由於您需要學習腳本語言（與Java非常相似），因此不能直接使用。但是，它比任何其他斷言都更具可定制性。

腳本中可以直接使用各種變量：

• log - 記錄器對象。示例：log.warn("Message"[,Throwable])，
• SampleResult, prev：SampleResult對象; 讀寫，
• Response：響應對象; 讀寫，
• Failure：布爾值; 讀寫; 用於設置斷言狀態，
• FailureMessage：字符串; 讀寫; 用於設置斷言消息，
• ResponseData：響應體（byte []），
• ResponseCode：喜歡200，404等等，
• ResponseMessage：例如OK，
• ResponseHeaders - 包含HTTP響應標頭，
• RequestHeaders：包含HTTP請求標頭，
• SampleLabel：采樣器的名稱，
• SamplerData：發送到服務器的數據，
• ctx- 使用各種方法訪問當前線程，前一個采樣器等的JMeterContext，
• vars：JMeterVariables從腳本中獲取/設置變量。

需要一些例子嗎？請參閱我們的可重用示例腳本博客文章。

由於高 CPU和內存占用，更喜歡JSR223斷言。它非常相似，但執行起來要快得多。

MD5Hex斷言

JMeter MD5Hex斷言

執行服務器響應的MD5哈希並將其與給定的Md5哈希進行比較。它非常適合您要檢查下載文件是否完整的情況。

它只有一個設置：

• MD5Hex：輸入預期的響應MD5哈希值。

就像在維基百科上解釋：

MD5算法是廣泛使用的散列函數，產生128位散列值。盡管MD5最初設計用作加密哈希函數，但它已被發現存在廣泛的漏洞。

讓我們嘗試使用提供的隨機md5哈希對我們的虛擬采樣器運行它。

JMeter MD5Hex斷言失敗

正如預期的那樣，斷言失敗是因為MD5哈希值不同。

Assertion error: false
Assertion failure: true
Assertion failure message: Error asserting MD5 sum : got c9ed4e51d70d5fb374d12e63db2e42d4 but should have been c05f1d607f5f8a72c9a58652b845e98e

由於服務器響應在每次檢查時必須完全相同，因此它僅適用於靜態資源檢查。任何動態網頁都可能產生斷言錯誤，因為內容不同。

由於中等 CPU使用率，它可用於在小負載測試期間檢查文件完整性。

HTML斷言

JMeter HTML斷言

這個斷言檢查HTML響應是一個結構良好的HTML文檔。可以通過設置Error Threshold和Warning Threshold更高級別（除了0）來配置嚴格性級別。它主要適用於功能測試。

顯然，您不希望在服務器上每秒投入數千次點擊時檢查HTML響應的有效性。

可以使用以下設置進行配置：

• 的DocType：omit，auto，strict或loose。無論何時考慮HTML DocType，都要定義，
• 格式：HTML，XHTML或XML。取決於要驗證的響應類型，
• 僅錯誤：忽略警告（如果有）
• 錯誤和警告閾值：設置容忍錯誤和警告的數量，
• 文件名：在那裏輸出一個JTidy報告。

以下是JTidy報告的示例：

line 1 column 1 - Error: <root> is not recognized!
line 1 column 1 - Warning: missing <!DOCTYPE> declaration
line 1 column 1 - Warning: discarding unexpected <root>
line 2 column 3 - Error: <actors> is not recognized!
InputStream: Document content looks like HTML 3.2
2 warnings, 2 errors were found!
This document has errors that must be fixed before
using HTML Tidy to generate a tidied up version.

JMeter HTML斷言失敗

通常，失敗看起來像：

Assertion error: false
Assertion failure: true
Assertion failure message: Tidy Parser errors:   9 (allowed 0) Tidy Parser warnings: 21 (allowed 0)

由於高 CPU和內存使用，請避免在負載測試期間使用HTML斷言。它解析消耗大量資源的 HTML響應。

最後的話

雖然斷言提供了一種方便的方法來驗證服務器響應是否符合預期，但您應該知道它有成本。大多數花哨的斷言如斷言JSON或XPath斷言只應用於輕負載測試（少數並發用戶）或功能測試（通常是單個用戶）。

明智地使用腳本斷言，Beanshell或者JSR223可以解決其他斷言甚至不會觸及的問題。但是，請再次註意性能缺陷：腳本應該盡可能少地進行計算。

負載測試是一門需要強烈關註性能的學科。請務必閱讀我們的指南，解釋如何大規模優化JMeter以避免常見的JMeter陷阱。

JMETER斷言：終極指南