一、Aggregate Report 是 JMeter 常用的一個 Listener，中文被翻譯為“聚合報告
如果大家都是做Web應用的性能測試，例如只有一個登錄的請求，那么在Aggregate Report中，會顯示一行數據，共有10個字段，含義分別如下。
1、Lable：每個Jmeter的element（例如Http Request）都有一個Name屬性，這里顯示就是Name屬性的值
2、Samples：表示這次測試一共發出了多少次請求，如果模擬10用戶，每個用戶迭代10次，那么這里顯示100
3、Average：平均響應時間--默認情況下是單個Request的平均時間，當使用了Transaction Controller時，也可以以Transaction為單位顯示平均響應時間
4、Median：50%用戶響應時間
5、90%Line：90%用戶的響應時間
6、Min：最小響應時間
7、Max：最大響應時間
8、Error%：本次測試出現錯誤的請求的數量/請求總數
9、Troughput：吞吐量---默認情況下表示每秒完成的請求數量（Request per second）,當使用了Transaction Controller時，也可以表示類似Loadruner的Transaction per second數
10、KB/Sec：每秒從服務器端接收的數量，相當於Loadrunner的Throughput/Sec
二、描述性統計與性能結果分析
疑惑點：90％響應時間是什么意思？這個值在進行性能分析時有什么作用？
為什么要有90％用戶響應時間？因為在評估一次測試的結果時，僅僅有平均事務響應時間是不夠的。為什么這么說？你可以試着想想，是否平均事務響應時間滿足了性能需求就表示系統的性能已經滿足了絕大多數用戶的要求？
假如有兩組測試結果，響應時間分別是 {1，3，5，10，16} 和 {5，6，7，8，9}，它們的平均值都是7，你認為哪次測試的結果更理想？
假如有一次測試，總共有100個請求被響應，其中最小響應時間為0.02秒，最大響應時間為110秒，平均事務響應時間為4.7秒，你會不會想到最小和最大響應時間如此大的偏差是否會導致平均值本身並不可信？
為了解答上面的疑問，我們先來看一張表：
在上面這個表中包含了幾個不同的列，其含義如下：
CmdID 測試時被請求的頁面
NUM 響應成功的請求數量
MEAN 所有成功的請求的響應時間的平均值
STD DEV 標准差（這個值的作用將在下一篇文章中重點介紹）
MIN 響應時間的最小值
50 th(60/70/80/90/95 th) 如果把響應時間從小到大順序排序，那么50％的請求的響應時間在這個范圍之內。后面的60/70/80/90/95 th 也是同樣的含義
MAX 響應時間的最大值
我想看完了上面的這個表和各列的解釋，不用多說大家也可以明白我的意思了。我把結論性的東西整理一下：
1、90％用戶響應時間在 LoadRunner中是可以設置的，你可以改為80％或95％；
2、對於這個表，LoadRunner中是沒有直接提供的，你可以把LR中的原始數據導出到Excel中，並使用Excel中的PERCENTILE 函數很簡單的算出不同百分比用戶請求的響應時間分布情況；
3、(重點)從上面的表中來看，對於Home Page來說，平均事務響應時間(MEAN)只同70％用戶響應時間相一致。也就是說假如我們確定Home Page的響應時間應該在5秒內，那么從平均事務響應時間來看是滿足的，但是實際上有10-20％的用戶請求的響應時間是大於這個值的；對於Page 1也是一樣，假如我們確定對於Page 1 的請求應該在3秒內得到響應，雖然平均事務響應時間是滿足要求的，但是實際上有20-30％的用戶請求的響應時間是超過了我們的要求的；
4、你可以在95 th之后繼續添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，並利用Excel的圖表功能畫一條曲線，來更加清晰表現出系統響應時間的分布情況。這時候你也許會發現，那個最大值的出現幾率只不過是千分之一甚至萬分之一，而且99％的用戶請求的響應時間都是在性能需求所定義的范圍之內的；
5、 如果你想使用這種方法來評估系統的性能，一個推薦的做法是盡可能讓你的測試場景運行的時間長一些，因為當你獲得的測試數據越多，這個響應時間的分布曲線就越接近真實情況；
6、在確定性能需求時，你可以用平均事務響應時間來衡量系統的性能，也可以用90％或95％用戶響應時間來作為度量標准，它們並不沖突。實際上，在定義某些系統的性能需求時，一定范圍內的請求失敗也是可以被接受的；
7、上面提到的這些內容其實是與工具無關的，只要你可以得到原始的響應時間記錄，無論是使用LoadRunner還是JMeter或者OpenSTA，你都可以用這些方法和思路來評估你的系統的性能。
聚合報告中的，吞吐量=完成的transaction數/完成這些transaction數所需要的時間；平均響應時間=所有響應時間的總和/完成的transaction數；失敗率=失敗的個數/transaction數總的來說，對於jmeter的結果分析，主要就是對jtl文件中原始數據的整理
8、TestPlan ：是整個Jmeter測試執行的容器
9、ThreadGroup ：模擬請求，定義線程數、Ramp-Up Period、循環次數。
10、Step1 ：循環控制器 ，控制Sample的執行次數。
11、怎樣計算Ramp-up period時間？
Ramp-up period是指每個請求發生的總時間間隔，單位是秒。如果Number of Threads設置為5，而Ramp-up period是10，那么每個請求之間的間隔就是10／5，也就是2秒。Ramp-up period設置為0，就是同時並發請求。
12.、為什么Aggregate Report結果中的Total值不是真正的總和？
JMeter給結果中total的定義是並不完全指總和，為了方便使用，它的值表現了所在列的代表值，比如min值，它的total就是所在列的最小值。
13、在運行結果中為何有rate為N/A的情況出現？
可能因為JMeter自身問題造成，再次運行可以得到正確結果。
14、在使用JMeter測試時，是完全模擬用戶操作么？造成的結果也和用戶操作完全相同么？
是的。JMeter完全模擬用戶操作，所以操作記錄會全部寫入DB.在運行失敗時，可能會產生錯誤數據，這就取決於腳本檢查是否嚴謹，否則錯誤數據也會進入DB，給程序運行帶來很多麻煩。
1、小心緩存（類似查詢接口壓測，先問問有沒有做緩存）
2、瓶頸處持續壓測，測試系統穩定性
3、線上真實的一模一樣的環境配置
4、緩存洞穿，持續壓測/去緩存壓測/有緩存壓測
原文：https://www.cnblogs.com/dayiran1222/p/8746096.html