提示：聚合報告組件的使用和察看結果樹組件的使用方式相同。本篇文章主要是詳細的介紹一下聚合報告組件內容，不做示例演示。
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%（一個完整的事務）。
還有一種情況是，交易失敗率在你可以接受的范圍內，也就是對當前測試整體結果影響不大，到了可以忽略的程度。
給大家舉個栗子，大家都看過趙本山大叔的《鍾點工》小品，里面有個經典的問題：把大象關進冰箱需要幾步？相信大家都知道答案。我們換種思維：假如我們把這個操作看成一個事務，如果找不到大象，或者沒有冰箱，這個事務都是無法完成的，也就是說這個事務最終會失敗(事務只有兩種狀態要么成功要么失敗)。
那么這些步驟就不能算事務的完成，所以事務完成數和請求完成數之間還是有區別的。
參考：