【1+X】软件测试的原则

想看更多内容请移步专栏

转载：【1+X】软件测试技术 - 软件测试的原则 - 蓝桥云课 (lanqiao.cn)

软件测试的原则

知识点

• 所有的测试最终都应该以用户需求为依据
• 应尽早开展软件测试工作
• 软件测试中的 Pareto 法则
• 程序员应该尽量避免测试自己编写的程序
• 穷尽测试是不可能的
• 软件测试是有风险的
• Good-Enough 原则
• 缺陷的集群现象
• 软件测试经常会有免疫现象发生
• 无法通过软件测试发现所有的软件缺陷
• 并非所有的软件缺陷都会修复
• 前进两步，后退一步

简介

笔者结合实际工作经验，总结了一些软件测试的基本原则，为初级入门者透彻了解软件测试行业规则和常识提供指导，避免多走弯路。

软件测试的原则

所有的测试最终都应该以用户需求为依据

软件测试的目的是寻找实际结果和预期结果之间的差异。从用户角度来看，最严重的错误就是那些导致程序无法满足需求的错误。如果系统不能完成客户的需求和期望，那么，这个系统的研发是失败的。通常，所有的测试都是依据用户需求来进行的，一旦在测试过程中发生争执，所有问题的解决都要依据需求说明中的规定，追溯用户需求。

应尽早开展软件测试工作

软件项目中 40%~60%的问题都是需求分析阶段埋下的“祸根”（Leffingwell 1997）。而软件项目在软件生命周期的各个阶段都可能产生错误。实践证明，缺陷发现的越早，修改缺陷的成本越低。随着时间的推移，修复软件缺陷的费用在成倍的增长，在维护阶段发现缺陷修复成本甚至是在需求阶段的 200 倍，如下图所示。

如同我们前面讲过的奥运票务系统因无法承受每小时 800 万次的流量而宕机的案例，如果早在编写需求说明书的时候就指出系统需要的最大性能指标，那么再配置设计和测试，付出的代价小得几乎可以不计，即便在开发的某一阶段发现该缺陷，其修复成本与最终奥运票务系统所承担的负面影响、投诉和新一轮的修改相比，也要低的多。可见，我们必须尽早地开始软件测试。

软件测试中的 Pareto 法则

Pareto 法则又称为 80/20 效率法则，是意大利经济学家帕累托提出的，可以适用于各行各业，在软件测试中，Pareto 法则暗示：

• 软件测试发现的 80%的错误很可能起源于 20%的程序模块。
• 也可以表示，在分析、设计、实现阶段的复审和测试工作能够发现和避免 80%的缺陷，而系统测试又能找出其余缺陷的 80%（其余 20%的 80%），最后 4%的软件缺陷可能只有在用户大范围、长时间使用后才会暴露出来。如下图所示。
• 软件测试只能够保证尽可能多地发现错误，无法保证发现所有的错误。

程序员应该尽量避免测试自己编写的程序

这一说法并不意味着程序员测试自己的程序不可能，我的言下之意是，让独立的第三方来构造测试会更加客观、有效，并容易取得成功。软件测试的目的是寻找错误，但是人们常具有一种不愿意否定自己工作的心理，认为揭露自己程序中的问题总是一件很不愉快的事情，这一心理状态就会成为程序员测试自己程序的障碍。仅次于上述心理学原因，如果程序员本身就对需求理解错了，那就会带着同样的误解来测试自己的程序，这种错误就根本不可能测试出来，这是人的思维定式导致的。而第三方测试一般都拥有专业成熟的测试技术，经验丰富。

穷尽测试是不可能的

即使是功能很简单的程序，其输入路径的组合数量也非常庞大。

例如计算器程序的测试，要测试加法、减法、乘法、除法、平方根、百分数和倒数等操作，加法又有两个数相加、三个数相加、四个数相加，……小数相加等等。

除了正常数字的加法需要测试之外，还要测试异常输入的时候，程序是否正确的进行了处理。比如通过键盘输入字母、特殊符号等。

输入的数据组合无穷无尽，即使使用全世界最先进的设备和工具来输入也无济于事。所以穷尽测试是不可能的，即使是最简单的程序也不行。

软件测试是有风险的

因为穷尽测试是不可能的，所以缺陷被遗漏的可能性永远存在，这就是软件测试的风险。例如计算器程序的测试中，如果选择不去测试 1000+1000=2000 会怎么样呢？有可能程序员碰巧在这种情况下留下了软件缺陷，然后客户在使用过程中碰巧就发现了这个缺陷。软件已经发布投入使用，再修复这种缺陷，成本是非常高的。怎么办呢？如何把数量巨大的可能测试减少到可控的范围，是我们软件测试人员应该学习的技能。

Good-Enough 原则

既不要做过多的测试，也不要做不充分的测试，这就是“Good-Enough 原则”，也就是说当软件测试到达一个“最优工作量”的时候就停止测试。如下图所示，有个明显的转折点，它就是我们说的“最优工作量”。在这个点之前，测试成本的投入能取得明显的效果，即发现的 bug 数与投入的成本有显著的正比例关系；在这个点之后，虽然投入的测试成本在增加，但发现的 bug 数却没有显著增加。实际工作中通过制定最低测试通过标准和测试内容，帮助我们尽可能在“最优工作量”附近停止测试工作。

程序中存在软件缺陷的可能性与该部分已经发现的缺陷成正比

通常一段程序中已发现的错误数越多，意味着这段程序的潜在错误也较多，这是软件缺陷的集群现象。软件缺陷和生活中的害虫“小强”几乎一样：都是发现一个，附近就可能有一群。有时，软件测试人员会在长时间内找不到软件缺陷。但找到一个之后就可能会找到更多。

为什么会出现这样的情况呢？因为人总是会反复犯下自己容易犯的错误，程序员也不例外。另外一个可能是，错误聚集的模块是软件的底层架构，这样的位置牵一发而动全身。

软件测试经常会有免疫现象发生

在软件测试中，免疫现象用来描述测试人员对同一测试对象进行的测试次数越多，发现的缺陷就会越来越少的现象。这是 1990 年，Boris Beizer 在其编著的《软件测试技术》第二版一书中提出的。

为了克服免疫现象，软件测试人员必须常常采用新技术，编写不同的测试程序，对程序的不同部分进行测试，以发现更多的缺陷。也可以引入新人来测试软件，往往新人能发现一些意想不到的问题。

无法通过软件测试发现所有的软件缺陷

软件测试是质量保证中的一环，只能保证尽量暴露软件中的缺陷。通过软件测试可以证明缺陷存在，但不能证明系统不存在缺陷。测试可以减少软件中遗漏的缺陷数量，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全没有缺陷的，软件测试无法揭示潜伏的软件缺陷。

并非所有的软件缺陷都会修复

在实际的软件测试项目中，经常会发生带着 bug 上线的情况，也就是说在上线之前并没有修复所有的缺陷。但这并不意味着软件测试人员未达到目的，或者项目小组将发布质量欠佳的产品。带着 bug 上线的原因通常有几个：

• 到项目发布时间了，没有足够的时间修复缺陷了。
• 不是真正的软件缺陷，而是理解错误或测试错误或者说明书变更导致的。
• 修复一个缺陷，有可能会引入更多或者更严重的缺陷。在紧迫的产品发布进度压力下，修改软件缺陷将冒很大的风险，除非重构。暂时不去理睬这种软件缺陷是比较明智的做法。
• 一些随机缺陷或者出现在不常使用的模块中的软件缺陷是可以暂时放过的，等以后有时间的时候再修复或者根本不修复。

前进两步，后退一步

这是指修复软件缺陷，总会以 20%~50%的几率引入新的缺陷，所以整个过程是前进两步，后退一步的。通过合理的回归测试可以有效的解决部分这种问题。

小结

本章需要掌握的是软件测试的每一项原则的含义，学会灵活运用。这些原则在实际工作中应用极其普遍，而且在笔试题和面试题当中也经常会有涉猎。