2.3　软件潜在缺陷

软件bug或缺陷有很多来源和起因。为预测未来bug的数目，拥有度量现有项目和历史项目中所有bug来源的准确方法是很必要的。

因为大多数公司缺乏良好的质量和bug历史数据，所以他们不可避免地依赖于从同类公司获得的综合数据，或是质量估算工具的预测。本章提供的信息可以用来预测缺陷，但是由于牵涉的变量太多，因而含有质量估算功能的商业软件估算工具才是最好的选择。

表2-1试图给出影响软件应用程序的所有缺陷来源的近似平均值。根据应用程序的规模、团队技能、CMMI级别、方法论、认证的可重用材料以及其他因子的不同，这些平均值的范围从大于3到1不等。

由于缺乏数据库卷、网站和测试库的标准规模的度量方法，有些平均值有重大的错误幅度。作为替代，所有规模数据都是基于正被开发或维护的软件应用程序的假定规模的。这并不是一个理想的假设，但是它却便于以一种度量方法来表述所有形式的缺陷，并给出每种来源间的相对比例。

表2-1中的技术假设是CMMI 1级和传统的瀑布式开发方法。本书后续会讨论并说明其他可选的假设，如更高的CMMI级别和可选的开发方法（如敏捷、RUP和TSP）。表2-1中的数据来源于1973—2010年调查的13000多个项目。

表2-1与本书一位作者之前的著作中类似的表不同，比如Software Assessments，Benchmarks,and Best Practices（Jones 2000）^[1]、Estimating Software Costs（Jones 2007）^[2]、Applied Software Measurement（Jones 2008）以及Software Engineering Best Practices（Jones 2010）。先前这些书籍只讨论了需求、设计、编码、文档和不良修复等5种来源的缺陷。本书讨论了8种来源的缺陷。此外，在本书中不良修复缺陷没有作为一个单独的类别而是包含在这8种缺陷来源里。不过，不良修复中的平均不良修复注入率仍然有近7%。

表2-1说明了软件缺陷的所有可能来源，它们集合在一起组成了现代软件应用程序的“潜在缺陷”。

正如表2-1所示，现代的应用程序确实会含有多种来源和起因的缺陷。实际上，对于规模大于100个功能点或5000个源代码语句的应用程序而言，编码缺陷占缺陷总数的比例小于20%。

潜在缺陷随着应用程序的规模而增长。20世纪50年代人们就了解到了这一事实，并通过度量数千个应用程序而进一步证实了它，这些应用程序的规模从10个到300000多个功能点不等。然而，需求缺陷和设计缺陷的增长速度比编码缺陷要快。表2-2给出了规模在10个到100000个功能点间的应用程序的平均潜在缺陷。

测试主要关注于编码缺陷。但是在大型系统和应用程序中，编码缺陷不是最重要的问题来源。编码缺陷也是最容易消除的。在大型系统中，需求缺陷、架构缺陷和设计缺陷才是质量问题最重要的来源。当然，大型数据库和网站也有严重的质量问题。

现代商业应用程序已经变得如此复杂，以至于它们被分解为几个不同的子系统或层次，被使用不同的编程语言构建在不同的软件平台上。毫不奇怪，美国国家科学研究委员会（National Research Council）的一项对“可信软件”的研究指出，测试已经不足以保证应用程序是可靠、高效、安全和可维护的（Jackson，2009）。为降低这些多层应用程序的商业风险，在度量和控制应用程序质量和可信性（dependability）方面，有必要进行静态分析，作为对测试的补充。

大多数导致系统中断、性能下降、安全漏洞和过高维护费用的缺陷，不再能隔离在单个文件或者某段代码里（Hamill，2009）。最严重的问题发生在应用程序各层间的交互中。更具有挑战性的是，这些缺陷不是导致无法满足客户提出的功能性需求的缺陷，而是应用程序的架构或源代码中的非功能性缺陷（Spinellis，2007）。测试用例通常设计用于检查功能性缺陷。要找出运行时能造成最严重损失的缺陷，需要分析应用程序的结构质量——其内部结构和工程特性的完整性。

和动态估算正好相反，在已出版的书中存在的一个问题是，这些书并未涉及多个并发因素。预测软件潜在缺陷是一项高度复杂的工作，它包括：

●客户对自身需求的理解；

●团队在类似应用程序上的技能；

●用于缺陷预防的方法；

●测试前的缺陷清除方法；

●代码的圈复杂度；

●测试用例设计方法；

●测试覆盖率；

●测试库控制方法。

这里列出的每一个因素都以某种方式对软件潜在缺陷个数有大约20%的影响，并且它们可以同时起作用。

[1]中文版：《软件评估基准测试与最佳实践》，机械工业出版社，2003。——译者注

[2]中文版：《软件项目估计（第2版）》，电子工业出版社，2008。——译者注