在使用JMeter进行性能测试时，聚合报告(Aggregate Report)可以说是必用的监听器。

　　聚合报告有2中生成方式：

　　在已有.jtl文件的情况下，直接选择加载文件即可生成聚合报告。　　在运行JMeter的过程中，动态生成聚合报告。　　提示：我们一直使用GUI模式操作JMeter，所以看到的聚合报告组件中的内容，是第二种生成方式。等之后我们介绍非GUI模式操作JMeter时，会讲解第一种方式生成的聚合报告。

　　聚合报告中统计的数据来源，其实都是从统计的SampleResult中收集的数据。

　　需要特别注意的是：

　　　　聚合报告中的每一行，代表一个请求。注意：同名的请求会只显示一个，把结果合并。　　　　聚合报告中的每一列信息，是由SamplingStatCalculator类的不同方法实现统计的，相同名称的请求会共用同一个SamplingStatCalculator。　　　　不管是JMeter实时生成聚合报告，还是根据已经存在.jtl结果文件生成的聚合报告，最终的底层都是调用StatGraphVisualizer类的add(sampleResult)方法来生成表格的一行数据，传递的参数为每个请求的请求结果（sampleResult）信息。

　　add方法的调用时机：

　　　　1）根据.jtl文件生成报告时，每解析一行数据就调用一次add方法。

　　　　2）实时运行生成聚合报告，每请求一次，就调用一次add方法。

　　　　提示：　

　添加聚合报告组件方式：选中“线程组”右键 —> 添加 —> 监听器 —> 聚合报告。

　　界面内容如下图所示：

　聚合报告界面说明：

　　名称：聚合报告组件的自定义名称，见名知意最好。　　注释：即添加一些备注信息，对该聚合报告组件的简短说明，以便后期回顾时查看。　　（1）将所有数据写入一个文件

　　在JMeter中，我们可以将脚本测试中每个用户的访问内容，都存储到一个文件中。

　　需要操作聚合报告组件中的如下位置：

　　说明：

　　文件名：输入一个文件的完整路径，后缀可以为.csv，.html等。文件若不存在，则创建该文件；若已存在该文件，运行结果选择覆盖原有文件即可。

　　显示日志内容：

　　1）仅日志错误：仅保存错误的日志信息到文件中。

　　2）仅成功日志：仅保存正常响应的日志信息到文件中。

　　配置（configure）：配置测试结果文件中需要记录的内容，可以依据自己需求来选择。

　　如下图所示：

　　提示：我们可以点击“浏览”按钮，选择已存储的聚合报告文件，来查看之前脚本的请求结果。

　　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（发送）：每秒发送到服务器端的数据量。

　　在标签中包含组名称？：需要就勾选，不需要则取消勾选。　　保存表格数据：就是保存聚合报告页面中显示的表格内容，而不是用户的请求日志信息。　　保存表格标题：需要就勾选。

　　在这里我觉得有必要说一下对 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%的请求耗时，都在这个时间之内。

　　百分位数：统计学术语，如果将一组数据从大到小排序，并计算相应的累计百分位，则某一百分位所对应数据的值，就称为这一百分位的百分位数。可表示为：一组n个观测值按数值大小排列，处于p%位置的值称第p百分位数。

　　百分位通常用第几百分位来表示，如以身高为例，身高分布的第5百分位，表示有5%的人的身高小于此测量值，95%的身高大于此测量值。

　　有10个数：1、2、3、4、5、6、7、8、9、10，按由小到大将其排列。

　　求它的第90%百分位，也就是第9个数刚好是9 ，那么他的90%Line就是9 。

　　它可以使用我们的分析结果更准确！

　　因为在评估一次测试的结果时，仅仅有平均响应时间是不够的。假如在一次测试中，总共有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%用户的响应时间小于该值。

　　吞吐量（QPS）：默认情况下表示每秒完成的请求数。

　　误区：把吞吐量值当服务器每秒处理的事务数的值（TPS）。

　　经常有的同学直接把聚合报告中的吞吐量当作TPS来看，这种做法是相当不严谨的。

　　那么聚合报告中的吞吐量什么情况下可以看成TPS?

　　从严格意义来讲就是交易成功率为100%（一个完整的事务）。

　　还有一种情况是，交易失败率在你可以接受的范围内，也就是对当前测试整体结果影响不大，到了可以忽略的程度。

　　给大家举个栗子，大家都看过赵本山大叔的《钟点工》小品，里面有个经典的问题：把大象关进冰箱需要几步？相信大家都知道答案。我们换种思维：假如我们把这个操作看成一个事务，如果找不到大象，或者没有冰箱，这个事务都是无法完成的，也就是说这个事务最终会失败(事务只有两种状态要么成功要么失败)。　　那么这些步骤就不能算事务的完成，所以事务完成数和请求完成数之间还是有区别的————————————————版权声明：本文为CSDN博主「测试萌萌」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/weixin_50829653/article/details/118675802