一、缺陷分析的作用
软件缺陷不只是通常所说程序中存在的错误或疏忽，即俗称的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、定性分析
在分析指标、统计数据的基础上，还需要对软件的缺陷状况进行定性的分析，得出结论意见。必要时可召开相关人员的分析会进行分析和讨论。
例如，根据上述附表二程序缺陷变更测试情况统计表，可以得到以下几点看法：
