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