企业官网建设流程全解析

游戏商城购买怎么测：支付幂等、到账、补单与重复请求

摘要：商城测试的重点不是“点击购买后获得商品”，而是外部支付、游戏订单和玩家资产在超时、重试、回调重复与跨端场景下仍能保持一致。

标签：游戏测试、支付测试、商城系统、幂等、玩家资产

一、面试官真正想考什么

商城购买横跨客户端、游戏服务端、支付渠道和资产服务。任意一方都可能成功、失败或超时，因此“客户端收到成功”不能代表整个交易完成，“没有收到响应”也不能代表扣款失败。

面试官希望听到订单状态机、唯一业务号、回调验签、重复通知、补单、退款和对账，而不只是正常购买与余额不足。

二、30 秒合格回答

我会先画订单状态机，区分下单、渠道支付、回调确认、发货、到账和关闭。基础场景覆盖商品、价格、限购、余额、到账与收据；异常重点覆盖支付中断、响应丢失、回调重复、客户端重试、跨端登录、发货失败、补单和退款。每个订单使用唯一订单号，核对渠道流水、游戏订单、发货流水和最终资产，保证重复消息不重复扣款也不重复发货。

三、订单状态机

Created -> Paying -> Paid -> Delivering -> Delivered | | | | Closed Cancelled Refund DeliveryFailed

实际项目的状态名称可能不同，但必须明确：哪个系统能推动状态；状态能否回退；超时由谁扫描；支付成功但发货失败如何恢复；关闭订单收到迟到回调时如何处理。

测试需要覆盖合法路径，也要主动构造非法跳转，例如未支付直接发货、已退款再次发货、已关闭订单被旧回调唤醒。

四、核心测试范围

1. 商品规则：上下架、渠道、地区、币种、折扣、首充、限购、库存和账号资格。
2. 订单创建：商品快照、价格签名、订单号唯一性、重复点击和并发下单。
3. 支付过程：成功、取消、失败、超时、切后台、杀进程、网络切换和渠道页面返回。
4. 支付回调：验签、金额与商品匹配、重复通知、乱序、迟到和伪造参数。
5. 发货到账：背包满、资产服务超时、部分失败、重复发货保护与到账通知。
6. 恢复流程：客户端主动查询、服务端补单、人工补发、退款和每日对账。

五、最有价值的故障注入点

故障注入的目标是制造“不确定状态”，然后验证系统如何查询最终结果，而不是依赖客户端猜测成功或失败。

六、连续追问与参考答案

追问 1：什么是支付幂等？

同一业务意图被重复提交或重复通知时，系统产生的业务效果与执行一次相同。例如渠道连续发送三次同一支付成功回调，订单可以记录多次通知，但只能完成一次发货。通常以渠道交易号、游戏订单号和业务类型建立唯一约束。

追问 2：支付成功但未到账怎么处理？

客户端不应直接重新购买，而应查询订单最终状态。服务端确认渠道支付后，检查发货流水；未发货则进入可靠补发，已发货则返回结果。测试要验证补单重复执行、服务重启和跨天后仍不会重复到账。

追问 3：客户端价格显示 6 元，支付页面变成 30 元，怎么防？

服务端不能信任客户端提交的价格。创建订单时根据商品 ID、渠道和活动资格生成权威商品快照，渠道回调后再次核对金额、币种与商品。测试应尝试篡改商品 ID、价格、折扣和旧活动参数。

追问 4：支付回调验签通过就安全吗？

不够。还要校验交易号是否已处理、商户与应用身份、金额币种、商品与账号、交易状态和时间有效性。合法签名的旧回调也可能被重放。

追问 5：怎样做支付对账？

按时间范围关联渠道交易、游戏订单、发货流水和退款记录，识别渠道成功但游戏未发货、游戏已发货但渠道无成功、金额不一致和退款后仍保留资产等差异。对账是兜底，不应代替在线幂等。

七、项目案例表达模板

某渠道偶发玩家已扣款但未到账。调查发现渠道回调处理成功后，资产服务超时，订单仍停留在支付成功状态；客户端重新登录只查询背包，没有触发订单恢复。我推动补充订单级发货状态和定时补偿任务，并用相同订单号重复执行补单。回归验证回调丢失、重复回调、资产超时和服务重启，确认每笔渠道交易最终最多发货一次，失败订单能够被监控发现。

八、面试官评分点

• 商品展示、余额、购买成功：基础；
• 能画订单状态机并覆盖中断：中级；
• 能说明幂等、回调与补单：中高级；
• 能关联渠道、订单、发货和资产流水：高级；
• 能讨论对账、退款和非法状态迁移：支付专项能力。

九、常见失分回答

• 使用真实个人支付反复测试，却没有沙箱与退款控制；
• 把客户端成功弹窗当成到账证明；
• 超时后一律重新下单，制造重复扣款风险；
• 只测支付回调一次，不测重复、乱序和迟到；
• 只确认最终钻石数量，无法对应具体订单流水。

结语

商城系统面对的是分布式交易的不确定性。高质量测试必须证明每笔钱、每个订单和每份资产都能对上，并且任何重试只推进状态，不重复制造业务效果。