题目重点：按扫码到入账状态机设计功能、并发、故障与对账测试，不只罗列页面点击。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练商户展示订单二维码，用户扫码确认支付，系统异步通知商户；具体微信产品协议未给，规则为测试假设。
- 金额、币种、订单归属和到期时间以服务端可信数据为准；不在真实支付环境执行案例。
解题路线
- 先画状态：待支付→处理中→成功或失败/关闭；成功是否可退款及退款状态另定义。订单、支付交易和账本是不同对象，不能用页面提示当最终资金真相。
- 正常链路覆盖扫码识别、订单详情、金额币种、付款身份、确认、通知与订单展示；验证服务端金额不可由二维码客户端参数篡改，支付人/商户权限正确。
- 边界覆盖损坏/过期/已关闭码、网络弱/离线、重复扫码、重复点击、余额或渠道失败、用户取消、应用退出；每步预期不仅是错误文案，还包括订单和账本不变量。
- 并发与重试最重要：同订单两设备确认、提交成功响应丢失、重复/乱序/延迟通知；以幂等交易号确保不重复扣款或入账，状态不能从成功退回处理中。
- 安全与集成覆盖伪造回调、签名失败、重放、越权查订单、敏感日志；使用受控mock/sandbox验证，不需要把真实支付凭证嵌进自动化。
- 故障注入支付完成但商户落库失败、通知持续失败、退款响应不确定，观察重试和对账能否收敛。发布门槛用核心金额/状态不变量与对账差异，而非只看用例数量。
- 自动化分层：单测状态机，契约测渠道请求/回调，集成测事务与幂等，少量端到端验证扫码流程；压测分离真实外部限额，监控成功率、重复交易和长时间pending。
手动走一遍
用户点支付后超时再点，渠道实际上已成功：第二次不能再扣同订单，页面应查已有交易并收敛成功。回调重复两次只产生一次入账，错误签名不能改状态；通知失败需能通过对账修复。
规模与取舍
用例组合按状态、输入、故障点与并发交叉可能爆炸，先覆盖高风险不变量与成对组合；压测量化目标QPS和pending时长，渠道延迟决定端到端尾延迟。
易错点与追问
容易失分的边界
- 页面成功就当资金到账。
- 只测重复点击不测响应丢失和重复回调。
- 使用真实资金做可重复自动化。
继续深挖
- 退款和支付回调乱序怎样处理？
- 如何做渠道sandbox契约？
- 对账差异怎样告警和修复？
