[测试]接口自动化迭代过程

前言

作为一个测试从业者，一直都有在做接口自动化，探索过很多种方式，本文档目的记录一下整个历程。

基于 pytest

选择原因

项目刚刚立项，公司内部也没有比较通用的接口自动化平台可以用，为了快速的建设好新项目的接口自动化，我们选型了pytest框架作为v1.0版本的接口自动化选型。

优缺点分析

优点：1.搭建速度快，用例编写速度也非常快，适合项目刚刚立项时的短期使用；2.因为纯代码实现，自由度相当之高，一些复杂场景也能快速实现；
缺点：1.纯代码实现，学习成本和维护成本都比较高；2.不适合持续维护；3.报告结果等都是比较粗糙的开源结果展示，且没有历史记录，是一个临时方案。

项目目录设计

整体目录：

base_module:

1. 接口请求（写在目录/base_module/request_handler下），对请求做统一处理，例如一些环境变量赋值等；
2. 接口请求后的逻辑处理（写在目录/base_module/response_handler下），例如封装的一些数据清理函数；
3. 返回数据分析（写在目录/base_module/response_validation下)，对接口测试返回包的格式校验函数；
4. 参数处理（写在目录/base_module/parameter_handler下），因为测试用例是通过json维护，一些参数往往使用全局变量代替，例如用例中写right_user_id,参数处理程序将取一个正常合适的真实user_id替换

case:
api:放置测试用例的位置，每一个api都是一个文件，其中按照pytest语法加入前置处理，后置处理，语法糖等处理。
script：放置一些数据侧查询的函数，例如接口测试要查询db某个字段是否正确，redis某个数据是否正确，都可以放在这里。

common:
公共方法，主要包括登陆态，日志，常用字符处理等。

db：
按照项目的db接口配置，分层思路，暴露一些逻辑处理方法给case/api或者case/script使用。分库分表常用xx代替，然后传参替换。

deploy：没有使用上。

log：日志存放目录。

report：测试报告存放位置，一般上传到S3，然后通过邮件实时发送。

setting：基础配置，包括账号配置，全局常量配置等等。
source：接口测试需要用到的一些素材，例如图片资源等。
test_data_service:data文件都是json文件，每一个json文件代表一个接口的若干用例，case/api执行时，使用语法糖file_data来读取对应的用例执行。

main.py 执行的主入口，里面自定义设置执行自动化的各项参数，例如环境，地区，用例优先级，分支选择等等。

基于自动化平台

切换原因

随着项目越来越完善，团队里人员扩充，原先使用pytest的不足之处便显现出来，所以选型了一款自动化平台做接口自动化的迁移。

平台简述

平台相比于pytest纯代码维护的主要好处有两点：1.测试用例不需要再写json文件，页面直接展示，而且对于维护者来说，只需要填写入参的json和结果校验，还都是网页上直接配置，维护成本降低不少；2.每一次执行的结果都有记录保存，便于数据统计和历史追踪。

但是越是平台化自由度越低，迁移到平台后一些缺点也会暴露，最主要的就是平台的前置数据准备，后置数据清理，结果校验都需要根据平台语法配置，非常不方便。所以我们进行了下一步依赖项目集成优化。

平台接口自动化优化

自动化分层

把平台的功能独立起来。单一接口维度只依赖接口请求操作的调起和数据检查。任务维度依赖任务调度和历史追踪。把接口测试的前置数据准备和后置数据清理，再加上一些结果校验需要的数据获取全部独立

如此做，便可以在data project提前做很多自定义操作，核心目的：1.覆盖场景更全面；2.成功率更高.

稳定性优化方案

分层项目接口优化

1.数据准备引入重试，避免数据构造过程中偶然的失败；
2.header随机生成trace_id传给业务接口（需要项目开发支持），在与data project交互过程中，trace_id作为入参使用。
3.对报错的接口自动化用例进行分类：1.可重试错误；2.环境因素；3.其他。可重试的错误的用例可以重跑，环境因素的用例可以过滤，其他的需要开发人员或者测试人员

账号隔离

为什么要做账号隔离？
因为某些自动化场景需要特殊的数据，某些自动化场景清理数据需要对db进行直接操作，如果不分类场景，账号隔离，可能偶然的异常影响整体自动化的通过率。

依赖mock方案

背景

即使做了接口自动化项目分层，但是如果依赖方出问题，或者一些前置数据不支持准备。接口自动化稳定性和覆盖率都不高。这一系列依赖方或者我们自身的依赖如果可以mock，就可以解决这些问题。

问题

1.如何区分正常业务请求和需要mock的接口自动化接口呢？
2.接口自动化是接口维度，mock得一定是内部的子调用，如果实现mock这一批私有协议呢？
3.如果一个自动化任务调用同一个依赖接口多次，每次入参和返回不同，如何做区分呢？

解决方案

1.接口都有一个trace_id,其中第一段是32位数，网关侧支持trace_id通过header透传，我们把mock的一个集合id放在这里用于区分是自动化，而且指定了mock集。
2.另外一个项目通过无侵入插桩实现了mock功能，这里不赘述。
3.根据入参不同进行区分返回。

方案原理

简单来说就是自动化接口的header的trace_id被打了标，标代表了三个信息：1.接口调用是自动化任务调用；2.内部调用需要判断是否需要mock;3.mock的信息源来自某一个固定id的mock集合。