刘柯宏，刘晓建

（1.西安市第26中学，陕西 西安 710001；2.西安科技大学 计算机学院，陕西 西安 710054）

0 引言

在航天、核电、金融、军事等安全攸关领域，人们对软件的安全可靠性提出了很高要求[1,2,3]。软件安全性是指避免危险条件发生，保证人员、设施等免于遭受灾难性事故或重大损失的能力，软件可靠性是指软件在规定条件下，在规定的时间内完成规定任务的能力[4,5]。软件缺陷是影响软件安全性和可靠性的重要因素。研究软件缺陷的基本性质，发掘软件缺陷的内在规律，对于提高软件的安全性和可靠性，对于保障软件系统的安全可靠运行具有重要意义。

目前为止，人们对软件缺陷的性质以及内在规律的研究仍具有一定局限性。主要原因是，关于软件缺陷的一手数据资料很不全面。传统的软件开发局限在特定的机构中，软件缺陷的记录、跟踪和排除作为机构的技术资料一般并不对外公开。对于不成熟的开发机构，开发过程中软件缺陷的记录和跟踪资料并不完整。由于软件缺陷数据的欠缺和不完整，使得人们很难从宏观和统计的角度发掘软件缺陷的基本性质和基本规律[12,13]。近年来，由于开源代码和软件库的出现，使得开源程序的缺陷得以记录和跟踪，并通过缺陷库对外公开，这就为有关软件缺陷的研究提供了第一手数据资料，并为使用定量分析手段发现软件缺陷的宏观性质和规律提供了数据基础[6,11]。

本文首先明晰软件缺陷的基本概念，然后分析互联网上几个重要的软件缺陷库，然后在这些缺陷库的基础上使用数据分析方法试图发现一些软件缺陷的性质和规律。这一研究工作对于人们认识软件缺陷的规律，并在开发中避免和排除软件缺陷具有重要意义。

1 软件缺陷

SW-CMM对软件缺陷的定义是：“系统或系统成分中使得这些系统无法实现其所要求的功能的缺点；如果在执行过程中遇到缺陷,它可能导致系统的失效”[7]。软件错误(Error)、软件故障(Fault)、软件失效(Failure)、Bug、问题(Problem)等概念不完全等同于软件缺陷：软件错误一般指在软件开发过程中的一些人为的技术性错误；软件缺陷，即通常提到的Bug，表示软件存在不足，不能完全符合软件开发要求；软件故障一般指在软件运行过程中出现了执行错误，使软件不能正常运行，而软件失效是指软件在运行过程中不能完全执行既定的操作。软件故障和失效都是软件缺陷的一种外在表现[8,17]。

软件缺陷开始时处于休眠状态，只有在特定条件下，软件缺陷才能被激活。在构件化或模块化软件中，一个构件（或模块）中的缺陷被激活后，会在构件内部引起状态偏差，这种偏差随着程序的运行在构件内部不断传播，最终传播到构件的输出接口。当另一些构件使用这些输出接口时，这些状态偏差就会进一步传播到这些构件中，导致这些构件或软件系统发生故障或失效。我们把软件缺陷的这一传播过程成为软件缺陷的“威胁链”[18,19]。

软件缺陷的分类方法主要有：Putnam等人提出的简单分类法；国家军用标准GJB2437的软件错误分类方法；Thayer等人提出的利用软件错误性质分类方法，以及美国IBM公司提出的正交缺陷分类法等[9]。简单分类方法一般将软件缺陷分为需求缺陷、设计缺陷、算法缺陷、性能缺陷、文档缺陷和界面缺陷等六大类；国家军用标准GJB2437根据军用软件的软件错误来源，将软件缺陷分为程序错误、文档错误、设计错误三类；IBM正交缺陷法（ODC）从七个方面对缺陷进行了分类，即赋值、检验、算法、时序、接口、功能、关联。根据软件缺陷对软件所产生的影响程度的不同，把软件缺陷的严重性级别分为轻微、一般、严重和致命。

2 软件缺陷数据库

为了记录开发过程中的软件缺陷，并进行有效的分析，需要形成软件缺陷数据库。比较典型的软件缺陷数据库有：NIST、Bugtrap和Bugzilla[10]。NIST是由美国国家标准与技术研究院提供的一个软件缺陷数据库，提供了通用缺陷列表以及为部分代码缺陷模式所编写的测试用例。BugTrap软件缺陷数据库是由Security Focus公司开发并维护的软件缺陷数据库，为用户提供了5种检索方式[15]：软件提供商、标题、关键字、BugTrap ID和CVE ID。Bugzilla软件缺陷库，是一个开源的软件缺陷跟踪系统，为开发和测试工作以及产品质量的度量提供数据支持，可以很好的管理软件开发过程中软件缺陷的整个生命周期[16,20]。

为了更好的分析软件缺陷的性质，发掘其规律，需要了解软件缺陷的描述。下面以Bugzilla为例，介绍描述软件缺陷的各个属性，如表1所示。

在上述属性中，严重性级别、提交后的状态和最终处理状态对于分析软件缺陷具有特别重要的意义。

软件缺陷的严重性级别分为5类： normal（正常）、low（低级）、high（高级）、blocking（阻塞）和enhancement（增强）；软件缺陷的提交状态被分为5类：New（该缺陷有效，但未进行处理）、Assigned（该缺陷将由特定的维护者处理）、Reopened（新维护者对已经修改的缺陷进行再次处理）、Resolved（该缺陷已被某维护者处理并且没有新的缺陷产生）和Needinfo（表示需要提供更多的信息才可以妥善解决该软件缺陷）；而最终处理状态也被分为5类：Fixed（该缺陷被认为有效且被维护者进行了有效处理）、Wontfix（表示缺陷无法修复，可以忽略，不会对系统产生影响）、Invalid（表示缺陷是无效的）、Duplicate（表示相同的缺陷报告被不同的维护者重复提交）和Worksforme（表示不会重复出现的缺陷）。

表1 软件缺陷的属性Table 1 The properties of software defects

3 研究方法

采用统计方法研究开源软件的缺陷基本特征和规律。研究步骤包括：（1）选择具有代表性的开源软件作为研究对象；（2）获取这些开源软件的软件缺陷数据；（3）对缺陷数据进行处理，得到软件缺陷的分布以及演变状况；（4）试图通过软件开发过程以及软件结构来解释统计结果，形成对软件缺陷基本规律的认识。下面分别对前三个步骤进行展开。

选取Linux、Firefox和Tomcat三种大型开源软件作为研究对象，一是它们具有较强的代表性，分别代表了操作系统、浏览器和Web服务器这三类最常用的基础软件；二是规模较大，开发过程较成熟，因此从中获取的缺陷数据具有较好的代表性；三是它们的缺陷数据较为丰富，便于发挥统计分析方法的优势。

采用Bugzilla作为获取缺陷数据的主要来源。Bugzilla保存的缺陷数据较为完整，数据查询接口易于使用。实际上，对于很多软件缺陷，都有统一的CVE编号，这就使得软件缺陷可以跨越不同数据库得到标识和共享。

软件缺陷数据处理主要包括两个维度：缺陷数量统计和软件版本。缺陷数量统计分为总数统计和分属性统计，即按照缺陷的严重性、提交后的状态以及处理状态分别进行数量统计。另外，为了分析缺陷数量的动态变化规律，还需要统计各个版本的缺陷数量。

图1 Tomcat、Firefox与Linux三者缺陷数量随版本变化的趋势Fig.1 The number of software defects of Tomcat, Firefox and Linux, and their variations with version change

4 分析结果

根据研究步骤，从Bugzilla中获取了Linux、Firefox和Tomcat各个版本的缺陷数量总计约13,420条。图1是这三类开源程序的缺陷数量随版本变化的情况。

从中可以看到三者的缺陷数量整体上逐渐降低并最终逐渐趋于平稳，即随着软件版本的不断升级、产品的不断稳定，软件的缺陷率会呈下降趋势，但是局部仍存在波动。

选取了Status、Resolution和Severity三个属性，分别统计了不同属性的缺陷数量，如表2所示。

表2 分属性缺陷数量统计Table 2 Statistics for the typical properties of software defects

从统计数据可见，三种开源程序中，约90%的缺陷已经得到了解决（Resolved），约50%的缺陷确认为有意义并得到了修改（Fixed），还有约50%的缺陷是无效的（Invalid和其他）。这一数字与实际开发是吻合的。比如在一个大型商业软件的第三方测试中，软件缺陷报告中的547条缺陷中最终只有265条被开发部门认同并修改，这个比例为48%[11]。另外，大约只有50～70%的软件缺陷都是中等严重性的（Normal），高严重性的缺陷只占10～20%，剩下的缺陷都是低严重性的。

通过上面这些统计数据，大致可以得出结论：在软件产品的软件缺陷报告中通常有近乎50%的软件缺陷是处于无效状态的，即这些缺陷不需要修复，也不会对软件造成大的影响。因此，如果能够对软件缺陷报告数据先进行一定的数据预处理，去除掉重复或无效的软件缺陷，将会有利于软件开发周期的缩短和软件开发成本的降低。

通过对Bugzilla缺陷库中13,420条软件缺陷报告的分析和总结，研究发现造成软件缺陷的原因有很多，主要归结为以下几点：

（1）软件构件的变化。主要有软件构件数目、规模大小等因素。即使构件本身没有缺陷，当它被引入时，在一定程度上可能会引起缺陷。比如，在版本7.0以前，Tomcat的Connectors构件的缺陷数目一直保持着0水平，而在版本7.0之后开始呈现出正常的波形状态，这是由于版本7.0之前Connectors这个构件并没有被引入，而是在此之后新加入的软件构件，这引起了软件构件数量和规模的变化，一定程度上引入了新的缺陷。

（2）程序代码编写错误。这与开发人员的能力和经验有关，即便能力再高、经验再丰富的开发人员所编写的软件也一定会有程序缺陷出现。

（3）程序编写不规范。在软件程序的编写过程中，需要大量的开发人员和测试人员相互配合，因此需要程序编写有统一的规范，否则就会带来相互不理解、“各编各的”现象，带来不必要的软件缺陷。

（4）软件功能模块的复杂化。由于软件的功能不断增多，致使软件的结构也在不断增大，变得越来越复杂，进而会给软件的质量产生影响。例如，在100行的程序代码中，程序缺陷的数量和代码的行数是成线性的关系，但如果超过100行，程序缺陷的数量则和代码的行数成指数的关系。因此，软件越庞大，软件缺陷也就越多。

5 结论

本文首先介绍了Bugzilla、NIST、BugTrap等三种软件缺陷库及其查询接口，针对Tomcat、Firefox和Linux三个开源软件，分析了软件缺陷总数随不同版本的变化过程，统计了软件缺陷几项重要属性的分布规律，在此基础上归纳了造成软件缺陷的几项重要原因。通过对软件缺陷性质和规律的研究，为软件缺陷的预防和发掘起到指导性作用，从而在一定程度上提高软件可靠性和软件安全性。下一步的工作将集中于两点：一是获取大量的一手缺陷数据，在此基础上更细粒度的分析软件属性的分布及变化规律；二是研究软件结构变化与软件缺陷之间的关系，从而能够对引起缺陷的软件内部结构因素得出有意结论。

[1] 窦真兰，杜凤青. 电力系统节能策略和方法分析[J]. 新型工业化. 2015，5（10）：1-6.DOU Zhen-lan;DU Feng-qing，Research on the Energy-saving Strategies and the Methods for Power System[J].The Journal of New Industrialization. 2015，5（10）：1-6.

[2] 牛成林. 基于数据仓库的数据挖掘的电站决策支持系统[J]. 新型工业化. 2017，17（7）：62-67.NIU Cheng-lin. Operation Optimization Decision Support System in Power Plant Based on Data Warehouse and Data Mining[J]. The Journal of New Industrialization. 2017，17（7）：62-67.

[3] 王峰. 物联网数据处理若干关键问题[D]. 吉林：吉林大学，2016.WANG Feng. Research on Several Key Issues in Data Processing in the Internet of Things[D]. Jinlin：Jinlin University，2016.

[4] 朱媛媛.软件安全性测试与评估方法研究[D].江苏：江苏大学，2013.ZHU Yuan-yuan. Research on software security testing and evaluation method[D]. Jiangsu：Jiangsu University，2013.

[5] 黄锡滋.软件可靠性、安全性与质量保证[M].北京：电子工业出版社，2002.HUANG Xi-zi. Software reliability，security and quality assurance[M]. Beijing：Electronic Industry Press，2002.

[6] 周明辉，郭长国. 基于大数据的软件工程新思维[J]. 中国计算机学会通讯，2014，10（3）：37-42.ZHOU Ming-hui，GUO Chang-guo. New thinking of software engineering based on big data[J]. Communications of Chinese Computer Society. 2014，10（3）：37-42.

[7] Park C Paulk，et al. Capability Maturity Model for Software[R].Pittsburgh，Pennsylvania：Carnegie Mellon University，1993.

[8] Avizienis A，Laprie J C，Randell B，et al. Basic concepts and taxonomy of dependable and secure computing[J]. IEEE Transactions on Dependable and Secure Computing. 2004，1（1）：11-33.

[9] Ram Chillarege，et al. Orthogonal Defect Classification：A Concept for In-process Measurements[J].IEEE Transactions on Software Engineering. 1992，18（11）：943-956.

[10] https：//www.bugzilla.org/

[11] 李宁，李战怀.软件缺陷数据处理研究综述[J].计算机科学.2009，36（8）：21-25.LI Ning，LI Zhan-huai. Overview of Software Defect Data Processing Research[J]. Computer Science. 2009，36（8）：21-25.

[12] 郁抒思，周水庚，关佶红.软件工程数据挖掘研究进展[J].计算机科学与探索. 2012，6（1）：1−31.YU Shu-Si，ZHOU Shui-geng，GUAN Ji-hong. Software engineering data mining：A survey[J]. Journal of Frontiers of Computer Science and Technology. 2012，6（1）：1−31.

[13] 原子，于莉莉，刘超.面向细粒度源代码变更的缺陷预测方法[J].软件学报. 2014，25（11）：2499−2517.YUAN Zi，YU Li-li，LIU Chao. Bug prediction method for fine-grained source code changes[J]. Journal of Software. 2014，25（11）：2499−2517.

[14] 王青，伍书剑，李明树.软件缺陷预测技术.软件学报[J]. 2008，19（7）：1565−1580.WANG Qing，WU Shu-jian，LI Ming-Shu. Software defect prediction[J]. Journal of Software. 2008，19（7）：1565−1580.

[15] 哈清华，姜瑞凯，刘逻. 软件缺陷的生成因素分析[J]. 计算机技术与发展，2016，26（1）：1-5.HA Qing-hua，JIANG Rui-kai，LIU Luo. Analysis of Forming Factors in Software Defect[J]. Computer Technology and Development，2016，26（1）：1-5.

[16] 王婧宇，张欣，邹卫琴. 基于分类的软件缺陷严重性预测[J]. 计算机与数字工程. 2016，44（8）：1532-1536.WANG Jing-yu，ZHANG Xin，ZOU Wei-qin. Severity Predication of Software Defects Based on Classification[J]. Computer and Digital Engineering. 2016，44（8）：1532-1536.

[17] 陈翔，顾庆，刘树龙等. 静态软件缺陷预测方法研究[J]. 软件学报. 2016，27（1）：1-25.CHEN Xiang，GU-Qing，LIU Shu-long. Survey of Static Software Defect Predication[J]. Journal of Software. 2016，27（1）：1-25.

[18] Ricky，Michael Yoseph，Fredy Purnomo，and Budi Yulianto. Mobile Application Software Defect Prediction[C]. Service Oriented Software Engineering（2016）：307-313.

[19] Lanza，Michele，Andrea Mocci，and Luca Ponzanelli. The Tragedy of Defect Prediction，Prince of Empirical Software Engineering Research[J]. IEEE Software，2016，33（2016）：102-105.

[20] Vashisht，Vipul，Manohar Lal，and G. Sureshchandar. A Framework for Software Defect Prediction Using Neural Networks[J]. Journal of Software Engineering and Applications. 2015，28（8）：384-394.