1
背景
- 随着业务量和业务复杂度度增加，每次业务迭代都需要考虑业务影响域进行回归，效率低
- 业务重构导致覆盖度一定程度上不完全，质量不高
- tcp接口众多，http接口更接近业务场景
因为上述业务特点，故选择了接口diff的方式改进测试过程中效率和质量问题
2
实现目标
- 根据环境数据配置进行接口数据对比，找出结果中的差异
- 用例集成，使用csv文件管理用例case，支持不同业务线用例统一管理
- jenkins集成，自动化下载代码、执行用例、生成测试报告
- 入口集成，统一集成到开放平台中形成数据闭环，可选择具体业务线执行对应的用例集，报告产生后可在平台统一查看
3
技术实现
- 因为是通过jenkins集成部署到服务器中执行用例，故选择兼容的csv文件类型来做用例管理，每个业务有对应的csv文件用例集，主要维护用例接口名、要比对的配置环境、接口请求参数、接口请求cookie、cookie用到的uid等，其中接口请求参数可以通过数据平台初始化，更多接口定制化的数据就需要通过业务场景中抓包获取
- 接口数据集初始化，通过平台选择具体的业务线数据集以读取对应的csv文件中的接口case，通过数据平台获取uid对应的ppu为cookie准备数据，并组装单测框架所需的参数化数据
- 使用pytest单测框架执行用例，将参数化的用例数据进行接口请求，其中通过环境配置请求出json结果并传给服务平台进行diff比对，根据对比信息使用断言比较结果的差异（默认是线上同沙箱结果数据的比对）
- 在用例执行中发现服务器不稳定导致接口比对失败，故使用pytest-rerunfailures插件实现用例失败重试机制
- 用例执行后产出报告文件并发送邮件，平台页面可查看具体结果
4
经验分享&思考
- 接口diff更多针对的是读数据的请求，也可以根据具体情况做写数据的diff，但要注意写数据会在线上产生脏数据，其中写数据之后的验证一定要有对应读数据结果验证的配合
- cookie中的数据要根据实际接口进行配置，如客户端会根据v、t值不同有不同的逻辑
- 接口diff与接口测试无异，更多需要接口覆盖度（要是接口参数组合和异常情况的覆盖），与功能业务测试相辅相成
- 接口diff主要的使用场景：接口功能重构、功能快速迭代、沙箱验证回归
- 接口diff是对两个不同环境进行数据比对，那么环境的数据源就必须一致，因此比对时源数据的正确性就很重要
- 接口diff对新增接口的对比验证有一定的局限性
- 目前主要针对接口返回的全部数据进行比对，只对变化的字段进行过滤（如metric），后续用例量不断增加，diff比对的耗时也会递增，这样就要提前考虑比对数据字段中要过滤的部分和增加代码并发执行策略
- 用例执行过程中因为服务的不稳定经常发生接口异常的情况，故加入重试机制
