jmeter使用心得（四）

之前的文章，小编分享了一些关于jmeter的使用心得，不知是否对大家的测试工作有些许的帮助呢，本期将继续为大家带来jmeter相关的使用心得第四篇。

往期文章：

jmeter使用心得（一）https://cloud.tencent.com/developer/article/1745215

jmeter使用心得（二）https://cloud.tencent.com/developer/article/1752246

jmeter使用心得（三）https://cloud.tencent.com/developer/article/1799642

一、jmeter聚合报告的生成

在使用jmeter进行接口测试的过程中，聚合报告（Aggregate Report）几乎是必不可少的一项功能。使用聚合报告，我们可以不费吹灰之力就得到测试中的各项统计信息，如错误率、接口响应时间、吞吐量等，方便快捷。

如在GUI模式下对线程组或采样器添加聚合报告，在运行完测试计划后，我们可以在聚合报告中看到所需的统计信息，点击下面的Save Table Data，还可以将结果保存到csv文件，以便于后续查看。

以上是在GUI模式下得到聚合报告的方式，想必大家都比较熟悉。但其实jmeter很多情况下会在NO-GUI模式下使用，本系列文章也介绍过使用NO-GUI模式的一些好处。在NO-GUI模式下生成聚合报告的方式与在GUI下有一些区别，最显著区别的就是因为没有页面，所以不能直接生成聚合报告。虽然不能直接生成，但在NO-GUI模式下也有多种生成聚合报告的方法，下面主要介绍三种常用方法。

1、保存聚合报告文件，加载到GUI中生成 2、使用jmeter插件生成 3、通过生成html报告间接得到聚合报告

第一种方法最为简单，只需在添加聚合报告的时候设置一个保存的文件地址。这样跑完测试之后，每条case的统计信息就会输出到这个文件之中，之后将这个文件加载到GUI中，就可以自动计算得到聚合报告信息，与直接用GUI模式跑的没什么两样。

直接打开日志文件查看聚合报告

第二种方法我们需要利用jmeter的插件助手。同样需要在添加聚合报告时设置一个保存的文件地址，如test.jtl。然后从插件官网下载并安装插件助手，具体方式可以参见插件官网教程：

https://jmeter-plugins.org/wiki/JMeterPluginsCMD

安装好插件助手之后，在jmeter安装目录的bin目录下会出现JMeterPluginsCMD.bat和JMeterPluginsCMD.sh两个脚本，分别是windows和linux/MacOS下的命令行脚本程序，利用这个脚本，我们就可以直接用保存的日志文件test.jtl生成聚合报告test.csv文件了。命令行如下（以windows为例）：

JMeterPluginsCMD.bat --generate-csv test.csv --input-jtl test.jtl --plugin-type AggregateReport

生成的csv文件就和用GUI模式保存下来的csv文件完全一样。这种生成聚合报告的方式，相比第一种，重要的优势在于不用再通过GUI来操作，尤其是在实际测试和统计结果使用的机器不同时，这种方式省去了拷贝日志的过程，在测试时间长、并发量大、生成日志较多的情况下可以考虑使用。

保存的聚合报告csv文件

第三种方法其实是利用了jmeter另外一个生成html报告的功能，这种方式产出的聚合报告直接就包含在html报告之中了，在NO-GUI模式下可以通过在执行测试脚本命令时添加额外的参数一键实现。

jmeter -n -t test.jmx -l test.jtl -e -o report

其中report必须是一个已经存在的空目录，不然可能不能正常生成报告。

生成报告后，用浏览器打开，就可以看到其中的聚合报告字段了。这种方法的优点是，生成聚合报告比较方便，且除了聚合报告外还能输出一些其他统计信息，看起来非常直观。但也存在一些缺点，比如生成的报告信息都在网页中，且通过js加载，不利于单独进行数据分析、统计对比等操作。

html报告中的聚合报告

二、jmeter进行固定吞吐量（QPS）测试

一般我们使用jmeter进行测试时，多考虑的是不同并发数下服务的性能，这些性能指标包括吞吐量、响应时间等。但在某些场景下，服务其实对于并发数并不是很敏感，反倒是平常作为性能指标的吞吐量会对服务性能产生影响，比如不同吞吐量下，服务的响应时间和错误率会有所不同。这时就需要我们对jmeter发送请求的吞吐量进行限制，而jmeter正好有一个定时器（timer）可以实现这样的效果。他就是固定吞吐量控制器（Constant Throughput Timer）。

固定吞吐量控制器的参数很简单，只有两个，一个是期望达到的吞吐量（注意这里是每分钟，如果是控制QPS，需要填写QPS*60），一个是计算的模式。其中计算的模式有几种，各有区别，可以按照不同的需求选用。

This thread only：

控制每个线程的吞吐量，选择这种模式时，总的吞吐量为设置的target Throughput 乘以该线程的数量

All active threads：

设置的target Throughput 将分配在每个活跃线程上，每个活跃线程在上一次运行结束后等待合理的时间后再次运行。活跃线程指同一时刻同时运行的线程。

All avtive threads(shared)：

与All active threads的选项基本相同。唯一区别是，每个活跃线程都会在所有活跃线程上一次运行结束后等待合理的时间后再次运行。

All active threads in current thread group：

设置的target Throughput 将分配在当前线程组的每一个活跃线程上，当测试计划中只有一个线程组时，该选项和All active threads 选项的效果完全相同。

All active threads in current thread group(shared)：

与All active threads in current thread group 基本相同，唯一的区别是，每个活跃线程都会在所有活跃线程的上一次运行结束后等待合理的时间后再次运行。

例如我要控制某个线程组中某个请求的总QPS为1.0，那么就可以选择All active threads in current thread group模式，并将吞吐量设置为1.0*60=60。

这样当我们进行测试时，这个请求的QPS就被固定为1了，通过聚合报告可以清晰得看到，长时间测试下来，对于吞吐量的控制还是比较精确的。

通过使用吞吐量控制器保持QPS为1

小结

本文主要分享了在使用jmeter进行测试时的一些心得体会。以上内容均来自小编自身在测试中所遇到的问题以及总结的经验，后续还会继续为大家带来这方面的分享，如果大家有不同的看法或更好的建议，欢迎一起讨论~