09-性能测试之JMeter事务、聚合报告

导读

1. 精简测试脚本
2. 聚合报告简介
3. 事务控制器

1、精简测试脚本

（1）为了查看请求方便，我们将请求重命名，如下图所示：

（2）删除不必要的脚本
假如我们想对登录功能进行压测，那么第1个请求“Redmine首页”和第4个请求“登出”没有用，我们直接删掉（或者点击Toggle切换成不发送状态）。然后点击启动按钮，看是否能够成功。

2、添加监听器——聚合报告

（1）在Step1上，右键，添加监听器，聚合报告，如下图所示：

（2）聚合报告结果页

• 名称：聚合报告的名称；
• 注释：描述性信息；
• 所有数据写入一个文件：这部分我们后续介绍
• 统计数据的意义：
  
  • Label：请求的名称
  • Samples：发出请求数量。
  • Average：平均响应时间（单位：）。默认是单个Request的平均响应时间，当使用了Transaction Controller时，也可以以Transaction为单位显示平均响应时间；
  • Median：中位数，也就是50%用户的响应时间
  • 90%Line：90%用户的响应时间
  • 95%Line：95%用户的响应时间
  • 99%Line：99%用户的响应时间
  • Min：最小响应时间
  • Max：最大响应时间
  • Error%：本次测试中出现错误的请求的数量/请求的总数
  • Throughput：吞吐量。默认情况下标示每秒完成的请求数（具体单位如下图）
  • Received KB/sec：每秒从服务器端接收到的数据量；
  • Sent KB/sec：每秒发送到服务器的数据量

注：为什么要有*%用户响应时间？因为在评估一次测试的结果时，仅仅有平均事物响应时间是不够的。假如有一次测试，总共有100个请求被响应，其中最小响应时间为0.02秒，最大响应时间为110秒，平均事务响应时间为4.7秒，你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信？

我们可以在95 th之后继续添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，并利用Excel的图表功能画一条曲线，来更加清晰表现出系统响应时间的分布情况。这时候你也许会发现，那个最大值的出现几率只不过是千分之一甚至万分之一，而且99％的用户请求的响应时间都是在性能需求所定义的范围之内的；如下图则是最低响应时间的值出现几率是很小的，实际99%的用户请求响应时间都要20000+。

3、事务控制器

性能测试的结果统计时我们一定会关注TPS，就是每秒事务数，JMeter自动将每个请求统计为一个事务，但有时候我们希望将多个操作统计为一个事务，比如上面的登录功能包含两个请求。JMeter考虑到了这种需求，我们可以通过逻辑控制器中的事务控制器来实现这个功能。
（1）添加事务控制器

如上图，我们添加了一个事务控制器，将打开登录页和登录两个请求放到该事务控制器下面，删除其它干扰请求信息。

（2）压测，查看聚合报告

可以看到，多了一行事务的统计信息。这就是我们登录功能对应的数据统计信息。

小结

JMeter的一些基本操作算是学习完了，带领大家回顾一下重点：

• Badbody的录制方式
• 关联：这个主要是通过分析哪些内容是由服务器返回的，而且服务器后续还会验证的内容就需要关联；
• 参数化：把固定的数据动态化
• 断言：帮我们确定请求是否真的成功
• 定时器：固定定时器有点类似LR中的think time；同步定时器有点类似集合点
• 事务：把几个请求归到一个大的事务中去