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

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

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

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

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

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

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

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

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

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

何時(shí)使用JMeter斷言

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

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

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

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

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

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

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

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

1、基準(zhǔn)測(cè)試沒(méi)有斷言

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

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

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

在負(fù)載和性能測(cè)試中，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)是消耗過(guò)多資源，因此不能在每一個(gè)負(fù)載測(cè)試中使用斷言。

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

原文翻譯自：

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