基于 RPC 接口的业务侧流量回放

背 景

在产品需求迭代过程中，功能测试与回归测试是必不可少的两个环节。对于改动较大的项目，首先，确保功能的实现符合产品逻辑并做到 100%没有问题离不开有效的功能测试；其次，项目中很多逻辑的改动都是在原有功能的基础上进行的，这时候就需要一定的回归测试。通常，在功能测试时，人工 case 不能模拟线上用户的所有行为，且具有一定的主观性；回归测试时，采用全面回归的方式往往也伴随着测试成本的增加。一个好的方式就是利用线上流量来验证。

• 一方面，通过记录线上流量，在沙箱或者测试环境回放，来发现新分支代码是否能够让系统功能正常运行，从而降低代码变动给整体系统带来的风险；

• 另一方面，通过线上流量进行线下回归测试可以在保障全面回归的情况下有效的节约测试成本。

简 介

流量回放

使用真实的线上流量进行线下回放测试，节约回归测试成本，保障代码质量，进而减少线上事故。

流量平台搭建成本

全链路流量平台具备的能力

• 能录制线上真实流量；

• 能实现海量数据的并发请求；

• 能支持常见协议的请求；

• 对线上尽量应用透明，也就是说无侵入性；

• 工具使用简单，能够满足各场景流量回放。

可以看出按照以上的能力需求搭建一个流量平台需要投入一定的成本，而我们目前考虑的是针对某一个项目的快速流量回放，可能并不需要设计这么复杂并且重量级的流量平台。那么，如何快速的实现满足业务需求的流量回放呢？基于 RPC 接口的流量回放，简单、快捷、容易上手。接下来我将通过实际的业务场景来介绍下流量回放在采货侠卖场侧的业务应用。

流量回放的应用

1、项目背景

采货侠卖场侧新增后台配置功能且还涉及到对成拍逻辑的改动，需要验证新功能的正确性并对多种成单场景进行一定的回归测试。

• 回归工作量大需要有效的手段提高测试效率；

• 成单逻辑不容出错需要 100%的保障。

2、 方案

流量回放

• 回归测试：使用真实的线上流量进行线下回放测试，对比不支持议价功能的商品线上、线下成单结果的一致性；

• 功能测试：使用真实的线上流量进行线下新功能的验证。线上保持原有 Apollo 配置逻辑，线下应用新开发运营后台的配置功能。保持相同配置应用线上流量数据通过新开发分支代码运行获取相应的成单结果，验证补贴后台和议价后台功能的正确性。

优点

• 可以高度结合业务逻辑，实现细粒度定制化流量复制；

• 解放部分回归测试的人力成本，提升测试效率；

• 对业务的用例场景更加客观，保障代码质量，进而减少线上事故。

3、核心功能

流量采集

• 通过云窗获取相应要求的线上商品信息以及对应的最高出价和成单结果

• 将云窗所得线上数据的相关信息写入到数据库对应的字段中

流量回放

• 代码设计逻辑

首先，通过读取线上商品的保底价映射成相同价格的线下商品参拍暗拍卖场，接着模拟用户在采货侠卖场中的真实行为进行流量回放，并将线下的商品数据和成单结果写入数据库表；整个过程中采用了多线程以及数据库表批量增加、查找来提高运行效率。

• 数据存储结果

表中线上、线下数据一一对应存储，清晰、明了有利于结果分析。

结果分析

结果分析思路：调用开发分支在测试环境进行流量回放，得到相应的期望结果后和线上同一商品的相应结果进行比较，判断结果是否一致。校验的字段可根据实际需求场景进行相应的变更，在本次案例中验证的字段是成单结果和补贴金额。

• 回归测试验证逻辑

读取不议价商品的流量回放成单结果和线上相应数据的成单结果进行对比，判断结果是否一致。如下图所示为成单验证结果：线上和线下的成单结果全部是一致的，这说明新需求代码的开发未影响到原有不议价商品成单逻辑的正确性。此外，采用该方法进行测试使原计划进行回归测试的时间缩短了 3 倍多，这有效的节约了回归测试的成本。

• 功能测试验证逻辑

为了做进一步的功能保障。通过获取线上真实的用户流量，在保证线上原有配置和线下运营后台一致的情况下，调用新分支代码实现线下流量回放得到相应的预期结果，然后和线上结果进行比对。首先，对比线上、线下成单结果是否一致来验证成单逻辑的正确性；其次通过比较线上、线下补贴金额是否一致来验证运营后台补贴配置功能的正确性。本次验证不关心成单后商品的状态流转，而线上部分商品状态已经流转，所以验证成单结果时，可以把生成订单后流转的一些状态重置为成单状态和线下成单结果进行比对。逻辑如下：

验证结果如下：

首次验证结果中出现了部分商品线上、线下成单结果不一致，需进一步分析解决

问题 1：线下部分商品状态一直在售卖中

原因：有部分商品调用结束竞拍没有成功

解决：商品调用结束竞拍失败后继续重新调用

问题 2：线上商品成单，线下商品却是流拍

原因：线下运营后台部分价格段的设置没有和线上的保持一致

解决：保证线上、线下各价格段补贴、议价金额一致

确保线上、线下配置一致的情况下，使用优化后的代码重新进行流量回放，可以得到相同成单结果和补贴结果。说明运营后台配置功能的代码实现以及成单逻辑都是正确的。

4、总结

（1）流量回放的项目需求是不一致的，因此我们也可以采用一些灵活的方法来进行结果验证；

（2）目前公司底层代码实现多流量路由、多 IP 随机分配的方式，所以测试时一定要进行修改，测试服务调用保证在自己的测试机器；

（3）采用基于 RPC 接口的调用方式实现流量回放可以快速满足项目的短期验证，但是从一个长远的发展来看，搭建一个流量平台也是很必要的。

展 望

流量回放的应用场景不仅仅是以上介绍的两种。对于线上采集的流量，不同用户会有不同的业务用途，如压测平台可能希望将流量先持久化；有些研发同学只是简单从线上引一份流量转发到自己的开发环境做新特性测试；有些同学希望转发 QPS 能达到一定水位以实现压测的目的；还有的是特定流量会触发线上问题，他们希望把这段流量录制下来线下 debug 等等。因此，我们可以在后续的业务场景中不断的应用和扩展。

作者：高鸣旋

转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。

关注公众号「转转技术」（综合性）、「大转转 FE」（专注于 FE）、「转转 QA」（专注于 QA），更多干货实践，欢迎交流分享~