软件的缺陷分析
软件的缺陷分析
一、缺陷分析的作用
软件缺陷不只是通常所说程序中存在的错误或疏忽，即俗称的Bug。其范围更大，除程序外还包括其相关产品：项目计划、需求规格说明、设计文档、测试用例、用户手册等等中存在的错误和问题。需要强调，在软件工程整个生命周期中任何背离需求、无法正确完成用户所要求的功能的问题，包括存在于组件、设备或系统软件中因异常条件不支持而导致系统的失败等都属于缺陷的范畴。
软件测试的任务就是发现软件系统的缺陷，保证软件的优良品质。但在软件中是不可能没有缺陷的。即便软件开发人员，包括测试人员尽了努力，也是无法完全发现和消除缺陷。
如何做到最大限度地发现软件系统的缺陷，人们首先想到提高开发人员的素质和责任心，科学地应用测试方法和制定优秀的测试方案。但这是不够的，我们还需要实施缺陷分析。缺陷分析是将软件开发、运行过程中产生的缺陷进行必要的收集，对缺陷的信息进行分类和汇总统计，计算分析指标，编写分析报告的活动。
通过缺陷分析，发现各种类型缺陷发生的概率，掌握缺陷集中的区域、明晰缺陷发展趋势、了解缺陷产生主要原因。以便有针对性地提出遏制缺陷发生的措施、降低缺陷数量。对于改进软件开发，提高软件质量有着十分重要的作用。
缺陷分析报告中的统计数据及分析指标既是对软件质量的权威评估，也是判定软件是否能发布或交付使用的重要依据。
二、管理软件的缺陷分析
不同于系统、工具、工控、游戏等软件，管理软件在实际运行时面临情况要复杂得多。首先是用户的需求更加不统一，而且随时间的推移需求发生变化快、变化大；其次运行环境更复杂，除受操作系统、数据库等影响外，用户在网络、甚至同一计算机安装运行不同性质和背景的应用软件，其影响很难预测；再者客户的操作习性不同，等等。因此管理软件的种种缺陷，不是在开发时通过测试都能预计的。预测并控制缺陷有效手段之一是缺陷分析。
在高级别的CMM 中就包含了缺陷分析活动。缺陷分析更是一种以发展方式进行软件过程改进的机制。
三、缺陷的信息收集
软件工程通常要求为开发项目建立缺陷管理库，也有人称为变更控制库。从发现缺陷开始创建变更，直到缺陷解决、经验证、关闭变更止。在缺陷管理的整个生命周期记录了大量相关资料，它们是缺陷分析所需要的宝贵信息。
由于变更库并不专为缺陷分析而设计，缺陷分析主要关心以下信息项：变更编号、变更主题、变更提交的日期、变更状态、变更性质、变更解决的日期、变更产生的根本原因、解决变更的工作量、验证变更的工作量、变更的严重性等级、变更所属软件产品及子系统、变更修改的模块、变更产生的阶段、变更来源、变更测试情况等。缺陷信息部分是在创建变更时输入的，部分是在变更解决中或解决后输入的。
为了实施统计，有些缺陷信息必需事先设定关键字。
变更控制库中有一信息项——变更原因，由修改缺陷程序的程序员详细记录缺陷产生的具体原因。这项信息显然无法直接用于分类和汇总。变更产生的根本原因信息项，则是基于变更原因的关键字字段，是专为处理缺陷分析中缺陷原因而设计的信息项。
软件发布前缺陷分析所用缺陷根本原因的关键字，可以有下几种实例：
* 编程：原始编程出错，没有客观原因。
* 修改：由于修改缺陷而引发的新变更，并且引发的变更与原变更的错误是相关的。
* 培训：项目组新成员培训不充分，或使用新工具不熟练引起的变更。
* 需求文档：需求分析文档不明确、不详尽等原因所引起的变更。
* 信息交流：信息交流不畅，开发成员间沟通不及时引起的变更。
* 外部问题：所涉及软件模块外部问题引起的变更。
* 其他：指以上各种原因之外所产生的变更。
软件发布后缺陷分析所用缺陷根本原因的的关键字，可以有下几种实例：
* 需求分析：需求分析不足等原因所引起的变更。
* 系统设计：软件系统设计种种原因所引起的变更。
* 程序编码：软件开发阶段中编程错误所引起的变更。
* 维护：软件发布后程序维护时引起的变更。
* 实施：实施人员做软件初始化设置或系统参数设置不当等，实施时所引发的变更。 * 用户：泛指用户不了解业务和软件、不熟悉操作等原因产生的异常问题。
* 数据异常：运行中不明原因引起的用户数据混乱和异常。
* 升级：软件版本升级过程发生的问题，包括用户在升级时未按规程操作产生的问题。 * 外部问题：所涉及软件外部问题引起的变更，包括属操作系统、数据库软件、第三方软件所引起的问题。 * 错误变更：错误地提交的变更。包括无法重现出错、所列现象不是错误的变更。
* 其他：指以上各种原因之外的变更，包括变更原因不明。测试情况信息项是应用于分析缺陷是如何通过测试关的。可以有以下几种实例：
* 漏测试：软件发布前测试时没有被发现的缺陷，也没有对应测试用例。
* 条件冷僻：缺陷形成条件很冷僻，设计测试用例时很难考虑到。
* 回归测试：专指那些原先测试时是通过的、不存在错误，后来由于修改其他程序时产生的缺陷。关键是软件版本或补丁发布前未进行回归测试，因而被漏过。
* 判断标准：测试时已发现该现象但当时不认为是问题，没提交变更。
* 已测试：测试时已发现缺陷并提交变更，但缺陷没解决。
有些计算分析指标用到的信息在变更库中是没有的，可通过其他渠道获取。例如：软件规模（软件源代码的行数，单位是千行）、开发人员的平均人力成本（单位是元/人天）、软件持续运行时间（在开发阶段以软件测试的工作量来替代）、项目总工作量等。
记录缺陷信息的关键是注意信息正确性。不能有人为因素失真，尤其像变更产生根本原因、变更测试情况。只有正确的信息，才能保障正确的分析结果。
四、缺陷的分析
1、分析指标
缺陷分析时需计算一些分析指标，使分析结果得到度量，以便直观比对。分析指标有以下几项：
* 反映产品质量的指标：
缺陷密度 = 缺陷数量 / 软件规模
潜在缺陷概数 = (100% - 发布前缺陷去处率) * 缺陷密度
* 反映产品可靠性的指标：
平均失效时间 = 软件持续运行时间 / 缺陷数量
* 反映缺陷发现及修复的效率的指标：
缺陷检出率 = 某阶段当时发现的缺陷 / 属该阶段的全部缺陷 * 100%
发布前缺陷去处率 = 发布前发现的缺陷 / (发布前发现的缺陷 + 软件运行的前 3个月发现的缺陷)* 100%
缺陷修正率 = 修复过程中未引发其他问题的缺陷数 / 被修复缺陷的总数 *100%
* 反映缺陷修复成本的指标：