JMETER斷言:終極指南
你想要:
- 檢查服務器響應是否包含特定字符串,
- 或驗證服務器返回了
HTTP 200 OK
, - 或者檢查json字段的值(使用類似JsonPath
$.store..price
)。
斷言是要走的路。
問題是:你不知道如何開始。並且可用斷言的數量是壓倒性的。別擔心!
這個關於JMeter Assertion的終極指南通過綜合例子探討了每一個斷言類型。你會明白何時以及如何明智地使用各種斷言。一旦你閱讀了本指南,斷言將不再對你有任何秘密!我們走吧。
一般概念
在本節中,我們將介紹適用於所有斷言的概念。它們都不取決於您要使用的斷言類型。
支持的斷言
JMeter斷言必須對采樣器的結果執行額外的檢查。斷言是後處理器
JMeter提供了各種各樣的斷言,可以在許多不同的場景中使用:
類型 | 用法 |
---|---|
響應斷言 | 應用字符串模式以驗證服務器響應 |
持續時間斷言 | 檢查在給定的經過時間內收到的響應 |
大小斷言 | 檢查服務器響應的大小是否包含所需的字節數 |
XML斷言 | 檢查響應是否是有效的XML文檔 |
Beanshell斷言 | 使用Beanshell腳本執行您自己的邏輯 |
MD5Hex斷言 | 允許檢查響應數據的MD5哈希值(非常適合靜態文件) |
HTML斷言 | 使用JTidy檢查html響應語法 |
XPath斷言 | 測試文檔是否格式正確,可能進行DTD驗證,或者將文檔放在JTidy中並使用XPath |
XML Shema斷言 | 根據XML模式驗證XML響應 |
JSR223斷言 | 使用JSR223腳本運行您自己的代碼邏輯 |
比較斷言 | 比較他們自己之間的結果 |
SMIME斷言 | 評估Mail Reader Sampler的樣本結果 |
JSON斷言 | 執行JsonPath表達式並驗證Json文檔 |
你應該使用哪種斷言?它歸結為你必須檢查的那種反應。
斷言範圍
你應該使用哪個範圍?
斷言範圍定義斷言適用於哪個樣本結果:
- 僅限主樣本:僅適用於采樣器的結果(在大多數情況下是HTTP請求),
- 主樣本和子樣本:一些采樣器可以生成子樣本。例如,
Retrieve All Embedded Resources
- 僅限子樣本:僅適用於子樣本結果,
- JMeter變量:對變量的值應用斷言(如
${foo}
)。
在大多數情況下,您將需要使用“ 僅主樣本”選項。斷言很少應用於主要結果和子結果。
斷言位置
正如我們之前所說,斷言是一種特殊的後處理器。
斷言適用於在相同級別或以下定義的采樣器。如果不是,則僅適用於父采樣器。
讓我們用一些例子來理解這個概念:
采樣器A下的斷言
- 在上面的例子中,斷言僅適用於采樣器A,
控制器A之後的斷言
- 在這種情況下,斷言適用於采樣器A和采樣器B,
控制器B後斷言
- 在這種情況下,斷言適用於取樣器和采樣乙和采樣?。
我能給出的最好建議是:保持簡單和愚蠢。將斷言定義為采樣器的子項,避免嘗試過於聰明。越容易理解腳本的可維護性越強。
此外,當斷言失敗時,故障將擴散到采樣器周圍的邏輯控制器。這意味著失敗的斷言會導致關聯的控制器也失敗。
性能
您必須意識到大多數斷言都是CPU和內存耗盡。下表定義了每種類型的斷言需要多少資源:
斷言 | CPU /內存使用情況 | 筆記 |
---|---|---|
響應斷言 | 中等 | 常用表達 |
持續時間斷言 | 低 | |
大小斷言 | 低 | |
XML斷言 | 高 | 構建XML DOM文檔 |
Beanshell斷言 | 變量 | 取決於腳本邏輯 |
MD5Hex斷言 | 低 | |
HTML斷言 | 高 | 解析HTML響應 |
XPath斷言 | 高 | 構建XML DOM文檔 |
XML Schema斷言 | 高 | 構建XML DOM文檔 |
JSR223斷言 | 變量 | 取決於腳本邏輯 |
比較斷言 | 高 | 解析響應並進行比較 |
SMIME斷言 | 中等 | |
Json Assertion | 高 | 解析Json文檔 |
每種顏色都有自己的含義:
- 低:可以自由使用,性能開銷很低,
- 中等:特別是在大服務器響應上使用它們(如數百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斷言:終極指南