Baolu Aggregate TPS Report

1.说明

这是一个基于JMeter官方的Aggregate Report的监听器改进而来的监听器！！！

2.插件背景

早在很久之前，宝路就曾经改造过JMeter的Aggregate Report 的源码，建议大家先读下这两篇文章：

你真的了解JMeter聚合报告么

JMeter和LoadRunner的RT统计方式探究

3.插件原因

大概就在前几天，有很多同学私信宝路，有关我博文中的JMeter聚合报告源码优化的问题！其实一两句话也很难讲清楚！再结合最近宝路公众号发布的JMeter与LR的RT统计探究文章中提到的“我们常挂在嘴边谈论的RT”！

如果只改动源码的话，每当你升级JMeter版本后，需将改的代码重新移植到新版本JMeter！此时，把这些问题点进行优化做成一个插件更合适些！插件化才是我们的最终目的！

就这样！Baolu Aggregate TPS Report 插件诞生了！基于JMeter官方Aggregate Report优化改造而来！给予文章赞赏的同学已经第一时间收到了v1.1.0插件下载链接！！！就在写此文章材料验证准备时，也发现了一些极端情况下RT统计异常的bug！目前已经修复！夜深人静的时候，果然适合撸代码！！！

4.插件实战

脚本结构截图：

插件截图：

场景实战

 场景一：JavaSampler交易成率100%的情况对比！

Thread Group 设置10个线程，迭代10次，最终运行100次！结果如下：

我们可以看出，两者统计的出的值均一致！更精确的“吞吐量”值 同样一致！

场景二：JavaSampler交易成率50%的情况对比！此时脚本结构略有调整，Baolu Aggregate TPS Report 为2个

Thread Group 设置10个线程，迭代10次，最终运行100次！其中rt与flag均从参数化文件读取

上图中的11可以是除ok（不区分大小写）之外的任意值，执行结果：

嗯，大家看出统计结果不一样了吧！那么失败率为100%呢？会是什么样的结果？

场景三：JavaSampler交易成率0%的情况对比！

调整失败请求耗时为200ms，其余配置同场景二。

执行结果：

5.小结与思考

从几个对比场景不难看出：Baolu Aggregate TPS Report 监听器统计结果更符合我们日常口中谈论RT、TPS. 此种统计方式与传统工具LR统计一致。

大家可以参考宝路的这个思路尝试对Summariser改造！

现在许多公司都在做自己的测试平台，在数据收集这块不外乎以下几种方式：

1. 独立开发数据引擎，负责整合计算数据，再结合grafana + InfluxDB进行展示。
2. 传统JMeter方式收集计算数据，采用Backend Listener再结合grafana + InfluxDB进行展示。
3. 其他自研监听插件，再配合grafana 或 echarts等等。

要说那种方式好！那肯定是第一种！希望大家在做自己的平台时要充分考虑到数据计算的严谨性！同时也希望此文能在思路上对大家有所帮助！插件可在“宝路测试手记”公众号下载！