验证计划——编码前制定项目专属的证据路径。适用于功能开发、b…

# 支付模块策略模式重构验证计划

一、重构前置准备

• 梳理现状：画出现有支付流程时序图，明确支付宝、微信支付在创建订单、发起支付、回调验签、退款、对账、超时关单等环节的差异点
• 确定抽象边界：定义统一的 PaymentStrategy 接口（如：createPayRequest、handleCallback、refund、queryOrder），确认15个类的职责划分，避免策略类内部仍藏大量 if-else
• 建立基线：重构前在测试环境固化当前版本行为，作为对照基准

二、测试用例设计

• 核心场景覆盖：
• 两渠道各自的：下单→支付→回调→状态变更 正向链路
• 支付失败、回调重复（幂等）、验签失败、金额不一致、退款、部分退款
• 渠道间隔离：支付宝逻辑变更不影响微信支付（策略隔离性验证）
• 边界与异常：回调乱序、并发回调、网络超时重试、渠道返回码映射是否正确
• 新旧对照测试：同一输入分别跑旧实现与策略实现，比对生成的请求报文、签名、落库状态是否一致（影子对比）

三、分层验证手段

• 单元测试：每个策略类独立测试，mock 渠道 SDK/网关，覆盖率重点放在策略类与上下文路由类
• 集成测试：使用支付宝/微信沙箱环境跑全链路，验证真实报文格式与签名算法未被破坏
• 契约测试：固化回调报文样本，确保重构后解析逻辑兼容

四、上线与回归策略

• 灰度发布：按订单维度小流量切流（如先1%→10%→50%→全量），新旧实现可开关切换
• 数据核对：上线后比对订单状态与渠道侧账单的一致性（对账任务兜底）
• 监控告警：重点监控支付成功率、回调处理耗时、异常日志量，设置与基线对比的波动告警
• 回滚预案：保留旧代码路径开关，出现异常可秒级回切

五、验收标准

• 全部单测/集成测试通过，新旧对照无差异
• 灰度期间支付成功率与基线持平（无明显劣化）
• 对账无差错单，回调幂等无重复入账