另一方面，聚合报告是JMeter常用的监听器，中文翻译为“聚合报告”
如果大家都在对web APP应用程序进行性能测试，例如，只有一个登录请求，则Aggregate Report会显示一行包含10个字段的数据，每个字段的含义如下：
1、Lable :每个Jmeter的element (例如Http Request )都有一个Name属性，其中显示Name属性的值
2、Samples :展示在这次测试中一共提出了多少次请求。 模拟10个用户，每个用户重复10次，这里就会显示100
3、平均响应时间---默认为单个请求的平均时间，但使用事务控制器时，也可以以事务为单位显示平均响应时间
4、Median:50%用户响应时间
5，90 % line:90 %用户响应时间
6、Min :最小响应时间
7、Max :最大响应时间
8、错误% :本次测试发生错误的请求数/请求总数
9、Troughput :吞吐量---默认情况下表示每秒完成的请求数(Request per second )，如果使用了Transaction Controller，则为transaction runer (如加载运行程序)
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，95th之后继续添加96/97/98/99/99.9/99.99 th，利用Excel的图表功能绘制曲线，可以更清楚地表现系统响应时间的分布情况。 此时，您可能会发现最大值的出现概率仅为千分之一到万分之一，99%的用户请求的响应时间在性能要求中定义的范围内。
5、如果想用这种方法评价系统的性能，一种推荐的方法是尽量延长测试场景的执行时间
些，因为jyddm获得的测试数据越多，这个响应时间的分布曲线就越接近真实情况；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