API测试的重要性

API测试&API自动化测试工具选型 - 图1

这是非常流行的一个金字塔测试分层理念，这里把测试分三层，最底下最重要也是需要做最多的是单元测试，中间是服务这里我们也管他叫API，最顶部的是我们的UI测试做最少。

提出这种分层理念，其实归根到底想说明的几个道理：

  1. 越底层，越稳定。 金字塔主要观点认为单元测试的稳定性高，需要多投入。
  2. 越底层，越高效。 程序的问题，最终还得落在具体的代码上，所以底层的测试更容易发现问题。
  3. 越底层，越低成本。 越底层测试能越早发现问题，越早发现问题，修复的成本自然越低。
  4. 越底层，越难实施。 越底层的实现对技术专业性要求越高，这点跟第三点有点矛盾，往往越专业的人才也意味着人力成本越高。

但单元测试目前还不是我们测试能控的范围，基本都是开发自己编写，所以目前更适合我们测试的是这种橄榄模型，中间胖，两头尖。中间胖就是想说多做API相关的测试，手工也好自动化也好，毕竟业务相关逻辑都在后端，做好API测试至少能保证我们后端服务是正常的。

API测试&API自动化测试工具选型 - 图2

那API测试可以给我们测试带来哪些直观回报。

  1. 让测试提前。
  2. 发掘更多后端问题。
  3. 后端重构，测试不再是噩梦
  4. 更全面的测试
  5. 等等

API测试工具选型

目前我们公司RPC和Iot外的API应该都是http或者https协议。而目前市面上支持这协议的而且知名度较高的工具或者平台，有Postman、soapUI、jmeter，以及我们内部的API自动化测试平台。

百度指数

我从百度查到最近1个月的百度搜索指数来看 Postman的搜索指数是最高的，也可见Postman是3个工具里面最受欢迎的。

image.png

界面

SoapUI：传统Windows 产品界面，使用弹窗来表示不同界面，界面表现复杂，操作繁琐。

API测试&API自动化测试工具选型 - 图4

Jmeter：测试一个API 需要添加多个元件，例如http请求你要添加http请求、header 、cookies、结果查看等元件
image.png
PostMan：大体分左右模块，左边管理项目和接口，右边使用Tab 来表现界面，包含一个接口该有的信息，配置和发起以及查看请求结果一个界面全部显示。

image.png

支持协议和主要功能

工具/平台 支持协议 主要功能
SoapUI Soap，http/https 压力测试、安全测试、API测试、API自动化测试
Jmeter 第三方插件，支持大多数协议 压力测试、API测试
Postman Soap，http/https API测试、API自动化测试（跟newman结合）

快速配置、造case

工具/平台 快速Case 生成
SoapUI 不支持
Jmeter Badboy录制，但需要做大量去除
Postman 支持WADL / Swagger(v1/v2) / Open API 3.0 / Runscope file等导入，还支持代理拦截需要的请求，也支持fidder单请求信息导入

更多对比

工具/平台 扩展性 是否开源 多脚本场景关联 cookies管理 自定义变量 外部数据源 团队协作 多环境 mock
SoapUI 支持Groovy 收费 支持 通过脚本管理 通过脚本支持 不支持 不方便，生成xml文件不便于合并 不支持 不支持
Jmeter 支持java，但有时需要打jar包 开源 支持 通过配置元件 内置变量 支持外部txt csv等文件 不方便，生成jmx文件无法合并 通过修改全局变量 不支持
Postman 支持js和数十个常用node模块 免费但不开源，小部分功能收费 支持 自动管理 内置+自定义 Runner功能，支持csv txt json 通过url、json导入导出。Team功能但收费 支持，而且非常方便多环境切换 支持

综合评价

SoapUI：支持功能最多，但操作界面和交互复杂，且收费。如果破解版稳定性不好且对中文请求支持不好。

Jmeter：可扩展性强，一个请求配置需要用到多种元件麻烦。多接口也不方便管理。Jmeter更是一个性能压测工具，基本元件都是为性能测试而设计。

Postman：界面简单，功能设计简洁，上手简单，API管理方便，支持多种方式快速生成API基础信息，对一个http、https接口测试功能够用，但团队功能收费也造成时时同步相对麻烦。

结论

综合考虑，如果只进行http\https 协议的接口测试（非自动化测试），那么postman是以上几个工具中最佳选择。最主要理由简单易用，功能够用。

API自动化测试工具选型

先抛几个问题

如何度量测试覆盖率？

当前测试覆盖率计算通常有2种方式。 第一种我的测试或者我的用例覆盖了多少个需求点（也有理解成功能点）。第二种我的测试或者我的测试用例覆盖了多少行源码或者多少个方法或者多少个分支。

那我们API自动化测试，覆盖了主流程或者说正向请求，那么我们的API自动化测试就是百分百么或者说就OK了么？

明显是不行的。我们还有很多其它场景或者异常场景需要测试，那需要覆盖更多的场景就意味着我们需要设计更多的入参。那像这种异常场景，在我们case设计时用的是等价类划分法，那这类case我们自动化实现常用技术叫数据驱动方式可以轻松解决，所以看看你选的平台是不是支持的。

自动化测试，结果校验做到什么程度？

测试结果（出参）的校验是自动化测试难点也是重点。如果接口返回只校验是否返回状态success或者干脆不写校验，那么显然这已经谈不上测试了！

例如我们有这么个API，通过某个条件查询出商品列表，接口一次接口返回数十个商品，那么如果我们不想只校验接口返回状态success，而是更可靠的校验， 那么我们可能需要测校验每个商品信息是否正确，甚至校验商品返回的个数是否正确。

那如果这个case通过大多数API自动化平台或者工具来做，首先商品个数统计不支持，接着如果想商品信息校验需要写一大片的断言（因为你需要逐个去解析JSON等）。哪天某个商品信息变更了，这个脚本运行也就跟着挂了，但是程序不一定有问题。所以尴尬，断言做还是不做，做了后期难维护，不做这压根不是一个正常的测试用例。

以上两个问题，其实就是做自动化测试的难点和重点。 怎么保证入参的有效性，怎么更合理的校验出参。 如果所选的工具平台对这两个支持不好，那么我建议还是放弃吧。

那如果这个case通过平台来做，首先商品个数统计不支持，接着如果想商品信息校验需要写一大片的断言。哪天某个商品信息变更了，这个脚本运行也就跟着挂了，但是程序不一定有问题。所以尴尬，断言做还是不做，做了后期难维护，不做这压根不是一个正常的测试用例。

case的是否满足独立性？

case的独立性

在我们编写手工测试用例或者自动化测试用例，都得保证每个case的独立性，也就是case和case之间不相互依赖，每个case单独拿出来都是可以独立运行。独立性还可以让我们很容易对case进行分级，可以让我们可以根据不同情况运行不同级别的case。

那么你所选的API自动化测试工具或者平台，应该能对case分级，应该可以快速筛选出你需要执行的用例，而且每个用例可以独立运行。

所以居于以上3点，我想市面上基本上不存在能满足这3点的API自动化工具或者框架。目前看到API自动化测试比较靠谱的做法还是流量回放，但这明显是有一定的技术门槛。 所以想做好API自动化测试，我通过自己写代码方式实现。搭建一套API自动化测试框架。

自动化测试框架

技术架构

  • API调用框架：RestAssured
  • Case管理：TestNG
  • Json解析：fastjson、JsonPath
  • Log打印：slf4j logback Lombok
  • 持久层框架：Mybatis 、Mapper
  • 测试报告：Allure2
  • CI：Jenkins

需要支持功能

  1. case分级
  2. 数据驱动
  3. 简化数据库交互
  4. 参数化（多环境支持）
  5. 对象对比、两个Json对比
  6. 指定需要运行的case（冒烟，回归，全量等。。。）
  7. 简洁的测试报告，并可以回溯每个case的历史执行记录
  8. 支持任意次数的失败重跑
  9. 支持多种并发方式，自由配置的并发数
  10. 自由不受限，易扩展
  11. 等等

框架封装大体支持以上功能，当然更多功能待增加。