科技Bestblogs·Hugo Teijiz··AI 生成
如何在遗留系统迁移中使用差分测试
本文指出遗留系统迁移中最危险的时刻是新实现看似完成时，因为通过自身测试不代表与被替换系统行为等价。作者提出差分测试作为第二证据来源：在相同输入下并行运行新旧系统并比较输出、错误和副作用。文章通过TypeScript与Vitest示例，详细演示了如何规范化输出、控制非确定性、比较业务语义而非原始JSON、将错误和副作用纳入契约，以及使用影子流量和AI辅助分类来积累切换信心。适合正在或即将进行大型系统重构、对测试策略有深究兴趣的中高级后端或全栈工程师阅读。原文 ↗原文 ↗
核心观点
- ▍遗留系统迁移中最危险的时刻是新实现看似完成时，因为通过自身测试套件并不能证明其行为与被替换的系统等价；差分测试提供了第二种证据来源。
- ▍差分测试的目标不是证明两种实现内部相同，而是获取它们在等价重要时刻的行为等价证据，并在切换前测量偏差。
- 01差分测试应聚焦于单一可观测边界（如Calculate Order Total或Approve Customer功能），而非整个应用程序，使用共享接口（如OrderProcessor）可以在不需要内部架构匹配的情况下比较行为。
- 02原始输出比较往往因时间戳、请求ID和数值格式等无关差异导致误报，规范化后仅保留id、total、status等有意义字段，使等价规则明确。
- 03错误和副作用是契约的一部分，必须比较：遗留实现抛出'Customer not found'与新实现返回null的差异是严重行为改变；迁移后可能正确返回状态却丢失审计记录、支付或事件。
- 04非确定性应通过注入共享Clock和IdGenerator来控制；当控制不切实际时，仅在它们不属于受保护行为时才规范化数值，数值域可能需要容差（如34.333333333与34.333333334并不一定是迁移错误）。
- 05AI可帮助分类差异（triage不匹配），但人类保留判断哪些差异是错误、有意改进、无害表示差异或未知行为的权力，AI不决定正确性。
反方 / 局限
- — 文章承认，当遗留系统本身行为存在缺陷（如已知bug）时，差分测试会强制新系统继承这些缺陷，因为目标是与旧系统行为等价，而非更正确。
- — 文章未深入讨论差分测试在遗留系统本身输出非确定性极高（如强依赖全局状态或外部时间）时的适用边界，以及持续维护差分测试套件本身的长期成本。
概念锚点
前置背景
平行视角
未来推演
延伸追问