JMeter基础 — 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 群里有技术大牛一起交流分享~

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！

好文推荐：

阿里小黑叹息：越来越多的年轻人从职场撤退了？

Python简单？先来40道基础面试题测试下

App公共测试用例梳理

从一名开发人员转做测试的一些感悟