一、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、缓存洞穿，持续压测/去缓存压测/有缓存压测
