软件缺陷分析技术的研究

杨勋姮，段明璐

（华北计算技术研究所 软件测评中心，北京 100083）

0 引言

随着技术的不断发展和人类文明的不断进步，以软件为基础的产业发展迅猛，软件已经由以往的单一结构逐渐向复杂结构转变，航空航天等领域武器装备系统的结构复杂度不断提高，对系统进行缺陷分析是变得越来越重要的。

从开始进入软件领域，我们就一直被反复教导一个由无数惨痛教训总结出的道理：缺陷在研发过程的越早期被发现，其造成的影响和修复带来的成本就会越低[1]。

曾经有研究显示，如果在需求分析阶段发现并修复一个缺陷的成本为 1，在编码实现阶段发现并修复缺陷成本就增长到了15，而到了测试阶段一跃而升变为35，如果到了最终交付用户使用后才发现并修复，成本甚至可以到75。对于不同阶段注入的单位缺陷，修复成本和发现阶段的关系如图1所示：

从图1可以看出，项目开发后期修复缺陷的成本已经高到了初期修复成本的75倍，而且返工次数也随着项目进行而大幅提高。如果在交付用户后发现了一个缺陷需要修复，必须要重新修改设计和编码，然后再次进行评审和测试。

为了达到这些需求，本文首先会介绍软件缺陷分析的相关知识，然后列举目前主流的软件缺陷分析方法进行一一进行阐述，最终将六种缺陷分析方法综合进行比较。

图1 缺陷的成本与发现阶段的关系Fig.1 The relation of defect cost and found phase

1 缺陷分析技术的研究

1.1 软件缺陷相关概念

软件缺陷（software defect）是指在软件开发周期中软件产品产生的缺陷和不足，会导致实际运行结果与预期结果产生偏离。SW-CMM 给出的定义是：“系统中存在使其功能无法按需完成的缺点。执行过程中缺陷的产生会导致系统失效”。[2]

软件缺陷表达的含义非常宽泛，站在软件用户的角度来看，系统中一切不能完成用户需要的功能、不能满足标准规范要求、造成使用上的不便等缺点都是软件缺陷；而站在开发者的角度，软件缺陷不仅对用户的使用有影响，也会造成项目延期和超支。

下面介绍几个与软件缺陷相关的术语[3]。如软件错误、软件故障、软件失效，他们之间存在着紧密的联系。

（1）软件错误：Error，是指整个软件的生存周期中存在于软件设计、文档、程序代码或数据结构等载体中的不正确信息。软件错误是人为引起的，经过一定条件的催化，必然会引起软件故障。

（2）软件故障：Fault，是指软件本身没有按照用户所期待的正确结果进行表现，是软件运行时展现出来的一种不可接受的内部状态[4]。我们可以把它看做一种能导致软件错误产生的缺陷，这是一种动态行为。

（3）软件失效：Failure，是指软件在运行时产生出的无法被用户接受的外部行为结果[5]。例如：功能执行能力的丧失；系统失去在限度内按要求执行功能的能力；程序的实际操作与需求发生偏离等。

1.2 软件缺陷属性及分类

软件缺陷的属性有很多种，常见属性包括：缺陷标识、缺陷严重性、缺陷来源、缺陷类别、重现的频率、产生原因等等[6]。依据缺陷拥有的不同属性，可以有多种的分类方法，如通过缺陷标识进行分类、通过缺陷严重性进行分类、通过缺陷来源进行分类、通过缺陷类别进行分类、通过缺陷状态进行分类等。

首先，介绍一些常见的缺陷分类标准：

（1）缺陷的严重性

主要是不同程度的缺陷对系统和用户造成的影响，如表1所示。

（2）缺陷的起源

主要是指缺陷引发的系统故障第一次被发现所处的阶段，如表2所示。

（3）缺陷的来源

主要是指缺陷产生的位置，如代码、文档等，如表3所示。

（4）缺陷的根源

主要是指导致缺陷产生的根本原因，如表4所示。

（5）缺陷的类别

主要是指依据缺陷的表现形式和影响对缺陷本身进行的分类，如表5所示。

（6）缺陷的优先级

主要是指依据缺陷造成的影响来判别处理缺陷的优先顺序，优先级最高的缺陷并不一定是最严重的问题，而是当前影响最大的问题，因此缺陷的优先级与严重性并没有必然联系。如表6所示。

表1 软件缺陷的严重性分类Tab.1 The classification of software defect severity

表2 软件缺陷的起源分类Tab.2 The classification of software defect origin

表3 软件缺陷的来源分类Tab.3 The classification of software defect source

（7）缺陷重现的频率

主要是描述缺陷再次出现的可能性。如表7所示。

（8）缺陷状态

主要是描述缺陷在整个项目开发过程中的生命周期，从发现到被处理而被描述的状态。如表8所示。

下面，我们再对几种典型的缺陷分类方式[7]进行介绍：

（1）国军标分类：GJB437是我国的国家军用标准，在标准中依据在大量军用软件中发现错误的来源，将缺陷分为三大类：文档缺陷、程序缺陷和设计缺陷[8]。

（2）IEEE（电气和电子工程师学会）的异常分类标准：这个标准对软件生命周期中每个阶段发现缺陷的处理方式进行了描述，使用者还可以通过标准提供的相关数据对缺陷造成的异常进行识别和跟踪。

（3）IBM 的缺陷预防分类方案：1990年由R.G.Mays等人提出，这个方案对缺陷引入的消除效果较好。主要使用因果分析法对缺陷进行多次分类，直到找到问题引入的根源，这种分类方法非常简单。

表4 软件缺陷的根源分类Tab.4 The classification of software defect root

表5 软件缺陷的类别分类Tab.5 The classification of software defect category

表6 软件缺陷的优先级分类Tab.6 The classification of software defect priority

表7 软件缺陷重现的频率分类Tab.7 The classification of software defect repeat frequency

（4）IBM 的正交缺陷分类[9]：由 IBM 公司提出，该分类法定义了彼此正交的八个属性对缺陷特征进行描述，八个属性可对应到缺陷的发现和修复这两类活动中，该方法分类细致，并可适用于多种情况。

1.3 软件缺陷分析方法

在建立缺陷分析模型或者分析缺陷时，可以用到的分析方法[10]主要有根本原因分析法、缺陷分布分析法、缺陷注入-发现矩阵分析法、DRM（defect removal model analysis）分析法、ODC（orthogonal defect classification）分析法和软件故障树分析法。下面对这些方法进行简单的分析和比较。

表8 软件缺陷状态分类Tab.8 The classification of software defect state

1.3.1 根本原因分析法

Root Cause Analysis，简称为RCA。该方法的基础是鱼骨图和柏拉图等，通过分析产生缺陷的根本原因来采取相应的措施和方法，以提高开发和测试过程的工作效率。

根本原因分析法主要有以下使用场景：

（1）首先从各类评审和各级测试中收集缺陷，通过分析缺陷在产生的功能模块上的分布情况，掌握相对质量较差的模块有哪些，在测试时加以关注重点进行覆盖。

（2）然后对缺陷进行分类，依据分类的分布情况挑出其中最重要的缺陷类型，之后对此类缺陷使用鱼骨图[11]、柏拉图[12]等方式进行分析后找到它产生的根本原因，针对该种原因制定相符合的纠正措施，可以减少该类原因的产生。

（3）对找到的缺陷根本原因生成缺陷分布报告，依据根本原因的分布情况进行分析，可以提高软件质量。

通过本方法对大量数据进行分析后发现，软件缺陷产生的根本原因可能包括以下几种：

（1）需求类文档问题：需求类文档存在歧义、不详细、不一致的情况导致。

（2）系统设计问题：架构设计或模块设计考虑不周全，或与需求不一致导致。

（3）程序编码问题：编码人员编码错误。

（4）维护问题：软件版本变更时修复缺陷却引发了新的问题。

（5）实施问题：安装部署使实施人员安装或设置不当导致产生的问题。

（6）升级问题：软件版本升级时由于未完全按照操作规程实施导致软件升级不正确或不完全引发的缺陷。

（7）外部问题：软件运行环境中的软硬件导致的缺陷，可能包括硬件、操作系统、数据库、办公软件等等。

（8）沟通问题：开发组成员沟通不明确或理解出现不一致导致。

1.3.2 缺陷分布分析法

缺陷分布分析法就是依据软件缺陷的属性，如缺陷严重性、缺陷起源、缺陷来源、缺陷根源、缺陷类别等，对收集到的缺陷数据进行分布统计，以便于获取到缺陷分布反映出的软件情况，从而为提高软件质量提供依据。下面举几个通过不同属性分布进行分析的例子：

（1）缺陷按缺陷起源的分布。通过这种方法可以分析出来自于不同起源的缺陷是否有效、注入率等信息，可以用来衡量项目各阶段相关人员的水平及状态。缺陷起源一般包括需求、构架、设计、编码、测试、用户等。

（2）缺陷按缺陷严重性的分布。通过这种方法可以了解到处于各严重性等级的缺陷数量及其比例等信息，针对不同水平的软件制定相应的改进措施。缺陷严重性一般包括宕机、严重、重要、次要、无关紧要等级别。

（3）缺陷按缺陷根源的分布。通过这种方法可以了解到产生缺陷的根本原因是什么，并针对这些潜在的问题进行纠正。缺陷根源一般包括测试策略、过程工具和方法、团队、组织、软件、硬件等等。

1.3.3 缺陷注入-发现矩阵分析法

缺陷注入-发现矩阵分析法主要是依据缺陷属性中的“注入阶段”和“发现阶段”，通过绘制“缺陷注入-发现矩阵”对开发项目过程中的各环节质量进行分析，查明哪些环节是最需要进行改进的。

缺陷注入-分析矩阵表（表9）中行表示缺陷按照起源分类后在各个阶段进行统计得出的缺陷数，矩阵的列表示该阶段注入的缺陷遗留到后续各阶段的缺陷数。

表9 缺陷注入-发现矩阵Tab.9 Software defect matrix

本阶段缺陷清除率的含义是本阶段通过各种措施对软件质量进行控制后实施成效的反映。本阶段缺陷清除率用 表示，本阶段发现的缺陷数用 表示，本阶段注入的缺陷总数用 表示，计算公式为：

在需求阶段，总计注入200个缺陷，但在需求评审时只发现其中的35个，可以得出：需求分析阶段的缺陷清除率 为：

而且通过对表9的矩阵深入研究，可以发现编码实现阶段产生的缺陷大部分是在系统测试阶段才发现并进行修复的，这也就说明，系统测试之前的单元测试和集成测试活动必然进行的不够充分，从而使缺陷遗留到了后续阶段。

需求分析阶段注入的缺陷大部分是在设计评审时在被发现，分析结果表明这可能是由于需求本身稳定性和清晰度存在问题造成的，因此在设计评审时不能只是单纯评审设计，也需要同时软件需求规格说明与设计对照，互相进行验证，甚至可利用需求追溯查找到上级需求文档的中可能存在的问题。

1.3.4 DRM分析法

DRM（defect removal model analysis）分析法主要是通过对缺陷排除数据进行有效性分析，来验证各个阶段的测试情况是否充分。该方法是通过历史项目的数据，得出软件研发过程中各阶段对软件缺陷注入和排除的模型。

首先介绍一下缺陷率的通用概念，即缺陷数与错误概率在一定时间段内的比值，但这又与产品类型和发布前后不同时段均有关系。比如应用软件在发布后两年内可以发现90%以上的缺陷，而操作系统却至少要在产品发布后4年才能发现90%以上的缺陷。

（1）整体缺陷清除率

整体缺陷清除率是用来对整体缺陷排除能力进行分析的工具之一。

首先假设F为软件全部的功能点，D为发现的总缺陷数， D = D1 + D 2，其中， D 1为在整个软件研制过程中发现的全部缺陷数，D 2为软件发布后用户使用中发现的缺陷数。如果A系统规模为200个功能点，在研制过程中发现130个缺陷，发布后用户反馈了 24个错缺陷，则： D 1= 1 30， D 2 = 2 4，

据不完全统计，美国平均的整体缺陷清除率已经可以达到85%以上，其中一些具备良好管理体系的著名软件公司生产的主流软件产品的确信清除率甚至超过了98%。

（2）基于阶段的缺陷排除分析

基于阶段的缺陷排除分析又被称之为 DRM 模型，共涵盖了3种度量关系，包括缺陷注入、缺陷排除和有效性。该模型通过输入一组阶段有效性和一组错误注入率为DRM建模。

通过表 10的注入-发现矩阵，我们介绍一下DRM模型。

这个项目中由于特殊原因没有进行正式需求评审，因此矩阵中没有需求评审相关数据，但这并不意味着需求阶段注入缺陷的可能性会变小。接下来我们通过计算将矩阵进行简化，得到表11。

其中，阶段出口处缺陷数＝前一阶段的遗留缺陷数＋本阶段注入缺陷数－本阶段排除的缺陷数。

由此可见，通过 DRM 模型可以直接地对阶段缺陷排除能力进行有效的分析。

1.3.5 ODC分析法

ODC分析法（orthogonal defect classification）按不同维度对每个缺陷进行分类，目前共包括有 8个维度[13]，共114类，具体参见表12。

表10 缺陷矩阵分析表Tab.10 Software defect matrix analysis

表11 缺陷排除有效性结果Tab.11 The result of defect elimination effectiveness

ODC中的各维度关系如图2所示。

正交缺陷分类实际上就是对缺陷进行分类，基于这些分类实施过程改进。ODC分类法与其他分析方法相比，分类更为详尽。其特点如下：

（1）正交缺陷分类定义的八个属性彼此正交，每个属性的所有取值都是彼此正交的，也就是说分类之后信息不会重叠且统计结果也相对是可以独立的，这样就可以对缺陷进行定量的全面描述。

（2）正交缺陷分类适用于所有缺陷类型，经过正交分类的缺陷几乎覆盖了各个方面，因此可以为过程改进分析提供更多角度进行考虑。与RCA这种定性的分析相比，ODC更能完整的把握缺陷的全部信息，从而更全面的分析出缺陷产生的根本原因，更好的做到缺陷预防。

（3）由于正交缺陷分类法是贯穿软件开发过程的各个阶段的，对每一阶段的缺陷信息都会使用统一属性进行分类定义，因此缺陷的type属性可以适用于任何阶段，甚至可以反映出某个阶段展现出的特定特性，为开发过程的改进提供服务；通过缺陷的trigger属性和各阶段情况，可以表现出缺陷触发后的修复情况，为确认过程的改进提供服务。

（4）正交缺陷分类法不依赖于产品的特性、产品开发的工程模型或过程方法。它不依赖于某个产品的特性，不依赖于软件开发的工程模型。对于不同的软件产品，如果都是用ODC分类，那么他们的分析标准是统一的，这样就保证了产品之间的比较是公平的，是站在同一起跑线上的。

1.3.6 软件故障树分析法

20世纪80年代，软件故障树分析法（Software Fault Tree Analysis，简称SFTA）由硬件移植到软件领域，其主要功效是用来分析系统的安全和可靠性，是一种由上向下的分析方法，通过这种方法，可以将导致缺陷产生的各种基本事件逐一分析出，并确定这些基本事件对缺陷影响的大小，还可以依据各基本事件发生的概率计算出缺陷发生的概率，从而确定缺陷集中的模块或是可能产生严重问题的模块。软件故障树分析法就是将需要分析缺陷的故障模式作为分析目标，也就是故障树的顶事件，然后查明导致这一故障产生的全部直接因素，再继续找出造成这些直接因素的下一级直接因素，直到找到再继续分解的因素为止。

表12 正交缺陷分类Tab.12 Orthogonal defect classification

图2 ODC中的维度关系Fig.2 The relation of ODC dimension

故障树分析法的优点是因果关系清晰，通过故障树可以直观全面的看到导致故障产生的各种因素和其逻辑关系，从而可以指定相应的改进措施。依据建立出的故障树，可以进行定性分析、定量分析和系统评价。通过定性分析，可以找到决定顶事件发生的各因素，并了解到解决他们的优先顺序，从而为制定对应解决方案提供依据。通过定量分析，可以依据各因素的发生概率计算出顶事件的发生概率，为软件的整体质量评估做一个量化评价。

故障树分析法的缺点是进行发生概率推测的能力较弱，且只能对针对单个缺陷本身进行分析，而不能对整个过程和系统进行全面分析，在分析的过程中很多步骤需要依赖于分析人员的主观判断，这也就导致不同分析人员的分析结果可能不尽相同，统一性较差，对于复杂的缺陷故障，建立故障树的过程会非常复杂，消耗资源较多，计算和分析比较困难。

2 软件缺陷分析方法的比较

没有完美的分析方法，每一种分析方法都有自己的优点和缺点，如何能选取合适的方法在恰当的环境中使用是我们研究的重心，如果进一步可以将方法们组合使用，做到物尽其用，将会大大提高我们的分析效率和准确度。表13从方法复杂度、分析深度、分析广度和主观性四个方面对上述常见的缺陷分析方法进行了比较。

分析表13可见：

表13 软件缺陷分析方法的比较Tab.13 The comparison of software defect analysis methods

（1）方法复杂度方面，根本原因分析和软件故障树分析这两种方法的复杂度相比其他方法更复杂一些，其他四种方法相对简单。

（2）分析深度方面，根本原因分析法和软件故障树分析法由于可以深入查找到缺陷发生的根本原因，因此分析的深度比较大，其中故障树分析法的分析结果更直观、简洁和明确。

（3）分析广度方面，正交缺陷分类法远远高于其他五种方案，分类后提供了大量的信息为分析工作提供支持。

（4）在主观性方面，根本原因分析法和软件故障树分析法由于更需要依赖于分析人员的主观判断，相对最差，ODC也存在一定的主观性依赖，其他三种方法则主要依靠的是数据进行分析，因此较好。

由此可见，这些方法中，根本原因分析法最适合对大量数据分析产生的原因，故障树分析法是深入分析单类缺陷的最好方法，而ODC正交分解法则是覆盖最广、适用最全面、提供信息最丰富的方法。如果可以通过 ODC法结合根本原因分析法提供大量分析数据，并基于这些数据简化建立故障树的过程，然后对其中分析要求最高的缺陷进行故障树分析，就可以真正做到各司其职、物尽其用，避免重复工作，极大的提高效率。

3 结论

本文针对目前国内软件企业对提升软件质量的需要，介绍软件缺陷分析的相关知识，研究了缺陷分析的各类主流技术，并综合比较其优点和不足，以便能够采取针对性的改进措施，减少软件缺陷的产生，越早发现缺陷中存在的缺陷，就越是能够降低耗费在修复缺陷上的开发费用，同时提升软件的质量。

[1] Chang Ching-Pao, Chu Pchih-Ping. Defect Prevention in Software Processes: An Action-Based Approach[J]. Journal of Systems and Software, 2007.

[2] 张少中. 基于贝叶斯网络的知识发现与决策应用研究[D].大连: 大连理工大学, 2003.ZHANG S Z. Research of knowledge discovery and decision application based on bayesian network[D]. Dalian:Dalian University of Technology, 2003. (in Chinese)

[3] 梁成才, 章代雨, 林海静. 软件缺陷的综合硏究[J]. 计算机工程, 2006, 32(19): 88-90.LIANG C C, ZHANG D Y. The comprehensive research of Software defect[J]. Computer Engineering. 2006, 32(19):88-90. (in Chinese)

[4] 尹相乐, 马力, 关昕. 软件缺陷分类的研究[J]. 计算机工程与设计, 2008, 29(19): 4910-4912.YIN X L, MA L, GUAN X. The research of software defect classification[J]. Computer Engineering and Design, 2008,29(19): 4910-4912. (in Chinese)

[5] 陈春秀. 软件可靠性模型的研究及基于可靠性模型的测试[D]. 北京: 华北计算技术研究所, 2011.CHEN C X. The research of Software Reliability Modeling and testing based on Reliability Modeling[D]. Beijing: North China Institute of Computing Technology, 2011. (in Chinese)

[6] NIAZI M, BABARC M A, VERNERD J M. Software Process Improvement barriers: A cross-cultural comparison[J]. Information and Software Technology, 2010, 52(11): 1204-1216.

[7] 聂林波, 刘孟仁. 软件缺陷分类研究[J]. 计算机应用研究,2004(6): 84-86.NIE L B, LIU M R. The research of software defect classification[J]. Application Research of Computers, 2004(6): 84-86. (in Chinese)

[8] 王青, 伍书剑, 李明树. 软件缺陷预测技术研究[J]. 软件学报, 2008, 19(7): 1565-1581.WANG Q, WU S J, LI M S. The research of software defect Prediction[J]. Journal of Software, 2008, 19(7): 1565-1581.(in Chinese)

[9] WALT C, BARNARD E. Data characteristics that determine classifier performance[J]. SAIEE Africa Research Journal,2007.

[10] 陈爱真, 曾福萍, 陆民燕. 基于ODC的软件缺陷度量研究[J]. 计算机应用研究, 2010, 2(27): 563-565.CHEN A Z, ZENG F P, LU M Y. The research of software defect measurement based on ODC[J]. Application Research of Computers, 2010, 2(27): 563-565. (in Chinese)

[11] 朱永春, 徐红. 一种基于历史数据的软件缺陷预测方法改进[J]. 北京航空航天大学学报, 2003, 10: 947-950.ZHU Y C, XU H. The improvement of software defect prediction method based on historical data[J]. Journal of Beijing University of Aeronautics and Astronautics, 2003, 10: 947-950. (in Chinese)

[12] 罗宜美, 黄胜延, 曹式有. 改进鱼骨图在生产管理中的应用[J]. 工业工程, 2007, 10(2): 138-141.LUO Y M, HUANG S Y, CAO S Y. The application of improvement fishbone diagram in production management[J].Industrial Engineering, 2007, 10(2): 138-141. (in Chinese)

[13] 周丰, 马力. 基于AODE和再抽样的软件缺陷预测模型[J].计算机工程与设计, 2011, 32(1): 210-212.ZHOU F, MA L. Software defect prediction model based on AODE and resampling[J]. Computer Engineering and Design,2011, 32(1): 210-212. (in Chinese)

[14] 朱少民. 软件质量保证和管理[M]. 北京: 清华大学出版社, 2007.ZHU S M. Software Quality Assurance and Management[M].Beijing: Tsinghua University Press, 2007. (in Chinese)

[15] LEE S F, BAI X Y, CHEN Y N. Automatic Mutation Testing and Simulation on OWL-S Specified Web Services[R]. 41st Annual Simulation Symposium (ANSS-41), IEEE Computer Society, 2008.

[16] 王雅文. 基于缺陷模式的软件测试技术研究[D]. 北京: 北京邮电大学, 2009.WANG Y W. The research of software testing technology based on defect pattern[D]. Beijing: Beijing University of Posts and Telecommunications, 2009. (in Chinese)

[17] 李新军, 刘晓明, 黄松. 基于软件过程度量的正交缺陷分类技术[J]. 计算机工程, 2009, 35(23): 30-34.LI X J, LIU X M, HUANG S. Orthogonal defect classification technology based on software process measurement[J].Computer Engineering, 2009, 35(23): 30-34.