接口测试系列 | 某事务所的接口测试平台实践分享

本文节选自Testerhome社区爱好者合力编写的《2021接口测试白皮书》，点击链接可查看完整版《2021接口测试白皮书》。

##01 接口平台诞生的背景

现阶段接口自动化测试平台层出不穷，我司选择的是接口平台自研的路线，主要原因在于使用习惯和部分定制化需求的实现上。

对比之前的接口测试框架，测试平台平台需要满足的需求：

1、接口自动化用例和接口测试用例没有关联，没有一个统一的平台能看到接口测试的执行情况以及相关数据，更无从进行数据分析。

2、未使用平台前，大家测试接口八仙过海各显神通 有 POSTMAN、Jmeter、python 脚本等等，互相协作以及管理混乱。

3、快速生成和更新接口用例，自动化初版实现一般问题不是特别大。但是绝大部分自动化都是在使用过程中由于新项目接入以及旧的接口用例更新维护成本太高而被放弃。

4、满足特定的加签/加密方法的调用，接口测试现在由于应用层数据传输需要加密需要一些特定的方式对请求参数进行处理。

5、降低使用门槛,让所有人都可以简单使用，工具本身就是为了让人更快速、低成本的完成目标的，所以越傻瓜越好。

02 接口平台实现过程

平台上线后主要给功能测试的同学进行使用，替代原本的人工编写测试脚本工作。并且和测试平台数据打通，使接口自动化测试用例从接口用例中选取而生成。同时自动提交执行过程中的缺陷到测试平台，并且在执行后可以基于现有的测试平台展示测试报告和其他数据。 

期间我们也尝试过使用 DDT 框架的方式去做，但是 DDT 的方式做出来始终存在一定的功能局限性以及交互不友好的问题，在过渡期后最终还是做了平台化。

架构图如下: 

因为场景执行的时候必然是异步任务,而且场景存在定时执行的场景。也有通过外部 API 调用执行的情况，所以我们使用 celery 进行 job 的管理以及 mq 进行异步任务的处理以及 redis 进行任务结果的保存。因为存在动态定时任务配置的场景，使用 celery-beat进行配置。

03 接口平台功能介绍

自动化测试平台分为四个模块：用例管理、场景管理、全局配置、环境配置。

一、用例管理

用例管理：手 动 增 加 用 例 ， 删 除 用 例 ， 修 改 用 例 ， 调 试 用 例 ， 执 行 用 例。

导入 postman 导出格式、swagger 导出格式的用例，这个功能虽然说不是很有技术含量但是确实属于比较实用的需求。

核心代码如下：

参数提取：支持 jsonpath 提取自定义变量完成上下文关联。 

提取表达式例如： 

json||idsCollectTaskId||$.result.id 

代表使用jsonpath语句提取reuslt的id保存到临时参数idsCollectTaskId。 

断言方式：断言方式包括响应正文断言，数据库断言。响应正文断言分为通过 JSONPATH 进行精准断言，以及包含断言。后期还是要修改为 jsonschema 更科学一些。数据库断言是执行 SQL 语句进行精准查询断言，或者数量断言。

前后置处理：前置后置 python 和 js 脚本执行，也支持自定义SQL 语句来准备前置数据，以及后置数据清理。

自定义函数：URL 或请求正文中自定义函数，比如随机字符串、时间、手机号等函数。

用例执行前置/后置等待长设置：用例如果执行失败是否需要重试，重试次数设置，重试间隔时间设置。

二、场景管理

场景关联用例,使用拖拽方式编辑执行顺序。

场景关联测试环境

场景自动执行

场景通过外部 API 远程调用执行

场景定时任务配置

三、全局配置

子系统配置

BASE_URL 配置

默认测试账号信息等配置

四、环境配置

使用树形结构的方式管理场景以及场景下的变量。

配套支持导入 postman 导出的参数生成变量。

使用流程：

1、测试人员在用例管理平台新建接口用例。

2、自动化测试平台导入测试用例并关联到平台接口用例。

3、环境管理导入环境变量。

4、配置调试场景，配置场景执行触发规则。

5、测试结果推送到钉钉消息,回归任务发送邮件到负责人

场景执行顺序：

1、定时任务/手动触发场景执行

2、获取开始用例,获取用例对应数据

3、根据场景对应的环境进行参数替换

4、请求发送,获取响应结果

5、提取响应中的参数

6、执行 JSONPATH、DB 断言

7、继续执行下一条用例直到完成或者错误

8、结果生成，HTML报告生成

五、测试报告

本文节选自Testerhome社区爱好者合力编写的《2021接口测试白皮书》，点击链接可查看完整版《2021接口测试白皮书》。