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

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

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

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

SaaS是一個(gè)旅游業(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)時(shí)間（小于1000毫秒）。這些數(shù)據(jù)顯示web應(yīng)用程序的運(yùn)行速度是很快的。接著，我增加了并發(fā)用戶數(shù)再次執(zhí)行負(fù)載測試。結(jié)果顯示平均響應(yīng)時(shí)間沒有變化，并且應(yīng)用程序的運(yùn)行中沒有出現(xiàn)任何錯(cuò)誤。

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

在給顧客發(fā)送負(fù)載測試報(bào)告之前，我決定現(xiàn)在本地仔細(xì)檢查一下這個(gè)結(jié)果。因?yàn)樗械恼埱蠖际浅晒Φ模院茈y找到問題的根源。在進(jìn)行了很長一段時(shí)間的調(diào)查后，我決定在每個(gè)請求中添加斷言。在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)過時(shí)了，取而代之的是返回4xx status code（這表示它不成功）。它被重新指向2xx（成功）status code的維護(hù)頁面。其余的請求也返回到維護(hù)頁面，頁面托管在CDN上。當(dāng)我們加載該公司的web servers時(shí)，事實(shí)上所有的請求都被發(fā)送到了CDN。

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

何時(shí)使用JMeter斷言

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

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

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

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

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

為了找出斷言在上述情況下的影響，我做了一個(gè)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

測試計(jì)劃參數(shù)：

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

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

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

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

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

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

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

原文翻譯自：

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