软件测试基本原则

软件测试经过几十年的发展，测试界提出了很多软件测试的基本原则，为测试管理人员和测试人
员提供了测试指南。

软件测试原则非常重要，测试人员应该在测试原则指导下进行测试活动。

软件测试的基本原则有助于测试人员进行高质量的测试，尽早尽可能多的发现缺陷，并负责跟
踪和分析软件中的问题，对存在的问题和不足提出质疑和改进，从而持续改进测试过程。

原则1: 测试显示缺陷的存在
测试可以显示缺陷的存在，但不能证明系统不存在缺陷。

测试可以减少软件中存在缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的，或者说是不存在缺陷的。

原则2: 穷尽测试是不可能的
穷尽测试是不可能的，当满足一定的测试出口准则时测试就应当终止。

考虑到所有可能输入值
和它们的组合，以及结合所有不同的测试前置条件，这是一个天文数字，我们没有可能进行穷尽测试。

在实际测试过程中，测试人员无法执行“天文”数字的测试用例。

所以说，每个测试都只是抽
样测试。

因此，必须根据测试的风险和优先级，控制测试工作量，在测试成本、收益和风险之间求
得平衡。

原则3: 测试的尽早介入
根据统计表明，在软件开发生命周期早期引入的错误占软件过程中出现所有错误（包括最终的
缺陷）数量的50%～60%。

此外，IBM的一份研究结果表明，缺陷存在放大趋势。

如需求阶段的一个
错误可能会导致N个设计错误，因此，越是测试后期，为修复缺陷所付出的代价就会越大。

因此，
软件测试人员要尽早地且不断地进行软件测试，以提高软件质量，降低软件开发成本。

原则4: 缺陷的集群性
Pareto原则表明“80%的错误集中在20%的程序模块中”。

实际经验也证明了这一点，通常情
况下，大多数的缺陷只是存在测试对象的极小部分。

缺陷并不是平均而是集群分布的。

因此，如果
在一个地方发现了很多缺陷，那么通常在这个模块中可以发现更多的缺陷。

因此，测试过程中要充
分注意错误集群现象，对发现错误较多的程序段或者软件模块，应进行反复的深入的测试。

原则5: 杀虫剂悖论
杀虫剂用得多了，害虫就有免疫力，杀虫剂就发挥不了效力。

在测试中，同样的测试用例被一
遍一遍反复使用时，发现缺陷的能力就会越来越差。

这种现象的主要原因在于测试人员没有及时更
新测试用例，同时对测试用例及测试对象过于熟悉，形成思维定势。

为克服这种现象，测试用例需要经常的评审和修改，不断增加新的不同的测试用例来测试软件
或系统的不同部分，保证测试用例永远是最新的，即包含着最后一次程序代码或说明文档的更新信息。

这样软件中未被测试过的部分或者先前没有被使用过的输入组合就会重新执行，从而发现更多
的缺陷。

同时，作为专业的测试人员，要具有探索性思维和逆向思维，而不仅仅是做输出与期望结
果的比较。

原则6: 测试活动依赖于测试内容
项目测试相关的活动依赖于测试对象的内容。

对于每个软件系统，比如测试策略、测试技术、测试工具、测试阶段以及测试出口准则等等的选择，都是不一样的。

同时，测试活动必须与应用程序的运行环境和使用中可能存在的风险相关联。

因此，没有两个系统可以以完全相同的方式进行测试。

比如，对关注安全的电子商务系统进行测试，与一般的商业软件测试的重点是不一样的，它更多关注的是安全测试和性能测试。

原则7: 没有失效不代表系统是可用的
系统的质量特征不仅仅是功能性要求，还包括了很多其他方面的要求比如稳定性、可用性、兼容性等等。

假如系统无法使用，或者系统不能完成客户的需求和期望，那么，这个系统的研发是失败。

同时在系统中发现和修改缺陷也是没有任何意义的。

在开发过程中用户的早期介入和接触原型系统就是为了避免这类问题的预防性措施。

有时候，可能产品的测试结果非常完美，可最终的客户并不买帐。

因为，这个开发角度完美的产品可能并不是客户真正想要的产品。

原则8: 测试的标准是用户的需求
提供软件的目的是帮助用户完成预定的任务，并满足用户的需求。

这里的用户并不特指最终软件测试使用者。

比如我们可以认为系统测试人员是系统需求分析和设计的客户。

软件测试的最重要的目的之一是发现缺陷，因此测试人员应该在不同的测试阶段站在不同用户的角度去看问题，系统中最严重的问题是那些无法满足用户需求的错误。

原则9: 尽早定义产品的质量标准
只有建立了质量标准，才能根据测试的结果，对产品的质量进行分析和评估。

同样，测试用例应该确定期望输出结果。

如果无法确定测试期望结果，则无法进行检验。

必须用预先精确对应的输入数据和输出结果来对照检查当前的输出结果是否正确，做到有的放矢。

原则10: 测试贯穿于整个生命周期
由于软件的复杂性和抽象性，在软件生命周期的各个阶段都可能产生错误，测试的准备和设计必须在编码之前就开始，同时为了保证最终的质量，必须在开发过程的每个阶段都保证其过程产品的质量。

因此不应当把软件测试仅仅看作是软件开发完成后的一个独立阶段的工作，应当将测试贯穿于整个生命周期始末。

软件项目一启动，软件测试就应该介入，而不是等到软件开发完成。

在项目启动后，测试人员在每个阶段都应该参与相应的活动。

或者说每个开发阶段，测试都应该对本阶段的输出进行检查和验证。

比如在需求阶段，测试人员需要参与需求文档的评审。

原则11: 第三方或独立的测试团队
由于心理因素，人们潜意识都不希望找到自己的错误。

基于这种思维定势，人们难于发现自己的错误。

因此，由严格的独立测试部门或者第三方测试机构进行软件测试将更客观、公正，测试活动也会达到更好效果。

软件开发者应尽量避免测试自己的产品，应由第三方来进行测试，当然开发者需要在交付之前进行相关的自测。

测试是带有破坏性的活动，开发人员的心理状态会影响测试的效果。

同时对于需求规格说明的理解产生的错误，开发人员自己很难发现。

但是，第三方或者独立的测试团队这个原则，并不是认为所有的测试完全由他们来完成。

一定程度的独立测试（可以避免开发人员对自己代码的偏爱），可以更加高效的发现软件缺陷和软件存在的失效。

但独立测试不是完全的替代物，因为开发人员也可以高效的在他们的代码中找出很多缺陷。

在软件开发的早期，开发人员对自己的工作产品进行认真的测试，这也是开发人员的一个职责之一。