11、测试用例的噪音与修复策略

测试用例的噪音与修复策略

1. 测试通过也可能存在问题

在软件开发中，测试套件的表现至关重要。有时候，团队成员会因为所有测试都通过而感觉良好，但实际上，他们可能只是改变了测试中的“噪音”，而非真正将其消除。现在，成功通过的测试也可能成为噪音，掩盖了严重的问题。

1.1 测试套件的目标

将测试套件从充满噪音的状态转变为能提供有效信号的状态是正确的做法。让测试套件从频繁失败变为全部通过是一个良好的开端，因为这有助于克服团队对测试失败的麻木感。然而，仅仅让测试全部通过是不够的，即使测试都通过了，测试套件仍然可能存在噪音，隐藏着严重的问题。

1.2 处理噪音测试套件的建议

当处理有噪音的测试套件时，可以采取以下步骤：
1. 尽快让测试套件全部通过。
2. 真正修复每一个失败的测试，仅仅忽略它们只会增加更多的噪音。

例如，有团队在测试时发现 500 错误的百分比超过了服务水平目标（SLO）阈值，这让他们感到困惑，因为他们以为所有测试都已经修复好了。但实际上，有些测试只是“临时处理”，比如对于一些不稳定的测试（flake），他们选择重试；对于一些无法解决的测试，则暂时禁用。这表明他们对“修复测试”的理解可能存在偏差。

2. 修复测试失败的问题

判断是否真正修复了一个测试并非易事，这涉及到如何区分测试中的信号和噪音。

2.1 测试失败的原因

每次测试失败，通常意味着以下两种情况中的一种或两种同时发生：
1. 测试编写错误：系统的实际行为与测试预期的行为不符，即测试编写时对系统的期望有误。
2. 系统存