流量回放平台

测试是产品发布上线的一个重要环节, 但随着业务的不断壮大和快速迭代, 每次上线需要回归的功能会越来越多, 周期越来越长, 测试同学的压力会越来越大, 老板越来越不满意, 恶性循环就此开始...

基于此, 能快速回归测试,提升产品发布效率的流量回放平台应运而生.

在前文中, 我们已经介绍了请求录制和请求收集, 今天再从整体上看下平台架构, 并介绍下平台的另外两个重要服务: RequestBank和StoryTest.

平台架构图(v1.0)

1

RequestBank

流量银行, 记录所有访问日志等信息,并提供数据拉取接口.

2

StoryTest

流量回放的发起服务, 从RequestBank服务拉取数据, 并以相同的参数, method, header等信息再次访问该服务, 并比较返回值是否与预期相同或者数据增强.

3

待完善功能

从整个架构图中可以发现, Service(待回测服务)访问其他服务接口, 中间件信息时, 会有响应速度慢, 依赖服务和数据繁杂等问题, 会影响回放数据的准确性.

例如: 获取用户等级信息接口数据, 在录制时, 用户等级是1级, 也就对应执行用户等级为1级的流程. 但在回放时, 从生产环境上导下来数据时, 用户等级已经变为了2级, 这样对应的流程就发生了变化, 返回数据也就可能不一致, 影响准确性.

小结

到此, 一个流量回放平台的雏形已经搭建好了. 后续还会利用byteman完善接口和中间件部分等相关功能.