1.背景介绍1.1Dewupandora介绍什么是行车记录和回放？流量记录回放是指应用端通过挂载和注入记录器探针自动注册到服务器，形成记录流量回流，记录所有响应内容（如数据库、分布式缓存、对外服务响应等）所有外部调用都依赖于。平台向播放器下发流量播放指令。其核心价值是通过直接记录真实的生产数据，将真实的生产数据转化为可复用、可执行的流量，并在测试环境中快速进行播放对比接口返回值和中间环节验证。得物版的路况录放平台pandora在官方开源版上做了很大的扩展，支持了很多官方版不支持的子调用和入口调用。此外，平台还对得物的中间件进行了大量的适配工作，避免了很多播放失败的噪音。1.2市场工具比较目前市面上已知的流量录放平台大多是在Jvm-Sandbox-Repeater的基础上重新开发改造而成，而且大多只支持Java语言。核心原理也是通过记录真实的在线流量，然后在测试环境回放，来验证代码逻辑的正确性。2.实践落地2.1协作模式在具体实施层面，目前业务测试、平台研发、业务研发的模式是三方协作模式。任务划分如下图所示。2.2各阶段应用流量回放的理想实现：测试阶段卡点：聚焦核心场景，低成本验证每次测试对核心场景的影响；测试回归阶段的卡点：全场景，注重追求场景全面覆盖，验证新功能对历史功能的影响；预发布环境回归：目前预发布和生产同库，未来将推动基于预发布&生产环境实现流量回放，尽可能接近录制环境和回放环境.模拟差异，减少播放阶段噪声的影响；在德屋整体QA体系中，流量回放重在短期回归底线。2.3实际落地流量回放推出后，逐步从探索试用阶段过渡到该领域应用场景拓展阶段。经过一段时间的订单流回放模式探索，我们找到了一套适合在这个领域迭代的模式。第1部分。试接入团队在开展流量回放专项工作后，通过调研，选择了40%的业务优先接入。阶段目标是完成30%P0应用top10界面100%场景覆盖，形成迭代落地质量卡点，完成适用性和效率提升分析；增加订单域流量回放人员、土地质量卡点、覆盖5%回归场景；实施方案调研应用特点，尝试接入流量记录和回放；梳理服务的P0接口和用例，并配置相应的接口和用例标签；用例自动沉淀到用例集中后，在回归阶段尝试进行流量回放。完成30%的收益成果并形成应用质量，15%的用例回流到现场，验证方案的可行性和易用性，探索研发和测试协同机制。第2部分。探索与升级上一阶段花了大量时间整理接口配置标签。用例沉淀缓慢，收益与投入不成正比。因此调整策略，通过智能分析提高效率，快速积累用例，扩大用例数量和覆盖面。界面体积。45%的业务应用已经打通，全部实现强卡点。随着平台端的优化，解决了大部分组件适配和使用问题，迭代应用流程和应用指标分析机制也基本顺利运行。阶段目标应用：接入的应用交给对应的服务负责人，负责对应服务的接口维护、运营、沉淀、故障分析；用例：尝试探索新的用例沉淀方式，进一步扩大用例数量，增加接口覆盖量；故障排查：根据服务的用例数量和接入时间，提升测试排查能力。2期结束后，测试调试达到50-50；应用热点流量方案后，升级之路开始了。连接的应用数量也超过了原定目标的50%，全部实现了强卡积分。应用智能分析策略提效效果明显，累计用例数量成倍增长，P0接口接入应用覆盖率达到100%。测试调试错误的能力有所提升，每次流量回放迭代发现的bug数量也在增加。新方案的可实施性和普适性基本符合预期。Part3、专项提速在积累用例数量增加很多，用例积累速度明显提升的前提下，流量回放在迭代应用中发现了更多的缺陷，计划将应用扩展到连接和覆盖接口的范围。阶段目标应用接入：新增应用接入40%，接入应用总占比90%；排错：提升测试排错能力，新版本排错由平台研发转为业务研发，测试开发排错占比55%；用例：加快用例积累，扩大覆盖面，至少65%的应用已完成全用例积累；卡点：应用100%接入，提高排障速度，部分应用被生产卡点转化为预发卡点；全局接入应用接口维度覆盖率超过98%，接口配置完备度超过98%，全用例路径覆盖率超过60%。收益随着应用的接入，积累的用例也在不断扩大，发现的问题也在不断增加。同时，还加入了覆盖率这个指标，衡量流量播放用例覆盖的代码占总代码行的比例。以覆盖为重点，平台抽样策略也进行了调整，删除所有历史沉淀用例，只沉淀新政策实施后记录的流量。流量播放接入了90%的应用，扩大了应用接入和案例沉淀，实现了超出预期的目标。沉淀申请数量是原计划的3倍。该阶段累计发现的BUG数量占全球流量播放发现BUG数量的45%。落地策略的有效性得到充分验证；从stage3现场发现的缺陷统计来看，regressionbug占38%，线上自有/隐藏问题占8%，迭代过程中的代码问题（日志报错）和代码规范问题占46个%，性能问题占8%；界面配置完善度100%；界面尺寸覆盖率为96.49%；全用例路径覆盖率为79.32%，全代码平均覆盖率为39.8%；3.总结分析3.1问题分类分析3.1.1累计发现缺陷分类：3.1.2累计发现缺陷源分类：3.1.3典型案例：播放时系统异常，排查后定位为NPE问题，如：responsereturns业务字段diff比较不一致。例如，通过缺陷分类和缺陷来源不难看出：在流量回放中发现的拦截问题中，近一半会导致生产业务错误，包括涉及资金损失的金额不正确等问题和字段值不正确等缺陷通过和错误的枚举类型；作为产品发布前最后阶段的一道防线，充分体现了流量录放作为测试回归能力补充手段的重要性。大约45%的问题是人工测试时很难发现隐藏的深层次代码级问题，比如NPE报错、输入输出参数字段未序列化等，如果这些问题只是通过前端-endtestorinterfacetest不读日志对比所有字段必然会给生产环境带来问题，最终影响生产环境的稳定性。大约6%的性能问题，比如子调用重复影响界面RT，如果在产品发布前没有发现和解决，势必会给用户体验带来一定的挑战。从缺陷来源来看，发现的缺陷来源仍然集中在项目迭代需求和技术优化上，充分验证了流量播放整体提速的有效性，补充了测试覆盖能力。通过故障用例故障排查和分析经验的积累和分享，参与专项的测试团队整体技术水平通过专项流量回放项目提速得到显着提升，技术氛围得到改善得到显着改善。日读能力，代码diff能力，深入挖掘缺陷。3.2适用性分析适用场景适用于返回数据量大，业务流量也大，阅读业务占比大的场景，比如ToC类产品。不适用场景挂载沙箱后开始录制会导致RT瞬间飙升，影响生产服务的稳定性。流量播放平台目前不支持异步场景。需要验证数据库的落地和节点流的链路测试，需要自动化。先投资能快速形成卡住盈利的应用（相对较少的代码迭代改动，更好的层次结构，较少的异步，较少的写操作），并做出可见的使用效果。流量回放能否完全替代人工回归和自动化？到目前为止，答案是否定的。首先，从沙盒挂载到接口配置再到流量记录，实现高用例覆盖需要很长时间，一些极端场景仍然需要人工设计；其次，流量记录回放是后端回归口袋，更侧重于历史逻辑的回归验证。1、接口覆盖不全。需要新接口迭代，没有配置关联录音，不在流量回放的录音范围内。2.全代码覆盖率不高。界面已经配置覆盖，但是由于场景采样率小等原因，界面的分支场景没有被记录，所以没有被覆盖。3.故障排除能力高低的影响。接口被覆盖。故障排除时，由于增加了子调用，故障用例很容易被定义为故障排除时的代码更改。4.平台问题。diff比较异常，说明播放成功。异步线程的播放是一个需要攻克的难点。3.3挑战3.3.1排错效率记录流量和回放流量后，发现很多回放结果无法比对。经过对失败原因的排查分析，有些失败是代码bug引起的，但更多的失败不一定是代码bug。常见的噪音主要有：代码修改，新增或删除子调用，导致mock失败平台不支持时间戳相关的子调用导致失败。时间戳相关的子调用不一致。子调用中使用的随机参数是相关的，导致mock无法匹配repeater代码本身。错误失败的原因有很多，真正有效的失败是很少的。因此，每次播放失败的排查成本都非常高。对业务的推进造成了巨大的阻碍。原中继器报告的信息不够丰富。在很多情况下，您需要查看日志来排除故障。目前还没有公开成熟的参考方案。平台也进行了一些初步探索，对回放失败的场景进行自动分类，上报更丰富的数据信息为故障排查提供指导，帮助侦查人员重点定位问题。同时，该平台还会自动识别一些噪音，并在播放过程中自动过滤和降低噪音。3.3.2异步线程录制回放问题在主线程返回不等待子线程执行完毕的异步场景下，目前的策略是用户可以配置多次调用异步子线程忽略，以及只关注主线程的执行。这种方式虽然可以提高这种异步线程场景的播放成功率，但是失去了异步子线程业务逻辑的回归能力。上述案例中，应用打开了故障排除和效率提升的优先级开关，忽略了异步子线程的调用，导致diff比较异常，提示播放成功。该接口生产发布时报异常。String类型长度过长被trycatch捕获，埋点丢失。四、展望&未来规划流量录放作为测试领域的新生事物，在诞生之初就受到了众多测试同仁的关注，市场上也有一些公司对此进行了一些实践。我们对行车记录和回放的实践还处于初级阶段，一些问题的解决方案也在探索中。预发布只读接口的非模拟播放是联通生产环境中的数据库和下游应用。所以预发布的无mock播放，尤其是只读界面的无mock播放可以在上线前完成。在最后阶段，执行自下而上的回归检查。最难解决的问题是目前的只读接口不能保证后续的改动不会引入写操作。现阶段开放该功能将引入额外的资金损失风险敞口。对于这个问题，每次回放前人工校验或许可以解决，但是引入了一个巨大的效率问题。如何高效保证预发布/灰度环境下无mock流量回放不会造成资金流失风险，是一个值得探讨的问题，需要研发和测试的共同努力。方案一-单机播放（准实时播放）方案一实现中遇到的问题：1.配置中心数据不一致，噪音比较大2.时效性问题，有10S的时间差，还有一些业务对时效要求比较高。方案2-DoublePlayback（实时回放）方案2不仅避免了上述方案1的问题，而且可以在后续规划中根据覆盖率积累有效用例集，手动添加异常用例。经过一段时间的运营，我们看到一些流量记录和回放在业务迭代中产生了价值，也发现了一些隐藏的bug。访问流量回放的明显变化在于，可以将测试从繁重的回归测试、用例整理和维护等高重复性工作中解放出来，专注于制定测试计划、思考测试策略、践行自我提升。比如做一些辅助调试和效率提升，提高编码能力，加强熟悉业务的广度和深度，最大程度保证业务系统的质量和稳定性。未来，期待在不断的实践中，将德屋的行车录放系统建设得越来越完善，解放更多的生产力，产生更多的价值。文/苏三
