重构旧系统前，先把实际业务行为变成可重复证据

不同规则采用什么验证

按业务损失选规则，先做能保护改动的测试

旧系统全面补测试成本很高，应从本期要改的规则及影响最大的行为开始。金额、库存、权限和状态变化通常比静态页面更值得优先记录。

从缺陷记录、客服处理和业务演示寻找高风险规则。例如取消操作是否恢复资源、历史客户是否适用特殊价格、审批驳回后能否再次提交。这些问题由真实业务决定，不能只根据代码行数选取。为每条规则标注负责人、关联流程及改变之后可能影响的结果，后续测试范围便有依据。

• 列出本期改动涉及的计算、状态与副作用。
• 优先覆盖高价值、频繁变化和已有事故的规则。
• 注明暂未覆盖的流程，避免把部分保护视为全面验证。

样例不仅保留成功路径，还要体现历史例外

好的样例需要可重复且来源可解释。真实数据脱敏后可作为输入，但不能默认一个正常订单代表所有业务情况。

围绕金额边界、空字段、非法状态、重复提交、历史版本和人工补单设计样例集合。每份样例记录输入、旧结果及业务备注，敏感信息脱敏后仍保持关系和格式有效。业务专家确认覆盖分类后，团队再逐步补充；缺乏某种历史场景的数据时，可以明确构造场景，但不能称为真实客户案例。

• 为正常、边界、异常和重复处理分别准备样例。
• 保存样例来源、脱敏方式和期望结果的确认记录。
• 对无法重现的规则保留待查事项及业务解释。

隔离时间、随机值和外部系统，让结果稳定

同一输入每次得到不同结果时，测试难以发现真正变化。先识别时间、随机数、网络调用和环境配置等不稳定来源。

通过合适的调用边界把真实依赖替换为固定响应，使价格、日期和状态计算可以单独运行。引入隔离点本身也可能改变旧逻辑，因此应从小范围着手并核对行为。对于数据库查询，使用明确初始化数据；对于通知或支付，测试验证调用内容和次数，隔离真实发送。不要为了测试方便修改生产中的规则默认值。

测试替身的响应应包括缺字段、非预期状态和失败，不只有理想结果。外部接口真实语义仍需单独联调；替身返回值由团队自己定义，不能用它来证明供应方一定如此响应。保留替身对应协议与样例的来源。

• 固定时钟、时区和随机输入，记录环境前提。
• 给外部查询准备正常、超时和错误响应。
• 将有副作用的调用换为受控替身，并检查执行次数。

快照用于复杂输出，关键字段要有明确断言

大结构结果可以用快照发现差异，但核心金额、授权结果和状态转换需要直接可读的期望条件，便于评审者判断含义。

快照只保留与业务有关的内容。请求编号、生成时间等允许变化的字段可以规范化，但忽略规则必须被审查，防止把重要差异一起抹掉。测试失败时查看字段差异及关联场景，再决定修代码还是更新期望；快照更新应与需求确认放在同一评审记录中，不能让工具自动接受新版全部输出。

• 对金额、状态、权限和副作用单独写明期望。
• 规范化仅针对经确认的非业务字段。
• 更新快照前保留差异说明和业务确认。

按采集、审核、重构和差异处理推进

先在旧版本运行样例形成基线，再由业务确认，之后实施结构改动。新旧差异是待解释事项，不应自动理解为新版本更好或旧版一定正确。

每次改动范围尽量能与一组规则对应。差异出现时先确认环境与依赖是否一致，再定位逻辑变化。必须保持的行为恢复一致；获批修正的缺陷建立新期望并保留旧样例；尚不清楚的行为暂不随结构改造发布。最后补充新发现的回归样例，让后续团队知道为什么存在该测试。

差异记录要能关联到具体规则、输入与输出，不只写“回归通过”。多人处理时指定同一规则的确认主责，避免一组人按旧口径、另一组人按新口径接受结果。确认过程可随测试版本一起保存，便于以后解释。

• 第一步：运行旧版本并审核样例及结果。
• 第二步：在相同条件下运行新实现并分类差异。
• 第三步：完成差异确认后更新规则记录与验收证据。

行为一致不代表性能、安全和业务正确都已通过

特征测试适合保护既有行为，无法独立回答旧规则是否合理，也不会天然覆盖并发、响应时间和全部授权风险。

如果旧系统已有错误，不应为了一致性永久保留；应将纠正行为作为独立需求处理。涉及并发竞争和运行容量的模块，还需专门验证；第三方系统无法模拟的特性，需要真实测试环境联调。本文面向准备改变内部实现的已有系统，新功能从零开发可以直接按业务需求建立期望，不必先制造旧行为基线。

• 在测试报告说明已覆盖规则和未覆盖领域。
• 对已知缺陷明确保留或修正的审批结论。
• 将容量、授权与外部协议验证作为相应专项检查。

需求讨论中的问题