聊一聊Jmeter的简单使用

背景

近段时间，团队想补强测试这一块，减少重复性的一些工作，让一些内容可以自动化起来，同时对开发同学写的接口的性能也开始有所要求了。

考虑到团队内没有人有测试开发的经验，所以前期的选择还是以工具为主，编程为辅。

说起工具，用的比较多的是 Jmeter ，它即可以处理自动化的测试，也可以完成性能测试。

后面也会不定期更新一些在使用 Jmeter 时候的经验。

开篇往往都会是比较简单的内容。

所以这一篇写的内容主要是拿一个 HTTP 接口出来，然后通过配置，在 Jmeter 中成功访问这个接口，并断言请求成功与否，查看结果。

最后还会通过 CLI 来跑测试计划，输出 HTML 格式的报告。

下面就开始吧！

准备一个 HTTP 接口

这里创建一个 ASP.NET Core Web API 项目，同时写一个简单到不能再简单的接口，直接返回一个 JSON 串。

[ApiController]
[Route("[controller]")]
public class RunController : ControllerBase
{        
    [HttpGet]
    public IActionResult Get()
    {
        return Ok(new 
        {
            code = 0,
            msg = "ok"
        });
    }
}

把这个项目启动起来，暴露出 8532 端口。

下面就开始在 Jmeter 里面对这个接口进行配置和调试了。

添加线程组

在测试计划添加一个线程组 (Thread Group)

添加完成之后可以看到下面的内容

在线程组中，最为主要的就是 Thread Properties 的配置了，不过这里先不对这个进行修改，先保持默认值。

因为首先要做的事情是，把测试接口调试通！如果接口没调好，设置再多的线程也没有意义！

所以这里只把名字改成了 sample1 。

线程组有了，就相当于有了一个骨架，下面就要对这个线程组填充内容，让它丰富起来。

由于我们主要是对 HTTP 接口进行测试，所以大部分内容会是和 HTTP 相关的。

添加 HTTP 请求默认值

在线程组里面，添加一个 HTTP 请求默认值的配置元件 （HTTP Request Defaults）

这里一般会配置一些不怎么变的东西，正常就是接口的域名信息，指定好之后，后面就可以不用在填接口的域名了。

下面就把测试接口的 IP 和 端口填上去。

添加 HTTP 信息头管理器

请求头，大部分接口都会有要求的，最常见的应该就是 Content-Type 。

这里就可以添加一个 HTTP 信息头管理器（HTTP Header Manager）来管理这些请求头。

测试接口是 JSON 格式的，所以要把 Content-Type 和 application/json 配置上去。

再下一步就是真正的请求了。

添加 HTTP 请求

在线程组里面添加一个 HTTP Request 类型的 Sampler。

这一个步骤要根据对应的测试接口填写对应的信息。

以测试接口为例：

1. Web Server 这一块内容不用填，我们在 HTTP 请求默认值 里面已经配置了。
2. 测试接口是 GET 请求， 测试接口的相对路径是 /run
3. 接口参数填了 a=b&c=d ，因为是 GET 请求，放到相对路径上面去也是可以的。

到这里的话，对这个接口的请求内容已经准备好了。

要怎么判断请求这个接口是不是成功了呢？

接口成功与否，一般会有几类标识，一类是当状态码为 2xx 时就当作是成功的，一类是返回的 JSON 里面包含了一个 code ，用这个 code 的值来判断。

上面的测试接口是属于第二类，所以要判断的是返回内容里面 code 的具体值是什么。

回想到单元测试，会有一个断言的步骤去判断是不是达到了预期的结果。

同样的，Jmeter 这里也有这个内容。这里选用的是 JSON 断言。

添加 JSON 断言

在线程组里面添加一个 JSON 断言（JSON Assertion）

示例接口返回 code 为 0 时，才是成功的，所以可以这样填写

首先是判断节点存在与否，其次是勾选断言值，填上期望值。

现在请求有了，断言有了，要怎么查看结果呢？

这里就要请出监听器这个神奇的东西了。

添加监听器

监听器的种类有很多，这里选择查看结果树（View Results Tree）和聚合报告（Aggregate Report）两个。

这个时候，整一个测试计划是这样的：

运行一下，打开查看结果树，可以看到测试接口已经跑成功了，返回的 code 确实也是 0。

如果把 JSON 断言里面的 code 调整成 1，查看结果树这里就会有错误提示：

再来看看聚合报告长什么样：

主要就是平均响应时间，中位数，错误率，吞吐量这些常见指标。

到这里是不是就结束了呢？

当然没有结束，从刚才的结果来看，明显才请求了一次接口，请求一次接口怎么测试接口的压力呢？

其实一直到看到结果是能成功请求接口，返回正常的数据了，才算是刚刚把接口那部分配置调试好，并没有真正的给压力到测试接口。

前面在创建线程组的时候，采取的都是默认值 1，下面可以调整线程组的一些配置来达到压测的目的。

好比说把线程数调成 100，循环 100 次。

CLI 运行 Jmeter

在启动 Jmeter 时，可以看到下面这段话。

就是让我们做压力测试的时候不要用图形化界面，而是用脚本来操作。

要用脚本操作，还是要先有配置文件，这个配置文件在保存测试计划的那个 jmx 文件。

下面是几个常用的参数说明：

下面我们通过 CLI 来执行一下，并生成一个 HTML 报告。

 .\jmeter.bat -n -t ..\..\jmeterfiles\jmx\sample1.jmx -l result\sample1.jtl -e -o result\sample1

sample1.jmx 就是上面保存的脚本文件。

同时看看输出的测试报告

打开 index.html 可以看到测试报告了。

这个面板的内容是很详细的。

写在最后

这一篇内容比较基础，就是走了一遍 Jmeter 的基本操作。

对于一些常见的参数化，引用自定义 jar 包这些内容还没有介绍到。

相对来说，Jmeter 在测试的场景用起来还是比较 OK 的。