法则5：测试用例中不但要写明有效的和预期规定的输入条件，也要包括无效的及预期规定之外的输入条件

　　在测试的过程中，将大部分精力放在检验程序在输入有效数据和预期输入条件的运行结果上，而忽视了在无效输入数据和预期外的输入数据后的运行情况，这种做法是在测试的过程中普遍存在的。举例来说，在第一章提到的对三角形程序的测试中，这种测试趋势就已经体现出来了。

　　在向程序输入1，2，5这三个数据的时候，只有很少的人会认为程序将判断出这是一个无效三角形而并非一个不等边三角形。就像这样，许多问题在意想不到的测试条件下暴露无遗。得到的结果显示，在用例中无效输入数据和预期外的输入数据，会检测出常规数据所检测不到的问题。

　　法则6：检查程序应该完成哪些功能，这只是测试工作的一半，测试工作的另一半是，检查程序完成了哪些不应该完成的功能

　　法则中所阐述的观点已经在上述各个法则的描述中得到了解答。检查程序是否产生了预期外的结果很重要。例如，一个看似正常运行的薪资系统，为并不存在的雇员支出了工资或是后面的记录覆盖了前面的记录。

　　法则7：避免一次性的测试用例，除非该程序是一个真正的一次性项目

　　这条法则经常用于交互式系统的测试当中。通常的作法是建立灵活性较高的测试用例，然后在程序中执行它们。困难的是已经完成的测试用例是否仅适用于当前的测试环境，当环境变更的时候就再也用不上了。测试用例需要随时维护（例如，发现用例中存在漏洞的情况下要及时修正），以便在经后的测试中可以重复使用。由于需求的频繁变更所带来的测试用例维护的工作量非常大，这也是对测试人员的一种考验，是否能够及时的修正测试用例以便测试到程序的新特性，如果用例没有根据新需求及时做出修改，那么将会发生漏测的现象，许多错误也因此不会在测试中被发现了。将修改后的测试用例存档，并在新环境中作为回归测试的用例执行它们。

　　法则8：如果没有很好的对测试工作进行计划，只凭主观臆断来测试，将很难发现程序中存在的错误

　　大多数的测试经理都会犯这样的错误，原因在于他们错误的理解了测试的意义，在他们眼中测试的过程是在证明程序能够按照预期规定的正确运行。这里再次强调，测试的真正意义在于尽可能多的找出程序中的缺陷。

　　法则9：如果某段程序出现了错误，那么该段程序出错的概率与代码数量成正比

　　图2.2描述了这个现象。很少的人会认同这种现象，但在实现的程序中这种现象却经常发生。举个例子，有这样一段程序，由两个模块组成，这两个模块可以是类也可以是两个子程序，将它们分别记作A和B。在模块A中发现了5个错误，在模块B中只发现了一个，如果对模块A进行更严格的测试的话，你将会发现正好印正了法则中所阐述的观点，模块A存在错误远远大于模块B。

　　换一种比较通俗的解释来说明本法则，就是错误簇。在一个典型的程序中，问题更倾向发生在其中一段程序中，那么这段程序的错误发生率就会高于另一段程序，没有人能解释这种现象。在测试的过程中要对这个现象加倍注意，如果其中某段程序的错误率高于其他部分，那么投入较多的精力去测试这段程序就十分必要了，因为有可能通过严格的测试后发现，这段程序的确存在很多的错误。

　　法则10：测试是一项具有创造性和挑战性的任务

　　软件测试是比其他工作更具有创造性和挑战性的工作。在前面我们已经阐述了对程序的完全测试并找出所有错误是不可能办到的事情。在后面的章节中我们将阐述建立合理的测试用例的方法，但学习这些方法需求学习者具有更强的创造性和应变能力。

　　摘要

　　如果要继续阅读本书，那么请在脑海中时刻谨记以下三个法则：

　　软件测试是找出程序中隐藏错误的过程。

　　高质量的测试用例能够发现较多的程序中的隐藏错误。

　　一个成功的用例能够发现未被发现的隐藏错误。