流量回放自动化测试（流量回放 自动化测试）



大家好，又见面了，我是你们的朋友全栈君。

流量回放近几年一直是大家热衷讨论的话题，具体的效果智者见智。文章作者也是在技术工程领域有丰富的实践经验，推荐一看。

本篇背景是另外一同事朋友，最近在利用流量回放技术应用在服务端接口自动化测试方面，还在各部门全力推进阶段，未来效果暂且不好说，但这部分内容确实各大公司，测试技术大会等等的热词，由于我没参与但我很感兴趣，所以邀请普及一篇，后边应该还会带来实战篇，本公众号坚持原创和干货分享，欢迎长期关注，一同成长，如果你有好的实战分享也欢迎投稿。

在日常的测试工作中我们或多或少总会遇到下列问题：

1）服务架构升级或重构，需要验证原始接口逻辑，对原有的一堆接口做回归

2）对于业务逻辑复杂的场景，每个迭代版本都需要大量的时间用于回归测试

3）编写自动化用例时复杂场景造数麻烦，日常自动化维护成本高

4）构造压测模拟数据麻烦

…等等

那么从服务的所有环境来看，仅线上环境拥有场景丰富、数据真实、覆盖全面的条件，那么我们将线上环境的请求数据获取下来，在指定的环境中模拟用户请求基本上可解决或者优化上面的这些问题。因此有必要需要对流量回放这项技术探究一下，首先从资料总结和自身搭建讲演来讲，总结流量回放的大概流程可为：流量录制 – 数据持久化 – 回放计划 – 环境维护 – 流量回放 – 结果比对。其次，所谓工欲善其事，必先利其器，下面我们看一些常用的流量回放分类以及工具的优缺点。

根据流量录制的位置大致可分为：基于web服务器录制、基于应用层录制、基于网络协议栈录制。

方案：在服务上定制化代码

优点：请求类型比较多样

缺点：不通用，维护成本高，会占用大量线上资源

方案：在网关或基于AOP切面进行录制

优点：对代码无侵入、实现相对比较快捷简单

缺点：会占用线上部分资源、可能会对业务有影响

常用工具：Nginx插件-ngx_http_mirror_moudle、Java-sandbox

方案：直接监听网络端口，复制数据包方式录制

优点：基本对应用无影响

缺点：比较偏向底层实现成本较高

常用工具：goReplay、tcpCopy、tcpReplay

ngx_http_mirror_module

流量请求到nginx后，nginx正常转发请求到目标应用，同时复制流量到mirror服务后不再管控。

优点：

缺点：

项目地址：https://github.com/session-replay-tools/tcpcopy

流转示意图：

TcpCopy主要有tcpcopy和intercept两个模块组成，tcpcopy模块运行在线上机器，主要负责捕获在线请求并修改请求头中的目标地址和 源地址，然后使用raw socket输出技术发送数据包到目标服务器。目标服务器上根据配置的信息将响应数据包路由到intercept辅助服务器。intercept辅助将提取的响应头信息发送给tcpcopy。tcpcopy利用收到的信息修改捕获的数据包属性并发送至目标服务器。

优点：

缺点：

项目地址：https://github.com/buger/goreplay

GoReplay是基于Go语言实现与Tcpdump一样都是依赖pcap库，主要监听网络接口流量来录制流量，支持在线和离线方式回放流量

优点：

缺点：

项目地址：https://github.com/alibaba/jvm-sandbox-repeater

使用jvm-sandbox沙箱技术，通过Java agent或者attach方式挂载到Java应用上。repeater模块根据配置的规则录制或回放数据，console模块主要负责触发和数据交互。

优点：

缺点：

通过技术方案可以方便我们利用线上真实流量验证压测、自动化、回归等场景，根据自己实际的需求选择合适的工具，但一切以不影响线上服务的稳定可用为前提。也期待后续会有更多的更完善的流量回放方案。

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/159900.html原文链接：https://javaforall.cn

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/te-auto/18980.html