1、测试心理
上文中曾经提到过研发和测试在思路和观念上的一些矛盾。多数情况下，研发工程师并不精通软件测试的思路，因此可能会认为测试无非就是走一个流程，认为“软件测试就是证明软件不存在错误的过程”，或者“测试的目的在于证明软件能正确完成其功能”，或者“演示软件做了应该做的流程”。
实际上，几乎所有的程序代码在一开始都存在或大或小的错误，而测试的实际意义在于为了发现各种错误而执行的过程。
2、测试分类
软件测试通常有两种不同的策略：黑盒测试和白盒测试。
（1）黑盒测试
所谓黑盒测试，即为数据驱动的测试，或者叫做输入/输出驱动测试。黑盒测试不需要了解程序内部的结构，完全依赖输入和输出数据的关系判断软件的正确性。要在黑盒测试中确保完全避免所有错误，则需要遍历所有可能的输入数据，实际上这是完全不可能实现的。
（2）白盒测试
白盒测试是与黑盒测试相对应的另一种测试策略，在这种测试方法中，测试者将检查代码内部的运行流程，确保正确的路程产生正确的结果。同样，要保证白盒测试避免所有错误，则需要遍历程序运行的所有可能流程，而这更是不可能的任务。
因此综上所述，无论黑盒或白盒测试都不能单独保证代码的质量。在实践中，通常是将二者有机结合形成一种不完美却合理的方法。
3、测试原则
（1）测试用例必须定义对某个输入的预期输出或结果：不应该出现含糊不清的输入-输出关系，无论正确或错误的结果都应该有合理的判断。
（2）研发工程师和开发组织不应该测试自己的代码：原因已经在上一篇叙述过，主要是思维定式的问题。但是，由于我们这一系列博文主要是针对研发工程师，因此我们的思路却是反其道而行之，更加强调研发工程师的自测，用这种方式突破思维定式的限制，写出更加优秀的代码。
（3）测试用例不仅仅应当依据有效和预期的输入，更多地应当考虑无效和未预料到的情况：该原则呼应了软件测试的实际意义——为发现各种错误而测试。
（4）测试时不仅仅应该考虑软件“是否完成了应该完成的”，也要考虑“是否避免了不该做的”：原理同上。
（5）保留测试用例用于回归测试：在软件的bug修复后往往需要重新测试，如果不能保证测试用例一致，那么回归测试可能会漏掉某些新出现的故障。
（6）已发现的错误数量通常和仍然隐藏的错误数量成正比：错误总是倾向于聚集存在。
