彩票走势图

负载测试为什么必须使用JMeter断言

原创|行业资讯|编辑:龚雪|2016-05-06 18:22:31.000|阅读 1817 次

概述:JMeter断言用于将实际测试结果与请求的预期结果进行对比。这篇文章将为大家阐述,即使您使用一些方法避免使用了断言,也强烈建议大家优化它们。

# 慧都年终大促·界面/图表报表/文档/IDE等千款热门软控件火热促销中 >>

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


标签:性能测试测试优化软件测试技术

本站文章除注明转载外,均为本站原创或翻译。欢迎任何形式的转载,但请务必注明出处、不得修改原文相关链接,如果存在内容上的异议请邮件反馈至chenjj@pclwef.cn


为你推荐

  • 推荐视频
  • 推荐活动
  • 推荐产品
  • 推荐文章
  • 慧都慧问
扫码咨询


添加微信 立即咨询

电话咨询

客服热线
023-68661681

TOP