以发现错误为目的测试与在雷区排查地雷类似，如果你只沿相同路径重复查找，你不会找到大量地雷，相反，这是一个躲避地雷的一个很好的方法。现代软件代表的空间比雷区复杂很多，所以设定一定数量的路径更是问题，例如，成百，成千，或成万的路径。当不断沿着这些路径查找时，会发现每一个重要的错误。一个测试团队在几周或几个月内尽他们最大努力执行的所有测试并不能涵盖可能发生在一个产品的所有情况。
        雷区分析实际上以另一种方式说明测试是一个采样过程，并且我们需要的是一个比较大范围内的样本，而不是一个多次重复使用小样本，因此，雷区给我们的启发是：执行不同的测试，而不是重复相同的测试。
        但是我所说的重复相同的测试指的是什么呢？我们知道，没有测试是可以精确的重复执行，就好像你不能精确的沿着你的足迹往回走，你可以很接近，但你总会有一点偏移。重复执行一个测试是否意味你第二次执行一个测试时，你要确保日光以同样的角度照射在你的鼠标上？可能，别以为这只是一个玩笑，我确实碰到过一个由日光照射在鼠标内的光学传感器触发的错误。所以你是不可能确保什么因素会影响一个测试，然而，当你测试时，你有一个确定的目标和对系统确定的预测，你就很可能可以针对目标和预测通过考虑以下方面：Ａ）你知道的和Ｂ）你关心的和Ｃ）不是太昂贵的来重复测试。这并不是什么很难处理的问题。
        因此，我所说的重复测试是指一个测试包含了在其它的测试中已经确定的元素。重复测试就是重复之前测试某些方面。以雷区分析的理论解释就是：最好尝试你没有做过的东西，然后重复你已经做过的东西。
        如果你不同意这种想法，或同意，请做更深入的阅读。因为这种分析过于简单化！事实上，即使多元化的测试是很重要和强大的，即使是反对重复测试的理由一般情况下是有效的，我还是知道10种例外情况。以下是10个具体的理由，关于在某些特殊的情况下，重复测试并不是不合理的，相反，它可能相当重要。
出于技术原因，你可能需要理性的重复测试…
        1. 再充电：当存在一个新的问题或一个旧问题的重复出现，可以通过现有的具体测试发现的明确可能性，或如果一个旧测试应用到一个新代码基础的时候。这就包括重新执行一个测试以确保问题已经修复，或者一个接一个地在较早期的版本上重复一个测试，因为你希望知道一个具体的问题或行为在什么时候出现的。这也包括对一个安装在新操作系统的，相同的软件上重新执行一个旧测试。换言之，在被测试的技术发生变化时，一个旧测试可以"再充电"。注意，再充电的作用并不一定意味着你应该执行相同的旧测试，无理性的这样做不必要的。
        2. 间断：当可能因为一些你无法控制的相关重要变量，你怀疑正确的执行一个测试能否确保发现一个错误的时候。对于你来，执行一个测试，严格来说是和你以前已经执行过的，相同的一个测试，可能会找到之前已经存在，但直到无法控制的变量以某种方式起作用才可以发现的错误。这和一个赌徒在第一次失败后，还继续在老虎机上赌是一样的道理。
        3. 重试：当你不确定一个测试在其它的时候是否被正确的执行时，这种情况的一种处理方法就是让几个测试员沿着同样的测试说明执行测试，检查他们是否得到相同的结果。
        4. 改变：当你修改了一个测试中的重要部分，但同时保持其它部分不变时，即使这个测试的一部分元素是保持不变的，但对整个测试来说，它是新的，并且可能会引发新的行为。之所以会对一个测试作改变，那是因为虽然之前的测试涵盖了某些方面，但涵盖的范围还不足够。一个常见的修改测试形式就是以同样的方式操作产品，但过程中采用不同的测试数据。区分改变，间断，和重试的关键就是在改变测试时，你可以直接控制改变，改变是有目的性的，间断是偶然事件的附带结果，并且因为偶然元素才会重试一个测试。
        5. 基准：当重复的测试包含一个绩效标准时，这个标准的值是与相同测试之前的执行情况比较得出的。当历史测试数据被用作预期结果，那你得保证你执行的测试历史数据有可比性。掌握测试常量未必是使结果可比的唯一途径，但它可能最好的选择。
出于商业原因，你可能会理性地重复测试…
        6. 便宜的：当重复测试有一定的价值，并且以一个新的，不同的测试相比，是十分便宜的时，但，这些测试可能不能确保产品的质量。
        7. 重要性：当可以通过重复测试发生的问题可能比其它检测出来的问题更重要时，产品行为的重要性不一定是均衡分布的，有时一个特殊的问题只因影响重要用户一次就可能被认为难以接受的（"决不允许再次发生"的情况）。这并不意味着你要执行完全相同的测试，只要重复的测试包含可检测出问题的足够相似的元素就可以了（查看改变部分）。注意，不要混淆问题的重要性和测试的重要性。一个测试，即使它检测出来的问题不是很重要的，但因为许多原因它也可能是重要的。同样，为了查找一个重要的错误而花费过多的精力在一个测试上，而忽略了其它同样可以，或更利于检测出那种问题的测试，这样的错误不要犯。
        8. 充分性：当你重复的测试代表唯一值得重复的测试。这和病毒检测原理相似：可能对一个普通用户来说，一个重复的病毒扫描就足够了，持续变化的病毒测试则并不必要。然而，我们可能对重复的测试引入某些改变，因为我们不知道哪些测试真正值得重复的，或者说我们通过重复测试不能得到充分测试的效果。
        9. 被授权的：当根据合同规定，管理法令或规则，你必须执行完全相同的测试，然而，即使在这些情况下，往往只执行授权的测试并不必要，你可以执行新的测试而不违法规则。
        10. 不重视/避免：当“测试”因一些原因而不是为了查找错误被执行时，例如，培训，演示（例如，你非常希望能通过的演示给用户看的验收测试），或把系统置于某个阶段。如果你执行测试目的之一是避免缺陷，那么改变的主要论据就不成立了。
        通过与测试课程的学生和同事近百小时的辩论，我收集了上述原因。我的很多同事都喜欢这些原因的其它表达方式和分类方法，我这样表达和分类并没特殊的原因（除了其它的一些分类方式会有很长的列表，并且列表中会出现非常相似的项），重要的是，当我听到一个原因，它与我之前听到的那些不同。我就会添加这个原因到列表中，我在1997开始添加了头两个原因，第10个原因则是在2004年添加的。

雷区应用：一个例子
        Ward Cunningham写过：我相信ＴＤＤ[测试驱动设计](和修改)的自动化需求是不可比拟的，因为我们正在进行的研究是用于一个程序在测试之前的最好表达，而不是最好测试。　
        以下是我对上面理论的理解：
        你的单元测试可能成功或失败，你编写这些单元测试，使它们在关注的预期结果被干扰的情况下不能通过，所以，你把它们叫做测试并且他们看起来也像是测试
在第一次执行成套单元测试中的任何指定测试时，我们引入雷区批判理论。你第一次执行单元测试时失败，对吧？当然，因为它不是ＴＤＤ，否则就会成功。下面的问题是从雷区启发性理论得出的：“使你的测试多样化，而不是单纯的重复执行”
        问题：为什么要再次执行它？
        解答：例外#１，“再充电”。你重新执行它是因为你已经添加了代码使这个测试能通过，因此重新执行测试并不是多余的，这个测试的价值已经被相关改变的代码重新激发。
        问题：在开发的过程，但在第一次测试通过后，为什么不删除它？何必再执行一遍？
        解答：原因有几个，再充电还有一点应用，因为你可能在开发过程中不小心破坏了产品。并且可以说大部分的单元测试大多时候不会失败，即使你改变很多代码，其中的一些单元测试很可能不会失败。这样你就有第二个原因了：例外#６，“便宜的”，创建这些测试，执行它们，和保持它们运行的成本非常低，同时这些测试又有一定的价值，即使价值不是很大。对于一些测试，你还可以有第三个原因：例外#７：“重要性”。对于很多的单元测试来说，失败可以预示一个非常严重的问题。如果你在测试的软件有一些非常复杂的代码，或包括了很多互相作用的子系统，这时因为例外#２，“间断”。你可能需要重复测试。可能在第43次执行后，因为测试中的概率因素，一些测试会失败，所以，最后一个原因，例外#３，“重试”。这个例外会提醒我们可能之前的测试没有被正确的执行。正如Ward你曾经说过，一些问题可能只会在你测试了成百次后才冒出一些苗头。换句话说，经过多次测试后，你可能会找到产品一直存在，但从没注意到的缺陷。
        问题：如果我是一个非常好的程序员，并且虽然我写出很好的测试代码，因为我不会在我的代码引入错误, 所以这些测试代码不会失败。我有一整套的测试，并且它们都不会失败，那么重复这些测试还有什么意义？
        解答：两个潜在的原因，例外#10，“不重视/避免”，你可能文档的形式记载那些测试，以供以后的开发人员使用，并且为了把失败的机率减到最低，你希望他们完全遵循这些说明去执行测试（因此文档的作用会减少）。或者可能你希望你的软件给客户留下一个深刻的印象，但如果测试没有通过，客户会有不好的印象。第二个原因是例外#９，“被授权的”。你可能采用这种方式工作，因为你的组员或经理要求你这样做。这有一点像是避免，除非你确实希望通过授权的方式查找到错误。你在查找这些错误时，你需要使用某种技术去这样做。
        因此，从在我提到的种种原因来看，我们可以看到ＴＤＤ的相当简单的，经常重复执行的单元测试实际与偏向于多样化测试的雷区分析理论不同，但ＴＤＤ也没有偏离雷区的启示性分析。质疑重复测试的价值总是有理由的，并且雷区分析理论引导我们这样做。
        （本文写作过程中得到了以下同事的协助：Doug Hoffman, Michael Bolton, Ken Pugh, Cem Kaner, Bret Pettichord, Jim Batterson, Geoff Sutton，并且还得到了参加"Minefield Debate"课程的学生的帮助，"Minefield Debate"是我测试课程的一部分，我提到的雷区分析理论由Brian Marick在典型测试错误的报告中提出。）

版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。