提示：聚合报告组件的使用和察看结果树组件的使用方式相同。本篇文章主要是详细的介绍一下聚合报告组件内容，不做示例演示。
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方法。
提示：
- 注意：使用聚合报告时，测试计划中不要用相同的的请求取样器名称。
- 观察聚合报告的结果发现，聚合报告是累加的，即每次运行的结果统计都是基于前一次运行的结果进行统计，包括发起的请求样本数等都是叠加的。
2、聚合报告界面详解
添加聚合报告组件方式：选中“线程组”右键 —> 添加 —> 监听器 —> 聚合报告。
界面内容如下图所示：
聚合报告界面说明：
- 名称：聚合报告组件的自定义名称，见名知意最好。
- 注释：即添加一些备注信息，对该聚合报告组件的简短说明，以便后期回顾时查看。
（1）将所有数据写入一个文件
在JMeter中，我们可以将脚本测试中每个用户的访问内容，都存储到一个文件中。
需要操作聚合报告组件中的如下位置：
说明：
- 文件名：输入一个文件的完整路径，后缀可以为
.csv，.html等。文件若不存在，则创建该文件；若已存在该文件，运行结果选择覆盖原有文件即可。 - 显示日志内容：
1）仅日志错误：仅保存错误的日志信息到文件中。
2）仅成功日志：仅保存正常响应的日志信息到文件中。 - 配置（
configure）：配置测试结果文件中需要记录的内容，可以依据自己需求来选择。
如下图所示：
提示：我们可以点击“浏览”按钮，选择已存储的聚合报告文件，来查看之前脚本的请求结果。
（2）聚合报告列表项介绍
-
Label：请求的名称，就是脚本中Sampler的名称。 -
# Samples（样本）：总共发给服务器的请求数量，如果模拟10个用户，每个用户迭代10次，那么总的请求数为：10*10 =100次。 -
Average（平均值）：默认情况下是单个Request的平均响应时间，当使用了Transaction Controller（事务控制器） 时，也可以用Transaction的时间，来显示平均响应时间 ，单位是毫秒。 -
Median（中位数）：50%用户的响应时间小于该值。 -
90% Line（90% 百分位）：90%用户的响应时间小于该值。 -
95% Line（95% 百分位）：95%用户的响应时间小于该值。 -
99% Line（99% 百分位）：99%用户的响应时间小于该值。 -
Min（最小值）：最小的响应时间。 -
Maximum（最大值）：最大的响应时间。 -
Error%（异常%）：错误率=错误请求的数量/请求的总数。 -
Throughput（吞吐量）：默认情况下表示每秒完成的请求数（Request per Second）。 -
Received KB/sec（接收数据）：每秒从服务器端接收到的数据量。 -
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%（一个完整的事务）。
还有一种情况是，交易失败率在你可以接受的范围内，也就是对当前测试整体结果影响不大，到了可以忽略的程度。
给大家举个栗子，大家都看过赵本山大叔的《钟点工》小品，里面有个经典的问题：把大象关进冰箱需要几步？相信大家都知道答案。我们换种思维：假如我们把这个操作看成一个事务，如果找不到大象，或者没有冰箱，这个事务都是无法完成的，也就是说这个事务最终会失败(事务只有两种状态要么成功要么失败)。
那么这些步骤就不能算事务的完成，所以事务完成数和请求完成数之间还是有区别的。
参考：