该章最后，作者给予了十大测试原则：
测试用例中一个必需部分是对预期输出或结果的定义。
一个测试用例必需包括两个部分：对程序的输入数据的描述和对程序在上述输入数据下的正确输出结果的精确描述。
程序员应当避免测试自己编写的程序。
原因有三：
当程序员“建设性”地设计和编写完程序之后，很难让他突然改变视角以一种“破坏性”的眼光来审查程序，即，他们无法改变思维方式来尽力暴露自己程序中的错误；
程序员可能会下意识地避免找出错误来，担心受到同事、上司、客户或正在开发的程序或系统的主管的惩罚；
由于程序员错误地理解了疑难定义或规范，导致程序中存在错误。如果是这种情况，程序员可能会带着同样的误解来测试自己的程序。需要指出的是：“调试”还是由程序的编写人员来完成会更加有效的。
编写软件的组织不应当测试自己编写的软件。
应该是由客观、独立的第三方来进行测试。理由雷同于上条规则中所涉及到的。
应当彻底检查每个测试的执行结果。
在项目测试的时候，总是会发现在后续测试中发现的错误，往往是前面的测试遗漏掉的。
测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况。
其实在软件产品中暴露出来的许多问题是当程序以某些新的或未预料到的方式运行时发现的。所以这条原则的重要性可能在测试中的地位还应该是更要值得引起注意的才是。
检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。
应避免测试用例用后放弃，除非软件本身就是一个一次性的软件。
在交互式系统上来测试的话，这条原则可能就会显现的更加重要了。这条原则体现的会更加省时省力。因为如果对程序的更改导致了程序某个先前可以执行的部分发生了故障，这个故障往往是不会被发现的。保留测试用例，当程序其他部分发生更动后重新执行，这就是我们所谓的“回归测试”了。
计划测试工作时不应默认假定不会发现错误。
程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
作者所说的而言，错误总是倾向于聚集存在，而在一个具体的程序中，某些部分要比其他部分更容易存在错误。那么为了使测试获得更大的成效，最好对这些容易存在错误的部分进行额外的测试。
测试是一项极富创造性、极具智力挑战性的工作
文章来源于领测软件测试网 https://www.ltesting.net/