接口自动化测试实战经验分享，测试用例也能自动生成

作为测试，你可能会对以下场景感到似曾相识：开发改好的 BUG 反复横跳；版本兼容逻辑多，修复一个 BUG 触发了更多 BUG；上线时系统监控毫无异常，过段时间用户投诉某个页面无数据；改动祖传代码时如履薄冰，心智负担极重。为此本文提出一个自动化测试系统，它能够低成本实现100%的测试用例覆盖率，极大减轻管理自动化测试用例的工作量并提高测试效率，保障后台服务平稳变更。欢迎阅读~

01 背景

1.1 接口自动化测试介绍

顾名思义，接口测试就是对系统或者组件之间的接口进行测试，主要校验数据的交换、传递以及系统间的相互依赖关系等。根据测试金字塔的模型理论，测试分为三层，分别是单元测试（Unit Tests）、服务测试（Service Tests）、UI 测试（UI Tests），而我们的接口自动化测试就是服务测试层。

单元测试会导致工作量大幅提升，在需求快速迭代和人力紧张的背景下，很难持续推进，本文暂不讨论。而接口自动化测试容易实现、维护成本低，且收益更高，有着更高的投入产出比。

1.2 现状及痛点

实际上我们有一个叫 WeJestAPITest 的自动化测试平台，它是基于 Facebook 开源的 Jest 测试框架搭建的，用于校验后台的接口返回是否符合预期。在这个平台此前运行了数年的测试，一定程度上保障了后台服务的平稳运行。

但在长期使用中我们也发现了一些痛点：

• 遇到失败用例习惯性申请跳过测试，自动化测试形同虚设；
• 版本需求迭代速度飞快，用例落后于需求变更，用例迭代成本高；
• 开发同学很难参与到用例维护中，而测试同学对接口逻辑了解不深，编写的用例过于简单、僵硬，导致覆盖率低、用例质量差，开发上线心理负担重。

我们需要的不只是一个自动化测试系统，而是一个更好用的、管理成本更低的自动化测试系统。

1.3 为什么要自研

提到接口自动化测试工具，开源有 JMeter、Postman 等，司内也有成熟的 WeTest、ITEST 等，这些都是开箱即用的，但经过调研和评估，我们还是决定自己造一个轮子。考虑的点如下：

测试工具的实现原理并不复杂，实现成本不高，维护难度不大；

现有工具并不符合业务要求，例如自定义的调度方案，以及支持内部 RPC 框架；

我们需要把自动化测试与现有的系统连接起来，比如上线系统，用例失败告警系统，流量分析系统等；

当我们需要一些非标准能力的时候，外部工具很难快速，甚至无法支持，拓展性弱；

这个系统主要是为了覆盖后台接口测试，使用体验上要更贴近后台同学的使用习惯，降低用例管理成本。

1.4 目标

结合我们遇到的痛点以及业务需求，自研的自动化测试系统应该具备以下的能力：

它应该是跟实现语言无关的，甚至是无代码的，消除不同编程语言和框架带来的隔阂；

编写用例应该是纯粹的，用例跟测试服务分离，变更用例不需要变更自动化测试服务；

能够支持场景测试（多个用例组成场景），且能支持用例间的变量引用；

提供多种调度方案，可以按全量调度、按业务模块调度、按用例组调度、按单个用例调度，充分满足业务和调试需求；

这个系统要支持同时管理 HTTP 和 RPC 用例，可以覆盖请求的上下游链路；

尽最大可能降低后台同学编写用例的成本。

02 自动化测试系统实现

2.1 整体架构

2.2 统一 HTTP 和 RPC 访问形式

HTTP 和 RPC 请求在形式上可以被统一起来，其描述形式如下：

HTTP访问方式：http://host:port/urlpath + reqbody

RPC访问方式：rpc://ip:port/method + reqbody

通过这种统一的描述形式，再结合我们的业务架构，就可以设计一种通用的访问方式。后台的系统架构如下图所示：

从 proxy 层往下，所有的调用都是一个个后台服务模块，HTTP 访问的是逻辑层，RPC 访问的是服务层。那么只需要配置用例的归属模块，通过模块名 + Client 配置就可以对 HTTP 和 RPC 请求进行区分以及寻址。

从变更系统的角度来看，我们的上线变更也是按模块来的。因此把用例归属到一个个具体的模块，是最符合后台同学认知的做法。

因此我们通过配置模块名这种统一的形式，为使用者提供了统一的管理方式，只需要指定模块名就可以任意访问 HTTP 或者 RPC 请求，其流程如下：

在红色虚线框的流程中，只需要配置模块名，就可以通过模块名获取到 RPC 服务的所有信息，包括其接口定义、请求包定义、回包定义，这不是一种通用能力，需要业务基于系统架构以及线上环境去拓展，但这带来了以下便利：

可以支持任意的业务 RPC 框架，拓展性强；

只需要配置模块名就可以访问所有的 RPC 请求，无需逐个手动上传解析 proto 文件，减少操作步骤；

不需要关心 proto 的更新，实时拉取线上 proto 的信息，协议永远是最新版本。

这里的统一包含两部分：第一部分是访问形式的统一（模块），降低了配置用例的成本；第二部分是数据的统一（JSON），它统一了对回包方式的校验，降低了校验成本。

2.3 接口参数传递（参数池构造）

很多业务场景的完成都是由多个接口组成的一条链路实现，而且这种链路型的自动化测试，通常会存在参数依赖关系，一个用例的入参，可能要依赖上游响应回包的某个字段值，因此需要提取出来并传递给下一个接口。如下图：

其解决方案是，通过正则或者 JSON Extracor 等提取的结果作为变量，然后再传递给下游用例使用，这也是很多测试工具使用的方式，但是维护起来不够方便，仍有进一步优化的空间。

于是我们提出了参数池的概念，将每个用例可能用到的字段都放入一个池子里，这个池子的元素是一个个 key-value。key 是我们要使用的变量，value 则是 key 对应的取值，值得注意的是，value 既可以是一个字面值，也可以是一个 JSONPointer 的路径，这个路径可以从响应回包中提取变量值。

在这种方式下，不同用例间的参数依赖不再是从上一个“传递”到下一个，而变成了一个随取随用的池子，因此我们把它称为参数池。同时我们通过自定义的语法，实现了一个简单的模板引擎，将我们引用的变量替换为池子里的 value 值。参数池构造以及使用图示如下：

2.4 JSON Schema 组件

下面贴一段代码看看现有 WeJestAPITest 框架是如何对返回值做校验的，并分析一下它可能存在的问题：

1. function bookInfoBaseCases(bookInfoObject) {

2. it('预期 bookInfo.bookId 非空，且为字符串，且等于12345', () => {

3. expect(bookInfo.bookId).not.toBeNull();

4. expect(typeof bookInfo.bookId).toEqual('string');

5. expect(bookInfo.bookId).toEqual('12345');

6. });

7. }

这种校验方式存在以下几个问题：

这是针对单个字段进行校验，如果一个回包里有几十上百个字段，这种手工方式不可能实现全量字段校验；

编写一个用例需要有 js 基础，对其他编程语言的使用者不友好；

断言规则都是一条条散落在代码文件中，展示和管理有难度；

调试需要变更测试服务，调试成本高。

现有框架的不便导致了用例管理上的种种问题，而我们根据这些不便之处去反向思考，我们到底需要什么样的校验方式，这种情况下我们找到了 JSON Schema。

JSON Schema 是描述 JSON 数据格式的工具，Schema 可以理解为模式或者规则，它可以约束 JSON 数据应该符合哪些模式、有哪些字段、其值是如何表现的。JSON Schema 本身用 JSON 编写，且需要遵循 JSON 本身的语法规范。

下面以bookInfo的校验为例，写一份 JSON Schema 的校验规则：

1. // bookInfo信息

2. {

3. "bookId":"123456",

4. "title":"书名123",

5. "author":"作者123",

6. "cover":"https://abc.com/cover/123456.jpg",

7. "format":"epub",

8. "price":100

9. }

11. // 对应的JsonSchema校验规则

12. {

13. "type": "object",

14. "required": ["bookId", "title", "author", "cover", "format", "price"],

15. "properties": {

16. "bookId": {

17. "type": "string",

18. "const": "123456"

19. },

20. "title": {

21. "type": "string",

22. "minLength": 1

23. },

24. "author": {

25. "type": "string",

26. "minLength": 1

27. },

28. "cover": {

29. "type": "string",

30. "format": "uri"

31. },

32. "format": {

33. "type": "string",

34. "enum": ["epub", "txt", "pdf", "mobi"]

35. },

36. "price": {

37. "type": "number",

38. "exclusiveMinimum": 0

39. }

40. }

41. }

通过对比，JSON Schema 的优点非常显而易见：

可读性高，其结构跟 JSON 数据完全对应；

所有规则都处在一个 Schema 中，管理和展示清晰易懂；

它本身是一个 JSON，对于任何编程语言的使用者都没有额外学习成本；

此外，我们可以通过一个现有的 JSON 反向生成 JSON Schema，然后在这个 JSON Schema 的基础上进行简单的修改，就能得到最终的校验规则，极大降低了我们编辑用例的工作量和时间成本。

2.5 JSON Path 组件

有了 JSON Schema 之后，我们校验方式看似已经非常完美了。它既可以低成本的覆盖全量字段校验，还可以很方便的进行字段类型、数值的校验。

但实际使用中我们发现有些测试场景是 JSON Schema 覆盖不到的，比如：一条用户评论有 createtime 和 updatetime 两个字段，需要校验 updatetime >= createtime。这是 JSON Schema 的短板，它可以约束 JSON 的字段，但是它没办法对两个字段进行对比；同时 JSON Schema 跟 JSON 是一对一的，如果我们需要比较两个不同 JSON 的同一个字段，它同样无能为力。这就引出了我们需要的第二个工具 —— JSONPath。

JSONPath 是一个 JSON 的信息抽取工具，可以从 JSON 数据中抽取指定特定的值、对象或者数组，以及进行过滤、排序和聚合等操作。而 JSONPath 只是一个 JSON 字段的提取工具，要利用它来实现一个断言判断还需要进一步封装。

在这里我们用一个 JSONPath 表达式来表示一个断言，下面是一些简单的使用示例：

1. // 校验updateTime > createTime

2. $.updateTime > $.createTime

4. // 返回的bookId必须为某个固定值

5. $.bookId == ["123456"]

7. // datas数组不能为空

8. $.datas.length > [0]

10. // datas数组中必须包含某本书，且价格要大于0

11. $.datas[?(@.bookId=='123456')] > [0]

值得注意的是，JSON Schema 和 JSON Path 断言校验并非二选一，既可以同时校验，也可以根据场景选择任意一种校验方式。与此同时，如果项目前后端交互的协议是 XML、 proto 或者其他协议，可以将其统一转为 JSON 格式，JSON 更容易理解且工具链更多更成熟，否则我们将要为每一种序列化的协议都开发一套类似的工具，重复劳动。

2.6 变更系统接入与调度

在这里，我们使用异步 MQ 去调度测试任务，它有三个主要的特点：

03 自动化测试系统实现

在拥有了一个接口自动化测试平台之后，我们面临一个新的问题：如何快速提升自动化测试的覆盖率？

这个问题有一个隐含的前提，我们需要一个可以衡量覆盖率的指标，接下来将介绍我们如何构造这个指标，并分享一些提升覆盖率的方案。

3.1 变更系统接入与调度

要衡量覆盖率，第一反应必然是基于前后端约定的协议进行分析。但是沿着这条思路去分析我们遇到了以下几个难点：

协议管理不规范，散落在 git 文档、yapi、wiki 等多处地方，且格式不统一；

文档落后于实际接口协议，且可靠性有待考究；

协议参数并非都是正交的，使用协议计算出来的参数组合不符合实际情况；

因此，使用前后端协议进行分析这条路是行不通的。因此我们打算从线上流量入手，对流量的参数特征进行分析，并使用线上流量来生成自动化测试用例。

3.2 整体流程

3.3 流量特征分析

一个 HTTP 请求，我们通常需要分析的是以下部分：请求方法、URL、请求包、返回包。而结合我们的业务场景，我们还需要一些额外的信息：用户 ID、平台（安卓、IOS、网页等）、客户端版本号等。我们调研过一些流量采集分析并生成用例的系统，大多只能对通用信息进行分析，并不能很好的结合业务场景进行分析，拓展性不足。

我们有一个请求，其 url 参数为 listType=1&listMode=2、vid 为10000、平台为 android、版本号为7.2.0，其请求体如下:

1. {

2. "bookId":"12345",

3. "filterType":1,

4. "filterTags":["abc","def"],

5. "commOptions":{

6. "ops1":"testops1",

7. "ops2":"testops2"

8. }

9. }

其中 url 和 header 里的参数都很容易解析，不再赘言，下面讲一下 JSON 请求中的参数提取方法。这里我们用 JSONPointer 来表示一个参数的路径，作为这个参数的 key 值，那么可以提取获得以下参数：

1. // url 和 header 中提取的参数

2. listType=1

3. listMode=2

4. vid=10000

5. platform=android

6. appver=7.2.0

8. // JSON 中提取的参数

9. /bookId=12345

10. /filterType=1

11. /filterTags=["abc", "def"]

12. /commOptions/opts1=testops1

13. /commOptions/opts2=testops2

如此一来，参数的表现形式可以统一为 key-value 的形式，我们调研的工具也基本止步于此，接下来要么是用正交计算用例的方式辅助人工编辑用例，要么就是对大量流量生成的用例进行去重。

但这达不到我们预设的目标，我们不妨更进一步，通过大量的线上流量构造出接口参数的特征，在这里我们提出一个定义，接口参数的特征包括五部分：

参数个数；

参数类型；

参数取值范围；

参数可枚举性；

参数可组合性。

我们的工作主要集中在参数的可枚举性分析，这也是参数分析的突破点。假设我们从线上对某个接口进行采样，采样条数为 1W 条，将得到以下的参数：

1. listType=[1, 2, 3, 4]

2. listMode=[1, 2]

3. vid=[10000, 10001, 10002, 10003, ...] // 3000+

4. platform=[android, ios, web]

5. appver=[7.2.0, 7.1.0, 7.3.0, ...] // 20

6. /bookId=[12345, 23456, 34567, 56779, ...] // 4000+

7. /filterType=[1, 2]

8. /filterTags=[abc, def, efg]

9. /commOptions/opts1=[testops1, testops1_]

10. /commOptions/opts2=[testops2]

有了以上提取到的参数枚举值，我们设定一个合理的阈值（比如30），就可以判断哪些参数是可枚举的，很明显 vid 和 /bookId 并不是可枚举的参数，在覆盖用例时不需要对这两个参数进行覆盖。

在实践中，我们发现固定阈值并不能精准识别到有效的枚举参数，阈值需要跟随采样的数据动态调整。不同接口请求量可能从几十到几十万不等，如果一个接口请求条数只有30条，每一个参数的枚举值都小于设定的阈值，所有参数都是有效参数，这不符合实际情况。因此阈值要随着采样条数的变化而变化，可以按请求数量阶梯变化，也可以按请求数量成比例变化。对于特定参数，还要提供人工配置快速介入，指定参数是否可枚举。

在我们知道哪些参数是可枚举的有效参数后，接下来可以对参数的可组合性进行分析。实际上我们并不需要分析任意两个参数两两是否可组合，基于线上流量去分析即可。我们简单给一个例子：

1. listType=1&listMode=1&platform=android&appver=7.2.0

2. listType=1&listMode=1&platform=ios&appver=7.2.0

3. listType=1&listMode=1&platform=web&appver=7.2.0

4. listType=2&listMode=1&platform=android&appver=7.2.0

5. listType=2&listMode=1&platform=ios&appver=7.2.0

6. listType=2&listMode=1&platform=web&appver=7.2.0

7. listType=3&listMode=2&platform=android&appver=7.2.0

8. listType=3&listMode=2&platform=ios&appver=7.2.0

9. listType=3&listMode=2&platform=web&appver=7.2.0

那么在覆盖用例时我们需要覆盖这9个组合，通过组合分析我们甚至可以发现线上是否有错误使用的参数组合，需求是否发生了变更产生了新的组合参数。

要提升覆盖率，本质上就是覆盖所有可枚举参数的枚举类型以及组合，这就是我们在上面提到过的覆盖率指标。有了这个指标，我们就可以对覆盖率提出以下计算公式：