软件的缺陷分析

软件的缺陷分析
一、缺陷分析的作用
软件缺陷不只是通常所说程序中存在的错误或疏忽，即俗称的Bug。

其范围更大，除程序外还包括其相关产品：项目计划、需求规格说明、设计文档、测试用例、用户手册等等中存在的错误和问题。

需要强调，在软件工程整个生命周期中任何背离需求、无法正确完成用户所要求的功能的问题，包括存在于组件、设备或系统软件中因异常条件不支持而导致系统的失败等都属于缺陷的范畴。

软件测试的任务就是发现软件系统的缺陷，保证软件的优良品质。

但在软件中是不可能没有缺陷的。

即便软件开发人员，包括测试人员尽了努力，也是无法完全发现和消除缺陷。

如何做到最大限度地发现软件系统的缺陷，人们首先想到提高开发人员的素质和责任心，科学地应用测试方法和制定优秀的测试方案。

但这是不够的，我们还需要实施缺陷分析。

缺陷分析是将软件开发、运行过程中产生的缺陷进行必要的收集，对缺陷的信息进行分类和汇总统计，计算分析指标，编写分析报告的活动。

通过缺陷分析，发现各种类型缺陷发生的概率，掌握缺陷集中的区域、明晰缺陷发展趋势、了解缺陷产生主要原因。

以便有针对性地提出遏制缺陷发生的措施、降低缺陷数量。

对于改进软件开发，提高软件质量有着十分重要的作用。

缺陷分析报告中的统计数据及分析指标既是对软件质量的权威评估，也是判定软件是否能发布或交付使用的重要依据。

二、管理软件的缺陷分析
不同于系统、工具、工控、游戏等软件，管理软件在实际运行时面临情况要复杂得多。

首先是用户的需求更加不统一，而且随时间的推移需求发生变化快、变化大；其次运行环境更复杂，除受操作系统、数据库等影响外，用户在网络、甚至同一计算机安装运行不同性质和背景的应用软件，其影响很难预测；再者客户的操作习性不同，等等。

因此管理软件的种种缺陷，不是在开发时通过测试都能预计的。

预测并控制缺陷有效手段之一是缺陷分析。

在高级别的CMM 中就包含了缺陷分析活动。

缺陷分析更是一种以发展方式进行软件过程改进的机制。

三、缺陷的信息收集
软件工程通常要求为开发项目建立缺陷管理库，也有人称为变更控制库。

从发现缺陷开始创建变更，直到缺陷解决、经验证、关闭变更止。

在缺陷管理的整个生命周期记录了大量相关资料，它们是缺陷分析所需要的宝贵信息。

由于变更库并不专为缺陷分析而设计，缺陷分析主要关心以下信息项：变更编号、变更主题、变更提交的日期、变更状态、变更性质、变更解决的日期、变更产生的根本原因、解决变更的工作量、验证变更的工作量、变更的严重性等级、变更所属软件产品及子系统、变更修改的模块、变更产生的阶段、变更来源、变更测试情况等。

缺陷信息部分是在创建变更时输入的，部分是在变更解决中或解决后输入的。

为了实施统计，有些缺陷信息必需事先设定关键字。

变更控制库中有一信息项——变更原因，由修改缺陷程序的程序员详细记录缺陷产生的具体原因。

这项信息显然无法直接用于分类和汇总。

变更产生的根本原因信息项，则是基于变更原因的关键字字段，是专为处理缺陷分析中缺陷原因而设计的信息项。

软件发布前缺陷分析所用缺陷根本原因的关键字，可以有下几种实例：
* 编程：原始编程出错，没有客观原因。

* 修改：由于修改缺陷而引发的新变更，并且引发的变更与原变更的错误是相关的。

* 培训：项目组新成员培训不充分，或使用新工具不熟练引起的变更。

* 需求文档：需求分析文档不明确、不详尽等原因所引起的变更。

* 信息交流：信息交流不畅，开发成员间沟通不及时引起的变更。

* 外部问题：所涉及软件模块外部问题引起的变更。

* 其他：指以上各种原因之外所产生的变更。

软件发布后缺陷分析所用缺陷根本原因的的关键字，可以有下几种实例：
* 需求分析：需求分析不足等原因所引起的变更。

* 系统设计：软件系统设计种种原因所引起的变更。

* 程序编码：软件开发阶段中编程错误所引起的变更。

* 维护：软件发布后程序维护时引起的变更。

* 实施：实施人员做软件初始化设置或系统参数设置不当等，实施时所引发的变更。

* 用户：泛指用户不了解业务和软件、不熟悉操作等原因产生的异常问题。

* 数据异常：运行中不明原因引起的用户数据混乱和异常。

* 升级：软件版本升级过程发生的问题，包括用户在升级时未按规程操作产生的问题。

* 外部问题：所涉及软件外部问题引起的变更，包括属操作系统、数据库软件、第三方软件所引起的问题。

* 错误变更：错误地提交的变更。

包括无法重现出错、所列现象不是错误的变更。

* 其他：指以上各种原因之外的变更，包括变更原因不明。

测试情况信息项是应用于分析缺陷是如何通过测试关的。

可以有以下几种实例：
* 漏测试：软件发布前测试时没有被发现的缺陷，也没有对应测试用例。

* 条件冷僻：缺陷形成条件很冷僻，设计测试用例时很难考虑到。

* 回归测试：专指那些原先测试时是通过的、不存在错误，后来由于修改其他程序时产生的缺陷。

关键是软件版本或补丁发布前未进行回归测试，因而被漏过。

* 判断标准：测试时已发现该现象但当时不认为是问题，没提交变更。

* 已测试：测试时已发现缺陷并提交变更，但缺陷没解决。

有些计算分析指标用到的信息在变更库中是没有的，可通过其他渠道获取。

例如：软件规模（软件源代码的行数，单位是千行）、开发人员的平均人力成本（单位是元/人天）、软件持续运行时间（在开发阶段以软件测试的工作量来替代）、项目总工作量等。

记录缺陷信息的关键是注意信息正确性。

不能有人为因素失真，尤其像变更产生根本原因、变更测试情况。

只有正确的信息，才能保障正确的分析结果。

四、缺陷的分析
1、分析指标
缺陷分析时需计算一些分析指标，使分析结果得到度量，以便直观比对。

分析指标有以下几项：
* 反映产品质量的指标：
缺陷密度 = 缺陷数量 / 软件规模
潜在缺陷概数 = (100% - 发布前缺陷去处率) * 缺陷密度
* 反映产品可靠性的指标：
平均失效时间 = 软件持续运行时间 / 缺陷数量
* 反映缺陷发现及修复的效率的指标：
缺陷检出率 = 某阶段当时发现的缺陷 / 属该阶段的全部缺陷 * 100%
发布前缺陷去处率 = 发布前发现的缺陷 / (发布前发现的缺陷 + 软件运行的前 3个月发现的缺陷)* 100%
缺陷修正率 = 修复过程中未引发其他问题的缺陷数 / 被修复缺陷的总数 *100%
* 反映缺陷修复成本的指标：
平均修复时间 = ∑缺陷修复时间 / 缺陷数量
平均修复成本 = 开发人员的平均人力成本 * 平均修复时间
相对返工成本 = 返工的工作量 / 项目总工作量 *100%
2、汇总统计
在缺陷分析中可以使用统计方法对收集的变更进行分类、汇总。

* 缺陷发生日期统计：是按变更提交的年月统计。

分析反映缺陷发生的动态趋势。

* 缺陷性质统计：变更性质属性一般分为：缺陷变更和需求变更两种。

* 缺陷状态分布：变更状态属性分类很多，但在缺陷分析中没必要分那么细，故按 3 种统计：关闭、挂起和处理中。

分析主要反映缺陷修改完成情况。

* 缺陷按产品分类统计：该分析能显示各软件子系统的缺陷分布情况。

* 缺陷按原因分类统计：是按变更的根本原因属性进行分类统计，统计不包括需求变更。

该分析能揭示缺陷原因的分布。

* 缺陷测试情况统计：统计仅涉及变更的根本原因是系统设计、程序编码、维护和外部问题等缺陷变更。

该分析能暴露软件测试本身存在的问题。

* 缺陷来源统计：该分析主要反映用户或软件代理的地区分布，发现一些客户分布规律。

分析统计表、图可按单一属性，也可按多个属性进行汇总统计。

请看以下几个实例。

附表一、缺陷变更原因统计表
2004/10 2004/11 2004/12 小计
变更的原因
数量 % 数量 % 数量 % 数量 %
程序编码问题 7 29 5 20 5 20 17 23
系统设计问题 2 8 1 4 3 4
维护 2 8 6 24 4 16 12 16
外部问题 0 1 4 1 4 2 3
需求分析 1 4 2 8 4 16 7 10
实施 3 12 4 16 7 10
升级问题 2 8 1 4 3 4
数据异常 2 8 4 16 2 8 8 11
用户 1 4 2 8 3 4
错误变更 1 4 1 4 7 28 9 12
其它 3 12 3 4
变更总数 24 25 25 74
附表二：程序缺陷变更测试情况统计表
测试情况
缺陷变更原因变更数
漏测试条件冷僻回归测试判断标准已测试
程序编码问题 20 7 5 4 4
系统设计问题 3 1 2
维护问题 12 12
外部问题 1 1
合计 36 8 5 16 4 3
附图：缺陷按产品分布图
3、定性分析
在分析指标、统计数据的基础上，还需要对软件的缺陷状况进行定性的分析，得出结论意见。

必要时可召开相关人员的分析会进行分析和讨论。

例如，根据上述附表二程序缺陷变更测试情况统计表，可以得到以下几点看法：
①在缺陷中高达 92%的变更与测试把关不严有关。

其中 22%的变更属于明显漏测试。

②其中 44%的变更属于在回归测试环节出问题。

在维护阶段修改缺陷程序后只对变更本身进行验证，而没有进行回归测试，引发了新的缺陷。

③其中 8%的缺陷在软件发布前已测试发现，但没有给予解决。

根据上述分析，可采取针对性措施：
①增加测试的强度。

将缺陷所发现的问题，增补到测试用例中。

②软件维护阶段的软件补丁必需通过回归测试，才能发布。

③软件发布时对未关闭的变更需严加把关。

五、软件发布前和发布后的缺陷分析
缺陷分析有两种：软件发布前和软件发布后的缺陷分析。

两者的区别是：
①分析的变更不同
前者分析的对象是软件开发阶段发生的缺陷，居多是软件程序代码的缺陷。

软件发布后的缺陷分析，分析的对象是软件运行阶段发生的缺陷。

现在更多是：软件实施、维护、用户操作所发生的异常问题，不明原因引发的数据混乱，软件版本升级或各种运行环境引起的系统错误，还有用户提出的新的需求变更。

②分析的目的也不同
软件发布前的缺陷分析主要是通过计算缺陷指标，评估开发阶段软件的质量，预测软件上市后的运行情况，判定软件产品是否能够发布。

软件发布后的缺陷分析是通过定期分析掌握缺陷的分布和发展趋势，以便控制缺陷的发生，降低维护成本。

③分析的内容不同
大部分的计算指标是适用于发布前缺陷分析，象发布前缺陷去处率是专为其设计的。

但分类统计只有状态分布和按原因分类统计比较适用。

对发布后缺陷分析而言，大部分计算指标不适用。

仅平均修复时间指标比较重要，它反映了维护阶段处理缺陷的效率。

各分类统计基本都适用于发布后缺陷分析，象缺陷测试情况统计、缺陷来源统计等是专为发布后分析设计的。

缺陷分析除了应用在软件开发阶段。

在软件发布后或交付使用后，同样应重视缺陷分析的作用。

当软件产品推向市场后，将真正面临考验，涌现大量缺陷也会时有发生。

若处理延误或不当，就会遭到用户的抱怨和投诉。

不能简单地靠增加维护人员来应对，这会造成维护成本的提高。

必需靠科学的手段来揭示软件缺陷偏多的内在规律和症结所在，有效地遏制缺陷的发生，给用户一个满意的交代。

六、结束语
我们知道了缺陷分析的作用，但在实际中往往还是没有对缺陷分析给予足够的重视。

主要由于借助于变更管理、CMM 的有关活动，完全可以掌控开发过程中缺陷情况，因而容易忽视缺陷分析活动的正常开展，甚至认为它是多余的。

再者缺陷分析需要收集大量缺陷信息，是一项费时费力的工作。

而且一些分析指标数据没有长期的积累其指导意义并不大。

因此缺陷分析需要制度化、纳入日常工作中定期进行。

为确保缺陷分析活动的开展，机构的高层领导也应予以重视，给予资金、人力及其他资源的支持。

尤其当缺陷分析的结果涉及到需要改变机构的组织或机构标准软件过程时，高层领导必须直接参与，使措施落到实处，控制产生缺陷的共同原因。