软件缺陷的分类与管理

范文一：软件缺陷的分类与管理

软件缺陷的分类与管理

通常大家发现软件缺陷时会对软件缺陷进行分类，可分类的方式只有一种，就是严重极别,难道没有其它的分法吗。比如我们碰到下面这种情况，测试人员发现有一种功能是必需加入进去的，这时他与程序员说，程序员说没有时间或是不必要，这时这种情况则会形成两者的扯皮，最终的结果也就不了了知了，这样会戳伤了测试人员的积极性，下次他们再也不会尽心的考虑产品的问题，只要可以运行就可以了。其实这种情况是可以解决的,下面我会提到一个新的软件缺陷分类概念，从而有效的解决这个问题。在软件缺陷中不仅仅只是严重极别，更多的则是功能没有做到。说到这里也许大家都理解了，就是需求没有考虑到，可需求不会一次就很完美的，需要大家的共同努力，来不断的完善。那么怎样才能让测试人员提出的好的建议得到有效的执行,这就是我下面想说的。在软件缺陷中还有一种分法，跟据缺陷内容来分，主要分为需求Bug与程序Bug，对于这种分法的好处就是明确了Bug处理的责任人。对于程序Bug我们都知道是由相关开发人员进行处理。下面主要讨论一下需求Bug,需求Bug从名称上来就知道是要交由需求人员进行处理，可怎么处理，怎样在处理的过程中有效的让这些创意得到体现。现在我们都有Bug管理系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求Bug，处理的流程如图。

图1

这样处理有以下好处，首先需求Bug再不象以前，没有人进行确认，需求的处理人员本来就是需求人员，由他们确认与跟踪是最好不过的，因为他们对需求有绝对的权威。同时测试人员其实就是最早的用户，他们的需求就是用户的需求，这种方法加强了需求人员与测试人员的沟通，使需求得到有效的补充，从而让产品更加完善。还有测试人员从本质上来说与程序员还是对立的，这里如果为了这样一个不是软件本身问题的问题形成与开发人员的对立，则会出现赢得战役而丢失整个战争的情况，测试人员协调好与开发人员的关系，让他们更有效的对软件本身的缺陷形成有效的关注是最好的。还有最为关键的一点，测试人员的激情是最重要的，如果他们的想法没有得到体现，这时会渐渐的失去对测试的兴趣，从而软件的质量则会无法得到保证，通过这种方法可以让他们看到自己的建议可以通过对需求人员的反映得到实现，让他们时时觉得自己的想法是可

以通过这种方法来有效的推行，这样工作的积极性才会有保障。

不过从实施的角度来说，还是有一定的困难的，首先要让大家改变以前那种凡是Bug就是由开发人员负责的观念，其次需求人员的工作量是要加大的，不过广泛的了解需求是他们的本份工作，想来不会很困难，还有必需要有有效的Bug管理工具，比如BugManage等等，不要出现那种对需求人员说了，可过两天就忘的情况出现，这时需求Bug的生命周期会出现跨越两个软件开发周期，因为有些需求会在下一版实现，这时测试人员需要延长对这些需求Bug的管理，不过我想这些需求是他们提出的，会有兴趣对这些Bug进行管理的。

范文二：软件缺陷的分类统计

软件缺陷的分类统计

http://www.yunyoubar.com/ 邮件群发

许多刚刚接触软件测试的专业人员一样，对软件缺陷的分类和跟踪管理不是很感兴趣，极端的还有一种抵触的情绪，“搞那么多名堂干嘛”,这里，笔者就想说一

下，在实际的工作中缺陷分类和跟踪管理的意义。

首先应该明确的是，测试人员的职责是“软件质量”。基本的工作是，根据一定的方法和逻辑，寻找或者发现软件中的缺陷，通过这个过程来证明软件的质量是优秀的，还是低劣的。所以，往往发现缺陷，成为很多测试人员关注的焦点。但是，事实上，我们还应该对缺陷进行分类统计，从综合的角度考虑软件的质量问题。

现在和大家分享一下如下的规则给我们测试工作带来的指导意义。

规则 1:发现的缺陷的数量说明不了软件的质量。

软件中不可能没有缺陷，发现很多的缺陷对于测试工作来说，是件很正常的事。缺陷的数量大，只能说明测试的方法很好，思路很全面，测试工作有成效。但是，以此来否认软件的质量，还比较的武断。

如果，测试中发现的这些缺陷，绝大多数都是属于提示性错误、文字错误等，错误的等级很低，而且这些缺陷的修改几乎不会影响到执行指令的部分，而软件的基本功能或者是性能，发现很少的缺陷，很多时候，这样的测试证明的是“软件的质量是稳定的”，因而它属于优秀的软件的范畴。这样的软件，只要处理好发现的缺陷，进行一下返测，基本就可以发行使用了;进行完整的回归，就是增加软件的成本，浪费商机和时间。

反过来，如果在测试中发现的缺陷比较少，但是这些缺陷都集中在功能没有实现，性能没有达标，动不动就引起死机、系统崩溃等现象，而且，在大多数的用户在使用的过程中都会发现这样的问题，这样的软件不会有人轻言“发布”的，因为他承担的风险太大了。

虽然，这两个例子都比较的极端，在实际的测试中，几乎不会发生，但是，提出来，是希望从事测试工作的同行们，不要把自己的工作集中在发现缺陷的问题

上。

规则 2:缺陷要分类统计

看一下，笔者在实际的测试过程中得到的一组缺陷的统计的柱状图:(见第一幅图)

它说明的是，在某些模块，执行的测试用例多，但是没有成比例的发现很多缺陷，所以这些模块是比较成熟的，因为在这些模块几乎不怎么修改，再测试的话，也不会发现什么问题的;但是某些模块执行的测试少，却发现了更多的缺陷，这些模块修复的地方，或者发生功能变更的可能性大，所以将成为质量不稳定的关键点。

如果，你是一个软件质量管理人员，你就应该明白的是，在以后的回归测试中，应该在质量不稳定的模块中投入更多的人手和时间，进行更全面的测试，其它模块就相应减少测试工作的投入。这样，测试工作的压力就不是那么大了，而且效率也相对提高了。

规则 3:不要指望找出软件中所有的缺陷

很多人都知道这个道理，但是却不明白这个规则给软件测试工作的意义。它其实是在指导我们，该在什么时候停止软件测试，发布软件。

我们再来看一组数据:(见第二幅图)

这个缺陷趋势分析图，说明了，软件在测试版本的 Ver 1.4的时候，软件的质量已经得到了很好的控制了，在 Ver 1.8的时候，基本上就已经可以发布软件了，后面的测试几乎是没有什么意义的。原因很简单，软件中的缺陷既然是不可能全部发现的，就不要指望找出软件中全部的缺陷，当它足够少(各公司的定义是不同的)的时候，就应该停止测试了。

规则 4:只依赖缺陷的趋势也可能有问题

缺陷固然是在减少，但是是不是所有模块的缺陷都在减少呢,是不是所有级别的缺陷都在减少呢,而且它们也符合你的期望呢,

同样是上面一组数据，我们换个角度统计，看看又会怎么样,(见第三幅)

可能眼睛看得很花，没有关系，我想你至少能够看到的是，各模块之间，不同的阶段都会发现缺陷突然变多，这就是统计各模块的时候，发现的各模块的缺陷趋势。它给我们的信息是，软件不同阶段，各模块的质量和软件整体的质量是不对称的。虽然缺陷在不断的减少，但是一些关键的模块，尤其是风险分析中风险值比较大的模块，仍然是质量不稳定的，这样的软件可能可以算优秀的软件，因为缺陷的绝对值可能真的很小了，但是，也同时是风险大的软件。

规则 4:只依赖缺陷的趋势也可能有问题

缺陷固然是在减少，但是是不是所有模块的缺陷都在减少呢,是不是所有级别的缺陷都在减少呢,而且它们也符合你的期望呢,

同样是上面一组数据，我们换个角度统计，看看又会怎么样,(见第三幅)

诸如此类的规则，其实还有很多的，例如:修改一个缺陷，可能引入了更多更深的缺陷;软件测试中的“二八定律”等等。

很多公司都有严格的缺陷分类和管理制度，并在此基础上对软件产品的发布标准，都有具体的要求。例如:产品在发布的时候，一般都会要求，各模块致命的缺陷不得有 2个，严重的缺陷不得超过 5个，轻微的缺陷不能多于 5个，残留的缺陷总数不得多于 10个等。

这些看似简单的规定，其实是经历了很多人长期的努力才总结出来的经验，他们大多来源于一些事故，但是现在，却直接指导着我们的测试工作，无疑对减少软件测试工作的压力和工作量都提供了足够充分的理论依据。

综合的讲，笔者在这里的建议仅仅只是希望，即将进入或者已经进入软件测试行业的兄弟姐妹们，不要只关心如何发现软件中的缺陷，还应当对这些缺陷进行分类的跟踪、管理和分析，并从这些已经存在的数据中，找到一些对我们的软件测试工作有意义的指导，这才是缺陷跟踪分类、统计、跟踪管理的意义。

范文三：软件缺陷分类

由安博测试空间技术中心

http://www.btestingsky.com/提供

软件缺陷的分类

软件缺陷(software defect)是对软件产品预期属性的偏离现象。它包括检测缺陷和残留缺陷。每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。

一、软件缺陷(software defect)分类标准

1.1 缺陷属性

属性名称描述

缺陷标识(IDEntifier) 缺陷标识是标记某个缺陷的一组符号。每个缺陷必须

有一个唯一的标识

缺陷类型 (type) 缺陷类型是根据缺陷的自然属性划分的缺陷种类。缺陷严重程度缺陷严重程度是指因缺陷引起的故障对软件产品的影(Severity) 响程度。

缺陷优先级(Priority) 缺陷的优先级指缺陷必须被修复的紧急程度。缺陷状态(STatus) 缺陷状态指缺陷通过一个跟踪修复过程的进展情况。缺陷起源(Origin) 缺陷来源指缺陷引起的故障或事件第一次被检测到的

阶段。

缺陷来源(Source) 缺陷来源指引起缺陷的起因。

缺陷根源(Root Cause) 缺陷根源指发生错误的根本因素。

1.2 缺陷类型(Type)

缺陷类型编缺陷类型描述

号

10 F- Function 影响了重要的特性、用户界面、产品接

口、硬件结构接口和全局数据结构。并且

设计文档需要正式的变更。如逻辑，指

针，循环，递归，功能等缺陷。 20 A- ASsignment 需要修改少量代码，如初始化或控制块。

如声明、重复命名，范围、限定等缺陷。 30 I- Interface 与其他组件、模块或设备驱动程序、调用

参数、控制块或参数列表相互影响的缺

陷。

40 C- Checking 提示的错误信息，不适当的数据验证等缺

陷。

50 B 由于配置库、变更管理或版本控制引起的

Build/package/merge 错误。

60 D- Documentation 影响发布和维护，包括注释。 70 G- Algorithm 算法错误。

80 U-User Interface 人机交互特性:屏幕格式，确认用户输

入，功能有效性，页面排版等方面的缺

陷。

90 P-PerfORMance 不满足系统可测量的属性值，如:执行时

间，事务处理速率等。 100 N-Norms 不符合各种标准的要求，如编码标准、设

计符号等。

1.3 缺陷严重程度(Severity)

1.3.1 软件测试错误严重程度

# 缺陷严重等级描述

1 CRitical 不能执行正常工作功能或重要功能。或者危及人身安

全。

2 Major 严重地影响系统要求或基本功能的实现，且没有办法

更正。(重新安装或重新启动该软件不属于更正办

法)

3 Minor 严重地影响系统要求或基本功能的实现，但存在合理

的更正办法。(重新安装或重新启动该软件不属于更

正办法)

4 COSmetic 使操作者不方便或遇到麻烦，但它不影响执行工作功

能或重要功能。

5 Other 其它错误。

1.3.2 同行评审错误严重程度

# 缺陷严重等级描述

Major 主要的，较大的缺陷

Minor 次要的，小的缺陷

1.4 缺陷优先级(Priority)

# 缺陷优先级描述

1 RESolve ImmEDIately 缺陷必须被立即解决。

2 Normal Queue 缺陷需要正常排队等待修复或列入软件发布

清单。

3 Not Urgent 缺陷可以在方便时被纠正。

1.5 缺陷状态(Status)

缺陷状态描述 Submitted 已提交的缺陷

Open 确认“提交的缺陷”，等待处理 Rejected 拒绝“提交的缺陷”，不需要修复或不是缺

陷

Resolved 缺陷被修复

Closed 确认被修复的缺陷，将其关闭

1.6 缺陷起源(Origin)

缺陷起源描述 Requirement 在需求阶段发现的缺陷 Architecture 在构架阶段发现的缺陷 Design 在设计阶段发现的缺陷 Code 在编码阶段发现的缺陷 Test 在测试阶段发现的缺陷

1.7 缺陷来源(Source)

缺陷来源描述 Requirement 由于需求的问题引起的缺陷 Architecture 由于构架的问题引起的缺陷 Design 由于设计的问题引起的缺陷 Code 由于编码的问题引起的缺陷 Test 由于测试的问题引起的缺陷 Integration 由于集成的问题引起的缺陷

1.8 缺陷根源(Root Cause)

二、软件缺陷(software defect)的严重性和优先级

严重性和优先级是表征软件测试缺陷的两个重要因素，它影响软件缺陷的统计结果和修正缺陷的优先顺序，特别在软件测试的后期，将影响软件是否能够按期发布与否。

对于软件测试初学者而言，或者没有软件开发经验的测试工程师，对于这两个概念的理解，对于它们的作用和处理方式往往理解的不彻底，实际测试工作中不能正确表示缺陷的严重性和优先级。这将影响软件缺陷报告的质量，不利于尽早处理严重的软件缺陷，可能影响软件缺陷的处理时机。

什么是缺陷的严重性和优先级

严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。

在软件测试中，软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。

优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。

缺陷的严重性和优先级的关系

缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。

一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。

但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。

修正软件缺陷不是一件纯技术问题，有时需要综合考虑市场发布和质量风险等问题。例如，如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上解决。另外，如果修正一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多潜在的缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要全盘考虑。

另一方面，如果软件缺陷的严重性很低，例如，界面单词拼写错误，但是如果是软件名称或公司名称的拼写错误，则必须尽快修正，因为这关系到软件和公司的市场形象。

处理缺陷的严重性和优先级的常见错误

正确处理缺陷的严重性和优先级不是件非常容易的事情，对于经验不很丰富的测试和开发人员而言，经常犯的错误有以下集中情形:

第一，将比较轻微的缺陷报告成较高级别的缺陷和高优先级，夸大缺陷的严重程度，经常给人“狼来了”的错觉，将影响软件质量的正确评估，也耗费开发人员辨别和处理缺陷的时间。

第二，将很严重的缺陷报告成轻微缺陷和低优先级，这样可能掩盖了很多严重的缺陷。如果在项目发布前，发现还有很多由于不正确分配优先级造成的严重缺陷，将需要投入很多人力和时间进行修正，影响软件的正常发布。或者这些严重的缺陷成了“漏网之鱼”，随软件一起发布出去，影响软件的质量和用户的使用信心。

因此，正确处理和区分缺陷的严重性和优先级，是软件测试人员和开发人员，以及全体项目组人员的一件大事。处理严重性和优先级，既是一种经验技术，也是保证软件质量的重要环节，应该引起足够的重视。

如何表示缺陷的严重性和优先级

缺陷的严重性和优先级通常按照级别划分，各个公司和不同项目的具体表示方式有所不同。

为了尽量准确的表示缺陷信息，通常将缺陷的严重性和优先级分成4级。如果分级超过4级，则造成分类和判断尺度的复杂程度，而少于4级，精确性有时不能保证。

具体的表示方法机可以使用数字表示，也可以使用文字表示，还可以数字和文字综合表示。使用数字表示通常按照从高到底或从低到高的顺序，需要软件测试前达成一致。例如，使用数字1，2，3，4分别表示轻微、一般、较严重和非常严重的严重性。对于优先级而言，1，2，3，4可以分标表示低优先级、一般、较高优先级和最高优先级。

如何确定缺陷的严重性和优先级

通常由软件测试人员确定缺陷的严重性，由软件开发人员确定优先级较为适当。但是，实际测试中，通常都是由软件测试人员在缺陷报告中同时确定严重性和优先级。

确定缺陷的严重性和优先级要全面了解和深刻体会缺陷的特征，从用户和开发人员以及市场的因素综合考虑。通常功能性的缺陷较为严重，具有较高的优先级，而软件界面类缺陷的严重性一般较低，优先级也较低。

对于缺陷的严重性，如果分为4级，则可以参考下面的方法确定:

1 – 非常严重的缺陷，例如，软件的意外退出甚至操作系统崩溃，造成数据丢失。

2 – 较严重的缺陷，例如，软件的某个菜单不起作用或者产生错误的结果;

3 - 软件一般缺陷，例如，本地化软件的某些字符没有翻译或者翻译不准确;

4 - 软件界面的细微缺陷，例如，某个控件没有对齐，某个标点符号丢失等;

对于缺陷的优先性，如果分为4级，则可以参考下面的方法确定:

1 –最高优先级，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷。

2 – 较高优先级，例如，影响软件功能和性能的一般缺陷;

3 -一般优先级，例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷;

4 – 低优先级，例如，对软件的质量影响非常轻微或出现几率很低的缺陷;

其他注意事项

比较规范的软件测试，使用软件缺陷管理数据库进行缺陷报告和处理，需要在测试项目开始前对全体测试人员和开发人员进行培训，对缺陷严重性和优先级的表示和划分方法统一规定和遵守。

在测试项目进行过程中和项目接收后，充分利用统计功能统计缺陷的严重性，确定软件模块的开发质量，评估软件项目实施进度。统计优先级的分布情况，控制开发进度，使开发按照项目尽快进行，有效处理缺陷，降低风险和成本。

为了保证报告缺陷的严重性和优先级的一致性，质量保证人员需要经常检查测试和开发人员对于这两个指标的分配和处理情况，发现问题，及时反馈给项目负责人，及时解决。

对于测试人员而言，通常经验丰富的人员可以正确的表示缺陷的严重性和优先级，为缺陷的及时处理提供准确的信息。对于开发人员来说，开发经验丰富的人员严重缺陷的错误较少，但是不要将缺陷的严重性作为衡量其开发水平高低的主要判断指标，因为软件的模块的开发难度不同，各个模块的质量要求也有所差异。

三、软件缺陷(software defect)的分类与管理

题，只要可以运行就可以了。其实这种情况是可以解决的,下面我会提到一个新的软件缺陷分类概念，从而有效的解决这个问题。

在软件缺陷中不仅仅只是严重极别，更多的则是功能没有做到。说到这里也许大家都理解了，就是需求没有考虑到，可需求不会一次就很完美的，需要大家的共同努力，来不断的完善。那么怎样才能让测试人员提出的好的建议得到有效的执行,这就是我下面想说的。在软件缺陷中还有一种分法，跟据缺陷内容来分, , ，主要分为需求Bug与程序Bug，对于这种分法的好处就是明确了Bug处理的责任人。对于程序Bug我们都知道是由相关开发人员进行处理。下面主要讨论一下需求Bug,需求Bug从名称上来就知道是要交由需求人员进行处理，可怎么处理，怎样在处理的过程中有效的, 让这些创意得到体现。现在我们都有Bug管理系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序, , , , 员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求Bug，处理的流程如图。

让他们看到自己的建议可以通过对需求人员的反映得到实现，让他们时时觉得自己的想法是可以通过这种方法来有效的推行，这样工作的积极性才会有保障。

不过从实施的角度来说，还是有一定的困难的，首先要让大家改变以前那种凡是Bug就是由开发人员负责的观念，其次需求人员的工作量要加大，不过广泛的了解需求是他们的本份工作，想来不会很困难，还有必需要有有效的Bug管理工具，比如BugManage等等，不要出现那种对需求人员说了，可过两天就忘的情况出现，这时需求Bug的生命周期会出现跨越两个软件开发周期，因为有些需求会在下一版实现，这时测试人员需要延长对这些需求Bug的管理，不过我想这些需求是他们提出的，会有兴趣对这些Bug进行管理的。四、软件缺陷(software defect)管理指南

1、如何收集缺陷

缺陷既指程序中存在的错误，例如语法错误、拼写错误或者是一个正确的程序语句，缺陷也指可能出现在设计中，甚至在需求、规格说明或其他的文档中的种种错误。为了对缺陷进行管理，首先应对缺陷进行分类，通过对缺陷进行分类，可以迅速找出哪一类缺陷的问题最大，然后集中精力预防和排除这一类缺陷。而这正是缺陷管理的关键，一旦这几类缺陷得到控制，再进一步找到新的容易引起问题的几类缺陷上。

1(1 缺陷类型

缺陷类缺陷类型描述

型编号

10 F-功能如逻辑,指针,循环,递归,功能等缺陷

20 G-语法拼写、标点符号、打字

30 A-赋值如声明、重复命名，作用域

40 I-接口与其他组件、模块或设备驱动程序、调

用参数、控制块或参数列表相互影响的

缺陷

50 B-联编打包由于配置库、变更管理或版本控制引起

的错误

60 D-文档需求、设计类文档

70 U-用户接口人机交互特性:屏幕格式，确认用户输

入，功能有效性

80 P-性能不满足系统可测量的属性值，如:执行

时间，事务处理速率等

90 N-标准不符合各种标准的要求，如编码标准、

设计符号等

100 E-环境设计、编译、其他支持系统问题

1(2 了解缺陷

缺陷管理的第一步是了解缺陷，为此，必须首先收集缺陷数据，然后才能了解这些缺陷，并且找出如何预防它们，同时也能领会到如何更好地发现，修复甚至预防仍在引入的缺陷。可以按照以下步骤收集关于缺陷的数据:

? 为测试和同行评审中发现的每一个缺陷做一个记录

? 对每个缺陷要记录足够详细的信息，以便以后能更好地了解这个缺陷

? 分析这些数据以找出主要哪些缺陷类型引起大部分的问题

? 设计出发现和修复这些缺陷的方法(缺陷排除)

通常为了收集缺陷数据，可以采用缺陷记录日志来登记所发现的每一个缺陷

日期编号状态类型缺陷来源排除阶段修改时间修复缺陷

描述:

对于缺陷记录日志中的描述应该足够清楚，以便今后可以看出该缺陷的起因。修复缺陷一栏说明此缺陷是由于修复其他缺陷而引入的。引入阶级表示该缺陷的来源，缺陷的来源可以分为以下几类:

缺陷来源描述

Requirement 由于需求的问题引起的缺陷

Architecture 由于构架的问题引起的缺陷

Design 由于设计的问题引起的缺陷

Code 由于编码的问题引起的缺陷

Test 由于测试的问题引起的缺陷

Integration 由于集成的问题引起的缺陷

排除阶级表示发现和修复这个缺陷的阶级，通常分为如下:

排除阶段描述

Requirement 在需求阶段发现的缺陷

Architecture 在构架阶段发现的缺陷

Design 在设计阶段发现的缺陷

Code 在编码阶段发现的缺陷

Test 在测试阶段发现的缺陷

2、如何分析和统计缺陷

为了更好地分析缺陷，需要对缺陷在严重程度、优先级以及状态上加以区分。

2(1 缺陷严重程度

# 缺陷严重等级描述

1 严重缺陷不能执行正常工作功能或重要功能。或者危及人身安全

(Critical)

2 较大缺陷(Major) 严重地影响系统要求或基本功能的实现，且没有办法更

正。

(重新安装或重新启动该软件不属于更正办法) 3 较小缺陷(Minor) 严重地影响系统要求或基本功能的实现，但存在合理的更

正办法。(重新安装或重新启动该软件不属于更正办法) 4 轻微缺陷使操作者不方便或遇到麻烦，但它不影响执行工作功能或

(Cosmetic) 重要功能。

5 其他缺陷(Other) 其它错误

2(2 解决优先级(Priority)

# 解决优先级描述

1 立即解决缺陷必须被立即解决。

(Resolve ImmeDIately)

2 正常排队缺陷需要正常排队等待修复或列入软件发布清单。

(Normal Queue)

3 不紧急缺陷可以在方便时被纠正。

(Not Urgent)

, 让这些创意得到体现。现在我们都有Bug管理系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序, , , , 员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确

，处理的流程如图。提到的，我们则可以定位为需求Bug

1、如何收集缺陷

1(1 缺陷类型

缺陷类缺陷类型描述

型编号

10 F-功能如逻辑,指针,循环,递归,功能等缺陷

20 G-语法拼写、标点符号、打字

30 A-赋值如声明、重复命名，作用域

40 I-接口与其他组件、模块或设备驱动程序、调

用参数、控制块或参数列表相互影响的

缺陷

50 B-联编打包由于配置库、变更管理或版本控制引起

的错误

60 D-文档需求、设计类文档

70 U-用户接口人机交互特性:屏幕格式，确认用户输

入，功能有效性

80 P-性能不满足系统可测量的属性值，如:执行

时间，事务处理速率等

90 N-标准不符合各种标准的要求，如编码标准、

设计符号等

100 E-环境设计、编译、其他支持系统问题

1(2 了解缺陷

? 为测试和同行评审中发现的每一个缺陷做一个记录

? 对每个缺陷要记录足够详细的信息，以便以后能更好地了解这个缺陷

? 分析这些数据以找出主要哪些缺陷类型引起大部分的问题

? 设计出发现和修复这些缺陷的方法(缺陷排除)

通常为了收集缺陷数据，可以采用缺陷记录日志来登记所发现的每一个缺陷

日期编号状态类型缺陷来源排除阶段修改时间修复缺陷

描述:

缺陷来源描述

Requirement 由于需求的问题引起的缺陷

Architecture 由于构架的问题引起的缺陷

Design 由于设计的问题引起的缺陷

Code 由于编码的问题引起的缺陷

Test 由于测试的问题引起的缺陷

Integration 由于集成的问题引起的缺陷

排除阶级表示发现和修复这个缺陷的阶级，通常分为如下:

排除阶段描述

Requirement 在需求阶段发现的缺陷

Architecture 在构架阶段发现的缺陷

Design 在设计阶段发现的缺陷

Code 在编码阶段发现的缺陷

Test 在测试阶段发现的缺陷

2、如何分析和统计缺陷

为了更好地分析缺陷，需要对缺陷在严重程度、优先级以及状态上加以区分。

2(1 缺陷严重程度

# 缺陷严重等级描述

1 严重缺陷不能执行正常工作功能或重要功能。或者危及人身安全

(Critical)

2 较大缺陷(Major) 严重地影响系统要求或基本功能的实现，且没有办法更

正。

(重新安装或重新启动该软件不属于更正办法) 3 较小缺陷(Minor) 严重地影响系统要求或基本功能的实现，但存在合理的更

正办法。(重新安装或重新启动该软件不属于更正办法) 4 轻微缺陷使操作者不方便或遇到麻烦，但它不影响执行工作功能或

(Cosmetic) 重要功能。

5 其他缺陷(Other) 其它错误

2(2 解决优先级(Priority)

# 解决优先级描述

1 立即解决缺陷必须被立即解决。

(Resolve Immediately)

2 正常排队缺陷需要正常排队等待修复或列入软件发布清单。

(Normal Queue)

3 不紧急缺陷可以在方便时被纠正。

(Not Urgent)

范文四：软件缺陷导致严重后果的典型案例

软件缺陷导?致严重后果?的典型案例?

用户为了保?证自己业务?的顺利完成?，当然希望选?用优质的软?件。质量不佳的?软件产品不?仅会使开发?商的维护费?用和用户的?使用成本大?幅度增加，还可能产生?其他的责任?风险，造成公司信?誉下降。一些关键的?应用领域(例如银行、证券交易、军事等)如果质量有?问题，还可能造成?灾难性的后?果。

现在人们已?经逐步认识?到是软件中?存在的错误?导致了软件?开发在成本?、进度和质量?上的失控。由于软件是?由人来完成?的，所以它不可?能十全十美?，虽然不可能?完全杜绝软?件中的错误?，但是可以通?过软件测试?等手段使程?序中的错误?数量尽可能?少，密度尽可能?小。

接下来看看?成功的软件?测试带来的?好处和不完?整的软件测?试带来的教?训。

, IE和Ne?tscap?e

在IE 4.0的开发期?间，微软为了打?败Nets?cape而?汇集了一流?的开发人员?和测试人员?。测试人员搭?建起测试环?境，让IE在数?台计算机上?持续运行一?个星期，而且要保障?IE在几秒?钟以内可以?访问数千个?网站，在无数次的?试验以后，测试人员证?明了IE在?多次运行以?后依然可以?保障它的运?行速度。而且，为了快速完?成IE 4.0的开发，测试人员每?天都要对新?版本进行测?试，不仅要发现?问题，而且要找到?问题是哪一?行代码造成?的，让开发人员?专心于代码?的编写和修?改，最终IE取?得了很大的?成功。

, 360存在?严重后果缺?陷导致系统?崩溃

电脑中了木?马，使用360?安全卫士查?出一个名为?Backd?oor/Win32?.Agent?.cgg的木?马，文件位置为?C:\Windo?ws\syste?m32\shdoc?vw.dll。进行清理后?看不到Wi?ndows?任务栏和桌?面图标，根本进不去?桌面，手工运行E?xplor?er.exe也是?一闪就关，后来查明是?由于360?在处理此木?马时存在严?重缺陷。360安全?卫士只是简?单的删除了?木马文件，没有进行相?关的善后处?理工作，致使系统关?键进程Ex?plore?r.exe无法?加载。

, 2009年?2月份Go?ogle的?Gmail?故障

2009年?2月份Go?ogle的?Gmail?故障，Gmail?用户几小时?不能访问邮?箱，应该算是最?近因软件故?障而受到广?泛关注的事?件。据Goog?le后称，那次故障是?因数据中心?之间的负载?均衡软件的?Bug引发?的。

360问题?和Gmai?l故障还仅?是导致用户?不能正常使?用电脑或几?个小时内无?法访问邮箱?，并没有造成?伤亡。当然了，对某些用户?来讲，是非常不便?。

但看了下面?的一个例子?您会发现，360和G?mail的?问题真是“小巫见大巫?”了。

, 2011 年温州7.23 动车事故

2011年?7月23日?20时30?分05秒，甬温线浙江?省温州市境?内，由北京南站?开往福州站?的D301?次列车与杭?州站开往福?州南站的D?3115次?列车发生动?车组列车追?尾事故，造成40人?死亡、172人受?伤，中断行车3?2小时35?分，直接经济损?失1937?1.65万元。

上海铁路局?局长安路生?28日说，根据初步掌?握的情况分?析，“7?23”动车事故是?由于温州南?站信号设备?在设计上存?在严重缺陷?，遭雷击发生?故障后，导致本应显?示为红灯的?区间信号机?错误显示为?绿灯。

, 致命的辐射?治疗

辐射剂量超?标的事故发?生在200?0年的巴拿?马城(巴拿马首都?)。从美国Mu?ltida?ta公司引?入的治疗规?划软件，其(辐射剂量的?)预设值有误?。有些患者接?受了超标剂?量的治疗，至少有5人?死亡。后续几年中?，又有21人?死亡，但很难确定?这21人中?到底有多少?人是死于本?身的癌症，还是辐射治?疗剂量超标?引发的不良?后果。

, 消失在太空?

在制造其火?星气候轨道?探测器时，一个NAS?A的工程小?组使用的是?英制单位，而不是预定?的公制单位?。这会造成探?测器的推进?器无法正常?运作。正是因为这?个 Bug，1999年?探测器从距?离火星表面?130英尺?的高度垂直?坠毁。此项工程成?本耗费3.27亿美元?，这还不包括?损失的时间?(该探测器从?发射到抵达?火星将近一?年时间。)

, 阿丽亚娜5?型火箭的杯?具处女秀

1996年?6月4日，阿丽亚娜5?型运载火箭?的首航，原计划将运?送4颗太阳?风观察卫星?到预定轨道?，但因软件引?发的问题导?致火箭在发?射39秒后?偏轨，从而激活了?火箭的自我?摧毁装置。阿丽亚娜5?型火箭和其?他卫星在瞬?间灰飞烟灭?。

后来查明的?事故原因是?:代码重用。阿5型的发?射系统代码?直接重用了?阿4型的相?应代码，而阿4型的?飞行条件和?阿5型的飞?行条件截然?不同。此次事故损?失3.7亿美元。

, 英特尔奔腾?芯片缺陷

如果在计算?机的“计算器”中输入以下?算式:

41958?3/31457?27)X3145?727-41958?35 (

结果显示为?零。而在199?4年，结果可能为?其他答案，这就是英特?尔(Intel?)奔腾(Pentu?mn)CPU芯片?所带来的一?个浮点触发?缺陷。英特尔为此?付出了4亿?多美元的代?价。

, 一触即发的?第三次世界?大战

1980年?，北美防空联?合司令部曾?报告称美国?遭受导弹袭?击。后来证实，这是反馈系?统的电路故?障问题，但反馈系统?软件没有考?虑故障问题?引发的误报?。

1983年?，苏联卫星报?告有美国导?弹入侵，但主管官员?的直觉告诉?他这是误报?。后来事实证?明的确是误?报。

幸亏这些误?报没有激活?“核按钮”。在上述两个?案例中，如果对方真?的发起反击?，核战争将全?面爆发，后果不堪设?想。

通过以上的?例子，可以看出软?件发生错误?时对人类生?活所造成的?各种影响，有的甚至会?带来灾难性?的后果。软件测试可?以使这种风?险降低，它在一定程?度上解放了?程序员，使他们能够?更专心于解?决程序的算?法效率。同时它也减?轻了售后服?务人员的压?力，交到他们手?里的程序再?也不是那些?“一触即死机?”的定时炸弹?，而是经过严?格检验的完?整产品。同时，软件测试的?发展对程序?的外形、结构、输入和输出?的规约和标?准化提供了?参考，并推动了软?件工程的发?展。

范文五：代价敏感分类的软件缺陷预测方法

代价敏感分类的软件缺陷预测方法 *

李勇 1,2+, 黄志球 1, 房丙午 1, 王勇 1

1. 南京航空航天大学计算机科学与技术学院, 南京 210016

2. 新疆师范大学网络信息安全与舆情分析重点实验室, 乌鲁木齐 830054

Using Cost-Sensitive Classification for Software Defects Prediction

LI Yong 1,2+, HUANG Zhiqiu 1, FANG Bingwu 1, WANG Yong 1

1. College of Computer Science and Technology, Nanjing University of Aeronautics and Astronautics, Nanjing 210016, China

2. Key Laboratory of Network Information Security and Public Opinion Analysis, Xinjiang Normal University, Urumqi 830054, China

+Corresponding author:E-mail:liyong@live.com

LI Yong, HUANG Zhiqiu, FANG Bingwu, et al. Using cost-sensitive classification for software defects predic-tion. Journal of Frontiers of Computer Science and Technology, 2014, 8(12):1442-1451.

Abstract:Software defects prediction is considered as an effective means for the optimization of quality assurance activities. Taking into account the different misclassification cost for unknown software modules using the software defects prediction models, this paper proposes the cost-sensitive classification method for constructing software defects prediction models. Firstly, for the code attribute metric data, decision tree algorithm is selected to construct base-classifiers using cost-sensitive classification method by sampling with replacement of Bagging. Then, the defects prediction model is constructed based on majority rule, and the approach to obtain the approximate optimal cost-factor value is researched. The experimental results on the NASA software defects prediction datasets show that the proposed method is averagely superior to the conventional methods with lower probability of false alarm and higher compre-hensive evaluation values.

*The National Natural Science Foundation of China under Grant No. 61272083(国家自然科学基金 ); the Humanity and Social Science Youth Foundation of Ministry of Education of China under Grant No. 11YJC870014(教育部人文社会科学研究青年基金项目 ); the Funding of Jiangsu Innovation Program for Graduate Education under Grant No. CXLX13_160(江苏省普通高校研究生科研创新计划资助项目 ); the Fundamental Research Funds for the Central Universities of China (中央高校基本科研业务费专项资金 ). Received 2014-08, Accepted 2014-10.

CNKI 网络优先出版:2014-10-17, http://www.cnki.net/kcms/doi/10.3778/j.issn.1673-9418.1410007.html

李勇, 黄志球, 房丙午, 等 . 代价敏感分类的软件缺陷预测方法 [J].计算机科学与探索, 2014, 8(12) :1442-1451.

ISSN 1673-9418CODEN JKYTA8

Journal of Frontiers of Computer Science and Technology 1673-9418/2014/08(12)-1442-10doi:10.3778/j.issn.1673-9418.1410007E-mail:fcst@vip.163.comhttp://www.ceaj.orgTel:

+86-10-89056056

1引言随着计算机软件需求的增长, 软件的规模和复杂度在日益增加, 其开发技术和运行环境也更加多样化。由于各行业对软件系统的强烈依赖, 软件在运行过程中一旦失效则有可能导致严重的后果。在软件可靠性工程中, 导致软件失效的根本原因是软件中存在缺陷 [1]。软件缺陷预测是指利用软件开发过程中的历史数据构建预测模型, 然后对未知软件模块进行是否存在缺陷或缺陷分布的预测。通过软件缺陷预测可以在开发和测试过程中关注有可能存在缺陷的模块, 从而提高软件测试效率和保证软件的可靠性 [2]。采用机器学习技术构建软件缺陷预测模型是目前学术界和工业界研究的热点 [3]。在采用机器学习技术构建软件缺陷预测模型时, 软件属性度量和学习算法的选择决定着预测模型的性能 [4]。软件缺陷预测模型的有效性要求其准确率必须能满足软件工程实践的需求, 即缺陷预测率须超过人工代码审查缺陷预测率 (60%以上 ) [5]。为了获得更加有效的预测模型, 研究者在软件属性度量和模型学习算法方面做了大量的研究工作。代码属性度量中基于方法的复杂性规模度量和面向对象的度量使用最为广泛 [6]。常用的机器学习算法都被

用来构建软件缺陷预测模型, 在不同的实践应用中均取得了理想的预测结果 [7]。现有的研究文献在构建软件缺陷预测模型的过程中通常假定错误分类的代价是相同的 [8], 即将有缺

陷模块错误分类为无缺陷模块和将无缺陷模块错误分类为有缺陷模块的代价相等。但在软件工程实践中, 第一类错误的代价要大于第二类错误的代价 [9]。本文在现有研究工作的基础上, 提出代价敏感分类的软件缺陷预测模型构建方法。主要贡献包括以下两个方面:

(1) 集成方式是提升分类器泛化性能的有效途径, 提出代价敏感分类的决策树集成软件缺陷预测方法, 采用 Bagging 集成算法构建预测模型。实验结果表明该方法构建的模型误报率低, 综合评价指标优于现有方法。

(2) 给出了实验过程中代价敏感分类最优代价

因子的选择方法。在软件工程实践中, 可以根据不同的应用需求通过调节代价因子达到预定的缺陷预测指标, 有利于软件缺陷预测技术的应用。本文组织结构如下:第 2章介绍了软件缺陷预测的研究背景与相关工作; 第 3章提出了代价敏感分类的决策树集成软件缺陷预测方法; 第 4章对本文涉及到的相关算法进行了实验对比及结果分析; 最后进行总结, 并对未来工作进行了展望。

2背景与相关工作

软件缺陷预测的目标是在开发过程中提高软件

质量和降低软件测试成本。软件缺陷预测技术随着

Key words:software defects prediction; cost-sensitive classification; optimal cost-factor; decision tree; ensemble algorithm

摘要:软件缺陷预测是提高软件测试效率, 保证软件可靠性的重要途径。考虑到软件缺陷预测模型对软件模块错误分类代价的不同, 提出了代价敏感分类的软件缺陷预测模型构建方法。针对代码属性度量数据, 采用 Bagging 方式有放回地多次随机抽取训练样本来构建代价敏感分类的决策树基分类器, 然后通过投票的方式集成后进行软件模块的缺陷预测, 并给出模型构建过程中代价因子最优值的判定选择方法。使用公开的 NASA 软件缺陷预测数据集进行仿真实验, 结果表明该方法在保证缺陷预测率的前提下, 误报率明显降低, 综合评价指标 AUC 和 F 值均优于现有方法。

关键词:软件缺陷预测; 代价敏感分类; 最优代价因子; 决策树; 集成算法

文献标志码:A 中图分类号:TP311.5

李勇等:代价敏感分类的软件缺陷预测方法

1443

Journal of Frontiers of Computer Science and Technology 计算机科学与探索 2014, 8(12)

PROMISE 软件预测模型数据库 [10]的扩充而不断发展, 该数据库中的数据均在真实的软件开发过程中收集, 是专门用于研究软件属性度量和缺陷预测模型构建的公开数据集。

在软件缺陷预测中, 将描述是否存在缺陷的最小软件单元称为软件模块。在对软件模块属性进行度量时, 使用最广泛的是方法级代码度量属性 Mc-Cabe [11]和 Halstead [12]。 McCabe 基于对程序拓扑结构的复杂度分析, 度量软件模块的内部结构属性; Hal-stead 以程序中出现的操作符和操作数为计数对象, 用于测量软件模块的规模。文献 [4]指出这两种度量属性对于构建软件缺陷预测模型都是有效的, 模型的性能取决于构建算法的选择。

常用的机器学习算法已经用来构建预测模型并进行性能比较。由于决策树 C4.5算法 [7]产生的分类规则易于理解且学习速度快, 经常被用来作为模型构建的基准比较算法。文献 [13]采用 C4.5算法对软件模块的缺陷密度进行预测, 获得了不错的性能。但文献 [14]实验结果表明, 决策树算法在遇到软件缺陷类数据不平衡的情况时, 对预测模型性能的影响较大。文献 [4]采用朴素贝叶斯算法构建模型, 实验结果表明, 朴素贝叶斯算法对类数据的不平衡性敏感度较低, 并且预测性能出色。其他的机器学习算法如神经网络 [15]、支持向量机 [16]和集成算法 [17]等都被用来构建软件缺陷预测模型, 在特定的应用领域均获得了不错的预测性能。由于软件项目类型、算法参数设置和预测模型评价指标的不同, 不存在性能最好的模型构建通用算法。文献 [18]对 PROMISE 软件预测数据库中的 NASA 数据集选择多种机器学习算法进行基准测试, 实验结果表明, 随机森林算法对于大规模数据集预测性能较优, 朴素贝叶斯算法对于较小规模数据集预测性能较优。因此在本文实验中, 选择随机森林算法和朴素贝叶斯算法与本文算法进行比较。

在软件缺陷预测模型对未知软件模块是否有缺陷的预测中有两类错误:I 类是将有缺陷模块错误分类为无缺陷模块; II 类是将无缺陷模块错误分类为有缺陷模块。文献 [9]最早提出在软件缺陷预测中不同的分类错误造成的代价是不同的。 I 类错误会导致有些缺陷没有修复, 造成软件系统在运行中失效, 使得软件不可靠; 而 II 类错误会导致无用的测试, 造成开发资源的浪费。由软件工程实践可知, I 类错误的代价要大于 II 类。针对不同的错误代价, 文献 [19]采用代价敏感分类方法对软件开发中的过程度量属性分别用决策树 C4.5算法和朴素贝叶斯算法构建缺陷预测模型, 结果表明代价敏感分类可以有效提高跨版本软件缺陷的预测性能。因为实验中所选数据集的类数据相对平衡, 所以选择固定值作为代价因子。文献 [20]通过实验表明, 当类数据不平衡时 (即有缺陷模块的数量远远小于无缺陷模块的数量 ) , 会导致模型预测性能下降。文献 [17]提出采用集成多个决策树基分类器的方法, 可以有效解决类数据不平衡对决策树分类性能的影响。

本文在现有研究工作的基础上, 针对静态代码度量属性, 提出了新的代价敏感分类算法用来构建模型, 并结合实践需求和软件缺陷数据的类不平衡特性, 给出代价因子的选择方法。

3代价敏感分类的决策树集成缺陷预测方法 3.1代价敏感分类

本文将预测结果为有缺陷的模块标注为 1, 预测结果为无缺陷的模块标注为 0。软件缺陷预测模型对未知软件模块进行分类预测时产生的 I 类错误代价可表示为 C (1 0) , II 类错误代价可表示为 C (0 1) 。根据上述分析可知 C (1 0) >C (0 1) 。因此考虑不同错误预测的代价, 进行代价敏感分类的软件缺陷预测模型构建在实践中更为有效。定义代价矩阵如表 1所示。

True

C (1 1) =0

C (1 0) =α

C (0 1) =1

C (0 0) =0

Predictive

Table 1Cost matrix

表 1代价矩阵

1444

根据代价矩阵, 定义代价函数 L , 该函数的值为

预测为不同类 (1或者 0) 的代价之和:

L (x ) =L (x 1) +L (x 0)

L (x 1) =Prob (x c =0)×C (0 1) +

Prob (x c =1)×C (1 1) L (x 0) =Prob (x c =0)×C (0 0) +Prob (x c =1)×C (1 0) 代价函数 L (x ) 表示对软件模块 x 进行缺陷预测的期望代价, 对于模块 x , 最小化 L (x i ) 等同于选择最优的缺陷预测分类结果, 其中 i ?{0 1}; Prob (x c =i ) 表示把模块 x 预测为 i 类的概率; C (i j ) 表示代价矩阵中的 i 行 j 列。假设对于软件模块 x , 构建好的缺陷预测模型将该模块预测为无缺陷的概率为 0.7, 根据代价函数的

定义, L (x 1) =0.7, L (x 0) =0.3′α。如果选择代价因子 α=1, 则 L (x 1) >L (x 0) , 最小化代价函数 L (x ) , 应该将该模块预测为无缺陷模块。如果选择代价因子 α=5, 则 L (x 0) =0.3′5=1.5, L (x 1) C (0 1) , 即代价因子 α>1。如果 α值选取过高, 则预测率降低, 误报率增高, 导致预测精度下降; 如果 α值选取过低, 不同预测错误的代价在预测模型中表现不明显。因此, 在模型构建过程中应该根据实际应用需求选择最合适的代价因子。 3.2算法提出在机器学习中, 提高分类器泛化性能最成功的一种泛型就是集成学习技术 [21]。集成学习起源于强可学习和弱可学习概念的提出, Schapire 通过构造性方法证明了可以将一个比随机猜测好的弱学习器提升为强学习器 [22]。在提升算法中最具有代表性的是 AdaBoost [23]和 Bagging [24]算法。文献 [25]采用多种集成分类算法构建软件缺陷预测模型, 实验结果表明, 采用投票表决集成方法构建的模型预测性能要优于其

他方法。因此本文采用 Bagging 方式从原始训练集有放回地随机选取若干样例组成基分类器训练集, 通过多次选取不同的训练集增加基分类器的差异度, 然后通过投票的方式决定最终的分类预测结果。由于决策树算法产生的规则易于理解, 分类速度快, 在集成算法的相关研究中, 通常采用决策树 C4.5算法 [26]构建基分类器, 通过集成多个基分类器提高泛化能力。 C4.5算法使用信息增益率作为决策属性的选择标准, 递归地构建决策树。给定训练集 D ,

D 1 D 2 D k 为选择某个属性划分的子集, 信息增益

率定义如下:

P (D

1 D 2 D k ) =Ent (D ) -?i =1k |

|D i D Ent (D i )

-?i =1k D i D lb D i D 其中 Ent 为熵, 训练集 D 的熵为:

Ent (D ) =-?y ?Y

p (y |D )lb p (y |D )

根据 3.1节定义的代价函数, 进行代价敏感分类时要求预测模型输出的是概率值。在 C4.5算法中可以通过计算其对应输出节点的类分布得到预测结果的概率分布。

代价敏感分类的决策树集成软件缺陷预测模型构

建算法 (cost-sensitive C4.5ensemble algorithm , CSCE )

描述如下。

输入:软件缺陷预测模型训练数据集 D ={(x 1 y 1)

(x 2 y 2) (x n y n )}, 其中 x i 是输入空间 X 中的实例,

y i 是输出空间 Y 中相应的缺陷标签, Y ={1 0}; 基分类器数 M ; 代价因子 α; 基分类器 C4.5学习算法 L 。

训练过程:对于 t =1 2 M 。

(1) 从训练集 D 可放回地随机抽取样例形成训练集 D t ;

(2) 使用 D t 作为训练集, 基于 α构建代价敏感分类的决策树模型 h t =L (D t a ) ;

(3) 将基分类器 h t 加入集成序列。

输出:最终分类器 H (x ) =arg max

?t =1

T II(h t (x ) =y ) 。

4实验仿真与分析

4.1软件缺陷预测模型评价指标

本文关注的是将软件模块预测为是否有缺陷的二分类问题, 表示该结果的混淆矩阵定义如表 2所示。

李勇等:代价敏感分类的软件缺陷预测方法

1445

Journal of Frontiers of Computer Science and Technology 计算机科学与探索 2014, 8(12)

4.1.1预测率 PD 和误报率 PF

软件缺陷预测的目的是尽可能多地找到有缺陷的模块, 尽量减少将无缺陷模块预测为有缺陷模块的数量。根据混淆矩阵的定义, 预测率 (probability of detection , PD ) 定义为 :PD =TP /(TP +FN ) ; 误报率 (probability of false alarm , PF ) 定义为 :PF =FP / (FP +TN ) 。一个好的预测模型应该是具有较高的预测率, 较低的误报率。

4.1.2综合评价指标 AUC 值

为了权衡预测率和误报率, 在实验中采用不平衡数据分类算法评价常用的 ROC (receiver operating characteristic ) 曲线, 该曲线是模型预测率和误报率之间折中的一种图形化方法。 AUC (area under the curve ) 值为 ROC 曲线下方的面积, 提供了评价模型平均性能的另一种方法, AUC 值越大, 模型越好。理想模型的 AUC 值为 1, 随机猜测模型的 AUC 值为 0.5。 4.1.3综合评价指标 F 值

有缺陷模块预测的准确率 (precision , P ) 定义为 P =TP /(TP +FP ) , 表示被正确预测为有缺陷模块的比例; 召回率 (recall , R ) 定义为 R =TP /(TP +FN ) , 表示缺陷模块被正确预测的完整度, 与上述定义的预测率相等。在此基础上定义 F 值 (F-value , F ) :F = 2PR /(P +R ) , 表示准确率和召回率的加权调和平均, 综合了准确率和召回率的结果, 有利于软件缺陷预测模型综合性能的评价。

4.2实验环境

为了便于实验比较, 从 PROMISE 数据库中选择 10个 NASA 软件预测数据集作为实验数据。该数据集是美国航空航天局公布的专门用于构建软件缺陷预测模型的公开数据集, 其中每个软件模块的度量属性包括 Halstead 属性、 McCabe 属性、代码行数以及其他属性。为了比较数据不平衡性对算法的影响, 以及与代价因子取值的关系, 所选 10个数据集按照缺陷模块所占比例排序。数据集信息如表 3所示。

在实验过程中, 为了消除属性值之间数值差距较大对分类算法的影响, 有文献提出在预处理中采用取对数化的方式。文献 [4]通过实验表明, 取对数化后对朴素贝叶斯算法构建的模型性能提升较大, 但文献 [27]表明取对数化对决策树算法构建的模型性能没有影响。因此在本文的实验中, 采用朴素贝叶斯算法构建模型时, 为了获得最佳性能, 对属性值进行对数化预处理, 同时避免对属性中的零值取对数, 采取加一个极小值的方法取对数, 具体操作为: ifelse(A <=0,ln(a +0.000001),="" ln(a="">

在实验中采用分层十折交叉验证, 将每个数据集随机分为 10份, 每份中类比例与数据集中的类比例要求基本一致。每份依次轮流被旁置, 其余 90%的数据则参与某一算法的训练, 而旁置的数据集则用于模型测试。学习过程共进行 10次, 每次使用不同的训练集。最后将每个算法 10次测试所取得的预测率 PD 、误报率 PF 、 AUC 值和 F 值取平均得到其评价指标。

4.3代价敏感分类中代价因子的选择

代价因子的取值决定着模型的预测性能, 由于综合评价指标 AUC 值综合了预测率和误报率, 在实

1 0

True

TP (true positvie )

FN (false negative )

FP (false positive ) TN (true negative )

Predictive Table 2Confusion matrix

表 2混淆矩阵

Data

MC2

KC2

PC5

KC1

PC4

KC3

PC3

MW1

PC1

MC1

Language

C++

Java

Attributes

Examples

155

325

1694

1162

1270

324

1409

375

919

1952

Defect/(%) 32.9 28.3 27.0 25.3 13.9 13.0 10.5 7.5 6.5 1.8 Table 3Information of experimental datasets 表 3实验数据集

1446

践中可以选择 AUC 值作为优化目标, 选择最合适的代价因子 α值。本节以 PC4数据集为例, 给出实验中代价因子 α的选择过程。在采用 CSCE 算法构建预测模型时, 代价因子 α 1。当 α=1时, 表示错误分类的代价相等; 当 α>1时, 表示将有缺陷模块预测为无缺陷的代价要高。图 1所示为不同代价因子取值时所获得的预测率和误报率在 ROC 图中的分布。预测率 PD 较低意味着没有找全缺陷模块, 误报率 PF 较高意味着会浪费较多的开发资源去测试本来没有缺陷的模块。从图 1中可以得出以下结论:(1) 当 α=1时, 误报率 PF 虽然仅为 4.5%, 但预测率 PD 为 51.1%, 低于人工代码审查缺陷预测率 (60%以上 ) 。也就是说, 当选择相等的错误分类代价时, 采用决策树集成方法构建的缺陷预测模型无实用意义。 (2) 随着 α值的增大, 模型的预测性能在提高, 当 α=50时, 预测率 PD 为 95.5%, 误报率 PF 为 24.9%, AUC 值最高。可以认为 α=50为 CSCE 算法在对 PC4数据集构建缺陷预测模型时的 “近似最优代价因子” 。 (3) 当 α>50时, 综合评价指标 AUC 值在下降, 但预测率 PD 最高可达 97.2%, 适用于测试资源充足, 对系统可靠性要求较高的情况。为了与其他方法对比, 在 4.4节的实验结果分析中, 均取近似最优代价因子构建模型进行结果比较。图 2给出了各个数据集中缺陷模块比率与近似

最优代价因子的取值, 可以看出随着类不平衡率的提高, 近似最优代价因子的值也在提高。可解释为当缺陷模块比例越小, 即类数据的不平衡程度提高时, 需要提高有缺陷模块的代价, 只有获得分类器的足够 “重视” , 才能取得期望的预测性能。

4.4实验结果分析

对所选的 10个 NASA 缺陷预测数据集选择决策

树 C4.5算法、文献 [18]中提出的预测性能较好的随机

森林 (RF ) 和朴素贝叶斯 (NB ) 算法, 与本文提出的 CSCE 算法 (为了便于比较, 均选择 4.3节中提出的 “近似最优代价因子” ) 分别构建缺陷预测模型, 采用十折交叉验证方法计算预测率 PD 、误报率 PF 、综合

评价指标 AUC 和 F 值。便于直观比较 4种算法的性能, 图 3所示为所有实验结果的盒须图。

4.4.1预测率 PD 实验结果分析

表 4所示为 4种算法构建模型的预测率实验结

果。可以得出以下结论:

(1) C4.5算法和随机森林算法构建的预测模型预测率平均值最低, 而且随着类数据不平衡性的提高, 预测率也在降低, 也验证了文献 [14]中提出的决策树算法对类数据的不平衡性较为敏感的特点。

1.00.90.80.7

0.6

0.50.4

0.30.20.1预测率

P D 0.10.20.30.40.50.60.70.80.91.0误报率 PF 0α=90α=50α=10α=1Fig.1ROC(PD PF ) of different cost-factor on PC4

图 1PC4数据集中不同代价因子的预测率和误报率 ROC 图 103.301102.176

2.00010

1.778101.602101.699101.000

101.000100.903100.903104

103102101100

10-1

0取值

P C 1M W 1P C 3K C 3P C 4K C 1P C 5K C 2M C 2近似最优代价因子

缺陷模块所占比率

Fig.2Defect modules percentage and the

approximate optimal αvalue

图 2缺陷模块比率与近似最优代价因子 α的取值

李勇等:代价敏感分类的软件缺陷预测方法

1447

Journal of Frontiers of Computer Science and Technology 计算机科学与探索 2014, 8(12)(2) 朴素贝叶斯算法和 CSCE 算法构建的模型预测率平均在 80%以上, 验证了算法的有效性。从图 3的预测率盒须图中也可以直观看出 CSCE 算法的稳定性要高于朴素贝叶斯算法。 4.4.2误报率 PF 实验结果分析表 5所示为 4种算法构建模型的误报率实验结果。可以得出以下结论:(1) 决策树 C4.5算法和随机森林算法构建的预测模型误报率较低, 随机森林作为决策树的一种集成方式, 比决策树 C4.5算法的误报率大约降低了 50个百分点。 (2) 朴素贝叶斯算法的误报率平均达到 40%左右, CSCE 算法误报率平均在 35%左右, 比朴素贝叶斯算法大约降低了 5个百分点。 (3) 从图 3误报率的盒须图中可以直观地看出, 决策树 C4.5算法和随机森林算法的误报率要优于朴素贝叶斯算法和 CSCE 算法。但由于其预测率较低 (平均低于 30%) , 实用意义较差。

4.4.3AUC 和 F 值实验结果分析

表 6所示为 4种算法构建模型的综合评价指标 AUC 和 F 值的实验结果。可以得出以下结论:

(1) 对于综合评价指标 AUC 值, 除 C4.5算法外, 其他 3种算法均在 0.750以上。随机森林算法的 AUC

值较高, 是因为其预测率和误报率均较低所致, 也说明了单独使用 AUC 值作为评价缺陷预测模型性能的指标是不合理的。 CSCE 算法与朴素贝叶斯算法比较, AUC 值平均提高了大约 4个百分点。

(2) 对于综合评价指标 F 值, CSCE 算法比 C4.5

算法和随机森林算法平均提高了大约 8个百分点, 比朴素贝叶斯算法平均提高了大约 2.5个百分点。

(3) 从图 3所示的 AUC 和 F 值盒须图中也可以直观看出, CSCE 算法构建预测模型的 AUC 和 F 值要优于其他 3种方法。

Data MC2KC2PC5KC1PC4KC3PC3MW1PC1MC1Average C4.50.2500.1500.1550.1110.0680.0640.0460.0290.0160.0040.089RF 0.1150.1290.0950.0690.0260.0180.0210.0090.0080.0020.049NB 0.4710.4250.4740.6470.2720.4890.3880.2970.3070.3850.416CSCE

0.567

0.369

0.431

0.471

0.249

0.358

0.294

0.259

0.297

0.280

0.358

Table 5PF results of four methods

表 54种算法构建模型的误报率实验结果

1.0

0.9

0.8

0.7

0.60.50.40.30.2

0.10评价指标值 PD PF AUC F C S

C E

N B R F C 4. 5C S

C E N B R

F C 4. 5C S C E N B

R F C 4

. 5C S C E N B R F C 4. 5

Fig.3Performance deltas for PD , PF , AUC and F 图 3不同算法构建模型的评价指标盒须图 Data MC2KC2PC5KC1PC4KC3PC3MW1PC1MC1Average C4.50.3730.4570.4720.3440.4830.1900.1960.1790.1670.0280.289RF 0.3530.4780.3970.2930.3240.0480.1150.2500.1330.0560.245NB 0.7250.8800.8300.8610.8520.8810.8510.6790.7330.7500.804CSCE 0.8240.8150.8470.7210.9550.762

0.7700.7140.8170.8330.806Table 4PD results of four methods 表 44种算法构建模型的预测率实验结果

1448

5结束语构建软件缺陷预测模型的目标是尽可能地提高缺陷模块的预测率, 同时降低误报率。由于预测模型对错误分类的代价不同, 在 “容忍” 一定误报率的前提下, 尽可能地提高软件缺陷的预测率会更加符合软件工程的实践需求。本文针对代码方法级度量属性, 在现有研究成果的基础上提出了代价敏感分类的决策树集成软件缺陷预测模型构建方法, 并给出了代价因子选择方法。采用公开的软件缺陷预测数据集进行了实验, 结果表明本文方法构建的模型具有更好的准确性和稳定性, 有利于软件缺陷预测技术的实践应用。下一步的研究工作包括:(1) 如何根据预定的需求指标, 实现代价因子的自动选择。 (2) 对更多的算法进行测试, 进一步验证本文方法的有效性。 References:[1]Lu Minyan. Software reliability engineering[M].Beijing:National Defence of Industry Press, 2011:8-12. [2]Monden A, Hayashi T, Shinoda S, et al. Assessing the cost effectiveness of fault prediction in acceptance testing[J].IEEE Transactions on Software Engineering, 2013, 39(10):

1345-1357.

[3]Catal C, Diri B. A systematic review of software fault pre-diction studies[J].Expert Systems with Applications, 2009, 36(4):7346-7354.

[4]Menzies T, Greenwald J, Frank A. Data mining static code attributes to learn defect predictors[J].IEEE Transactions

on Software Engineering, 2007, 33(1):2-13.

[5]Shull F, Basili V , Boehm B, et al. What we have learned about fighting defects[C]//Proceedingsof the 8th IEEE Sympo-sium on Software Metrics (METRICS?02). Washington, DC, USA:IEEE Computer Society, 2002:249-258.

[6]Radjenovi ?D, Heri ?ko M, Torkar R, et al. Software fault

prediction metrics:a systematic literature review[J].Infor-

mation and Software Technology, 2013, 55(8):1397-1418. [7]Hall T, Beecham S, Bowes D, et al. A systematic literature

review on fault prediction performance in software engi-

neering[J].IEEE Transactions on Software Engineering,

2012, 38(6):1276-1304.

[8]Catal C. Performance evaluation metrics for software fault

prediction studies[J].Acta Polytechnica Hungarica, 2012,

9(4):193-206.

[9]Lanubile F, Visaggio G. Evaluating predictive quality models

derived from software measures:lessons learned[J].Journal of Systems and Software, 1997, 38(3):225-234.

Data MC2KC2PC5KC1PC4KC3PC3MW1PC1MC1Average AUC C4.50.5630.6770.6640.6240.7940.6230.6140.4900.5890.5360.617RF 0.6180.7910.7720.7040.9090.6870.7590.7210.8010.8180.758NB 0.6830.8320.7430.6790.8470.7450.7790.7690.7680.7100.756CSCE 0.7060.8260.7860.7110.9080.7520.7950.7760.8430.8250.793F

C4.50.3960.4970.4990.4110.5070.2350.2470.2330.2380.0440.331RF 0.4440.5300.4810.3910.4370.0820.1780.3680.2130.0980.322NB 0.5400.5960.5340.4560.4810.3410.3300.2530.2390.0680.384CSCE

0.553

0.593

0.563

0.463

0.531

0.366

0.360

0.290

0.269

0.1000.409

Table 6AUC and F results of four methods

表 64种算法构建模型的 AUC 和 F 值结果

李勇等:代价敏感分类的软件缺陷预测方法

1449

Journal of Frontiers of Computer Science and Technology 计算机科学与探索 2014, 8(12)

[10]Menzies T, Caglayan B, Kocaguneli E, et al. The promise repository of empirical software engineering data[EB/OL].(2012)[2014-06-16].http://promisedata.googlecode.com.[11]McCabe T J. A complexity measure[J].IEEE Transactions on Software Engineering, 1976, 2(4):308-320. [12]Halstead M H. Elements of software science (operatingand programming systems series) [M].[S.l.]:Elsevier Science Inc, 1977:128. [13]Knab P, Pinzger M, Bernstein A. Predicting defect densities in source code files with decision tree learners[C]//Proceedingsof the 2006International Workshop on Mining Software Repositories (MSR?06), Shanghai, China, 2006. New York, NY , USA:ACM, 2006:119-125. [14]Arisholm E, Briand L C, Fuglerud M. Data mining techniques for building fault-proneness models in telecom Java soft-ware[C]//Proceedingsof the 18th IEEE International Sym-posium on Software Reliability (ISSRE?07), Trollhattan, Sweden, 2007. Piscataway, NJ, USA:IEEE, 2007:215-224. [15]Kanmani S, Uthariaraj V R, Sankaranarayanan V , et al. Object-oriented software fault prediction using neural networks[J].Information and Software Technology, 2007, 49(5):483-492. [16]Wang Tao, Li Weihua, Liu Zun, et al. A software DP (defectsprediction) model based on SVM[J].Journal of Northwestern Polytechnical University, 2011, 29(6):864-870. [17]Wang Shou, Yao Xin. Using class imbalance learning for software defect prediction[J].IEEE Transactions on Reli-ability, 2013, 62(2):434-443. [18]Catal C, Diri B. Investigating the effect of dataset size, metrics

sets, and feature selection techniques on software fault pre-diction problem[J].Information Sciences, 2009, 179(8):1040-1058. [19]Moser R, Pedrycz W, Succi G. A comparative analysis of the efficiency of change metrics and static code attributes for defect prediction[C]//Proceedingsof the 30th International

Conference on Software Engineering (ICSE?08), Leipzig, Germany, 2008. New York, NY , USA:ACM, 2008:181-190.

[20]Menzies T, Turhan B, Bener A, et al. Implications of ceiling

effects in defect predictors[C]//Proceedingsof the 4th Inter-

national Workshop on Predictor Models in Software Engi-

neering (PROMISE?08), Leipzig, Germany, 2008. New York, NY , USA:ACM, 2008:47-54.

[21]Zhou Zhihua. Ensemble methods:foundations and algo-

rithms[M].[S.l.]:CRC Press, 2012.

[22]Schapire R. The strength of weak learnability[J].Machine Learning, 1990, 5(2):197-227.

[23]Freund Y , Schapire R E. A desicion-theoretic generalization

of on-line learning and an application to boosting[C]//LNCS

904:Proceedings of the 2nd European Conference on Compu-tational Learning Theory (EuroCOLT?95), Barcelona, Spain, Mar 13-15, 1995. Berlin, Heidelberg:Springer, 1995:23-37. [24]Breiman L. Bagging predictors[J].Machine Learning, 1996,

24(2):123-140.

[25]Wang Tao, Li Weihua, Shi Haobin, et al. Software defect prediction based on classifiers ensemble[J].Journal of Infor-

mation and Computational Science, 2011, 8(16):4241-4254.

[26]Quinlan J R. C4. 5:programs for machine learning[M].San Francisco, CA, USA:Morgan Kaufmann, 1993.

[27]Song Qinbao, Jia Zihan, Shepperd M, et al. A general software

defect-proneness prediction framework[J].IEEE Transac-tions on Software Engineering, 2011, 37(3):356-370.

附中文参考文献:

[1]陆民燕 . 软件可靠性工程 [M].北京 :国防工业出版社 , 2011:8-12.

[16]王涛 , 李伟华 , 刘尊 , 等 . 基于支持向量机的软件缺陷预测

模型 [J].西北工业大学学报 , 2011, 29(6):864-870.

LI Yong was born in 1983. He is a Ph.D. candidate at Nanjing University of Aeronautics and Astronautics, and

the member of CCF. His research interests include software engineering and data mining, etc.

李勇 (1983— ) , 男, 山西晋中人, 南京航空航天大学博士研究生, CCF 会员, 主要研究领域为软件工程, 数据

挖掘等。

1450

HUANG Zhiqiu was born in 1965. He received the Ph.D. degree in computer software from Nanjing University

of Aeronautics and Astronautics in 1999. Now he is a professor and Ph.D. supervisor at Nanjing University of

Aeronautics and Astronautics, and the senior member of CCF. His research interests include software engineering

and software metrics, etc.

黄志球 (1965— ) , 男, 江苏南京人, 1999年于南京航空航天大学计算机软件专业获得博士学位, 现为南京航

空航天大学教授、博士生导师, CCF 高级会员, 主要研究领域为软件工程, 软件度量等。

FANG Bingwu was born in 1974. He is a Ph.D. candidate at Nanjing University of Aeronautics and Astronautics.

His research interests include software security and Web service, etc.

房丙午 (1974— ) , 男, 安徽合肥人, 南京航空航天大学博士研究生, 主要研究领域为软件安全, Web 服务等。

WANG Yong was born in 1979. He is a Ph.D. candidate at Nanjing University of Aeronautics and Astronautics.

His research interests include software metrics and software testing, etc.

王勇 (1979— ) , 男, 安徽芜湖人, 南京航空航天大学博士研究生, 主要研究领域为软件度量,

软件测试等。

《计算机科学与探索》为月刊 , 大 16开 , 单价 40元 , 全年 12期总订价 480元 , 邮发代号:82-560。

邮局汇款地址:

北京 619信箱 26分箱《计算机科学与探索》杂志社 (收 ) 邮编:100083

《计算机工程与应用》为半月刊 , 大 16开 , 每月 1日、 15日出版 , 单价 45元 , 全年 24期总订价 1080元 , 邮发代号:82-605。邮局汇款地址:

北京 619信箱 26分箱《计算机工程与应用》杂志社 (收 ) 邮编:100083

欢迎到各地邮局或编辑部订阅。个人从编辑部直接订阅可享受 8折优惠!

发行部

电话:(010)89055541欢迎订阅 2015年《计算机科学与探索》、《计算机工程与应用》杂志

李勇等:代价敏感分类的软件缺陷预测方法

1451

代价敏感分类的软件缺陷预测方法

作者:李勇 , 黄志球 , 房丙午 , 王勇 , LI Yong, HUANG Zhiqiu, FANG Bingwu, WANG Yong

作者单位:李勇,LI Yong(南京航空航天大学计算机科学与技术学院,南京 210016; 新疆师范大学网络信息安全与舆情分析重点实验室,乌鲁木齐 830054), 黄志球,房丙午,王勇,HUANG Zhiqiu,FANG

Bingwu,WANG Yong(南京航空航天大学计算机科学与技术学院,南京,210016)

刊名:

计算机科学与探索

英文刊名:Journal of Frontiers of Computer Science & Technology

年,卷(期):2014(12)

引用本文格式:李勇 . 黄志球 . 房丙午 . 王勇 . LI Yong. HUANG Zhiqiu. FANG Bingwu. WANG Yong代价敏感分类的软件缺陷预测方法 [期刊论文]-计算机科学与探索 2014(12)

转载请注明出处范文大全网 » 软件缺陷的分类与管理