|
|
|
基于测试是为了寻找软件的错误与缺陷，评估与提高软件质量，我们提出这样的一组测试原则，如下所示。
|
|
|
|
|
|
这是因为软件的目的是使用户完成预定的任务，并满足用户的需求，而软件测试所揭示的缺陷和错误使软件达不到用户的目标，满足不了用户需求。
|
|
|
|
. 应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。
|
|
|
|
由于软件的复杂性和抽象性，在软件生命周期各个阶段都可能产生错误，所以不应把软件测试仅仅看作是软件开发的一个独立阶段的工作，而应当把它贯穿到软件开发的各个阶段中。在软件开发的需求分析和设计阶段就应开始测试工作，编写相应的测试文档。同时，坚持在软件开发的各个阶段进行技术评审与验证，这样才能在开发过程中尽早发现和预防错误，杜绝某些缺陷和隐患，提高软件质量。只要测试在生命周期中进行得足够早，就能够提高被测软件的质量，这就是预防性测试的基本原则。
|
|
|
|
|
|
想要进行完全的测试，在有限的时间和资源条件下，找出所有的软件缺陷和错误，使软件趋于完美，是不可能的。主要有三个原因：
|
|
|
|
|
|
|
|
|
|
一个适度规模的程序，其路径组合近似天文数字，对于每一种可能的路径都执行一次的穷举测试是不可能的。此外，测试也是有成本的，越是测试后期，为发现错误所付出的代价就会越大，因此也要根据测试错误的概率以及软件可靠性要求，确定最佳停止测试时间，我们不能无限地测试下去。
|
|
|
|
|
|
进行测试是可以查找并报告发现的软件缺陷和错误，但不能保证软件的缺陷和错误全部找到，继续进一步测试可能还会找到一些，也就是说测试只能证明软件存在错误而不能证明软件没有错误。
|
|
|
|
|
|
经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正比。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。在所测程序段中，若发现错误数目多，则残存错误数目也比较多。这种错误群集性现象，已为许多程序的测试实践所证实。例如，在美国IBM公司的OS/370操作系统中，47%的错误仅与该系统的4%的程序模块有关。这种现象对测试很有用。如果发现某一程序模块似乎比其他程序模块有更多的错误倾向，则应当花费较多的时间和代价测试这个程序模块。
|
|
|
|
|
|
基于心理因素，人们认为揭露自己程序中的问题总不是一件愉快的事，不愿否认自己的工作；由于思维定势，人们难于发现自己的错误。因此，为达到测试目的，应由客观、公正、严格的独立的测试部门或者独立的第三方测试机构进行测试。
|
|
|
|
|
|
应该从工程的角度去理解软件测试，它是有组织、有计划、有步骤的活动。
|
|
|
