1.背景
大家在使用JMeter進行性能測試時，聚合報告(Aggregate Report)可以說是必用的監聽器，但是你真的了解聚合報告么？
2.目的
本次筆者跟大家聊聊聚合報告(Aggregate Report)常用誤區。
3.常見誤區
說明：本次筆者采用的JMeter版本為5.1.1
- 誤區一：90%、95%、99百分位的理解
經常有的同學理解成平均90%、95%、99%請求的交易耗時，包括一些做了很久的老測人員試竟然也是這么理解的（其實筆者最開始也是這么理解的），出現這個問題根本原因是對百分位的概念理解錯誤（換句話說：你數學是體育老師教的吧！），那么正確該怎么理解呢？
我們來看一張聚合報告圖：
正解：90%百分位值為230ms，在發送100筆請求過程中，聚合報告會實時給請求耗時進行由小到大行排序，排序后的第90個請求耗時為230ms，也就是說前90筆請求中耗時最長的是230ms（其余90%百分位，95%百分位道理類似就不占篇贅述了），聚合報告平均值要與百分位值結合來看。
說明：90%、95%、99%值是支持自定義在jmeter.properties修改：
- 誤區二：把吞吐量值當TPS值
經常有的同學直接把聚合報告中的吞吐量當作TPS來看（網上還有一種說法是把請求放在事務控制器里，吞吐量就可以看成TPS，經筆者驗證並不可以）,這種做法是相當不嚴謹的。那么聚合報告中的吞吐量什么情況下可以看成TPS?
老規矩還是用實際操作來驗證：
沒錯，還是上面聚合報告的圖，筆者把100.jtl文件中的請求全部改成false,再來看下聚合報告結果：
然后再用聚合報告打開100.jtl結果文件，聚合報告各項數據沒有任何改變（筆者就不放圖了，不然就一張圖用了3遍），筆者這種做法是比較極端的（或者可以說筆者把現象放大了），此時再把吞吐量看成TPS就出事了。。。。請求全失敗了，TPS應該是0吧？？？？？
給大家舉個栗子，大家都看過趙本山大叔的《鍾點工》小品，里面有個經典的問題：把大象關進冰箱需要幾步？相信大家都知道答案。我們換種思維：假如我們把這個操作看成一個事務，如果找不到大象，或者沒有冰箱，這個事務都是無法完成的，也就是說這個事務最終會失敗(事務只有兩種狀態要么成功要么失敗)。
那么什么時候吞吐量可以成TPS,從嚴格意義來講就是交易成功率為100%；還有一種情況是：交易失敗率在你可以接受的范圍內（對當前測試整體結果影響不大，到了可以忽略的程度）。
我們再來驗證下網上說的方法吧：把請求放在事務控制器里
腳本結構圖：
有的同學可以能會問：事務控制器為啥不放多個請求，其實從本質上看是沒這個必要的，放多個請求也不影響最終結果。
筆者還是用之前的操作把100_2.jtl中的請求全部改成false,再來看下聚合報告結果：
聚合報告結果圖（為什么會總體樣本會是200，筆者覺得問題出在逆向解析過程中會把JTL結果文件中所有的樣本解析出來）：
吞吐量的值還是沒有變，此時吞吐量值預期結果應該是零，進而證明網上的所謂的套路不靠譜（感覺網上說的增加事務控制器的，目的更偏向與如何把多個請求組裝成一個事務，這也是事務控制的作用）。
4.JMeter聚合報告源碼優化
針對以上問題，筆者查看了聚合報告底層源碼，總結下：聚合報告是無狀態的（狀態是樣本的狀態），只負責統計數據（就是個計數器），統計時只認Sampler的Label，筆者個人感覺源生的聚合報告，不是十分合適OLTP。
筆者優化了：統計計算公式，支持GUI頁面控制（默認勾選統計tps，如果不勾選則還是統計吞吐量）
再看下100.jtl結果文件全部false效果：
筆者手動改下100.jtl改成只失敗1筆，執行結果如下：
