随着业务的增长，系统的高频率迭代，质量保障工作迫切需要引入更加科学高效的测试方法来助力业务高质量的交付。长城项目一期测试中，全渠道质量团队引入技术平台部 R2 技术，极大的提升了项目交付的质量。因此，本文将重点介绍全渠道质量团队是如何利用 R2 来保障业务质量的。
全渠道长城项目是将全渠道现有交易能力下沉至交易中台，在技术系统层面实现了线上线下系统深度一体化，为零售的全渠道技术（人通、货通、场通、数据通）奠定了基石，贯穿从全渠道门店、商品、采购、促销、优惠券、通用下单、支付到售后的整个订单生命周期。项目涉及改动的应用多达 27+，接口 300+，业务范围极广。如果完全依赖传统的人工测试，那么在有限的时间内，不仅需要投入大量人力，同时也很难保证每次迭代回归覆盖了所有业务场景，最终也会影响项目交付的质量。
因此，为了更加全面的有效的覆盖线上的所有业务场景，全渠道质量团队调研了适用于长城项目改造前后数据对比的平台工具，最后在多种工具中选择了技术平台部的 R2 工具。R2 的全称是 Record 和 Replay，即录制和回放。测试同事与 R2 团队沟通试用后，发现它是一款非常适合于大型项目大量数据对比的辅助测试工具。另外，R2 的接入也非常简单，仅需要在应用中接入所要求的 pfinder 版本，R2 就可以找到测试的应用，并进行辅助测试。通过录制线上真实的流量，回放至线上或者测试环境中，不仅可以帮助测试完善业务测试用例，同时通过 mock 上游 jsf 接口、mysql 数据库、jimdb 缓存的方式，可以屏蔽外部对于待测代码的影响，只关注于系统内部的代码改动。
基于以上 R2 的定位和特点，R2 完全可以助力系统的技改类测试和回归测试。本文所介绍的长城项目属于技改类测试。
首先，对相关接口进行线上流量的录制。然后，异步回放到待测应用中。最后，根据接口在线上和待测应用的 diff 结果以及录制的相关请求，综合分析和评估系统是否达到了上线标准。以长城项目促销业务为例，介绍如下。
由于长城项目的促销业务对用例的实时性要求高，因此采用实时 DIFF 助力回归测试。实时 DIFF 和离线 DIFF 的主要区别是：离线是先录制好线上流量，暂时不回放，等需要回放时再回放。而实时是录制完成后立刻开始异步回放，从而减少时效性对测试结果的影响。实时 DIFF 对应的录制和回放任务需要注意以下三点：
任务设置：设置任务名称，选择回放环境，选择被测试应用。如图 2.1 左上角所示。
链路设置：首先需要选择要实时 DIFF 的接口，每个接口分别开启接口回放和选择要回放的接口别名。注意：该别名是后续录制完流量要进行接口再次请求的别名。 然后设置接口响应相关的规则。其中，接口影响对比规则有 3 种，常用的是第一种和第二种，第三种需要自己写对比脚本。请求对比规则的 equals method 指进行整个方法的对比，会对比方法内的所有字段。可视化配置指需要设置忽略的字段，如果响应结果里有 list 类型则需要设置 list 内字段的排序，以保证数据比对的准确性。图 2.1 中展示了部分示例。
图 2.1
应用设置：指选择录制的机器，后续会将这些机器上录制的流量异步回放到待测应用中。如图 2.1 中右下角所示，所选择的机器即为机器对应的 IP。
2.2 结果分析
实时 DIFF 任务回放完成后，点击结果可以看到本次任务所录制的请求，及产生 DIFF 的请求有多少。如果有 DIFF 的任务，则可以通过对比结果查看具体是哪个方法的请求结果不一样。如图 2.2 所示。
图 2.2
以促销的一个接口实时 DIFF 结果为例。图 2.3 和 2.4 分别是查询某个秒杀场次下对应 sku 的接口请求参数和响应结果，其中图 2.3 中接口入参主要包括门店 id，场次和租户，响应结果中每个 sku 都包含该 sku 对应的促销 id，促销价和限购信息，其中 boundNumber 表示活动限购数，surplusRepertory 表示活动库存。
图 2.3
图 2.4 左侧为当前的请求结果，右侧为历史录制的结果。可以发现左右两个结果中的同一个 sku 的同一个促销 surplusRepertory 对应的值不一样。对此，分析造成不同的原因如下：
（1）首先考虑到异步回放也会存在一定的时间差，所以实时查询的剩余库存可能不一致。但是历史版本里对应剩余库存是 0，并且历史版本是线上最先进行请求的，这个请求是早于左侧的请求的，如果是时间差的原因，则只会出现左侧剩余库存小于右侧的，所以 diff 的原因不是时间差导致的。
（2）从 DIFF 结果来看，问题为待测应用查询的剩余库存不同。通过分析发现，左侧每一个 sku 对应的剩余库存都是等于活动库存的，有订单产生剩余库存也没有做相应的变化。然后，通过相同场景的模拟定位发现待测应用对于设置了活动库存的场景，没有进行活动剩余库存动态变更，这样就会造成 sku 超卖的情况，影响业务运营。
图 2.4
全渠道从 2021.12 开始接入 R2，在 R2 团队的指导下，1 天内快速完成了 27 个核心应用和 320 个接口的接入，目前接入约 79+ 个应用。长城项目在 2021 年 12 月份上线以后到 2022 年 2 月正式开始切流期间， 使用 R2 进行实时 DIFF 和离线 DIFF，同时在后续的切流过程和切流完成后核心接口也采用实时 DIFF 测试，从而保证了系统的稳定性。
图 3.1
图 3.1 展示了全渠道应用接入 R2 的发展情况，横坐标表示时间，纵坐标表示每个月全渠道已经接入 R2 的应用数。2021 年 12 月底长城开始上线，为了更好的监控长城项目的质量，全渠道核心应用于该月陆续接入 R2，并利用 R2 进行线上流量录制，回放到待测应用中，提前监控待测应用，提前发现不一致的地方，并及早的进行修复和优化。因为前期大部分应用接入了 R2，所以后期新增的应用没有明显的变化。2022 年 2 月切量完成后，2022 年 3 月新增部分需求，然后继续对该部分需求接入 R2 进行测试。
图 3.2
图 3.2 展示了全渠道使用 R2 进行实时 DIFF 和离线 DIFF 的任务数，横坐标表示时间，纵坐标表示任务数。蓝色表示实时 DIFF 任务，橘色是离线 DIFF 任务。2021 年 12 月是各个应用接入 R2 的开始阶段，因此实时和离线 DIFF 任务想对都比较多。另外，开始时有的应用是一个接口建一个任务，但实际上其实一个应用可以将多个接口根据每个接口录制和回放的规则单独设置，即只需建一个任务即可。2022 年 2 月完成切量前，大部分是研发使用 R2 进行长城项目的数据对比。2022 年 3 月份测试使用 R2 进行日常项目和需求测试。其中，根据每个业务线的情况，对于实效性要求强的业务会优先选择实时 DIFF，对实效性不强的业务还可以选择离线 DIFF。从数据来看，使用实时 DIFF 进行需求测试居多。
以促销和商品线接入 R2 进行实时 DIFF 为例，图 3.3 展示了长城上线前通过 R2 发现的 bug 数量。其中，商品&促销共发现 140+ 问题，其中商品 B 端发现了 76 个问题，C 端发现了 37 个问题。另外，促销 B 端发现了 27 个问题，促销 C 端发现了 30 个问题。图中 B 端指的运营管理后台，C 端指七鲜前端。
图 3.3
另外，基于 R2 对比结果可以发现，商品涉及的属性相对较多，所以 R2 会将切流前后每一个不一致的字段对比出来。其中，商品 B 端对比不一致的字段主要有商品状态、图片丢失、商品描述、商品名称、商品品牌等。导致这些数据不一致的主要原因是：（1）数据同步问题；（2）对于某些字段 0 和 null 的不一致；（3）字段没有对齐。使用 R2 的优势是，可以提前将这些不一致的对比出来，进行修复和优化，降低了项目上线的风险。
图 3.3 中展示的促销 B 端对比发现的问题主要是促销活动切流后查不到，但是 C 端可以命中，主要原因是数据同步异常和产品功能没有对齐，因此需要进行系统的数据修复和开发与产品对齐功能，从而保障上线质量。C 端问题集中在用户实时请求后响应结果中只要有字段或者值不同，都将被对比出来。促销 C 端的问题也集中在了数据同步的问题。因此，R2 在验证数据同步逻辑时起到了非常重要的作用。
本文主要介绍了全渠道质量团队是如何利用 R2 来保障业务质量的。从为什么引入 R2 开始，一步步介绍引入 R2 到全渠道落地及收益情况。基于长城项目促销业务，详细介绍了全渠道接入 R2 的应用情况和 R2 的使用情况，以及 R2 助力发现的问题汇总。最后，基于长城项目使用 R2 测试经验，提出一下几点使用建议：
来保障业务质量的。
（1）使用 R2 进行任务设置时，可以将一个应用的相关接口建立为一个任务，尽量不要一个接口建一个任务。
（2）可以借助 R2 获取一些接口的入参，将接口相关的参数进行沉淀，完善自动化测试用例。
（3）对于有 DIFF 的接口响应，可以在研发修复之后，直接进行 DIFF 回放测试，不需要重新执行任务。另外，对实时性要求高的，可以借助 DeepTest 进行手动模拟 DIFF 的请求进行验证。实时性要求不高的就可以借助 R2 的离线 DIFF 回放功能。
（4）对于返回结果结构复杂的，可以设置要对比的字段或者要过滤的字段，并沉淀一个任务模版，后期稍作改动就可以复用，提高创建任务的效率。
作者：京东零售 杨亚晓
来源：京东云开发者社区
