随着业务的增长，系统的高频率迭代，质量保障工作迫切需要引入更加科学高效的测试方法来助力业务高质量的交付。长城项目一期测试中，全渠道质量团队引入技术平台部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）对于返回结果结构复杂的，可以设置要对比的字段或者要过滤的字段，并沉淀一个任务模版，后期稍作改动就可以复用，提高创建任务的效率。
作者：京东零售 杨亚晓
来源：京东云开发者社区