共计 4516 个字符，预计需要花费 12 分钟才能阅读完成。
1. 背景介绍 1.1 得物 pandora 介绍什么是流量录制回放？流量录制回放是利用端通过挂载注入录制器探针主动注册到服务端造成录制流量回流，将所有内部调用依赖的响应内容（如数据库、分布式缓存、内部服务响应等）进行残缺记录。由平台向回放器散发流量回放指令。其外围价值是通过间接录制生产的实在数据，将生产实在数据转化成可复用、可执行的流量，疾速地在测试环境中进行回放比对接口返回值和两头链路的验证。得物版本的流量录制回放平台 pandora 在官网开源版本上进行了很大的拓展，反对了很多官网版本不反对的子调用和入口调用。此外，平台还对得物的中间件进行了诸多适配工作，防止了大量的回放失败乐音。
1.2 市场工具比照目前市场上已知的流量录制回放平台大部分都是在 Jvm-Sandbox-Repeater 根底上进行二次开发和革新，并且少数都是只反对 Java 语言。外围原理也都是通过录制线上实在流量而后在测试环境进行回放，验证代码逻辑正确性。2. 实际落地 2.1 合作模式在具体的施行层面，目前采纳的是业务测试，平台研发，业务研发三方协同的模式。工作分拆如下图所示。
2.2 阶段利用流量回放在各阶段的现实施行利用：提测阶段卡点：聚焦外围场景，低成本验证每次提测对于外围场景的影响；测试回归阶段卡点：全量场景，重点谋求笼罩场景全面性，验证新性能对历史性能的影响；预发环境回归：目前预发跟生产同库，将来会推动落地基于预发 & 生产环境的流量回放，尽可能拉近录制时环境和回放时环境的仿真差别，从而升高回放阶段的乐音影响；在得物的整体 QA 体系中，流量回放短期聚焦在回归兜底保障上。
2.3 实际落地流量回放的发展自发动后，在本域由摸索尝试阶段逐步过渡到利用场景拓展阶段。订单流量回放模式在通过一段时间的摸索，摸索出了一套实用于本域迭代的模式。
Part1、尝试接入团队开始发展流量回放的专项之后，通过调研，选取了 40% 的服务优先接入。阶段指标实现 30%P0 利用 top10 接口 100% 场景笼罩，造成迭代落地品质卡点，实现适用性和提效剖析；减少订单域流量回放人员投入，落地品质卡点，笼罩 5% 回归场景；实施方案调研利用的个性，尝试接入流量录制回放；梳理服务的 P0 接口及用例，配置对应的接口及用例标签；用例主动积淀到用例集后，在回归阶段尝试进行流量回放。收益成绩实现 30% 利用造成落地品质卡点，落地 15% 用例回归场景，验证计划可行性和易用性，摸索研发测试协同机制。Part2、摸索降级上一阶段破费大量的工夫梳理接口配置标签，用例积淀速度迟缓，并且收益与投入不成正比，因而调整了策略，利用智能化剖析进行提效，疾速积淀用例，扩充用例量及笼罩的接口量。45% 业务利用接入并均实现强卡点落地，配合平台侧优化，解决大部分组件适配和应用问题，迭代利用流程以及利用指标剖析机制根本跑顺。阶段指标利用：接入的利用交由对应的服务负责人，负责对应服务的接口保护经营及积淀、排错剖析；用例：尝试摸索新的用例积淀形式，进一步扩充用例量，减少笼罩的接口量；排错：依据服务的用例量以及接入的工夫，晋升测试排错能力，阶段 2 完结测开排错达到五五开；2. 收益成绩从开始试点到利用卡点，积淀的用例量也在利用热点流量计划之后开始了降级之路。接入的利用数也超过原定指标达到 50% 且均实现强卡点落地。利用智能化剖析策略提效成果显著，积淀的用例数成指数型增长，接入利用的 P0 接口覆盖率达到 100%。测试排错能力晋升，每迭代流量回放发现的 bug 数也在减少，新计划的可施行性和可推广性根本合乎预期。Part3、专项提速在积淀的用例 case 大量的减少、用例积淀速度提效显著的前提下，流量回放在迭代的利用中发现更多的缺点，布局扩充接入的利用以及笼罩的接口范畴。阶段指标利用接入：新增 40% 利用接入，接入利用占比共计 90%；排错：晋升测试的排错能力，新版本排错由平台研发转交业务研发，测试开发排错占比五五开；用例量：减速积淀用例量，扩充笼罩的范畴，至多 65% 的利用实现全量用例积淀；卡点：接入利用达到 100% 卡点，晋升排错速度，局部利用由生产卡点转为预发卡点；全域接入利用接口维度覆盖率 98% 以上，接口配置欠缺度 98% 以上，全量用例门路覆盖率 60% 以上。收益成绩随着利用的接入，积淀的用例量也在扩充，发现的问题数也在增多。同时也减少覆盖率的指标来掂量流量回放用例笼罩的代码占总代码行的比值。随着对覆盖率的关注，平台采样策略也进行了一个调整，删除所有历史积淀用例，仅积淀新策略施行之后录制的流量。流量回放接入 90% 利用，扩充利用接入和 case 积淀，超预期达成指标，积淀利用 Case 量是原打算的 3 倍，此阶段累计发现缺点数占全域流量回放发现的 bug 数的 45%，充沛验证了落地策略的有效性；从阶段 3 本域发现的缺点统计来看，其中回归类 BUG 占比 38%，发现线上自有 / 暗藏问题占比 8%，迭代过程中代码问题（日志报错）和代码标准类问题占比 46%，性能问题占比 8%；接口配置欠缺度 100%；接口维度覆盖率 96.49%；全量用例门路覆盖率 79.32%，全量代码覆盖率均匀 39.8%；3. 总结剖析 3.1 问题归类剖析 3.1.1 累计发现的缺点分类：
3.1.2 累计发现的缺点起源分类：
3.1.3 典型案例：回放时零碎异样，排查之后定位为 NPE 类问题，如：
response 返回的业务字段 diff 比照不统一，如：
通过对缺点以及缺点起源的归类不难看出：流量回放发现拦挡的问题近一半都是会引起生产业务报错的，其中包含像金额不对波及资损的问题以及字段传值不对、枚举类型取错等缺点；作为生产公布前的最初阶段的防线之一，充沛展示了流量录制回放作为对测试回归的兜底能力的补充伎俩的重要性。45% 左右的问题是手工测试过程中难以发现暗藏比拟深的代码层面问题，例如 NPE 报错、入参出参字段未序列化等，这些问题如果仅仅通过前端测试或接口测试不看日志不一一比照所有字段势必会将问题带到生产环境，最终影响生产环境的稳定性。6% 左右的性能问题，例如存在重复子调用，影响接口 RT，如果不在生产公布前发现解决，势必给用户体验带来肯定的挑战。从缺点的起源上看，发现的缺点起源还是集中在我的项目迭代需要和技术优化上，充沛验证了流量回放整体提速后的有效性以及对测试笼罩兜底能力的补充。通过对失败用例的排错剖析教训的累积和分享培训，参加专项的测试团队的整体技术水平通过流量回放专项提速在技术气氛上有显著晋升，造就了多位同学对本身负责模块的实现的代码走读能力，以及深挖缺点的 code diff 能力。3.2 适用性剖析实用场景实用于返回数据量大、业务流量也很大，以及读取业务占比大的场景，如 ToC 产品。不实用场景挂载沙箱后开启录制会导致 RT 霎时飙高，影响生产服务的稳定性。异步场景目前流量回放平台不反对。须要验证数据库的落地，节点的流转的链路测试，须要自动化。先投入能迅速造成能卡点有收益的利用（迭代代码变更绝对少，分层构造比拟好，异步少，写操作少），把看失去的应用成果做进去。流量回放是否齐全代替手工回归以及自动化？目前来看，答案是否定的。首先，从沙箱挂载到接口配置再到流量录制这一套流程下来，也须要较长的工夫能力达到较高的用例笼罩，对于一些边界极其场景还是须要手工设计；其次，流量录制回放是后置的回归兜底，更侧重于对历史逻辑的回归验证。1、接口笼罩不全。迭代需要新接口，未配置关联录制，不在流量回放的录制范畴。2、全量代码覆盖率不高。接口曾经配置笼罩了，然而因为采样比例小场景极其等起因，接口的分支场景并没有录制到未被笼罩。3、排错能力的高下影响。接口笼罩了，排错的时候因为新加了子调用，导致失败的用例在排错的时候容易被简略定义为代码变更。4、平台问题。diff 比对异样，显示回放胜利，异步线程的回放是一个待攻克的难点。3.3 面临的挑战 3.3.1 排错的效率录制流量后对流量进行回放，发现回放后果比对失败的很多。通过对失败起因的排查与剖析，有些是代码 bug 导致的失败，但更多的失败不肯定是代码 bug，常见乐音次要蕴含：代码批改，新增或删除了子调用，导致 mock 失败平台不反对的子调用，导致失败工夫戳相干的子调用，diff 不统一子调用中应用随机参数相干，导致 mock 匹配不上 repeater 代码本身缺点业务自增数据差别配置核心数据不统一返回无序元素汇合，造成后果比照误差失败起因很多，真正无效的失败数很少。如此一来，每次回放失败的排查老本就十分高。给业务的推动造成了微小的妨碍。原版 repeater 上报的信息不够丰盛，很多状况须要看日志能力排查。目前也没有公开成熟的参考的计划。平台也进行了一些初步的摸索，对回放失败的场景主动进行归类，上报更丰盛的数据信息提供排查指引，帮忙排查人员聚焦定位问题。同时平台也针对一些乐音进行自动识别并在回放时主动过滤降噪。
3.3.2 异步线程录制回放问题入口主线程不等子线程执行完就返回的异步场景，以后的策略是用户可配置对异步子线程的多调用疏忽，只关注主线程的执行状况。这一形式尽管能够晋升这种异步线程场景的回放成功率，然而损失了异步子线程业务逻辑的回归能力。
下面的案例就是因为利用开启了排查提效优先的开关，疏忽了异步子线程的调用，导致 diff 比对异样，显示回放胜利。该接口在生产公布时报了异样，String 类型长度超长被 try catch，埋点失落。4. 瞻望 & 将来布局流量录制回放作为测试畛域的一个新兴事物，在诞生初期就吸引了宽广测试同仁的关注，市场上也有些公司也对此进行了一些实际。咱们对流量录制回放的实际还处于起步的阶段，一些问题的解法也在摸索中。预发只读接口非 mock 回放在得物预发环境是联通生产环境的数据库和上游利用，因而对于预发进行不 mock 的回放，特地是对只读接口进行不 mock 的回放可能在上线前的最初阶段进行一次兜底的回归校验。最难解决的问题是，以后是只读的接口难以保障后续的变更不会引入写操作。在以后阶段凋谢这一性能会引入额定的资损类危险敞口。对此问题，每次回放前都进行人工校验可能能够解决，然而又引入了极大的效率问题。如何高效地保障在预发 / 灰度环境进行不 mock 流量回放不会产生资损危险，是一个值得摸索的问题，须要研发跟测试的共同努力。计划 1- 单回放（准实时回放）
计划 1 落地遇到的问题：1. 配置核心的数据不统一，乐音比拟大 2. 时效问题，有 10S 的时差，一些业务对时效要求比拟高计划 2- 双回放（实时回放）
计划 2 不仅防止了下面计划 1 的问题，另外后续布局还能够依据覆盖率积淀无效用例集，手工增加异样用例。通过一段时间的运行，目前曾经看到了一些流量录制回放在业务迭代中产生了价值，发现了一些暗藏 bug。接入流量回放显著的变动是可能将测试从沉重的回归测试、用例梳理保护等重复性高的劳动中解放出来，将重心放在测试计划的设定、思考测试策略以及自我晋升的实际上，比方做些辅助排错提效的 coding 能力晋升和增强对业务的相熟的宽度和深度上，从而最大水平的保障业务零碎的品质和稳定性。将来冀望能在一直的实际中把得物的流量录制回放体系建设得越来越欠缺，解放更多的生产力，产出更多的价值。文 / 苏三