1.說明
這是一個基於JMeter官方的Aggregate Report的監聽器改進而來的監聽器！！！
2.插件背景
早在很久之前，寶路就曾經改造過JMeter的Aggregate Report 的源碼，建議大家先讀下這兩篇文章：
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改造！
現在許多公司都在做自己的測試平臺，在數據收集這塊不外乎以下幾種方式：
- 獨立開發數據引擎，負責整合計算數據，再結合grafana + InfluxDB進行展示。
- 傳統JMeter方式收集計算數據，採用Backend Listener再結合grafana + InfluxDB進行展示。
- 其他自研監聽插件，再配合grafana 或 echarts等等。
要說那種方式好！那肯定是第一種！希望大家在做自己的平臺時要充分考慮到數據計算的嚴謹性！同時也希望此文能在思路上對大家有所幫助！插件可在“寶路測試手記”公衆號下載！