JMeter斷言用于將實(shí)際測試結(jié)果與請求的預(yù)期結(jié)果進(jìn)行對比。這篇文章將為大家闡述，即使您使用一些方法避免使用了斷言，也強(qiáng)烈建議大家優(yōu)化它們。

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

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

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

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

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

對于以上的測試結(jié)果，我的想法是這樣的。應(yīng)用程序看起來很穩(wěn)定，但是平均響應(yīng)時間保持不變這一點(diǎn)很奇怪。

在給顧客發(fā)送負(fù)載測試報告之前，我決定現(xiàn)在本地仔細(xì)檢查一下這個結(jié)果。因?yàn)樗械恼埱蠖际浅晒Φ模院茈y找到問題的根源。在進(jìn)行了很長一段時間的調(diào)查后，我決定在每個請求中添加斷言。在Assertion Results listener中看到的結(jié)果讓我驚訝。在監(jiān)聽器中顯示有近90%的請求是失敗的，但在View Results Tree listener（顯示所有樣品的響應(yīng)樹，可以查看任何樣本）中，一切響應(yīng)都是正確的。

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

根據(jù)這一經(jīng)驗(yàn)的結(jié)果，我們可以得出結(jié)論，一個成功的響應(yīng)狀態(tài)消息并不總是表示成功。而JMeter斷言可以幫助我們解決這一問題。

何時使用JMeter斷言

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

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

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

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

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

為了找出斷言在上述情況下的影響，我做了一個JMeter的基準(zhǔn)測試。我使用了來自 "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

測試計劃參數(shù)：

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

1、基準(zhǔn)測試沒有斷言

2、基準(zhǔn)測試采用響應(yīng)斷言

3、基準(zhǔn)測試使用XPath斷言

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

在負(fù)載和性能測試中，JMeter斷言是必不可少的，特別是遇到服務(wù)器返回非標(biāo)準(zhǔn)的響應(yīng)代碼動態(tài)數(shù)據(jù)的情況時。當(dāng)服務(wù)器返回靜態(tài)純文本數(shù)據(jù)是正確的時候，可以忽略Meter斷言，但同樣建議添加額外的驗(yàn)證。斷言的缺點(diǎn)是消耗過多資源，因此不能在每一個負(fù)載測試中使用斷言。

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

原文翻譯自：

轉(zhuǎn)載請注明：evget