洪渺 贾淑华 李雯 | 转转 QA
电商行业，整个购物流程，离不开跟钱打交道，系统内也是门门道道，例如打款，对账等等业务，一旦涉及到钱的业务出现问题，都有可能造成严重的线上事故。
这部分的测试验证存在很多痛点，验证的过程主要依靠人工校验，涉及多个系统查询比对，耗时较长；此外在跨部门协作项目中，常常由于彼此对专业术语理解不一致，导致沟通成本较高。
本文重点分享转转 QA 在涉及钱款方面的业务场景测试中是如何解决上述测试痛点的？我们为什么要设计一套涉及打款校验的工具？它在实际应用中效果如何？
在进行工具开发之前，我们首先针对目前线上回收的业务现状进行了梳理整合，其中涉及到打款的核心业务有三部分，这里以回收 1、回收 2、回收 3 代替。
回收 1 和回收 2 业务的打款类型主要有：A 类出款和 B 类的出款。其中，A 类的出款又包含各种加价和补贴，这些不同的出款类型都对应不同的账户。目前线上回收业务有 15+ 条业务线，每条业务线对应的账户配置信息都不相同。
回收 3 业务对应的打款类型更复杂一些，有售出、A 类出款、B 类出款三大类，都有不同的抽佣计算逻辑，而且还有不同回收类型相互转换的场景。测试过程中除了要覆盖到业务场景之外，账户的核对也是一项非常耗费精力的工作。
经过沟通发现门店侧对于打款相关的验证也有同样的痛点，所以我们将线上回收和线下门店涉及到的打款场景和校验内容进行初步调研，结果如下图：
从图中可以看出我们测试打款相关的需求时，重点关注的内容主要是账户、打款金额和计算公式等这些关键信息，针对这个结论我们明确了打款工具的需求设计。
打款校验工具核心功能主要包含以下三部分：
（1）展示回收单和订单基本信息
主要返回订单或回收单的状态、订单编号、业务线等关键信息，方便快速定位问题。
（2）关键信息的结果比对
返回所有对账记录的预期结果和实际结果，例如：打款类型、账户、金额等关键数据展示到页面上，及预计结果与实际结果的比对结果。一方面可以直观的看到各条记录的结果，另一方面也能看到每条记录的校验结果，可以快速定位校验不通过的数据。
（3）对账明细
每一条打款明细点击可以展开详细的计算过程，含文字的计算公式说明及各个字段的计算过程取值，不了解业务的人也可以通过说明快速上手了解计算过程，计算结果有差异的可以更快速的定位问题。
系统整体设计分为三层：前端 UI 层、展示层、业务层。
前端 UI 层：主要是前端页面的渲染。
展示层：主要是页面基本信息的获取。
业务层：对账打款逻辑实现，整合订单、回收单、售后服务的信息，作为基础信息来源，进行各个价格计算，然后进行对比校验，并返回比对的结果。
用户在前端页面选择业务线和场景后，输入订单 id 或者回收单 id，首先调用中台接口拿到订单的关键信息，作为基础数据进行预期结果计算，用支付结果作为实际运行结果，两者进行比对。如果一致则校验通过，反之则校验失败。
核心校验逻辑：根据不同的业务线来设定不同 Map 的 key 值，从中台获取到实际结果 list 和自己计算的预期结果 list 转换为两个 Map，遍历 Map 中的值并塞入新的 Map 中，再将需要对比的金额、收支、账号进行对比输出对比结果。一个 Map 遍历完之后再对另外一个 Map 进行遍历，返回结果为两个 Map 的合集。
打款工具上线后，如果服务之间是通过普通的接口调用方式进行通信的，无论是调用方还是服务方请求都只能发送到线上，我们也就只能校验线上的数据。在实际测试过程中，不仅需要校验线上环境的真实单据信息，还要校验测试环境的打款信息。所以，我们通过泛化调用的方式指定调用方和服务方的运行环境，从而在线上也能请求到测试环境的服务和数据。如图所示，用户先在前端选择服务方 ip，并发送 http 请求给 web 层，web 层获取到前端用户发送的请求后，调用 zzjava_test 服务的接口，zzjava_test 又调用 zzjava_scf 服务的接口。
具体是怎么实现的呢？首先，指定服务名、接口名、方法名、参数类型和参数值等；然后，指定 zzjava_test 的运行环境，并把服务方 ip 指定为 zzjava_test 的目的 ip；最后，通过对 zzjava_test 服务中的接口进行泛化调用，将请求发送给目的 ip 中的 zzjava_scf 服务。
在开发校验工具之前，校验方式主要是根据所测场景自行计算出抽佣和打款金额，再和交易工具箱中查询到的结果一一进行比对。
2、自动校验
有了校验工具之后，只需要输入订单或回收单就可以自动地计算出各项打款记录和比对结果，省去了我们在多个系统中查询和手动计算的过程，对于不了解业务抽佣规则的同学来说更是省去了了解的成本，大大提高了测试效率。
3、项目中的应用
打款工具的目的就是为了在日常的测试工作中帮助我们提高效率，现在距离上线已经一个多月，目前已经在以下几类项目中得到实践，详细使用情况如下：
（1）扩品类需求
品类扩充，抽佣打款信息需要回归，线上功能可以直接使用，提高了测试效率。
（2）计算逻辑变更需求
代码兼容开发后，并推给 RD 自测使用，简化了测试过程，提高了效率。
（3）打款类型多的需求
品类多、账户多、流程多打款类型多，利用打款工具做了基础校验，项目上线后补充完成所有校验。
打款工具的应用场景应该不仅仅只在我们单个业务中，可以应用于涉及订单&打款相关的其他业务。打款工具校验的内容也可以更加丰富，提高打款测试效率的方法也不止这一种，更希望借此可以抛砖引玉，发现更多好的方法来帮助我们日常工作提效。
