订单流量录制与回放探索实践

什么是流量录制回放？流量录制回放是应用端通过挂载注入录制器探针自动注册到服务端形成录制流量回流，将所有外部调用依赖的响应内容（如数据库、分布式缓存、外部服务响应等）进行完整记录。由平台向回放器分发流量回放指令。其核心价值是通过直接录制生产的真实数据，将生产真实数据转化成可复用、可执行的流量，快速地在测试环境中进行回放比对接口返回值和中间链路的验证。,得物版本的流量录制回放平台pandora在官方开源版本上进行了很大的拓展，支持了很多官方版本不支持的子调用和入口调用。此外，平台还对得物的中间件进行了诸多适配工作，避免了大量的回放失败噪音。,,目前市场上已知的流量录制回放平台大部分都是在Jvm-Sandbox-Repeater基础上进行二次开发和改造，并且多数都是只支持Java语言。核心原理也都是通过录制线上真实流量然后在测试环境进行回放，验证代码逻辑正确性。,在具体的实施层面，目前采用的是业务测试，平台研发，业务研发三方协同的模式。任务分拆如下图所示。,,得物流量回放实施模式,流量回放在各阶段的理想实施应用：,在得物的整体QA体系中，流量回放短期聚焦在回归兜底保障上。,,得物迭代&项目时间轴,流量回放的开展自发起后，在本域由探索尝试阶段逐渐过渡到应用场景拓展阶段。,订单流量回放模式,在经过一段时间的探索，摸索出了一套适用于本域迭代的模式。,,团队开始开展流量回放的专项之后，通过调研，选取了40%的服务优先接入。,1. 阶段目标,2. 实施方案,3. 收益成果,上一阶段花费大量的时间梳理接口配置标签，用例沉淀速度缓慢，并且收益与投入不成正比，因此调整了策略，应用智能化分析进行提效，快速沉淀用例，扩大用例量及覆盖的接口量。45%业务应用接入并均实现强卡点落地，配合平台侧优化，解决大部分组件适配和使用问题，迭代应用流程以及应用指标分析机制基本跑顺。,1. 阶段目标,2.收益成果,在沉淀的用例case大量的增加、用例沉淀速度提效明显的前提下，流量回放在迭代的应用中发现更多的缺陷，规划扩大接入的应用以及覆盖的接口范围。,1. 阶段目标,2. 收益成果,随着应用的接入，沉淀的用例量也在扩大，发现的问题数也在增多。同时也增加覆盖率的指标来衡量流量回放用例覆盖的代码占总代码行的比值。随着对覆盖率的关注，平台采样策略也进行了一个调整，删除所有历史沉淀用例，仅沉淀新策略实施之后录制的流量。,,,,,,通过对缺陷以及缺陷来源的归类不难看出：,适用于返回数据量大、业务流量也很大，以及读取业务占比大的场景，如ToC产品。,先投入能迅速形成能卡点有收益的应用（迭代代码变更相对少，分层结构比较好，异步少，写操作少），把看得到的使用效果做出来。,流量回放能否完全替代手工回归以及自动化？,目前来看，答案是否定的。首先，从沙箱挂载到接口配置再到流量录制这一套流程下来，也需要较长的时间才能达到较高的用例覆盖，对于一些边界极端场景还是需要手工设计；其次，流量录制回放是后置的回归兜底，更侧重于对历史逻辑的回归验证。,1、接口覆盖不全。迭代需求新接口，未配置关联录制，不在流量回放的录制范围。,2、全量代码覆盖率不高。接口已经配置覆盖了，但是由于采样比例小场景极端等原因，接口的分支场景并没有录制到未被覆盖。,3、排错能力的高低影响。接口覆盖了，排错的时候由于新加了子调用，导致失败的用例在排错的时候容易被简单定义为代码变更。,4、平台问题。diff比对异常，显示回放成功，异步线程的回放是一个待攻克的难点。,录制流量后对流量进行回放，发现回放结果比对失败的很多。经过对失败原因的排查与分析，有些是代码bug导致的失败，但更多的失败不一定是代码bug，常见噪音主要包含：,失败原因很多，真正有效的失败数很少。如此一来，每次回放失败的排查成本就非常高。给业务的推进造成了巨大的阻碍。,原版repeater上报的信息不够丰富，很多情况需要看日志才能排查。目前也没有公开成熟的参考的方案。平台也进行了一些初步的探索，对回放失败的场景自动进行归类，上报更丰富的数据信息提供排查指引，帮助排查人员聚焦定位问题。同时平台也针对一些噪音进行自动识别并在回放时自动过滤降噪。,入口主线程不等子线程执行完就返回的异步场景，当前的策略是用户可配置对异步子线程的多调用忽略，只关注主线程的执行情况。这一方式虽然可以提升这种异步线程场景的回放成功率，但是损失了异步子线程业务逻辑的回归能力。,,上面的案例就是由于应用开启了排查提效优先的开关，忽略了异步子线程的调用，导致diff比对异常，显示回放成功。该接口在生产发布时报了异常，String类型长度超长被try catch，埋点丢失。,流量录制回放作为测试领域的一个新兴事物，在诞生初期就吸引了广大测试同仁的关注，市场上也有些公司也对此进行了一些实践。我们对流量录制回放的实践还处于起步的阶段，一些问题的解法也在探索中 。,在得物预发环境是联通生产环境的数据库和下游应用，因此对于预发进行不mock的回放，特别是对只读接口进行不mock的回放能够在上线前的最后阶段进行一次兜底的回归校验。最难解决的问题是，当前是只读的接口难以保证后续的变更不会引入写操作。在当前阶段开放这一功能会引入额外的资损类风险敞口。,对此问题，每次回放前都进行人工校验可能可以解决，但是又引入了极大的效率问题。如何高效地保证在预发/灰度环境进行不mock流量回放不会产生资损风险，是一个值得探索的问题，需要研发跟测试的共同努力。,,方案1落地遇到的问题：,1.配置中心的数据不一致，噪音比较大,2.时效问题，有10S的时差，一些业务对时效要求比较高,,方案2不仅避免了上面方案1的问题，另外后续规划还可以根据覆盖率沉淀有效用例集，手工添加异常用例。,通过一段时间的运行，目前已经看到了一些流量录制回放在业务迭代中产生了价值，发现了一些隐藏bug。接入流量回放明显的变化是能够将测试从繁重的回归测试、用例梳理维护等重复性高的劳动中解放出来，将重心放在测试计划的设定、思考测试策略以及自我提升的实践上，比如做些辅助排错提效的coding能力提升和加强对业务的熟悉的宽度和深度上，从而最大程度的保障业务系统的质量和稳定性。,未来期望能在不断的实践中把得物的流量录制回放体系建设得越来越完善，解放更多的生产力，产出更多的价值。