1. 概览

得物流量录制回放平台经过几个月的建设，目前已经支持了多个域的日常开发回归工作，沉淀了1000+自动化回归用例，帮助开发人员在上线前发现了多起隐藏bug。作为一个阶段的小结，仅以此文记录下得物流量录制回放体系建设的经验和踩过的坑，让大家了解这个平台能干什么，我们是怎么一步步建设和体系化运转的，遇到了哪些困难，又是怎么解决的。希望此文能抛砖引玉，对如何充分利用好流量录制回放这个工具，为业务带来价值，做出一点点贡献。

2. 背景

如概览所言，在得物进行流量录制回放实践的初衷是为了解决日常测试的回归效率问题。

例如发布前的全场景用例回归，每次迭代希望实现对历史场景进行一次全量且高效的回归验证。目前业界通常使用一些自动化的手段来解决人工回归的效率问题。但是这些自动化回归手段也产生了新的问题。主要体现在以下几个方面：

• 自动化用例编写成本高。每次新增功能都需要编写新的自动化测试回归用例。
• 自动化用例维护成本高。随着用例数量的增加，维护成本指数级上升，代码变更，包括关联的代码变更，都可能导致用例失效，需要耗费大量精力重新修正自动化用例。
• 为了降低维护成本，不得已缩减场景覆盖度以及校验深度，从而导致质量保障的效果打了折扣；

而流量回放的思路有所不同，其测试用例是基于真实流量录制实现的。在维护成本和拟真度上有天然的优势。因为用例的创建成本很低，使得每次迭代全量回归有了理论基础。在结果分析的成本上，则与其他测试手段差别不大。

3. 平台设计

在设计得物流量回放平台之前，我们参考了当前业界一些公司的流量回放平台的设计。通过一些比对论证，我们发现一些业界同类产品设计上存在一些误区，例如：

• 整套体系的玩法未思考清楚，例如采用无差别大批量录制流量，大批量回放 -》比较粗矿的玩法，价值较低

• 一上来就考虑链路回放-》技术挑战性大，性价比不高

• 对排查问题提效的产品设计和研发投入过低 -》最大的问题，会导致用户使用意愿降低。

对这些问题，我们在设计流量回放平台产品的时候会有一些自己的思考：

• 1、精细化，以应用每个接口的角度进行用例沉淀，一个接口可以对应n笔不同业务类型的流量，我们希望终态能做到每个接口的每种业务类型都有一条回归用例沉淀下来

• 2、先聚焦单应用进程回放。让每个应用把流量录制回放作为一个日常迭代的基础check点玩转起来

• 3、多次进行头脑风暴，从使用方，也就是测试，业务研发的角度思考如何能更好地在平台界面上进行错误问题自动分类和问题提示。结合平台研发相应的技术攻关，当前取得了一定的进展。

在具体的实施层面，我们采用业务测试，平台研发，业务研发三方协同的模式。任务分拆如下图所示:

产品设计是业务测试主导的。因为从QA的角度，业务测试有最丰富的经验，这样才能保证最后产出的产品不存在方向性偏差。同时业务测试还负责用例的沉淀和流量回放与得物质量保证体系的集成工作。

平台研发则负责jvm sandbox repeater的相应二次开发技术难关攻关，同时协同业务测试进行产品设计。

业务研发在得物每个迭代会投入少量人力，对流量回放不成功的用例进行分析归类，如果是业务代码bug造成回放失败，则进行bug修复。通过这个三方协同模式，每一方可以发挥各自所长，让流量录制回放体系化轮转起来。

在得物的整体QA体系中，流量回放短期更加聚焦回归性质的提效，未来希望探索更多新功能测试维度的提效。

• 提测阶段卡点：聚焦核心场景，低成本验证每次提测对于核心场景的影响；

• 测试阶段回归卡点：全量场景，重点追求覆盖场景全面性，验证新功能对历史功能的影响；

• 预发环境回归：目前得物预发跟生产同库，未来会推动落地基于预发&生产环境的流量回放，尽可能拉近录制时环境和回放时环境的仿真差异，从而降低回放阶段的噪音影响；

4. 技术选型

当前市面上的录制回放工具主要分两类:

• 一类是诸如go replay之类通过网络抓包，录制流量，并提供回放功能。
• 另一类如阿里开源的jvm sandbox repeater, 在应用进程内录制，可以录制到更精细的信息。

例如: 某次数据库访问操作，某次对外的redis读写操作，等等。根据这些工具的特性分析，不难发现，go replay这类工具更适合做压测，jvm sandbox repeater这类工具能更好地支持测试回归工作。

jvm sandbox repeater在回放时提供了两大类check点，一个是入口的返回数据，一个是子调用的多调用和少调用，包括子调用参数不一致等问题都能发现出来。后面这一点特性对得物业务来说是十分需要的功能，能够检测出一些潜在的风险。例如某个接口里面有一次数据库调用进行转账，某次迭代业务开发引入了bug造成两次数据库调用操作进行了两次转账，而入口的返回数据还是跟原来一致。这个例子中，如果业务幂等没做好极可能造成资损。这类问题可以通过jvm sandbox repeater发现出来。

jvm sandbox repeater跟其他录制回放方案相比，最大的局限性在于只支持java程序。得物当前的后端服务是以java为主，因此这一点对我们来说不是一个阻碍点。

综上所述，我们最终选择了以阿里开源的jvm sandbox repeater为基础，进行得物流量录制回放平台的建设。

5. 技术架构

结合得物的实际情况，我们目前的技术架构如下图所示：

• 沙箱&repeater module版本更新：通过oss发布

• 管控面后台：springboot程序，承载录制回放平台核心功能

• 录制流量存储：写入ES

• 录制环境：通常在生产环境录制，其他环境也支持录制

• 回放环境：得物专门构建了一个容器环境用于流量回放。目的是为了解决业务配置在录制和回放时不一致导致失败噪音的问题（得物大部分业务配置是通过中间件ark实现，ark是得物的配置中心）。当前暂时由测试同学进行业务配置一致性check，后续平台会提供自动check功能

6. 技术挑战

我们在平台建设中也遇到了技术上的挑战，下面列举了部分我们在平台建设中踩过的坑和我们想到的解法。包括我们目前还没有很好解决的挑战性问题。

6.1 开源版本bug修复

在平台建设过程中，我们发现开源的的jvm sandbox存在一些bug。对于这些问题，我们在使用过程中进行了修复。这里仅举两个例子。

1. 录制采样率不均衡

开源版本的采样率算法不均衡，会造成一段时间内流量都采集，一段时间都采集不到的情况。跟我们的预期不符。因此我们在使用过程中修改了采样率算法，使得每笔流量是否录制是否采样的判断逻辑都符合我们设置的采样概率。

2. java入口插件JavaEntrancePlugin bug导致java入口的配置动态变更时无法rewatch

@Override 
 public void onConfigChange(RepeaterConfig config) throws PluginLifeCycleException { 
 if (configTemporary == null) { 
   super.onConfigChange(config); 
} else { 
 this.config = config;
 super.onConfigChange(config);
 List current = config.getJavaEntranceBehaviors(); 
 List latest = configTemporary.getJavaEntranceBehaviors(); 
if (JavaPluginUtils.hasDifference(current, latest)) { 
 reWatch0(); 
 } 
 } 
 }

上述第6-7行部分代码位置应该移动到第10行代码上方，否则无法在运行时重新监听配置变化。

6.2 开源版本插件扩展

开源的jvm sandbox repeater提供了最基础的一些插件能力支持。但是在得物业务应用上使用后我们发现尚有很多能力缺失。因此我们梳理了得物当前需要的插件能力，按使用率排了优先级进行了插件能力的扩展，让更多得物应用可以使用这套方案进行回归。下图得物当前未支持的插件能力，我们也计划在未来一到两个月内补齐。

注：下图部分插件能力开源版本只支持部分功能，例如mq入口不支持，dubbo只支持录制，回放不支持, http只支持入口不支持子调用，等等。部分支持的图中均设置为N。

6.3 支持入口独立采样率

得物的一些服务接口，调用频率会比较低。而这个服务的其他接口调用频率很高。这种情况下，开源版本的统一采样率就满足不了我们需求了，因此我们对采样逻辑进行了改造，用户在管控面上可以为每个接口单独设置采样率。这样就可以单独为调用频率低的接口设置百分百采样。

6.4 用例-场景分类标签化

在平台第一版上线后，用户反馈筛选流量比较耗时。因此我们设计了流量打标的功能，用户可以设置流量打标规则，如果录制的流量符合设置的规则，就会打上一个标签。在筛选的时候可以按标签过滤，进行用例的筛选和沉淀。

如下图所示，用户可以根据入口调用的请求，响应，也可以根据子调用的请求，设置打标规则。当前，这部分的打标规则创建目前还是靠人工完成，并且依赖用户对业务的理解经验，还是半自动化的。后续我们希望通过一些大数据分析，特征提取，聚类算法，进行全自动打标的尝试，希望能进一步降低用户在这块工作上的投入成本。

6.5 新用例自动沉淀

在真正实现全自动化用例沉淀之前，我们同时也在思考能否用一些自动化功能替换部分用户人工筛选流量沉淀用例的操作。我们设计了一个自动沉淀的功能。用户在设置打标规则后，可以指定希望沉淀的标签和希望沉淀的用例集。平台检测到符合条件的一条流量后就会作为用例自动放入指定用例集中沉淀下来。

6.6 回放失败排查提效

回放失败排查提效是一个流量回放最难解决的问题。一方面因为原版repeater上报的信息不够丰富，很多情况需要看日志才能排查，另一方面目前业界也没有比较好的，公开的方法论。我们对此进行了一些初步的探索。当前我们的方法可以一定程度上提效。当然，后面还需要结合实际使用情况进行持续地探索。

我们对回放失败的场景自动进行了以下分类，帮助排查人员聚焦定位问题，同时通过上报更丰富的数据信息提供排查指引。下表从上往下按优先级从高到低排列。界面展示以优先级高的为准，避免冗余无效信息干扰排查。

6.7 失效用例替换提效

根据我们一段时间的实际使用，我们发现在回放失败的用例中，有很大一部分是因为业务代码正常变更导致。这类问题导致的回放失败是正常现象，我们会认为这个用例失效需要等发版后重新录制。其相关的业务代码逻辑应当由本次迭代的新功能的测试用例覆盖。

对于这些失效的流量回放用例，一开始我们是通过业务测试进行人工替换的。但是我们发现这部分工作量比较大。因此我们开发了自动化替换功能。业务测试只需要指定需要自动替换的用例，后续工作都可以通过平台自动完成。

6.8 只读接口预发/灰度不mock回放

因为在得物预发/灰度环境是联通生产环境的数据库和下游应用，因此对于预发进行不mock的回放，特别是对只读接口进行不mock的回放能够在上线前的最后阶段进行一次兜底的回归校验。但是这个方案存在一定的风险。最难解决的问题是，当前是只读的接口难以保证后续的变更不会引入写操作。在当前阶段开放这一功能会引入额外的资损类风险敞口。对此问题，每次回放前都进行人工校验可能可以解决，但是又引入了极大的效率问题。如何高效地保证在预发/灰度环境进行不mock流量回放不会产生资损风险，是一个难度颇高的问题。当前得物在这一领域还处于探索阶段，有一些初步的想法，但是距离真正落地还有一段距离。

7、总结

流量录制回放作为测试领域的一个新生事物，在诞生初期就吸引了广大测试同仁的关注，各个公司也对此进行了一些实践。得物对流量录制回放的实践还属于比较初期的阶段，一些问题的解法也在探索中 (例如如何在预发/灰度回放而不引入资损)。但是通过一段时间的滚动运行，目前已经看到了一些流量录制回放在业务迭代中产生了价值，发现了一些隐藏bug。期望我们能在不断的实践中把得物的流量录制回放体系建设得越来越完善，产生更多的业务价值。

本文来源自：得到技术分享