重复测试的原因

Reasons to Repeat Tests - Satisfice, Inc.

测试发现bug就像在雷区排雷。如果你只是在雷区中沿着同一条路走来走去，那么你不会发现很多地雷。实际上，这是一种很好的避雷方法。现代软件产品所代表的空间比雷区复杂得多，所以假设一些小数量的“路径”，比如说，一百条或一千条，当无休止地重复时，会发现每一个重要的bug，这甚至是一个更大的问题。尽管一组测试人员可以在几周内进行很多测试，但与该领域中产品可能发生的所有事情相比，这些测试仍然不是很多。

雷区类比实际上是另一种说法，即测试是一个抽样过程，我们可能想要一个更大的样本，具有良好的多样性，而不是一个微小的、特殊的样本反复重复。因此，雷区启发式是进行不同的测试，而不是重复相同的测试。

但是我的意思是什么呢？很容易看到，没有测试可以重复，就像你不能精确地追踪你的脚步到微米的水平一样。你可以接近，但你总会偏离一点点。重复测试是否意味着第二次运行测试时，你必须确保阳光以相同的角度照在你的鼠标垫上？你只是不能确定哪些因素会影响测试。然而，当你测试时，你有一个特定的目标和系统的特定理论。你可能非常能够在 A)你知道的、B)你关心的、C)重复成本不太高的各个方面重复这个目标和理论。

因此，通过“重复测试”，我的意思是“重复测试的某个重要的部分”。我认为这才是人们真正在谈论的重复。重复某些东西是可能的。重复所有东西则不是。然而，雷区启发式建议，即使根据这个定义，你也不应该重复测试。

如果你不同意这个观点，或者你同意这个观点，请继续阅读。因为......

这个分析太过简单化了。尽管测试的多样性很重要，尽管反对重复测试的观点通常很有用，但我知道有十个例外。有十个具体的理由说明，在某些特定的情况下，重复测试并不是不合理的。重复一些测试甚至可能很重要。

你可能会理性地重复测试......

回归：如果被测试的产品发生了代码变动，那么一个新的问题或重复的老问题很有可能被一个特定的现有测试捕获。这包括重新运行测试来验证一个修复，或在你试图发现一个特定的问题或行为时在连续的构建中重复测试。这也包括在运行在新的 O/S 上的相同软件上运行一个旧的测试。换句话说，一个旧测试可以通过对被测技术的变化进行补充。请注意，回归论点并不一定意味着运行相同的旧测试，只是这样做不是不合理的。

间歇性：如果你怀疑一个缺陷的发现不一定是通过一次正确的测试运行，也许是因为你在测试中无法控制所涉及的重要变量。执行一个与你之前执行的测试完全相同的测试，可能会导致发现一个一直存在但直到未控制的变量以某种方式排列才被揭示的缺陷。这与赌徒在老虎机上输了第一次后再次玩的原因是一样的。

重试：如果你不确定测试在其他时间是否正确运行，或者第一次收集的信息是否被忽略了，这就是为什么让几个测试人员遵循相同的指令并检查他们是否都得到了相同的结果是一个好主意，这也是为什么开发人员可能想要重现报告的缺陷的一个常见原因。

突变：如果你在重复测试的一部分的同时改变了另一个重要的部分。即使你在重复测试的某些元素，整个测试仍然是新的，并且可能揭示出新的行为。做突变测试，是因为虽然我之前已经覆盖了一些东西，但我还没有覆盖它。突变的一个常见形式是使用不同的数据以同样的方式操作产品。突变测试和间歇或重试之间的关键区别是，突变的改变是直接在你的控制之下。突变是有意的，间歇是偶然因素的结果，而你重试一个测试主要是由于偶然因素。

基准测试：如果测试的输出包含一个标准，该标准通过与以前执行的相同测试的比较来获得其值。最明显的例子是性能基准测试。当历史测试数据被用作预言时，那么您必须注意您执行的测试与历史数据是可比较的。保持测试不变可能不是使结果可比较的唯一方法，但它可能是可用的最佳选择。

你可能会理性地重复测试......

这些原因不是单独存在的，而是与技术原因相结合，使其变得更好

重要性：如果一个问题可能被测试发现，它很可能比其他测试发现的问题更重要。产品行为重要性的分布不一定是一致的。有时一个特定的问题可能被认为是不可容忍的，仅仅因为它已经影响了一个重要的用户一次。这并不一定意味着你必须运行相同的测试，只是一些足够相似的捕获问题(见突变测试)。小心不要混淆一个问题的重要性和一个测试的重要性。可能有更好的测试来发现一个特定的重要问题，也许你不应该重复这个。

廉价：如果它们具有一定的价值，并且与新的和不同的测试成本相比足够便宜。然而，这些测试可能不包括产品。

充足的：如果你重复的测试代表了唯一值得做的测试，然而，我们通常没有很好的理由认为我们有正确的测试集。我们可能会引入变量，因为我们不知道哪些测试真正值得做。

强制的：如果由于合同、管理法令或法规，需要你被迫运行相同的测试。然而，即使在这些情况下，通常也没有必要将强制的测试作为执行的唯一测试。你可能能够在不违反强制的情况下运行新的测试。

实践

Ward Cunningham写道：“我相信，TDD(测试驱动设计)所要求的自动化，是免于类比的，因为我们正在做的搜索是在测试存在的情况下，对程序的最佳表达，而不是最好的测试。”

首先，我不把你写的代码叫做“测试”。测试是一个事件；测试的一个实例。测试是一个人的过程。像任何一个想做好工作的工匠一样，我需要我的语言和思想是清晰的——在这种情况下，这样我们就不会忽视测试员的角色。你所指的是一套输出检查。这里的“测试”是你设计或重新设计整个断言集、执行它们并评估输出的过程。你编写它们，以便它们在违反一些有趣的期望的情况下会失败。

Question: 问题: Why run it again?

Answer: 回归。你再次运行它，因为你已经添加了代码使检查通过，因此再次运行测试不仅仅是多余的，测试的价值已经被产品更改重新充电。

Question: 问题:During the course of development, but after the first time the test passes, why not delete it? Why bother to run it again?

Answer: 几个原因。回归仍然适用，因为在开发过程中你可能会意外地破坏产品，但可以认为大多数单元测试在大多数时间不会失败，即使你对代码做了一些改动，其中一些也极不可能失败。但还有第二个原因：廉价。创建这些检查、运行它们并保持它们运行的成本很低，同时它们确实有价值，即使不是很多。对于一些检查还有第三个原因：重要性。对于许多单元测试，失败将表明一个非常严重的问题。如果你正在测试某个特别复杂的东西，或者涉及许多相互作用的子系统，你可能还想因为间歇性而重复。由于测试中的概率因素，可能在第43次运行后某个东西会失败。最后，还有重试的原因，这提醒我们，我们可能以前没有正确地运行测试。正如你曾经说过的，沃德，只有在你执行了大约100次测试后，才可能有东西困扰你。

Question: 问题: Let’s say that I’m a really good developer and though I write good checks, they don’t fail because I just don’t put bugs into my code. I have a whole lot of tests and they don’t fail. What was the sense in investing in such tests?

Answer: 两个潜在的原因。一个是避免/无关紧要。你可能创建检查作为未来开发人员的一种文档形式，你希望它们完全相同，以尽量减少失败的可能性(因此作为文档的用处更小)。或者你可能想用你伟大的软件给客户留下深刻的印象，如果检查不通过，他们不会那么印象深刻。第二个原因是强制的：你可能这样做，因为你的同事组或你的经理要求你这样做。这有点像避免，除了你确实需要执行命令，实际上，你想找到bug。你正在寻找它们，你只是被要求使用某种技术来这样做。

因此，我们看到，TDD中相当简单、经常重复的单元测试可能确实免除了基于雷区的争论，因为我引用的原因适用于测试。但是TDD不能免除这种启发式分析。质疑重复测试的价值是合理的，而这正是雷区让我们做的。