马蜂窝交酒业务接口测试管理系统的构建与应用

点击上方“马蜂窝技术”，关注订阅更多优质内容

接口作为服务端和前端/客户端之间的连接纽带，在系统交互间至关重要。这就让接口测试成为了软件质量保障中必不可少的一环。

接口测试在底层模拟用户的行为，直接和服务器进行快速交互。它可以在项目提测之前介入，只要给出接口的定义及实现，不需要界面也可以进行。另外，我们可以将需求中的业务用例分拆成不同的接口组合，针对每一个接口进行异常测试，来弥补页面测试或业务测试的不足。

对于测试人员来说，通过接口测试可以更加熟悉系统功能的组成，包括接口依赖关系、接口验签的实现等，帮助测试更贴近代码。

可以进行接口测试的工具有很多，比如 Postman、Jmeter、SoapUI 等，在一些复杂的场景下也需要自己编写的 Java、Python 脚本，这种「百花齐放」的态势一方面给测试人员更多选择，但在一些大型的项目和团队中，也会带来一些不便：

1.管理混乱：入口不统一，各自为政，方式、套路各不相同；如果项目中接口测试意识不强，做与没做也无法衡量。

2.扩展性差：随着业务线功能的迭代，接口越来越多，而接口包含元素众多，名称、路径、入参、出参等，其中有的值动辄几十行，添加起来非常复杂。

3.维护成本高：测试接口中的验签、断言、参数化、关联执行需要编写各种脚本或引入工具，编写接口用例成本、测试脚本维护成本高。

4.重复造轮子：项目中编写完的接口用例或者脚本，只能在单一项目、工具中运行，无法提供服务给其他系统，如 CI/CD。

为了解决以上痛点，交酒测试团队决定在统一的测试平台上打造自己的接口测试工具（以下简称 ITest），提升测试人员的效率，按需开发，灵活运用。

目前业务线存在两种协议的接口：一种是网关层 HTTP/HTTPS 接口，另一种是 Dubbo 协议接口。一期工程先实现 HTTP/HTTPS 协议下的接口测试功能，工具命名 ITest。

目前业务线引入了环境隔离，网关层的服务就是用环境隔离标示来区分的，而接口就在这个服务下。因此 我们首先根据环境隔离+服务名称+环境名称的规则对 ITest 中的服务命名，根据服务快速创建接口，用程序的方式将接口组织成用例，添加进用例集合来标识项目，然后执行用例，查看结果。

图1：主要功能及流程示意

系统主要模块及功能如下：

服务管理：简称 Service。定义业务中的服务，以环境隔离为标识，主要包含业务场景、服务名称、状态三个字段。其中服务名称是根据环境隔离+服务名称+环境名称组成。如：gjssqz-fiwl-qa，即国际搜索前置项目中搜索网关服务 fiwl 在 QA 环境下的服务名称。

接口管理：简称 API，作用是对接口主要参数进行管理，包括所属服务、名称、URL、描述、断言等；配置参数定义简称 apiConfig，包括 header、query、parameter、body、response。其中 URL 及 apiConfig 中可以进行参数化配置；apiConfig 中 response 用来存储该接口需要保存的返回值。

用例管理：简称 Case。每个 Case 是一个或多个接口的有序组合，还包含名称、描述、所属用例集合 caseSet。用例在这里执行、查看结果。

规则管理：简称 Rule，规则管理主要用来实现接口参数化，它支持参数动态生成，返回值保存。

ITest 后端使用 Java 语言 SpringBoot+Mybatis 框架开发，前端 Vue+ElementUI 实现，遵循 MVC 结构，Controller 接收请求，Model 处理数据，View 展示结果。

图2：系统流程

图3：系统功能

2.1 一键导入 API 接口

使用 Swagger 导入来实现，解决服务中接口繁多，添加困难问题。

Swagger 文档中的接口信息是通过 api-doc 请求获取的，需要解析其返回值，并按照需求提取出想要的信息。关键点在于它把接口定义在 definitions 字段，路径等其他信息在 paths 字段，并不是按照我们所看到的方式去编排，而且入参会包含多重对象。想解析它，首先需要获取接口定义，然后根据接口定义获取 paths 信息，最后实现递归取到所有对象信息，然后封装成 ITest 中 API 的格式入库保存。

下面结合一个业务中的实例说明：

1）交通业务国际交易网关服务 Swagger 文档样例

2）获取定义，根据定义获取 paths，递归提取每层对象

3）所有接口创建完毕，结果展示

2.2 测试配置平台化

ITest 将所有工具进行了封装，使接口的配置只需通过界面操作即可完成，无需脚本维护；创建完用例，产品、研发人员都可执行并查看结果，降低了接口测试成本。

（1）断言

交酒业务中接口返回值已经统一为 JSON 标准，断言使用 JSONSchema 工具实现非常合适。它可以校验多层嵌套，以及不同参数的类型、阀值。接口创建时，将需要断言的 JSONSchema 填写进去，ITest 会先进行默认判断，当执行接口返回 Status 为 200 后再去判断该接口是否需要断言如果包含，则进行断言。

比如校验航班去程列表接口返回是否正常，同时是否包含航班号。这就是一个多层断言的例子，需要从嵌套的 JSON 中解析出需要的值，校验规则如下：

（2）参数化

在接口测试中很多地方都需要参数化，如请求地址域名变化、请求 body 字段值变化、字段值随机生成等。

ITest 在规则管理中可以根据需求配置固定规则，规则为一个 Map 组成，key 值在接口创建时使用 {{}} 扩起来进行引用。Value 分为固定值、随机值，随机值使用 Generex 工具生成。当 value 是一个标准的正则表达式时就会按照表达式随机生成值，完成参数化响应值提取。

（3）响应值提取

在规则管理中一个规则的 key 也可以用来保存返回值，初始化时它的值为空，当接口执行完毕会判断 apiConfig 中 response 是否需要保存特定的返回值，需要则回写 value，供其他接口使用，实现上下文关联接口执行。

（4）验签

为防止接口被录制后，篡改参数任意回放，接口中加入了验签算法。如交通业务的航班搜索、报价搜索。那么就需要我们根据这些算法去实时生成验签值，否则接口请求无法执行。ITest 根据不同的接口，定义对应的算法，将它们封装为黑盒，使用者无需关注内部逻辑，直接执行即可。

2.3 CI/CD 

我们将接口测试引入了交酒研发的 CI/CD 体系，将 ITest 的功能与 Java 平台项目管理及持续集成系统 Mone 打通，来提升接口测试的效率。

具体方式为当隔离环境部署完成时，自动运行接口测试回归用例，全部用例通过后测试人员再介入，开始执行测试；如果有自动化用例不通过，开发人员需要排查问题并解决后，再次部署和执行自动化用例，全部通过后测试人员才介入。

在 ITest 中维护需要回归的用例，ITest 会根据 Mone 系统指令，动态配置参数执行用例，保证测试是在本次环境隔离下运行。

除此之外，随着 ITest 的应用，越来越多的接口用例被创建，我们就可以提取出重要的流程用例用来回归测试，方便快捷。当一个需求测试全部完毕后，可以在测试平台或者 Mone 上再次运行接口测试回归用例集，保障已有功能不受此次改动影响。

ITest 目前已经投入到交酒研发的多个业务中使用，总结起来优势如下：

1. 为接口测试提供了统一入口，以项目维度将接口测试引入，方便数据统计与量化。

2.提高了接口配置速度，系统将所有工具封装到黑盒，界面操作无需脚本维护，创建完用例，产品、研发人员都可执行并查看结果，降低了接口测试成本。

3. ITest 开放接口对接外部平台 Mone 实现 CI/CD，提升了测试的效率。

近期 ITest 系统将完善 Dubbo 接口测试功能，未来还将根据需求的升级不断迭代，希望大家多提宝贵意见。

本文作者：Meepo，交酒研发部测试开发工程师。

你「在看」我吗？