测试找BUG就像在雷区找地雷。如果你总在同一条路上走来走去，你就找不到许多
地雷。实际上，这是一条很好的路用来避免地雷。其余的空地对一个现代的软件
产品要比一个雷区巨大和复杂的多，因此这是比一些小量的路径更多的难以假设
的问题，可以说，一百，一千或一百万，在不断的重复时，将会发现每个重要的
BUG.一个小组的测试员可以手动执行数周或数月的测试，但仍不能和在这个区域
发生在这个产品的事情相比。
类似于布雷区的说法仅仅是关于测试是一个类似的过程的另一种说法，我们可能
想要一个更大的例子，而不是一个小的重复了多遍的例子。因此雷区带来的取法
就是做不同的测试而不是重复相同的测试。
但是我说的重复相同的测试是什么意思呢？显而易见，没有测试能被准确的重复
执行，这要比你准确重复执行的更多一些。你可以关闭，但那将总是一小部分。
作复测就是你第二次运行测试，而且应确保阳光一直照射在你鼠标垫的同一个角
落吗?可能吧，不要笑，我经历过这样的BUG，一次，阳光照射到鼠标内的一个传
感器触发了这个BUG.你不能确实什么因素将会影响测试。可是，在你测试时，你
仍需要一个确定的目标和确定系统理论。你可以很好的重复测试，通过在每个值
得注意目标和理论，包括：A：你所知道的；B：你能确认的；C：代价太大而不去
重复的。对于此没有什么是必要处理的。
因此，通过复测，我的意思是包括在其他测试中覆盖的已知的基础。重复测试就
是要重复一些之前测试的方面。雷区的启发就是你试着去做一些事情要好于你没
有做过，然后做一些已经做过的事情。
如果你不同意这个说法或如果你同意这个说法，都请你读下去，因为...
这个分析太简单了！事实上，即使测试中的差异是重要和强大的，即使反对重复
的辩论是有效的，我知道有10个例外。有10个明确的原因，在一些特殊的情况下
，复测并不是没有道理的。重复一些测试可能是很重要的。
使你可以理性的测试有关技术上的原因有：
1.再充电：一个新问题或旧问题重现的真实的可能性是，可能是被一个现有的特
殊的测试捕获，或者是旧的测试应用在新的代码基础之上。包括再运行测试来证
实一个错误，或者当一个特殊的问题或行为可能介入时，在你试着去找到问题时
更早的连续构建之上的重复测试。也包括在新的操作系统中对同样的软件做原来
的测试。换句话说，一个疲劳的旧的测试能被改变测试的技术再充电。注意再充
电不会产生必要的影响意思是，你应该运行相同的旧的测试，仅仅是这么做是理
性的。
2.间断：如果你怀疑一个BUG的发现不是一次测试的正确运行能保证的，可能是与
你在测试中不能控制的一些重要的可变的因素有关。执行一个测试，对你而言，
正确的就像你已经执行过的那样，可能导致发现的BUG是一直存在但是没有显示出
来，直到自由的可变因素用一种确定的方式排队。这是相同的原因，对于一个赌
徒在输掉第一次之后在赌博器前玩了又玩。
3.再试：如果你不能确信测试再其他时候被正确执行。一个方法就是让所有的测
试人员根据这个相同的说明检查看是否能得到相同的结果。
4.转变：如果你要改变一个测试的重要部分并保持其他部分不变。尽管你重复了
一些测试的原理，测试整体是新的，并且可能会显示新的行为。我变异了一个测
试，因为尽管我之前覆盖了一些东西，但是并没有做得很好。一个共同转变的形
式就是使用不同的数据用同样的办法操作产品。变异一个测试和间断或重试之间
关键的不同就是变异要使改变在你的直接控制之下。变异是有意的，而间断结果
是因为偶然因素，你重试一个测试是因为偶然因素。
5.基准：比较之前相同准确测试的执行，可以得到一个执行标准的价值，如果复
测包括这个执行价值。当一个历史性的测试数据象神化一样被使用时，你应该意
识到你执行的测试对历史数据是有可比性的。保持测试一致可能不是使结果有可
比性的唯一方法，但他可能是可用的最好的选择。
使你可以理性的测试有关商业上的原因有：
6.便宜的：如果有一些相比新的和不同的测试价值十分便宜的测试，然而，这些
测试在证明在产品中的信心不是足够的。
7.重要性：如果一个问题是通过这些测试发现的，可能比通过另外的测试发现的
可现的BUG有更充分的重要性。产品行为的重要性分类没有必要统一。有时感觉一
个特殊的问题是难以忍受的，仅仅是因为它已经影响了一个重要的用户一次（一
个永不让它再次发生的情形）。这没有必要意思就是你必须运行相同的准确的测
试，发现这个问题正确地事情是十分类似的。注意不要用一个测试的重要性搞乱
一个问题的重要性。一个测试可能是重要的存在很多原因，即使那些问题发觉的
并不是危急的。同样，不要犯这些错误：花很多精力在一个看起来可以找到重要
BUG的测试上，而忽略了其他可能一样好的或者更好的可以发现这类型问题的测试
。
8.充足的：如果你做的复测是值得做的。这是一个病毒扫描的争论：对于一个平
常的用户，一个重复的病毒扫描是可以被认可的，代替了经常的改变病毒测试。
无论如何，我们可以说明变化因为我们不知道哪些测试是值得做的，或者我们不
能完成足够的复测。
9.委托管理的：如果，由于合同，管理布告，规章，你不得不相同的准确的测试
。无论如何，即使在这些情形下，通常委托管理的测试作为你唯一可执行的测试
是没有必要的。你可以在不违反委托管理的前提下运行新的测试。
10.不关心/避免：如果运行测试是因为一些原因而不是为了找BUG，比如为达到某
训练目的，演示目的（例如一个在客户的观看下，你拼命希望能通过的验收测试
），或把系统放在一个特定的状态。如果其中的一个目标在运行测试时是为了避
免BUG，那么主要的争论就是为了变化的消失。
我大概用了一百个小时和测试学生和同事争论这个问题，在此期间，我收集了这
些原因。我的许多同事更喜欢不同的词汇或一个不同的分类原因。我这种做法不
是什么特别神圣的（除非这些分类将使每个类似的项有更长的列表）。重要的事
是当我听到一个看起来不在我已经总结好的原因之列，我把它加到这个列表。
1997年，我开始只有2个原因。在2004年末，我增加到第十个。
在雷区的应用：一个例子
Ward Cunningham写过“我相信TDD自动需求免除了类推，因为我们做的研究是为
了在现有测试中做一个最好的程序表达，而不是最好的测试”
以下是一些我怎么想到的关于这个的应用：
你的单元测试可能通过了或没有通过。你记下他们所以他们将在一些违反预期结
果的事件中失败。所以，你叫他们测试并且，看到他们在测试。
我们介绍的雷区批判第一次你在单元测试中运行任何给出的测试。第一次运行，
失败了，对吗？当然，因为它不是TDD，否则。雷区启发了以下问题“变化测试而
不是重复测试”。
问题：为什么再次运行？
回答：“再充电”例外。你再次运行是因为你已经增加了代码使得测试通过，因
此再次运行测试不是多余的，通过代码的改变，测试的价值已经再次填充。
问题：在开发期间，除了测试在第一次通过后，为什么不删除？为什么这么麻烦
的再运行一次？
回答：几个原因。再仍然应用了一些，因为你可能在开发中偶然中断了，但是它
要被争论：大多数的单元测试和大多数的时间都失败了，他们中间的一些非常不
像失败，即使你彻底改变了代码。这里给你第二个原因:例6，便宜的。创建和运
行测试是很便宜的，同时他们还有一些价值，即使不是很多。对于一些测试，还
有第三个原因：例7，价值。对于一些好的单元测试，失败的发生将说明一个严重
的问题。如果你测试的一些东西是特别复杂的，或包括了许多互相影响的子系统
，你可能也想重复因为例2，间断。可能有些东西会在43次运行之后失败，因为在
测试中有一些或然而论的因素。最后，例3，再试。这提醒我们以前可能没有正确
运行测试。象你从前说过的，ward，有些东西会发出不好的气味仅在你看到测试
运行了大约100次以后。换句话说，运行测试很多遍的结果，你可能在显示产品的
缺陷有灵感，他们是一直存在的，但是没有注意到。
问题：我是一个很好的开发人员，尽管我写了好的测试，但是他们没有失败，因
为我的代码没有BUG。我有许多测试，并且他们没有失败。投资这样的测试有什么
意义呢？
回答:2个潜在的原因。例10，避免/不关心。你可能用文档的形式为将来的开发人
员建了很多测试，为了减少失败的可能性，你希望他们是正确的（因而象文档一
样没什么用）。或许你想用你这伟大的软件给客户留下印象，如果测试没有通过
，他们可能没什么印象。第二的原因是例9，委托管理的。你用这种方式工作因为
你同组或经理要求你这样做。除了你用这种委托管理的方式，这与避免有点象，
实际上，想找到BUG.你在寻找BUG，你只能使用要求的特定的技术来做。
我们因此可以看到一个相当简单经常复测的TDD单元测试真正的要避免基于雷区的
争论是有利于改变测试的，因此作为原因我已经引用了。但是TDD不能脱离这种启
发式的分析，对复测的价值提出疑问总是有道理的，这就是雷区邀请我们做到事
情。
