电商平台接口自动化框架实践

技术栈

Mimproxy(抓包)+pytest+allure+docker+Jenkins+gitlab

语言：电商API接口自动化实现流程

1. 红色为可实现/尚未完成

2. 绿色为需要人工干预部分

自动生成测试用例模板（俩种方式二选一）：

1. mimproxy，通过浏览器代理抓包方式，访问 H5 或者 web 页面，将指定域名的接口请求抓包生成标准的测试用例模板+测试数据集

   

   
   抓包流程图

2. yapi 导出接口标准的 swaggerjson 文件、将指定 tag 的接口导入到测试用例模板

3. 测试数据集也可以通过 mitmproxy 抓包生成

Cases 生成器，根据测试用例模板，生成标准 TestCases 代码，一个接口为一个 module

1. 测试用例模板支持预置一些基本断言，包括：状态码校验、响应时间断言、关键字断言、jsonpath 断言、jsonpath 长度断言等，可根据需要进行扩展

2. 测试用例模板支持对测试用例添加 mark，不添加的话会默认初始化一个 mark，后续 pytest 执行时可以指定执行哪些 mark

3. 测试用例模板支持添加前置操作(比如执行前置关联接口等，在测试 case 脚本里体现为生成 setupclass 方法)

4. 测试用例模板支持添加后置操作，主要用途为传递变量（如将该接口返回的指定值写入全局变量中）

如需要自定义断言，将生成的 TestCases 脚本拷贝到新建的 package 下（注意必须是 package，而不能只是一个目录）

1. 引入私有断言库和一些工具操作类，维护私有断言目前已有的比对和工具操作类，包括：elasticsearch 操作类、redis 操作类、mysql 操作类、sqlserver 操作类、excel 操作类、json 操作类

2. Json 解析、Json 深度遍历、Json 比对计划增加断言库：通过yapi 导入接口模板时，再增加导入接口 responsebody 的 jsonschema 定义

3. 引入 python 的 jsonschema 包，增加接口返回 body 的 json 格式校验。

测试数据如何去维护
1. 每一个接口都有其对应的测试数据存储表 datacenter_[项目名称][method][apipath]
2. 表中固定字段：datadesc为数据标签，用于标记该数据，该标签是模糊匹配
3. 正向业务数据[PositiveTest]
4. 反向数据-非法输入[InvalidInput]
5. 反向数据-类型错误[TypeError]
6. 反向数据-适用于GET查询类接口的[empty]等等

自动生成通用测试数据：
1. Check下每个接口的输入参数，是否有范围限制，举个例子：pageSize，限制输入范围1-50，将此类数据手动维护到datacenter_testdatalimit表中，记录参数的range
2. 调用生成通用测试数据的接口，数据中心将针对指定项目下指定接口，批量生成通用测试数据包括：
3. 根据参数range，生成的边界值测试数据
4. 根据是否必填(程序自动采集的)，生成的空值、delete测试数据
5. 根据参数类型(程序自动采集) ：integer、string、double、boolean等，生成的校验数据类型的反向测试数据，比如：int32型，则生成string、小数、特殊字符、超出int32数值范围的测试数据
6. 根据参数是否支持多值(程序自动采集) ，生成只包含分割符、空格的空数组格式的测试数据

拉取被测系统的测试数据：
1. 根据不同系统的自身业务，定制采集数据的sql，输出到对应接口的测试数据表
2. 此部分需要根据业务自定义，可以抽出通用方法：传入sql集合和接口存储表作为参数
3. 被测系统的数据源在setting配置文件里维护

浏览器抓包（流量录制）：
1. 前提：被测接口已经有web前端在调用，被测系统前后端分离，且前端不是用的服务端渲染技术
2. 启动基于mitmproxy包二次开发的录制脚本，指定代理端口如8080，指定需要抓包的3. 请求前缀，如：http://dsapi.xdf.cn
4. 启动浏览器，开启8080代理端口
5. 点点点web前端，享受一边测试业务系统一边自动录制接口业务数据的美妙旅程吧～～

如何去做断言：
Test_[method]_[apipath].py 重写正向断言方法
系统内置的常用断言方法：

1. 项目根路径下的client.py模块下Http类
   该类封装requests方法，主要用于发送请求
   解析请求响应报文，封装属性方法，用于取请求响应的状态码、jsonpath值、body、content内容
   封装基本的断言方法，包括check：状态码、响应时长、关键字、json值

2. tools.util包下封装了mysql、sqlserver、elasticserch、redis、excel、json操作类

3. tools.customAssert.commonAssert提供【json对象比对、字典比对、列表比对】 3个常用方法
   2和3结合起来可以实现接口返回数据和数据库、redis、elasticsearch 进行比对断言

执行测试用例输出报告：
1. Pytest支持命令行方式直接执行指定目录下的所有测试代码，有很丰富的插件，支持多线程、按mark过滤测试用例、失败重跑机制……
2. 支持在pytest.ini添加运行时配置，自行学习这一部分内容
3. Pytest有allure插件，在执行命令里添加alluredir，即可自动将执行结果result输出到指定目录下
4. 再用allure generate命令，将输出的result转成html报告
5. 本框架内置执行脚本，runPytest_Private.py ，将pytest执行命令和allure生成报告命令串起来，实现一键完成执行测试、输出报告功能

配置中心

配置全局变量、接口访问域名、数据库/es/redis 连接信息等

Cases代码示例：

执行 Cases

run 脚本执行指定项目的测试用例，目前两种模式：

1、根据配置中心配置的 TESTCASEFILE（支持多个 file 文件），通过 runPytest.py 去执行，执行过程为：

a) 读取对应的测试用例模板文件 xlsx
b) 自动在 TestCases 包下生成接口测试代码
c) 执行 TestCases 包根目录下的所有 Test 开头的测试用例
d) 生成 Allure 报告

此种方法，测试用例的断言必须在测试用例模板文件里提前维护好，一般用于简单断言，如：响应状态码、长度、固定值断言，简单 sql 的数据库断言等等，可以用此种方法。

如需要编写复杂 sql 进行数据库断言、进行 es/redis 断言，需要进行复杂数据处理的，建议自己手工编写断言代码

2、runPytest_Private.py 带上 projectName 参数执行测试用例

a) 执行 Cases 生成器，把维护好的测试用例模板生成接口测试代码，路径也在TestCases 包的根目录
b) 在 TestCases 包下新建 subPackage，按照自己的项目名称命名，如 projectA
c) 把自动生成的接口测试代码文件，拷贝到 projectA 下
d) 编写自己的断言代码
e) 执行 runPytest_Private.py projectA：
将执行 projectA 下所有的测试用例代码，也可以修改runPytest_Private.py 里的代码执行指定 mark 的接口用例
f) 生成 Allure 报告
g) Push 钉钉消息，消息里带上用例总量、失败数量、报告路径
h) 集成 JENKINS 方案：

打包带有 python、openjdk、allure 插件的 docker 镜像，镜像里安装好自动化框架依赖的第三方模块

Jenkins 拉取gitlab 自动化代码到宿主机指定路径

运行 docker 容器，将容器里的工作目录和宿主机的自动化脚本目录挂载上，容器运行时即自动运行自动化，执行完成后，容器自动销毁，保存报告到宿主机

Push 钉钉消息，推送当前运行结果和报告路径

Allure 报告所在大目录集成到 jenkins，通过访问 jenkins 地址查看对应报告

Allure报告示例：

当下问题和优化方案

1、测试数据维护

目前困境：

电商平台souke 的测试数据非自产数据，测试数据极容易随着时间过期，导致一部分测试数据失效，代码覆盖率下降，如果自己造数据成本比较高，也不真实

解决思路：

增加加工测试数据的数据工厂：

前置条件：目前用 csv 维护的测试数据集迁移到 sqllite 数据库技术栈：

计划使用 pandas 数据分析利器，也能很好的支持导入导出 excel 和数据库数据

实现思路：

划分等价类，制定测试数据的筛选规则，从被测数据库同步测试数据到测试数据集

制定通用的测试数据生成规则，根据参数的类型自动生成通用的测试数据，主要用在参数格式、特殊字符等反向测试

2、代码覆盖率测试

目前情况：

目前只是根据测试经验，依据等价类划分，手工寻找测试数据用于测试，不能完全保证测试覆盖率

后续计划：

电商平台souke 用的 java 技术栈，后续计划把 jacoco 与电商接口自动化相结合，接口自动化脚本执行完成后统计代码覆盖率