在旧系统迁移过程中如何使用差异测试方法

it.each(cases)(
  "matches legacy behavior",
  async (input) => {
    const legacy =
      await legacyProcessor.process(
        structuredClone(input)
      );

    const migrated =
      await newProcessor.process(
        structuredClone(input)
      );

    expect(
      normalizeOrder(migrated)
    ).toEqual(
      normalizeOrder(legacy)
    );
  }
);

真实的例子有助于揭示那些合成测试数据常常会忽略的假设。但处理生产数据时必须格外小心。

需要删除或对以下信息进行匿名化处理：

个人数据
凭证信息
令牌
财务识别信息
机密商业数据

我们的目标是保留那些有用的行为差异，而不是将敏感的生产信息复制到测试用例中。

区分每一个细微差异

出现差异性故障，并不意味着新的实现方式就是错误的。

假设你发现了200处不一致之处，那么就需要对这些差异进行分类。

我喜欢的分类方式包括：

迁移缺陷
故意保留的旧有代码缺陷
有意为之的行为变更
表现形式上的差异
非确定性差异
测试/对比用例中的缺陷
未知原因

例如：

输入数据：
小计 = 5000

旧版本代码：
折扣 = 0

新版本代码：
折扣 = 500

分类结果：
未知原因

经过调查后发现，新版本中的代码将条件修改为：

金额 > 5000

改为：

金额 >= 5000

现在你需要做出一个决定：
这是由于：
偶然的代码迁移错误

还是：
如何利用人工智能来分析差异性故障
大规模的代码迁移可能会产生成百上千处差异，而人工智能可以帮助我们对这些差异进行筛选和分类。
假设你有如下数据：
{
  "输入数据": {
    "小计": 5000,
    "国家": "阿根廷"
  },
  "旧版本代码": {
    "总金额": 4500
  },
  "新版本代码": {
    "总金额": 4000
  }
}

你可以向人工智能模型提供以下信息：

输入数据
旧版本和新版本的输出结果
相关的旧版本代码
相关的新版本代码
用于比较的规则

然后让模型进行分析，询问它：
分析这个差异性故障。
找出最有可能导致这种不一致的行为差异。
对比旧版本和新版本的实现方式。
返回以下结果：
1. 观察到的差异；
2>相关的旧版本代码分支；
3>相关的新版本代码分支；
4>可能的原因；
5>支持这一原因的证据；
6>可以用来验证这一结论的额外测试用例。
请注意，不要自行判断哪种行为是正确的，也暂时不要修改任何代码。
最后这条指令非常重要。人工智能在帮助我们找出两种实现方式之间差异的原因方面确实非常有用，但它不应该默默地将这种分析结果转化为商业决策。
不要让人工智能来决定哪种行为是正确的
假设旧系统是这样运作的：
客户年龄为65岁 → 不享受折扣
客户年龄为66岁 → 可享受折扣
而新系统的运作方式则是：
客户年龄为65岁 → 可享受折扣
客户年龄为66岁 → 仍可享受折扣
人工智能看到这样的代码后，可能会认为：

新的实现方式看起来更合理，因为通常老年人折扣政策是从65岁开始的。

但这种看法其实并不重要。
业务规则可能是这样的：
年龄 > 65岁
制定这样的规则肯定是有原因的；或者，旧系统的这种行为可能隐藏着某种错误。
你需要确凿的证据来支持你的判断。
你可以利用以下这些信息来进行分析：
需求文档
现有的测试用例
系统在生产环境中的实际表现
业务负责人提供的意见
历史故障记录
代码提交历史
相关合同文件
人工智能可以帮助你收集并整理这些证据，但它不应该自行创造规则或假设。
差异测试非常有用，因为它能让你在错误地将某些差异带入生产环境之前，就发现它们存在的真实性。
如何安全地使用影子流量测试
当离线差异测试的结果看起来可靠时，你有时可以将系统的实际运行情况与真实流量进行对比。这种测试方法通常被称为“影子测试”或“流量镜像测试”。
真实请求      │
│              └────────────→ 旧系统
│                          │
│                          ↓
│             真实响应     │
│
└────────────→ 新系统       │
                       │
                       ↓
                  影子测试结果
在这种情况下，用户仍然会收到旧系统的响应，而新系统则会处理这个请求的副本。
旧系统的输出    vs.
影子测试的输出
通过这种对比，你可以发现那些原本被测试用例遗漏的问题。
意外的空值组合
罕见的客户状态
不常见的国际数据格式
过时的记录
超大数值
异常的数据序列模式
不过，进行影子测试时需要特别小心设计，尤其是当某些操作会产生副作用时。
如何防止影子测试产生重复的副作用
假设我们正在进行影子测试：
POST /payments
如果两个系统都会真正执行这笔支付操作，那就会带来严重的后果。
发送邮件
创建货运订单
扣款
修改库存信息
发布事件
写入外部数据库记录
除非这些操作被妥善隔离，否则影子测试系统不应该产生任何破坏性效果或可被外部观察到的结果。
class ShadowPaymentGateway
  implements PaymentGateway {
  calls: PaymentRequest[] = [];

  async charge(
    request: PaymentRequest
  ) {
    this.calls.push(request);

    return {
      paymentId: "shadow",
    };
  }
}
新的实现仍然会尝试执行以下操作：
支付相关操作
但 instead of 使用真实的银行卡进行收费，这个“影子适配器”只会记录下本应被发送的数据：
对比它们的行为差异
并不意味着：
通过测量差异来判断是否准备就绪，而不是等待一切完美无缺
当进行成千上万的对比测试时，一个简单的“通过/失败”结果：
对比次数：100,000次
结果一致的情况：99,620次
存在差异的情况：380次
差异占比：0.38%
然后对这些差异进行分类：
最终剩余且原因不明的差异仅为5次，
占比为0.005%
这样，讨论就变得具体多了。
与其说：“我认为迁移工作已经准备就绪了”，

不如这样说：

我们对比了100,000次具有代表性的测试结果，发现还有5处行为差异尚未得到解决。

这些差异是否可以接受，取决于它们的具体性质。例如，一次错误的财务交易可能比100次无害的格式差异更为严重。
因此，评估时不要只看比例，还要考虑问题的严重性。
如何判断是否已经准备好进行切换
差异测试并不能给出一个通用的标准，但它可以为你提供有力的证据。
在切换之前，我需要回答以下问题：
不仅是要检查正常运行情况下的结果，
这些差异是否都得到了分类？
关键性的差异是否都已经得到解决？
那些人为故意造成的差异是否都已经被记录下来？
如果新的行为确实是人为故意设计的，那么这一点就必须明确记录在案。
副作用是否相同？
不仅仅是响应结果而已。
类似生产环境的测试案例是否已经过测试？
仅使用合成测试环境可能还不够。
迁移操作可以撤销吗？
差异化的评估方法虽然能降低风险，但并不能完全消除进行撤销操作的必要性。
如果你能够回答这些问题，那么你就离实现可控的切换流程更近了一步。
实用的差异化测试工作流程
以下是我会采用的工作流程。
1. 选择一项功能进行测试
例如：
处理顺序：
计算发票金额
审批客户请求
不要一次性比较整个平台的所有功能。
2. 明确可观察的测试结果指标
列出需要关注的关键要素：
返回值
状态
错误信息
数据库状态
发生的事件
外部调用情况
3>创建旧版本和新版本的适配器
通过相同的接口来暴露这两种实现方式。
4>制定标准化规则

确定如何处理以下情况：
5>对比已知的测试案例

首先从以下这些案例开始测试：
6>记录副作用
必要时可以使用录制功能或模拟适配器来收集数据。
7>自动化测试流程
对于每一处不匹配的情况，都要生成结构化的输出结果。
例如：
{
  "caseId": "case-493",
  "equivalent": false,
  "legacy": {},
  "migrated": {},
  "difference": {}
}
8>对差异进行分类

可以使用以下分类标准：
9>添加具有代表性的真实世界案例

可以使用匿名化处理过的或经过安全重建的生产环境数据来进行测试。
10>在适当的情况下模拟真实业务流量
只有在对副作用和隐私风险进行了有效控制之后，才能进行这种模拟测试。
11>衡量差异程度
需要跟踪以下两个方面：
12>在切换之前解决所有未知问题
最危险的情况往往并不是：

系统确实存在差异，但没有人知道原因何在
差分测试无法证明什么
差分测试有一个重要的局限性：它只是将新系统与旧系统进行比较。
这意味着旧系统成为了行为参考标准，但这个旧系统本身可能就已经存在错误了。
旧系统的输出结果是错误的
新系统的输出结果也是相同的错误结果
虽然差分测试通过了，但这并不意味着新系统的行为就是正确的。
正因如此，差分测试应该与其他测试方法相结合使用：
差分测试将迁移风险转化为可验证的证据
我之所以喜欢这种技术，还有另一个原因：如果没有差分测试，关于系统迁移的讨论就很容易变得主观化。
另一个人则说：“我还不太信任它。”
这两个人的观点都可能有道理，但它们的论据都不容易被量化或验证。
差分测试能够改变这种讨论方式。
结论
仅仅因为新系统的实现通过了自身的测试，并不意味着迁移工作就已经完成。
真正重要的是：新系统是否保留了被替换旧系统中那些重要的行为特征。
差分测试为回答这个问题提供了另一种方法。
只有那些真正无关紧要的差异才需要被忽略，
其他所有问题都应当被仔细研究。
了解现状 → 分析系统特性 → 优化代码结构 → 进行系统迁移 → 对结果进行对比 → 最后完成切换
人工智能也可以帮助加速这一过程。
它能够帮助构建比较工具、分析故障、将相似的差异归类到一起、检查代码执行路径，并建议添加额外的测试用例。
但是，它不应该去判定哪种实现方式是正确的。
这样的判断仍然需要证据、领域知识以及工程判断力。
差异测试的目的并不是要完全消除不确定性。
它的作用是在你将生产环境中的流量切换到新系统之前，让这些不确定性变得显而易见。
因为在系统迁移的过程中，如果能够及时发现新系统的行为与旧系统不同，那会非常有用；
而如果在旧系统已经被停用之后才发现问题，那么所造成的损失将会大得多。