继续本章开头所阐述的问题“在软件测试中心理因素占有重要的位置”，通过对心理学的了解，我们能够找出软件测试中重要的原则或者称为重要的指导方针。这些原则大部分都是浅显易懂，但在实际工作当中却很容易被忽视。表2.1概括了这些重要的原则，在下面的章节中将详细阐述。

　　法则1：定义预期输出或结果，是测试用例的重要组成部分

　　这个显而易面的原则是软件测试中最容易忽略的问题之一，当然，这个它也涉及了心理学的一些基础知识。如果一个运行结果在测试用例没有明确定义，它看起来很合理，实际上却是错误的，结果测试员将它当作了程序的正确运行结果，这个现象叫“希望即所见”。换句话说，就是尽管这个结果是不正确的，但测试员的潜意识里希望它是正确的，那么就将主观的肯定了它的正确性。避免这个现象产生的方法就是在测试用例中列出所有的预期结果，、因此，测试用例必须由以下两个部分组成：

　　1. 描述程序的输入数据

　　2. 精确的描述出每个输入数据所对应的正确输出结果

　　如果问题的定性没有明确的解释，这看起来似乎很不寻常，或者不符合我们预期的目标，这将很难做出正确的判断。所以我们要事先确定程序的正确运行结果，来明确测试目标。如果没有期望，就没有惊喜。

　　法则2：软件工程师应该尽量避免测试自己编写的程序

　　任何作家都知道或应该知道，校对自己的作品是个坏主意。尽管作者很了解文章中哪个部分是应该加入的，哪个部分是多余的，但是在潜意识里却希望自己的作品找不出任何破绽。这个道理同样适用于软件开发人员。

　　软件工程师测试自己所编写的代码的第一个难点在于，在项目中所负担的工作职责突然发生转变，完成由编码到测试的角色转变将很困难，软件工程师如果去承担测试员这一角色，那么就必须打破在编码时所肩负的职责，背弃原有的工作思路，这将会需要相当长的时间或者这种转变根本不可能成功。

　　正如多数的房屋所有者都知道重新粘贴墙纸（一个破坏的过程）不是件容易的事情，最困难的环节就是动手去贴第一张墙纸并且贴正它。同样的道理，多数软件工程师不能对自己编写的代码进行有效的测试，因为从创造者的角度来看，每个人都不希望自己的作品中存在瑕疵。另外，软件工程师有可能会出于害怕上司的批评影响经后的工作而下意识的逃避错误，但是客户、软件购买者却不存在这样的担心，所以他们发现的问题要比软件工程师自己测试后发现的问题更多。

　　如果再增加一些心理因素，就会引出第二个难点：如果软件工程师在编写代码的声明的部分时犯了错误，或是错误的理解了软件的需求，那么在测试自己编写的代码的过程中，这些错误的观念可能仍会存在，那么这种测试将会毫无意义，因为软件工程师找不出自己究竟犯了哪些错误。

　　这并不意味着软件工程师一定不能胜任测试自己编写的代码，只是说如果让另一个人来完成测试的工作，软件测试的有效性和成功性将会大大提高。

　　对已知问题的争论远不如调试一次更为有效，调试代码是软件工程师测试代码质量的最有效也是有原始的一个步骤。

　　法则3：软件开发小组不应该测试自己编写的程序

　　本法则与上述的论点有相似之处。一个工程或项目组的成员，在许多问题会有相同的认知，而各个独立的团队间对相同事物的认知会有所不同。此外，在软件行业中，普遍以代码提交日期及节约项目成本为评价项目经理能力的标准。如果将上述问题说成节约时间及成本是项目的最终目标，这样更易于理解，但事实上这个目标却很难保证代码的质量。因此一个以时间和成本为开发目标的团队不应该去测试自己的产品，因为看起来增加测试的环节会拖延项目的工期，增加项目成本。

　　再次强调一下，软件开发小组不应该测试自己编写的程序，这与开发团队制定的工作目标是息息相关的。因此，选择另一个独立的团队来测试自己的程序是个明智的选择。

　　法则4：彻底检查每个测试结果

　　这是一条最显而易见，也是最容易被忽视的法则。我们做过很多实验来证明看似很被人发现的错误却常常被忽视掉，尽管这样的错误已经在输出结果的清单里面一一列出了。以另一种方式来解释这种现像，就是早期测试比晚期测试发现更多的问题。