思考

自动化接口测试的目的首先是保证能够测试出接口是否是正确的。

这引申了一个问题，

• 什么响应可以认为接口是正确的？
• 假如接口不正确，如何在测试报告中体现出来这些信息，可以帮助开发人员修改？

上面只是满足了接口测试的需求，自动化接口测试额外增加了"自动化"的需求。这又额外引申了几个问题：

• 开发人员以什么样的方式提供测试接口的信息？
• 自动化工具如何使用这些接口信息进行自动化测试？

本篇手记记录我的自动化测试探索之路，CI/CD要接入自动化接口测试阶段。现在有很多种方式：

• python + unitTest + htmlTestRunner
• swagger + soupUI

我最终选择postman是因为它非常自然，开发时对接口进行手动测试时，接口信息在开发阶段就记录下来，而自动化测试接入DevOps流水线时不需要开发人员额外提供比如python的测试代码，项目必须集成swagger这样的约束。

效果

先演示下最终的效果，避免浪费大把时间看后面冗长的过程：

导出API集合之后命令行开始API集合测试，生成的报告结果：

然后点击上面的tab键，可以看到所有接口测试的HTTP报文信息，请求头，请求体，响应体 etc.

当然，不只是简单测试一下接口，还有一些测试用例信息。比如检查响应是否符合某个JSON模式，见检查响应延时是否可以接受，这些作为每个接口的test case在报告中也可以看到：

实现

postman tests 执行顺序

postman不仅可以手动测试接口，还可以创建脚本。

举个简单的例子，在每个接口的右侧tab中看到tests脚本可以在每个接口收到响应后执行。可以写一些逻辑来判断响应是否是正确的。下图判断postman响应体中的code字段是否为200(不是HTTP状态码)。

实际上，你可以参考：Scripting in Postman来学习如何postman脚本。postman脚本是js语言，内置了一些全局对象，如postman etc，应对一些常用的测试（http状态码检查，响应字段检查）。

postman的api是分成三个层级来组织，collection, folder, api. 每个层级之前或之后都可以执行postman tests脚本。比如集合所有api请求每次收到响应，检查HTTP状态码，可以避免每个api都配置通用规则。而api的tests脚本会检测本api的响应体。

如果只有api层级，你可以在请求之前（pre-request script）和请求之后（test script）执行自定义脚本。

如果请求所属的folder,collection也有脚本，那么执行顺序为下图所示，先执行高层脚本，后执行低层脚本。（层级顺序由高到低：collection > folder > request api）

批量执行api测试

postman UI执行批量api测试

点击run $collection_name

可以看到接口测试顺序，接口的HTTP报文信息等

postman CLI执行批量api测试

如果集成jenkins CI/CD流水线，你需要使用命令行 ，下载newman和报告生成工具reporter:

npm install -g newman
npm install -g newman-reporter-htmlextra

导出环境变量

导出collection

生成测试报告

newman run restapi-suite.postman_collection.json -r htmlextra \ 
-e restapi-suite.postman_environment.json

生成的报告在文件夹newman下面。

更多newman cli 选项参考：newman the cli companion for postman

postman脚本实例

1. 测试http状态码

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

2. 响应体验证

通常响应体可能是这样的：

{
    "code": "20001", // 业务代号，不同的代号代表不同的结果
    "data": {
        "name": "oneslide",
        "age": 1581083651
    },
    "details": null
}

检测code是否为20001

pm.test("check business codename", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.code).to.eql("20001");
});

3. 响应时间

检测响应时间小于200ms

pm.test("Response time is less than 200ms", () => {
  pm.expect(pm.response.responseTime).to.be.below(200);
});

4. 设置环境变量

pm.environment.set("orderid","xxx");

5. 具有依赖关系的串行接口

通常一个完整的分布式事务由多个接口调用组成，接口间要有严格的顺序。你可以在postman中按照顺序去创建接口，它默认按照接口的显示顺序调用。

如上面那个，从获取ID顺序开始，往下依次执行。

如果接口B需要接口A的响应中的字段，可以通过环境变量来传递。比如上面的例子中，使用ID生成订单接口需要获取ID接口的响应数据来作为请求字段。

在获取ID接口接口中把响应字段中的data拿出来，放到环境变量orderid里。

ID生成订单接口就可以通过{{$var_name}}引用变量：

6. 验证响应头

验证响应头包含Content-Type ?

pm.test("Content-Type is present", function () {
    pm.response.to.have.header("Content-Type");
});

7. 迭代多次，每次不同值

比如测试登录接口时，可能你会有一个用户信息列表来测试登录。如果外部文件包含用户信息，则需要导入进来：

比如data.json

[
    { 
        "iteration" : 1, 
        "userid": "10"
    },

    { 
        "iteration" : 2, 
        "userid": "11"
    }
]

跑测试时导入进去：

点击preview,可以看到每次迭代使用的值

接口通过{{}}引用变量，如下第一次使用userid为10，第二次为11。 当然可以使用json文件中可以声明更多字段，如果测试场景稍微复杂点：

Reference List

• Postman JavaScript reference

如何评价这个工具 ？

虽然做的很优秀了，但是还是差点意思。

1. 自动化接口测试在思考那部分我说过，开发人员以什么样的方式提供测试接口的信息和 自动化工具如何使用这些接口信息进行自动化测试是两个事情，postman就做到了一团里面。

2. 对事务的实现很不直观。微服务盛行的今天，哪个事务不调用一堆接口？接口之间调用顺序是有向无环图（DAG形式），而非仅仅串行方式。

每次事务中，用到的请求数据也是不一样的。所以自动化测试的主体是事务，而非接口所属的业务域（postman中通常把一个业务域的接口e.g. 订单接口放到一个collection），事务中的接口通常属于不同的业务域。

3. 生成的测试报告不支持定制，标准也不开放。支持html,pdf格式报告等这本身并没有什么问题，但是报告内容最重要是数据，测试结果数据有良好规范和格式，至于怎样实现模板去展示这些数据都是可以的。

所以一个理想的自动化接口测试工具(仅RESTful API场景)是什么样的？

1. 按照事务组织接口，接口调用顺序支持DAG
2. 测试结果数据可以导出为json，json格式具有清晰的定义和规范。
3. 报告生成工具采用插拔式，输入是json格式的测试报告数据，输出是html