原因
负责该项目的同学走了,由我接手,对场景也不是很了解;
刚接手,场景多,过滤条件比较多,自动化不完善,回归起来麻烦而且易造成回归面覆盖不全;
初始想法
一直在考虑怎么保证该项目,后面考虑到是不是可以把stb的流量拿到dev进行再次请求,然后校验dev和stb的结果,有这个想法后眼前一亮,觉得应该可行;
为什么可行?
曾经写过一个捞取mq消息体的脚本;
实现的原理就是根据ip连接服务器,捞取mq消息,进行筛选分割,转成dto,对dto进行校验,不满足校验的信息打印出来;
为什么要写这么一个脚本呢?
原因就是系统接入新业务后,评估不影响新业务,上游测试在穿测的过程中,与下游核对结果,发现本系统的mq消息体缺失一个字段,造成下游消费失败;
后面我就在考虑,万一以后再遇到类似的场景,该怎么保证消息是成功的呢?不能每次都让下游同学来看,自身是否可以保证下呢?每次核对固然可以发现问题,但是也浪费人力,有没有更好的方法呢?想了好久,最终决定自己写个脚本校验,每天捞取,进行校验看看是否还会有问题;
到这里就证明捞取日志,进行分割解析是没问题的,上面的小型流量回放就可以开始实施了;
开始实施–缩减版的流量回放
先大致列了一个计划;
流量捞取;
筛选分割;
再次请求验证;
流量捞取
根据ssh连接,捞取日志,两台服务器的日志进行组装合并;
筛选分割
1、进行分割:留下入参参数、结果集以及接口名;
2、转成dto:根据不同的接口,把请求参数转成不同的DTO对象;
再次请求验证
根据接口,直接赋值dto进行再次请求,拿到结果后进行校验,不同场景不同处理;
到这就完成了一个简单的流量回放;