软件测试的7个基本原则

软件测试的7个基本原则

原则(Principles )，是每个人在行事中所遵循的准则。每个人都有自己的原则，或成人，或尚处襁褓。软件测试也有一套原则让每位软件测试从业人员去遵循，这些原则是前辈们前仆后继在无数的坑坑洼洼中总结出来的。

原则一：测试证明软件存在缺陷

时至今日，依然有不少人容易犯错：没有发现错误的测试说明软件没有缺陷。

这个原则可以用另一种方式来描述: 测试的本质是证明软件存在缺陷，而不是软件没有任何缺陷。

测试只能证明软件是存在缺陷的(证伪)，而不是证明软件是没有缺陷的(证实)。

软件测试只能找出应用程序或软件中存在的缺陷，测试是为了辅助开发，降低缺陷存在的可能性而开展的活动，即便对产品或者应用程序进行了多次的、比较彻底的测试都没有发现任何缺陷，也不能证明软件是100%完美的。

原则二：穷尽测试是不可能的

测试数据、输入和测试场景的所有组合是不可能的，因为它需要大量的时间。相反，测试团队只能专注于一些重要的指标，例如：设置测试策略的风险和优先级。一般来说，项目周期里永远不可能允许测试团队在项目中进行大量有效的组合测试。

比如测试一个简单的计算器，你可以尝试1+1,1+2,1+3,1+n……，但是时间上允许你把所有的数字都考虑进去做详尽测试吗?显然是不可能的，从功能本身出发也算是多余操作。

随着系统承载业务多，代码规模也越庞大，算法逻辑复杂度也越高。要让测试完全覆盖是不可能的。那难道不测?非也!我们可以采取以下策略：

1、精准测试：改动什么测什么;

2、二八原则：只测重点;

3、等价划分;

等等...

原则三：尽早介入测试

这条很重要，但是对测试的要求也会更高。

“早期的鸟儿有虫吃”或者是“早起的虫子被鸟吃”，对，说的就是这个理儿，早，是我们解决问题的有效办法。

必须尽早介入测试活动，为软件开发的下一阶段做好准备。只要生成产品需求或文档，测试人员甚至就可以开始测试。

据调查，缺陷的修复成本与其发现时间成反比，且越晚修复其修复成本将会成指数级增长。

显然，从一开始就解决问题总是更容易、更便宜，而不是如果发现错误太晚就改变整个系统。因此，通过早期测试，测试人员可以检测到错误，并帮助开发团队以更少的成本和精力解决问题。

另外，尽早介入测试，测试人员能够更全面的了解需求和项目整体进度，知己知彼百战不殆，说的就是这个理儿。

尽早介入测试原则与测试左移和测试前移具有异曲同工之妙。

原则四：缺陷具有集群性

之前听过一种理论，二八原则，即：80%的错误是由20%的模块引起的。

缺陷聚类指的是在几个模块中发现了大部分缺陷。这一原则要求测试团队利用自己的知识和经验，确定要测试的潜在模块。这一预测有助于节省时间和精力，因为团队只需要关注那些 “敏感” 领域。

然而，这种方法也有缺点: 一旦测试人员只专注于所有团队的一小块区域，他们可能会错过其他区域的错误。

原则五：杀虫剂悖论

当我们反复使用相同的杀虫剂的时候，会有少量害虫产生免疫而存活下来，使得杀虫剂失去药效。

杀虫剂悖论是指测试人员一直使用相同的方法或手段去重复测试，这些测试只适用于一些有限的模块，而不是整个系统。这种测试可能很难发现bug，甚至无法发现bug。因此，为了涵盖项目的各个部分，它要求测试团队经常审查和更新测试用例。

原则六：测试是上下文相关的

各种产品或项目包含不同的元素、特征和要求。因此，测试人员不能对不同的项目应用相同的测试方法。例如，银行行业的应用程序应该比娱乐软件需要做更多的测试。

原则七：无错误谬论

在 原则一：测试显示软件存在缺陷 中说明，测试是为了降低缺陷存在的可能性而开展的活动，即便多次测试都没有发现任何缺陷，也不能证明软件是完美的。

软件测试不仅仅是为了找出Bug而存在的活动，而是还需要确认软件是否满足用户的期望和需求，如果产品不能满足用户的需求，即使没有出现任何缺陷，这个产品也是失败的。

“没有错误” 并不是我们的追求，在互联网时代，始终快速给用户创造最大的价值才是我们孜孜不倦的追求。

上述原则是由 Rex Black 、 Erick Van Veenendaal 和 Dorothy Graham 的研究 “软件测试基础” (ISTQB 认证) 总结的。这些原则可以作为大多数测试项目的核心指南。然而，如上所述，每个产品或项目都包含非常不同的因素和需求，需要各种测试方法。测试人员应该利用他们的经验和知识来决定和平衡这些方法。