聊一聊Jmeter与多接口测试
背景
前面两篇聊过了 JMeter 的简单使用和参数化，主要都还是单接口的。
很多时候，一个业务要走完，它会依赖多个接口，而且这些接口会有依赖性。
好比说，我想查询一个订单信息，那么大前提肯定是我已经下单了，并且拿到了订单号我才可以去查。
像这个场景就会有下单接口和查询订单两个接口，并且查询订单接口会依赖于下单接口。
所以下面来看看多接口的情况下我们怎么用 JMeter 来实现自动化测试。
场景接口
在这里的话，老黄没有虚拟一个场景，用的是步骤一步骤二和步骤三来代替。
它们的流程大概如下：
- 调用步骤一接口，会返回一个 data 字段
- 根据步骤一返回的 data 字段，去调用步骤二的接口，会返回一个 data 字段
- 根据步骤二返回的 data 字段，去调用步骤三的接口
下面是各接口定义
步骤一
请求：
POST http://localhost:8532/auto/step1
Content-Type: application/json
{
"str":"123",
"r":"456"
}
响应：
{"code":0,"msg":"ok","data":"step1"}
步骤二
请求：
POST http://localhost:8532/auto/step2
Content-Type: application/json
{
"str":"123",
"r":"step1"
}
响应：
{"code":0,"msg":"ok","data":"step1+step2"}
步骤三
请求：
POST http://localhost:8532/auto/step3
Content-Type: application/json
{
"str":"123",
"r":"step1+step2"
}
响应：
{"code":0,"msg":"ok","data":"step1+step2+step3"}
步骤一处理
添加一个 HTTP 请求，进行相关的参数设定。
同时还要添加一个 JSON Extractor 的后置处理器
添加这个处理器的目的就是为了获取到接口返回的 data 字段。
这里的配置和前面的 JSON 断言其实差不多，都是定义一个参数名和 JSON 节点的路径就可以了。
到这里的话，步骤一的接口就可以了。
下面是步骤二，要怎么用步骤一返回的结果数据。
步骤二处理
步骤二也是一个 HTTP 请求，所以这里也是添加，不一样的地方是参数这一块。
可以看到，这里是直接把步骤一的 JSON Extractor 里面定义的变量名拿过来用了。
用法和参数化的方式差不多。这里继续复刻步骤一的 JSON Extractor，提取步骤三需要的内容。
步骤三处理
同样是添加一个 HTTP 请求，参数配置和步骤二类似。
换的是步骤二的变量名。
步骤三还要加一个 JSON 断言，确定返回的 data 是期望值。
到这里，有依赖性的多接口测试其实已经配置好了。
最后就是添加一个查看结果树，看对应的结果。
写在最后
对于多接口测试，老黄认为这里的核心的关键点会是后置处理器这一块内容，通过它可以很方便的拿到接口返回的内容。
试想一下，一个相对稳定业务，测试同学配置好这些接口的用例和流程。
只要开发同学调整了接口，通过 Jenkins 更新到测试环境后，就会自动跑测试同学定义的 Jmeter 脚本，就可以很轻松的知道这次更新会不会出现明显的问题。
这样的话可以节省很多不必要的时间。
但是呢，不建议刚起来的业务去做这些内容，因为多变，脚本会经常变，吃力不讨好！
最后的话，老黄把 JMeter 系列的内容都放在 github 了，方便大家查阅和测试。
