拨开流量录制回放从基建到业务落地的迷雾

2022 年 8 月 20 日 InfoQ

作者 | 汪成坤

策划 | 褚杏娟

在泛敏捷思潮变革、DevOps 大行其道的背景下，小步快跑的模式极大程度压缩了质量保障活动的时间，传统的自动化测试工具已无法满足持续交付的需求。流量录制回放的概念近年来愈发火热，从业界大会到社区论坛，众多工程师进行了大量的思辩悟，肯定了 API 录制回放能有效地解决测试、研发工程师在质量活动中的核心痛点从而带来可观测的研发效能提升。

流量录制回放的核心价值是通过直接录制生产的高保真数据，快速地在测试环境中进行回放比对接口返回值和中间链路的验证。录制回放很热，行业教育也很充分，但是要实现一站式开箱即用的平台建设难度大、落地场景模糊不清。众安科技汲取业界优秀思想，沉淀了诸如静默式探针注入、自动降噪等核心链路的底层基础建设方案，并在集团核心事业线进行了深入的落地验证，并取得了可见的成果。本文详细介绍了众安科技的研发和落地过程，希望能对大家有所启发。

众安科技工程效率部质量中台团队聚焦于录制回放核心链路的基础建设和探索核心业务场景落地的价值，经历了需求调研、技术选型验证、方案设计、MVP 版本系统、易用性验证、稳定性验证、业务价值落地等过程，最终沉淀了 Magic 流量录制回放产品，从回归验证、覆盖率收集、流量复用等多个手段来赋能研发效能质量。

图 1：产品里程碑

我们要解决的问题

随着业务系统的演进，业务系统日趋复杂，质量工程师整天疲于奔命，传统的功能测试或者自动化测试行为已经无法给到质量保障的自信力，质量活动的痛点如影随形。我们大致总结如下：

脚本维护成本高：无完整接口契约文档来辅助接口自动化实施，迭代变更，测试用例编写和维护成本高。
项目时间紧：测试回归不充分。
人员经验不足 & 测试造数难：脚本参数无法模拟真实环境场景，较难复现 bug。
流量复杂：请求构造成本比较高，测试场景覆盖不全。
业务复杂：业务场景梳理困难，流量配比不真实。

我们同样也是看到了不管是集团内部还是行业质量验证活动中都存在这些疑难杂症，例如众安集团内部产品采用的双周敏捷迭代模式，留给测试同学的质量活动时间被压缩得很紧，测试同学基本上无法在每个迭代做到核心功能的回归全覆盖验证。

我们致力于解决各事业线同学的核心痛点，将测试同学从繁杂的回归测试、用例维护的重复性劳动中解放出来，让大家的重点放在测试策略和测试计划的设定思考上。流量录制回放很大程度上能解决这些问题。

接下来，我们从底层基建建设到核心业务场景落地两方面跟大家分享下众安科技在流量录制回放平台的建设实践。

建设目标

产品立项前期，我们走访了集团各个事业线和参加业界大会，在充分了解行业在质量活动中产品诞生根因章节提到的痛点后，梳理了可运用的应用场景，并确定了技术方案、明确了建设目标：将生产高保真数据变成可复用、可执行的流量。

图 2：技术方案

应用场景

功能回归测试：采用录制的真实数据生成自动回归用例，覆盖所有已知场景和用例，减少测试投入成本。
改造验证：录制的稳定系统的场景和数据，进行全场景全覆盖自动回归测试，验证和保证系统基本场景和逻辑维持不变。
调用链路验证：录制过程生成调用链路，包括入口调用、子调用，快速识别链路调用失败节点。
覆盖率收集：流量批量回放后联动代码代码扫描平台快速进行覆盖率收集。
性能压测：用真实的压力流量（618，双 11 等）代替模拟数据，打通压测工具平台，达到测试人员即需即用。

技术方案

整体架构基于录制回放器的主路复制，设定接口采样率、流量分组等策略，应用端通过挂载注入录制器探针自动注册到服务端形成录制流量回流，平台层向回放器分发流量回放指令，这样形成了基本的流量录制回放闭环。

当然在完成流量录制和回放的主链路后，流程易用性、稳定性、跨环境回放数据不一致带来的比对噪音等一系列问题需要解决。Magic 质量中台团队聚焦于底层基建建设，形成了以 Mock 回放、自动降燥回放、普通回放三种模式的技术实现。

图 3：技术实现链路

实践落地

录制回放器探针静默注入

录制回放器作为底层支撑，如何优雅地注入 Agent 探针决定了产品推广的难度。我们考虑过编排基础镜像、边车模式等方案。如下：

图 4：探针插件注入方案

通过对比各个方案的优劣势，本着开箱即用、APP 无须改造适配、用户易上手的目标，我们最终选择了插件化注入的方式，Agent 静默式注入被测 APP，用户可自由地拆卸、自由地进行 POD 的选用：

被测应用无需额外开发适配
Agent 探针自动注册
Agent 探针可插拔
自由启停
多 POD 自助选择

Agent 自助注册目的是能够将已经挂载探针的应用通过长链接的方式注册到平台层，用户能够快速发现这些 Agent 并围绕探针展开录制回放的活动。

Agent 自动注册方案：探针通过长链接的方式与 Adapter 适配器握手并维持心跳。

图 5：Agent 自动注册技术方案

Agent 发现：平台层能够自动识别注册上来的 Agent，进而能够进行录制计划的设定和回放指令的下发。

图 6：Agent 自动注册

流量分组

生产海量的流量录制下来用户存在管理的诉求，用户需要按照业务属性、接口分类等纬度来编排数据。因此我们开发了流量分组的功能，用户可以根据使用场景对需要录制的接口进行分组来标记自己的流量，从而在回放和流量转化时更好地决策，每一组流量分组包括接口白名单和接口黑名单设置。接口需支持 path 输入规则，从根目录开始 /path1/path2, * 标识通配。

图 7：录制接口分组配置

接口采样率

同一场景下重复的接口如果全部录制的话，对于使用者来说存在不必要的鉴别成本，对于应用来说也会增加无效的硬件资源的消耗，接口采样率旨在接口级别控制采样的比率，进而在第一层起到去重的目的。

图 8：接口级采样率设定

流量脱敏 & 去重

通过以上录制计划的设定和 Agent 探针的基础，我们实际上就可以开启录制开关来录制流量。

图 9：录制流量

然后，从生产录制的流量到测试环境回放，我们需要针对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。

在涉及客户安全数据或者一些商业性敏感数据的情况下，要对真实数据进行改造并提供测试使用，如身份证号、手机号、卡号、客户号等个人信息都需要进行数据脱敏。这块脱敏包括生产数据展示脱敏和回放前执行数据造数脱敏，我们通过脱敏引擎制定通用的脱敏策略来识别需要变形的数据。

由于生产环境会存在很多重复和相似度高的流量数据，为了减少不必要的存储成本和提高录制流量的可用性，我们通过一定的策略进行频次筛选，将流量进行去重处理。

相似度计算方面，我们采用了 Levenshtein 距离算法，在获得字符串相似度之后，计算出请求体返回体相似度，再结合多级 key 的影响因子策略进而计算出两条流量的相似度，进而决策需要持久化保存的流量。

图 10：脱敏 & 去重技术方案

降噪过滤

已录制的流量进行回放，由于跨环境数据不一致，同一接口返回值不同，极易导致回放比对时失败，对使用者排查成本过高，疲于进行比对数据的走查和订正，常见噪音主要包含：

随机数：请求参数或者返回结果中使用了随机数。
时间戳：业务代码中使用时间戳进行逻辑处理，例如：System.currentTimeMillis()。
自增数据：业务数据自增。
链路 ID 标识：类似链路 ID、SequenceID 等标识的透传。

手动提噪

如何消除跨环境回放时数据不一致带来的回归对比验证失败的噪音？我们可以通过提供全局、应用级别、接口级别对噪音字段进行配置的方式进行手动预设噪点，例如：

图 11: 手动噪点提取

自动降噪

上述前置配置可以解决一部分问题，适合存在通用性字段且数量不多的情况，可以作为降噪的第一层配置。但是针对未知接口和海量数据单，靠字段配置的成本是灾难性的，我们需要做到能够自动识别噪音并在回放时自动过滤。

业界也有比较成熟的方案，Twitter 开源的 opendiffy 通过配置可进行快速的结果对比，自带噪声过滤功能。在整个测试开展过程中，Diffy 需要部署三个版本的系统，以实现它的噪声过滤和对比功能，它们分别是：

候选版本（candidate）：该版本为待测版本，有着最新待测代码。
稳定版本（primary）：该版本通常是已经上线版本，或者是已知功能正常的版本。
稳定版本副本（secondary）：该版本是稳定版本的副本，和稳定版本运行相同的代码，主要用于排除噪声。

OpenDiffy 工作原理：

通过向稳定版本和稳定版本副本回放流量，对比其流量差异得到“噪声 ”；
通过向候选版本和稳定版本回放流量，对比其流量差异得到“原始区别”；
再从“原始区别”剔除“噪声”，得到最终的 diff 结果。

Diffy 主要是充当了一个前置代理服务的角色，能够将来源请求分发到不同版本的系统中，通过对各个版本系统的输出进行对比，得出最终结论。但不足的是，opendiffy 的落地需要每个被测应用单独部署 diffy 服务，从机器成本、部署成本角度看，这是不被允许的。

我们汲取了 opendiffy 通过稳定版本和稳定版本副本差异这种噪点提取的思想，并自研了自动降噪过滤的逻辑：

通过对比 app 录制版本与副本提取噪点树形结构。
在与回放版本对比时以噪点为依据进行自动过滤。

图 12：自动降噪原理

噪点提取逻辑：通过提取的差异作为噪点依据。

图 13：自动降噪实现方案

噪点提取成果：回放时过滤噪音，同时提供人工二次结果订正的能力。

图 14：自动降噪噪点提取

Mock 回放

当然，跨环境回放除了数据不一致带来的比对噪音，还有中间件、第三方调用等中间链路的影响。Mock 模式下的回放对于外部的调用都是 Mock 的，这个过程不会真正去访问数据库或其他中间件，回放过程会将录制子调用和回放子调用的入参进行对比，如果参数不一致那么会阻断回放流量，如果参数一致会使用录制子调用的结果进行 Mock 返回。

回放完成同样会产生一个响应结果，这个时候我们会对比原始录制结果和回放响应结果，根据该对比结果和子调用的对比结果就能得出被测试系统的正确性，我们需要具备适配主流中间件的能力，通过自动监听追踪调用链路，回放时自动 mock 和展示回放轨迹。

中间件插件适配：

图 15：Mock 回放中间件适配

中间件链路回放轨迹：

图 16：回放链路轨迹对比

智能用例推荐

尽管我们可以通过流量分组、流量去重进行流量筛选，但是录制下来的生产流量仍然是海量的，对于用户来说很难快速找到自己需要的接口流量展开日常巡检、接口测试等质量活动。为此，我们思考怎样将海量的数据精准地沉淀为可复用的、可观测的用例来进行常态化的定时回归验证，这也是产品推广过程中可以落地的价值所在，因此智能用例推荐应运而生。

智能用例推荐的目的是通过预设流量转化规则引擎，在录制过程中自动匹配规则，将录制的流量自动转化为用例，用户基于这些用例进行定时回归任务的设定、接口自动化和压测引流，已达到复用的目的。

规则引擎设定：基于接口请求信息的推荐规则设置。