JMeter斷言用于將實際測試結果與請求的預期結果進行對比。這篇文章將為大家闡述，即使您使用一些方法避免使用了斷言，也強烈建議大家優化它們。

當我們計劃負載測試的工作量時，一般不使用斷言。其中的主要原因是，當負載或性能測試時，代碼的響應狀態是作為結果分析的主要指標之一。驗證每一個請求的響應數據是沒有太大必要的，我們需要的只是響應時間、延遲和響應代碼。從理論上講，我們并不需要使用JMeter斷言，但在實踐中，忽略斷言可能嚴重破壞最終結果。

200 Status Code并不總是意味著成功

為了說明在JMeter中斷言的重要性，在此分享給大家一個發生在我自己身上的案例，是關于SaaS service的負載測試。

SaaS是一個旅游業服務公司，他們要求我在網站發布之前進行負載測試。測試場景并不復雜，它包括了登陸、一些鏈接和注銷。這些看起來很簡單，所以我萬萬沒有想到還是出現了一些問題。

當我準備好JMeter腳本，并將JMX文件上傳到BlazeMeter后，開始運行測試。所有的請求均通過了200 status code和平均響應時間（小于1000毫秒）。這些數據顯示web應用程序的運行速度是很快的。接著，我增加了并發用戶數再次執行負載測試。結果顯示平均響應時間沒有變化，并且應用程序的運行中沒有出現任何錯誤。

對于以上的測試結果，我的想法是這樣的。應用程序看起來很穩定，但是平均響應時間保持不變這一點很奇怪。

在給顧客發送負載測試報告之前，我決定現在本地仔細檢查一下這個結果。因為所有的請求都是成功的，所以很難找到問題的根源。在進行了很長一段時間的調查后，我決定在每個請求中添加斷言。在Assertion Results listener中看到的結果讓我驚訝。在監聽器中顯示有近90%的請求是失敗的，但在View Results Tree listener（顯示所有樣品的響應樹，可以查看任何樣本）中，一切響應都是正確的。

我發現這種差異的根源在于登陸的樣本。曾經用于證書的CSV數據已經過時了，取而代之的是返回4xx status code（這表示它不成功）。它被重新指向2xx（成功）status code的維護頁面。其余的請求也返回到維護頁面，頁面托管在CDN上。當我們加載該公司的web servers時，事實上所有的請求都被發送到了CDN。

根據這一經驗的結果，我們可以得出結論，一個成功的響應狀態消息并不總是表示成功。而JMeter斷言可以幫助我們解決這一問題。

何時使用JMeter斷言

JMeter斷言不僅僅在上述的案例中很重要，在很多的負載測試中都有著舉足輕重的地位。例如，在性能測試中，JMeter斷言在任何測試腳本中都是必須具備的。

針對何時使用JMeter斷言，下面給出了一些建議：

• 請求使用的是來自“CSV數據集配置”的數據
• 使用的HTTP POST/PUT/PATCH方法
• 登陸和注銷后
• 當2xx status codes同時在正面測試和負面測試中返回
• 在API性能測試中
• 在功能測試中
• 有SOAP / XML-RPC請求
• 提醒一句：斷言消耗內存

在JMeter的官方文檔中，寫了這樣一句話“使用盡可能少的斷言越好”，主要的原因在于斷言會消耗過多的資源。在高負載測試中使用斷言很可能會引起性能問題，甚至是內存不足的問題。

下面是負載測試中，建議避免使用斷言的情況：

為了找出斷言在上述情況下的影響，我做了一個JMeter的基準測試。我使用了來自 "JMeter Performance evolution across versions"測試中的JMX文件。

• JMeter version: 2.13
• Tomcat version: 6.0.39
• Tomcat JVM: -Xmx128M
• JMeter JVM: -Xmx512m
• Java version: “1.7.0_95"
• Ubuntu: 14.04.3 LTS
• JMeter and Tomcat are on the same machine
• No particular OS Tuning
• Simple test plan using Tomcat examples

測試計劃參數：

• Ramp-up周期：100秒
• 線程數：1500
• 持續時間：10分鐘（以測試將只是運行10分鐘，10分鐘到了將被迫停止）
• 啟動延遲：7秒

1、基準測試沒有斷言

2、基準測試采用響應斷言

3、基準測試使用XPath斷言

如上圖所示，在所有測試中RAM的行為是穩定的。如果我們分析CPU結果，我們可以看到響應斷言在測試中并沒有大的變化。但在使用XPath斷言進行測試時，CPU的消耗增加了10％。測試計劃只包括4 samplers和4 XPath assertions。增加更多的斷言將大幅增加CPU的消耗，這將導致性能問題。

在負載和性能測試中，JMeter斷言是必不可少的，特別是遇到服務器返回非標準的響應代碼動態數據的情況時。當服務器返回靜態純文本數據是正確的時候，可以忽略Meter斷言，但同樣建議添加額外的驗證。斷言的缺點是消耗過多資源，因此不能在每一個負載測試中使用斷言。

在寫JMeter測試計劃時，我建議考慮性能和功能之間的平衡。這在分布式負載測試中，可以節省大量的時間和成本。

原文翻譯自：

轉載請注明：evget