JMeter基础 — JMeter聚合报告详解
提示:聚合报告组件的使用和察看结果树组件的使用方式相同。本篇文章主要是详细的介绍一下聚合报告组件内容,不做示例演示。1、聚合报告介绍在使用JMeter进行性能测试时,聚合报告(Aggregate Report)可以说是必用的监听器。(1)聚合报告的生成方式聚合报告有2中生成方式:在已有.jtl文件的情况下,直接选择加载文件即可生成聚合报告。在运行JMeter的过程中,动态生成聚合报告。提示:我们一
提示:聚合报告组件的使用和察看结果树组件的使用方式相同。本篇文章主要是详细的介绍一下聚合报告组件内容,不做示例演示。
1、聚合报告介绍
在使用JMeter进行性能测试时,聚合报告(Aggregate Report)可以说是必用的监听器。
(1)聚合报告的生成方式
聚合报告有2中生成方式:
- 在已有.jtl文件的情况下,直接选择加载文件即可生成聚合报告。
- 在运行JMeter的过程中,动态生成聚合报告。
提示:我们一直使用GUI模式操作JMeter,所以看到的聚合报告组件中的内容,是第二种生成方式。等之后我们介绍非GUI模式操作JMeter时,会讲解第一种方式生成的聚合报告。
(2)聚合报告的数据来源
聚合报告中统计的数据来源,其实都是从统计的SampleResult中收集的数据。
需要特别注意的是:
- 聚合报告中的每一行,代表一个请求。注意:同名的请求会只显示一个,把结果合并。
- 聚合报告中的每一列信息,是由SamplingStatCalculator类的不同方法实现统计的,相同名称的请求会共用同一个SamplingStatCalculator。
- 不管是JMeter实时生成聚合报告,还是根据已经存在.jtl结果文件生成的聚合报告,最终的底层都是调用StatGraphVisualizer类的add(sampleResult)方法来生成表格的一行数据,传递的参数为每个请求的请求结果(sampleResult)信息。
add方法的调用时机:
1)根据.jtl文件生成报告时,每解析一行数据就调用一次add方法。
2)实时运行生成聚合报告,每请求一次,就调用一次add方法。
提示:
1、注意:使用聚合报告时,测试计划中不要用相同的的请求取样器名称。
2、观察聚合报告的结果发现,聚合报告是累加的,即每次运行的结果统计都是基于前一次运行的结果进行统计,包括发起的请求样本数等都是叠加的。
2、聚合报告界面详解
添加聚合报告组件方式:选中“线程组”右键 —> 添加 —> 监听器 —> 聚合报告。
界面内容如下图所示:
聚合报告界面说明:
- 名称:聚合报告组件的自定义名称,见名知意最好。
- 注释:即添加一些备注信息,对该聚合报告组件的简短说明,以便后期回顾时查看。
(1)将所有数据写入一个文件
在JMeter中,我们可以将脚本测试中每个用户的访问内容,都存储到一个文件中。
需要操作聚合报告组件中的如下位置:
说明:
-
文件名:输入一个文件的完整路径,后缀可以为.csv,.html等。文件若不存在,则创建该文件;若已存在该文件,运行结果选择覆盖原有文件即可。
-
显示日志内容:
1)仅日志错误:仅保存错误的日志信息到文件中。
2)仅成功日志:仅保存正常响应的日志信息到文件中。
-
配置(configure):配置测试结果文件中需要记录的内容,可以依据自己需求来选择。
如下图所示:
提示:我们可以点击“浏览”按钮,选择已存储的聚合报告文件,来查看之前脚本的请求结果。
(2)聚合报告列表项介绍
1、Label:请求的名称,就是脚本中Sampler的名称。
2、#Samples(样本):总共发给服务器的请求数量,如果模拟10个用户,每个用户迭代10次,那么总的请求数为:10*10 =100次。
3、Average(平均值):默认情况下是单个Request的平均响应时间,当使用了Transaction Controller(事务控制器) 时,也可以用Transaction的时间,来显示平均响应时间 ,单位是毫秒。
4、Median(中位数):50%用户的响应时间小于该值。
5、90% Line(90% 百分位):90%用户的响应时间小于该值。
6、95% Line(95% 百分位):95%用户的响应时间小于该值。
7、99% Line(99% 百分位):99%用户的响应时间小于该值。
8、Min(最小值):最小的响应时间。
9、Maximum(最大值):最大的响应时间。
10、Error%(异常%):错误率=错误请求的数量/请求的总数。
11、Throughput(吞吐量):默认情况下表示每秒完成的请求数(Request per Second)。
12、Received KB/sec (接收数据):每秒从服务器端接收到的数据量。
13、Sent KB/sec(发送):每秒发送到服务器端的数据量。
(3)保存聚合报告报表
- 在标签中包含组名称?:需要就勾选,不需要则取消勾选。
- 保存表格数据:就是保存聚合报告页面中显示的表格内容,而不是用户的请求日志信息。
- 保存表格标题:需要就勾选。
3、聚合报告中信息点说明
(1)百分位数的说明
1、科普:90% Line参数正确的含义
在这里我觉得有必要说一下对 90%Line 的理解:
很多人都理解为:90%用户的平均响应时间。我之前也一直这样认为,但是后来才发现我错了。
那看看JMeter 官网是怎么说的?
90% Line - 90% of the samples took no more than this time. The remaining samples at least as long as this.
意思是:有 90% 的样本不超过这个时间, 剩下的样品至少只要等于或超过这个时间。
换句话说,就表示有90%的请求耗时,都在这个时间之内。
2、这里涉及到一个数学中的概念:百分位数
百分位数:统计学术语,如果将一组数据从大到小排序,并计算相应的累计百分位,则某一百分位所对应数据的值,就称为这一百分位的百分位数。可表示为:一组n个观测值按数值大小排列,处于p%位置的值称第p百分位数。
百分位通常用第几百分位来表示,如以身高为例,身高分布的第5百分位,表示有5%的人的身高小于此测量值,95%的身高大于此测量值。
3、再举个例子:
有10个数:1、2、3、4、5、6、7、8、9、10,按由小到大将其排列。
求它的第90%百分位,也就是第9个数刚好是9 ,那么他的90%Line就是9 。
4、那么百分位数用在性能测试中有什么意义呢?
它可以使用我们的分析结果更准确!
因为在评估一次测试的结果时,仅仅有平均响应时间是不够的。假如在一次测试中,总共有100个请求被响应,其中最小响应时间为0.02秒,最大响应时间为110秒,平均事务响应时间为4.7秒。你会不会想到最小和最大响应时间,这样如此大的偏差,是否会导致平均值本身并不可信?
如果我们把每个请求的响应时间用Excel统计出来,会发现那个最大值的出现几率,只不过是千分之一甚至万分之一,剩下99%的用户请求的响应时间,都是在性能需求所定义的范围之内的。所以为了更准确的衡量整体请求的耗时情况,除了平均响应时间之外,还要有90%Line、95%Line、99%Line来辅助统计。
总结一下,聚合报告中的百分位数的含意:
- Median:中位数,50%用户的响应时间在小于该值,注意它与Average平均响应时间的区别。
- 90% Line:90%用户的响应时间小于该值。
- 95% Line:95%用户的响应时间小于该值。
- 99% Line:99%用户的响应时间小于该值。
(2)吞吐量说明
吞吐量(QPS):默认情况下表示每秒完成的请求数。
误区:把吞吐量值当服务器每秒处理的事务数的值(TPS)。
经常有的同学直接把聚合报告中的吞吐量当作TPS来看,这种做法是相当不严谨的。
那么聚合报告中的吞吐量什么情况下可以看成TPS?
从严格意义来讲就是交易成功率为100%(一个完整的事务)。
还有一种情况是,交易失败率在你可以接受的范围内,也就是对当前测试整体结果影响不大,到了可以忽略的程度。
给大家举个栗子,大家都看过赵本山大叔的《钟点工》小品,里面有个经典的问题:把大象关进冰箱需要几步?相信大家都知道答案。我们换种思维:假如我们把这个操作看成一个事务,如果找不到大象,或者没有冰箱,这个事务都是无法完成的,也就是说这个事务最终会失败(事务只有两种状态要么成功要么失败)。
那么这些步骤就不能算事务的完成,所以事务完成数和请求完成数之间还是有区别的。
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你
关注我的微信公众号【伤心的辣条】免费获取~
送上一句话:
世界的模样取决于你凝视它的目光,自己的价值取决于你的追求和心态,一切美好的愿望,不在等待中拥有,而是在奋斗中争取。
我的学习交流群:902061117 群里有技术大牛一起交流分享~
如果我的博客对你有帮助、如果你喜欢我的博客内容,请 “点赞” “评论” “收藏” 一键三连哦!
好文推荐:
![Logo](https://devpress.csdnimg.cn/79de2bf0b7994defa4242ef90d5513fa.jpg)
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)