《软件测试技术实战：设计、工具及管理》—第1章 1.2节软件测试的七项基本原则...

本节书摘来自异步社区《软件测试技术实战：设计、工具及管理》一书中的第1章，第1.2节软件测试的七项基本原则，作者顾翔，更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.2　软件测试的七项基本原则
下面是业界公认的软件测试的七项原则。

1.2.1　原则1：软件测试显示存在缺陷
软件测试可以显示软件中存在缺陷，但不能证明软件不存在缺陷。软件测试可以减少软件中存在未被发现缺陷的可能性，但即使软件测试没有发现任何缺陷，也不能证明软件或系统是完全正确的。软件中到底存在多少缺陷，谁也不知道。软件测试的目的是尽可能发现更多的缺陷。此外，有些缺陷是不影响使用的，所以在考虑时间和成本上可以不必修改，从而防止过度测试带来对资源的浪费。

1.2.2　原则2：穷尽软件测试是不可行的
进行完全（各种输入和前提条件的组合）的软件测试是不可行的。通过运用风险分析和不同系统功能的软件测试优先级，确定软件测试的关注点，从而替代穷尽软件测试。穷尽软件测试真正的意思是，在软件测试完毕后，软件测试工程师知道在系统里没有残留任何未知的Bug。因为如果有未知的Bug，那么就可以通过做更多的软件测试找到他们，这样软件测试也就还没有穷尽。因为零缺陷的软件是不存在的，所以穷尽的软件测试也是不可行的。

扩展阅读：Good enough原则
　

软件测试的原则是Good-enough原则：这是一种权衡投入/产出比的原则，测试既不要不充分，也不要过分，不充分和过分都是一种不负责任的表现，当然达到Good enough是一种理想状态。
1.2.3　原则3：软件测试尽早介入
为了尽早发现缺陷，在软件或系统开发生命周期中，软件测试活动应该尽可能早地介入，并且也应该将关注点放在已经定义的软件测试目标上。在软件测试的各个阶段，软件测试最好在需求分析期间就介入进去，一方面可以尽早发现缺陷，另一方面可以尽早掌握产品的需求和设计，为更好地进行测试做好准备。请参考1.1.4节介绍的W软件测试模型。

1.2.4　原则4：缺陷集群性
软件测试工作的分配比例应该与预期的和后期观察到的缺陷分布模块相适应。少数模块通常包含大部分在软件测试版本中发现的缺陷或失效。这个符合80-20原则，即80%的缺陷发生在20%的模块中。造成这种现象的可能性如下：

• 该模块功能比较复杂；
• 实现该功能模块的开发工程师水平比较低；
• 其他原因。

James Whittaker等著的《探索式软件测试》书中提到对软件灾难区进行重点测试也是基于这点考虑的。

案例1-18：缺陷集群性。
产品项目同案例1-17，根据前两周的测试，总结出来的缺陷报告如下：

由此可见，模块D的缺陷是最多的，其次为模块A，然后是模块B，模块F和模块C，模块E和模块G相对缺陷比较少。根据缺陷集群性，测试经理调整第三周的测试任务如下：

1.2.5　原则5：杀虫剂悖论
采用同样的测试用例多次重复进行测试，最后将不再发现新的缺陷。为了克服这种“杀虫剂悖论”，测试用例需要进行定期评审和修改，同时需要不断增加新的不同的测试用例，来测试软件或系统的不同部分，从而发现更多的潜在缺陷。具体可以参见1.1.11节中关于杀虫剂现象的描述。

1.2.6　原则6：软件测试活动依赖于软件测试背景
针对不同的软件测试背景，进行不同的软件测试活动。比如，对通信系统的软件进行软件测试，与对嵌入式机顶盒系统软件的软件测试的方法是不一样的。

1.2.7　原则7：不存在缺陷（即有用系统）的谬论
假如系统无法使用，或者系统不能完成客户的需求和期望，发现和修改缺陷是没有任何意义的。