既然软件测试的目的是寻找软件的错误和缺陷,从而来评估和提高软件质量, 那么软件进行测试时必须要遵一定的原则:

　　一切测试要追溯到用户的需求

　　正如我们所知，软件测试的目标就是验证产品的一致性和确认产品是否满足客户的需求，所以测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。

　　应该把“尽早测试和不断测试”作为测试人员的座右铭

　　我们应该在需求模型完成后立马就开始制定测试的计划,详细的测试用例定义也可以在需求的模型确定后立即开始进行.因此测试应该在代码没有产生前就要进行计划和设计。

　　pareto原则(二八原则):80%的错误,发生在20%的模块中

　　当某个功能出现问题时,评估其对用户的影响有多大,然后根据大小确定测试的优先级别.优先级高的,优先进行测试。

　　一般来讲针对用户最常用的20%功能(优先级别最高)的测试会得到完全执行, 而低优先级的测试(另外用户不常用的80%功能)就不是必要的,如果时间或经费不够,就暂时不做或者少做。

　　穷举测试是不可能的

　　测试无法显示软件潜在的缺陷,测试只能证明全疆存在错误或缺陷,不能证明软件没错误.因为一个大小适度的程序,其路径排列的数量也非常大,因此不可能在测试中运行每一条路径的组合.然而,充分覆盖程序逻辑,并确保程序所有使用的条件是有可能的。

　　第三方测试会更客观

　　程序员应避免测试自己的程序，为达到最佳的效果，应由第三方来进行测试。测试是带有 ”挑剔性” 的行为，心理状态是测试自己程序的障碍。同时对于需求规格说明的理解产生的错误也很难在程序员本人测试时被发现。要做出“经得起考验和测试的产品”。

　　测试用例是设计出来的, 不是写出来的

　　测试用例是要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。除了检查程序是否做了应该做的事，还要看程序是否做了不该做的事;不仅应选用合理的输入数据，对于非法的输入也要设计测试用例进行测试。 要知道好的测试用例真的会有效且事半功倍。

　　不可将测试用例置之度外，排除随意性

　　特别是对于做了修改之后的程序进行重新测试时，如不严格执行测试用例，将有可能忽略由修改错误而引起的大量的新错误。所以，回归测试的关联性也应引起充分的注意，有相当一部分最终发现的错误是在早期测试结果中遗漏的。其它所有工作都应该避免随意性。

　　测试贯穿于整个生命周期

　　由于软件的复杂性和抽象性，在软件生命周期的各个阶段都可能产生错误，测试的准备和设计必须在编码之前就开始，同时为了保证最终的质量，必须在开发过程的每个阶段都保证其过程产品的质量。因此不应当把软件测试仅仅看作是软件开发完成后的一个独立阶段的工作，应当将测试贯穿于整个生命周期始末。 　　软件项目一启动，软件测试就应该介入，而不是等到软件开发完成。在项目启动后，测试人员在每个阶段都应该参与相应的活动。或者说每个开发阶段，测试都应该对本阶段的输出进行检查和验证。比如在需求阶段，测试人员需要参与需求文档的评审。

　　对发现错误较多的程序段，应进行更深入的测试

　　一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。越需要深入和多次测试。