背景
在日常的测试工作中我们或多或少总会遇到下列问题:
1)服务架构升级,对原有的一堆接口做回归
2)复杂度太高的业务场景,每次迭代版本都需要大量的时间用于回归
3)编写自动化用例时面对复杂场景,日常维护成本高,简单场景做自动化,就是面子工程
此时流量回放的出现能解决我的部分问题:
通过记录线上流量,在开发或者测试环境回放,用来回归原有系统功能,发现系统是否能够正常运行,降低代码变动整体系统带来的风险
流量回放原理
说流量回放之前必须得说下流量录制的原理,首先需要将agent下发到目标服务中,通过字节码增强对目标方法进行增强。录制时拦截对应的方法签名、入参、返回进行采集上报。回放时将录制的流量回放到指定的环境,通过流量返回的diff和断言比较接口业务代码逻辑是否存在问题。
流量录制的流程图如下:
流量回放的流程图如下:
工具分类
流量录制方式:
1)基于web服务器录制
方案:在服务上定制化代码
优点:请求类型比较多样
缺点:不通用,维护成本高,会占用大量线上资源
2)基于应用层录制
方案:在网关或基于AOP切面进行录制
优点:对代码无侵入、实现相对比较快捷简单
缺点:会占用线上部分资源、可能会对业务有影响
常用工具:Nginx插件-ngx_http_mirror_moudle、Java-sandbox
3)基于网络协议栈录制。
方案:直接监听网络端口,复制数据包方式录制
优点:基本对应用无影响
缺点:比较偏向底层实现成本较高
常用工具:goReplay、tcpCopy、tcpReplay
工具解析
Jvm-sandbox-repeater
项目地址:https://github.com/alibaba/jvm-sandbox-repeater
使用jvm-sandbox沙箱技术,通过Java agent或者attach方式挂载到Java应用上。repeater模块根据配置的规则录制或回放数据,console模块主要负责触发和数据交互。
优点:
通过字节码增强的方式可以直接录制Java方法、子调用
对业务代码0侵入
模块功能丰富
缺点:
对服务运行环境有一定侵入
在挂载瞬间会占用较多的机器资源,当业务量大时可能会导致服务夯住
当前功能不完善,需要代码开发能力
流量回放平台和接口测试平台很相似,但是有不同点
相似点:
1)都是基于接口层面测试,包含入参、出参、异常抛出
2)都是可以基于出参结果进行断言
3)都是可进行复杂场景的接口测试
不同点:
1)流量回放是基于用户使用时录制的接口操作流程,一定程度上保证了业务连续性和逻辑合理性
2)流量回放是以基础能力构建用户场景,满足单纯接口测试覆盖不到的用户场景痛点
建设过程:
目标:建设一个流量录制回放工具,可进行流量录制、回放的基础能力,在此基础上增加流量过滤策略、流量内精准断言、增加mock功能、流量编排能力。
Stage1:流量过滤策略
配置新建接口的URI,此时录制时仅录制该接口产生的流量,自动过滤其他业务接口操作流量,在录制流量过滤混杂了其他业务场景的流量
Stage2.:流量内精准断言
在回放详情的流量体中手动标记哪些需要断言,标记后依据不同标记方式进行不同断言
Stage3.:增加mock功能
流量回放启动后自动启动MOCK接口方法redis、数据库调用,快速验证代码本身业务逻辑。同时针对于业务本身的复杂性,增加MD5加密、业务随机数、雪花算法、时间函数等等
Stage4.:流量编排能力
基于实际业务发生时,用户可能存在的随机使用,我们创建了流量顺序,同一个录制的流量,通过流量编排后,可产生N个不同的业务场景