分账测试不能只验证“一笔正常订单能成功”。上线前还要检查金额取整、接收方变化、重复通知、结果未知和退款等情况,确保每次分配都能被业务和财务解释。

先写预期结果,再运行测试

准备一份独立计算的样本表,记录订单实付金额、费用、分配基数、参与方、规则版本和预期分配金额。测试工具的结果不能直接当作自己的正确答案,否则计算逻辑出错时也难以发现。

选择最小金额、带小数金额、多接收方和规则边界等样本。取整后的余数归属应明确,核对总分配额与可分配金额的关系,不用人工改小数来掩盖规则问题。

验证接收方与规则变化

测试无效、停用或资料变更中的接收方,确认错误能够被识别和跟进。合作规则更新后,新订单使用新版本,历史订单仍能追溯旧版本,避免重新查询就得到另一套金额。

需要延后执行的业务,检查等待期间接收方或规则发生变化时采用什么依据。将该安排写成确定的业务规则,再验证系统结果。

覆盖重复与未知结果

重放同一支付通知和分账请求,检查是否产生重复分配。模拟请求已送达但返回丢失,确认系统先查询原结果,而不是立即生成新请求重做。

如果存在部分参与方成功、其他参与方失败的情况,逐项记录最终结果,不能仅用批次“失败”把已经发生的分配忽略。后续重试要能识别已完成部分。

退款后再做一次完整核对

分别测试分账前退款、分账后退款、部分退款与重复退款申请。核对退款金额、原分配记录、收益调整和剩余待处理事项,确保没有出现资金已处理而业务台账未更新的状态。

最后由技术、运营和财务用同一组订单独立核对,记录预期与实际差异。设计原则可查阅分账规则设计,账单字段可参考结算台账,不要把只跑通接口当作整套业务验收完成。