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的官方文档中，写了这样一句话“使用尽可能少的断言越好”，主要的原因在于断言会消耗过多的资源。在高负载测试中使用断言很可能会引起性能问题，甚至是内存不足的问题。

下面是负载测试中，建议避免使用断言的情况：

• XML Assertion
• XML Schema Assertion
• XPath Assertion 
• Compare Assertion

为了找出断言在上述情况下的影响，我做了一个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测试计划时，我建议考虑性能和功能之间的平衡。这在分布式负载测试中，可以节省大量的时间和成本。

原文翻译自：dzone

转载请注明：evget