AutoDiff流量回放在集成测试中的实践应用-汽车之家

最新推荐文章于 2024-10-14 09:59:00 发布

TesterHome官方

最新推荐文章于 2024-10-14 09:59:00 发布

阅读量992

点赞数

分类专栏：测试技术和方案测试工具文章标签：接口测试

本文链接：https://blog.csdn.net/Testerhomee/article/details/125504109

版权

文章来源：本文节选自TesterHome社区爱好者合力编写的《2021接口测试白皮书》。

##接口回归测试面临的问题

迭代形态及组织变化

####迭代加快
在当今的互联网行业的形态背景下，产品需求迭代都愈加地追求快速交付流动，大部分公司都采用精益产品研发流程，那么在之家经销商bu内部，我们近2年的平均需求交付时间≈4天，而潜在的问题是，由于原自动化接口测试的开发/维护成本较高已追不上迭代，我们大部分的回归测试是被跳过的，更多要依赖开发人员水平+测试人员经验，所以一旦常规的节奏被打破（紧急需求插入、人员状态、人员变化等），回归缺失的问题就会暴露出来，而这种外来变化其实也越来越频繁。

项目/人员变更

随着公司内部布局的各种变化，也会产生一些项目交接/重组，或人员
转组的情况，一般在业务上会有一波新的改版，而后端接口技术上也会进行重构。但由于刚刚交接，产品、测试、开发都不会非常熟悉原有系统，传统回归测试手段，由于无法确定预期很难进行。

技术演进

另外随着技术的不断演进，给日常接口回归测试也带来了多元角度的影响：

架构或应用内部代码的演进重构的过程本身（容器化、接口合并/
拆分/优化、数据源迁表/迁ES…），需要回归验证支撑。
服务节点多，只改了1个服务几行代码，可能需要验证所有调用方。
服务链条长，跨BU/服务调用多，通过Mock单服务测试不能独善其
身，集成/联调测试阶段问题多。
服务功能类型增多，技术类型需求增多，使用传统回归验证方式效率低，效果差。

解决方案分析

接口自动化vs流量回放

在前述背景下，我们引入了新的流量回放方式来进行接口回归来解决上述问题，使用上一个版本的响应情况作为基准，默认是正确的，然后与新版本的情况做对比，检查差异项是否为预期内。相比原有的接口自动化测试，这种测试方式的收益比要更高。

整体方案

开源方案
当时的流量回放方案大概有 2 种，原理可以简述为：
• 基于 HTTP 接口纯黑盒的回放，如 Diffy。
拉取线上流量请求信息后，在部署了不同版本代码的 2 套测试环境进行 Http
接口的调用回放，实时或离线的比对接口的 response 响应的区别是否符合预期，来进行测试。代表的有 twitter 的 diffy 工具

• 基于代码方法级别的回放及验证，如 Repeater
回放思路相同，但基于代码方法级别的录制和回放验证，一般将查询数据库等操作，在录制时进行记录，回放时进行 mock，从而增加测试数据的稳定。Java 中代表的有阿里的 Repeater

方案分析
而结合我们实际诉求，以及方案的优缺点，进行匹配：

部门内.net 转 java 、接口合并等技术任务，需要这套方案能进行跨语言、平台的回归
需要能够兼并读+写接口的回归，即需要 Mock 或数据还原
需要能支持集成联调阶段，即对外真实的外部调用

基于分析，我们发现单独基于黑盒的方案，对写接口验证能力较弱（写接口对外只返回一个状态 ok），测试数据不稳定 case 类型偏移（如线上有数据的商家，在测试环境回放结果空）。而单独基于 Repeater 的方案，又只能支持单语言平台（不能支持.Net 转 java 的实际诉求），Mock 功能不能兼容有 IO 变化的迭代（只能匹配到已记录的 db 查询）。

没有完美解决所有问题的银弹

经过综合考虑，最终确定：
• 对于读接口（80%）：自研 AutoDiff 进行黑盒流量回放测试。
• 对于写接口：使用 Reapeater 进行回放测试。而其他仍不能支持的写接口场景（如有 io 变更、跨语言等情景）再进行常规的接口自动化测试或手工测试。
整体方案：