软件缺陷生命周期.docx
《软件缺陷生命周期.docx》由会员分享，可在线阅读，更多相关《软件缺陷生命周期.docx（9页珍藏版）》请在冰豆网上搜索。
软件缺陷生命周期
软件缺陷生命周期
缺陷生命周期
（K3）根据IEEEStd1044－1993定义的异常管理生命周期进行缺陷管理。
（K3）根据IEEEStd1044－1993评估缺陷报告和缺陷分类以改进缺陷报告的质量。
和软件开发生命周期一样，缺陷也是由一系列的阶段和活动组成的，即缺陷同样具有生命周期。
如图1所示，根据IEEEStd1044－1993中的描述，缺陷生命周期主要由四个阶段组成：
识别（Recognition）、调查（Investigation）、改正（Action）、总结（Disposition）。
图1缺陷分类过程
对于缺陷生命周期的每个阶段，都包括记录（Recording）、分类（Classifying）和确定影响（IdentifyingImpact）三个活动。
缺陷生命周期的四个阶段看起来是按照顺序进行的，但是缺陷可能会在这几个阶段中进行多次迭代。
下面对缺陷生命周期的每个阶段和阶段中的活动进行详细的讨论。
1、识别
缺陷的识别是整个缺陷生命周期的第一个阶段，它可以发生在软件开发生命周期的任何一个阶段。
缺陷的识别可以由参与项目的任何利益相关者完成，例如：
系统人员、开发人员、测试人员、支持人员、用户等。
缺陷识别阶段的主要活动包括：
记录：
在缺陷识别阶段，需要记录缺陷的相关信息，包括发现缺陷时的支持数据信息和环境配置信息，例如：
被测系统的硬件信息、软件信息、数据库信息和平台信息等。
分类：
在缺陷识别阶段，需要对缺陷相关的一些重要属性进行分类，主要包括发现缺陷时执行的项目活动（如表1所示）、引起缺陷的原因、缺陷是否可以重现、缺陷发现时的系统状态、缺陷发生时的征兆等。
确定影响：
根据缺陷发现者的经验和预期，判断缺陷可能会造成的影响，例如：
缺陷的严重程度（如表2所示）、优先级，以及缺陷对成本、进度、风险、可靠性、质量等的影响。
表1发现缺陷时的项目活动分类
类别
符合度要求
代号
分类
项目活动
RR100
强制性
RR110
分析
强制性
RR120
评审
强制性
RR130
审计
强制性
RR140
审查
强制性
RR150
编码/编译/汇编
强制性
RR160
测试
强制性
RR170
确认测试/鉴定测试
强制性
RR180
支持/操作
强制性
RR190
走查
表2严重程度分类
类别
符合度要求
代号
分类
严重程度
IM100
强制性
IM110
危急
强制性
IM120
高
强制性
IM130
中
强制性
IM140
低
强制性
IM150
无
2、调查
经过缺陷识别阶段后，需要对每个可能的缺陷进行调查。
调查阶段主要是用来发现可能存在的其他问题以及相关的解决方案，解决方案包括"不采取任何行动"。
缺陷调查阶段的主要活动包括：
记录：
在缺陷调查阶段，需要记录相关的数据和信息，对缺陷识别阶段记录的信息进行更新。
缺陷调查阶段记录的信息包括缺陷调查者的信息、缺陷调查的计划开始时间、计划结束时间、实际开始时间、实际结束时间、调查工作量等。
分类：
在缺陷调查阶段，需要进行分类的属性包括缺陷引起的实际原因、缺陷的来源、缺陷的具体类型等。
同时，对缺陷识别阶段中的分类信息，根据需要进行检查和更新。
确定影响：
根据缺陷调查阶段的分析结果，对缺陷识别阶段的影响分析进行更新。
表3列举了调查阶段的支持数据。
表3调查阶段的支持数据表格
接收确认
验证
接收日期
缺陷的来源
指定的报告号
缺陷识别过程的数据
调查员
姓名
代号或职能范围
电子邮件地址
电话号码
计划的调查开始日期
计划的调查结束日期
实际的调查开始日期
实际的调查结束日期
工时
接收确认的日期
调查使用的资料
名称
ID
版本
3、改正
根据缺陷调查阶段中得到的结果和信息，就可以采取改正措施解决引起缺陷的错误。
采取的行动可能是修复缺陷，也可能是针对开发过程和测试过程的改进建议，以避免在将来的项目中重复出现相似的缺陷。
针对每个缺陷的修复，需要进行相关的回归测试和再测试，避免由于缺陷的修复而影响原有的功能。
缺陷改正阶段的主要活动包括：
记录：
在缺陷改正阶段，需要记录改正缺陷的相关支持数据信息，包括需要修改的条目、需要修改的模块、修改的描述、修改的负责人、计划修改开始的时间、计划修改完成的时间等。
分类：
当合适的修改计划或者活动确定以后，需要对下面的信息进行分类：
缺陷修复的优先级（例如：
是马上修改、延期修改还是不修改）、缺陷的解决方法（如表4所示）、缺陷修复的改正措施等。
确定影响：
对在缺陷识别阶段、缺陷调查阶段中得到的影响分析进行合适的检查，并在需要的时候进行更新。
表4缺陷改正的分类表--解决方法
4、总结
经过了上面的几个阶段后，缺陷生命周期就到了缺陷的总结阶段。
总结阶段的主要活动包括：
记录：
在缺陷总结阶段，需要对一些支持数据信息进行记录，例如：
缺陷关闭时间、文档更新完成时间等。
分类：
针对缺陷进行确认测试和相关的回归测试以后，就可以将缺陷的状态进行分类，例如：
关闭状态、延迟状态或者合并到其他项目中去等。
确定影响：
对在缺陷识别阶段、缺陷调查阶段和缺陷改正阶段中得到的影响分析进行合适的检查，并在需要的时候进行更新。
表5列出了缺陷总结阶段的分类数据。
表5缺陷总结阶段的分类表
类别
符合度要求
代号
分类
缺陷总结
DP100
强制性
DP110
已关闭
DP111
已完成缺陷改正
DP112
不是错误
DP113
不属于项目范围（不能解决）
DP114
外部供应商问题
DP115
重复问题
DP120
延期改正
DP130
与其他缺陷合并
DP140
划归其他项目
5、案例
本节介绍一个根据IEEEStd1044－1993制定的缺陷生命周期案例，如图2所示。
图2缺陷状态转换图
图2是某项目的缺陷生命周期中的缺陷状态转换图。
下面分别从角色、状态、严重程度和优先级四个方面阐述该项目使用的缺陷生命周期。
（1）相关角色
测试人员：
主要是指发现和报告缺陷的测试人员。
通常情况下，测试人员需要对该缺陷后续相关的状态负责，包括回答相关人员对这个缺陷信息的询问，以及在正式版本上进行再测试和回归测试。
开发人员：
主要指对缺陷进行调查和修复的开发人员。
注意在提交测试人员正式再测试之前，需要对修改后的缺陷在开发环境上进行验证。
缺陷评审委员会：
主要由项目经理、测试经理、质量经理、开发经理以及资深的开发人员、测试人员等组成。
他们对缺陷进行确认，并将其分配给相应的开发人员进行修复，同时对有争议的缺陷进行仲裁。
版本经理：
负责将已经解决的缺陷相关的配置信息合并到新的版本。
（2）缺陷状态
新缺陷（New）：
软件中新发现的缺陷通常由测试人员提交。
当然也可能是开发人员自己在组件测试或代码走读过程中提交，还有可能是从软件使用的最终用户或使用现场反馈得到的缺陷报告。
具体缺陷发现的阶段包括：
需求和设计阶段：
文档评审过程中发现的缺陷。
编码阶段：
代码评审和代码静态分析过程中发现的缺陷。
测试阶段：
动态测试过程中发现的缺陷。
使用阶段：
用户反馈的缺陷。
接受（Accepted）：
相关人员提交的缺陷报告，需要经过缺陷评审委员会的评审。
缺陷评审通过后，将缺陷状态置为接受。
缺陷评审委员会评审的主要内容包括：
报告中描述的问题是否确实是一个缺陷。
提交的缺陷报告是否符合要求。
分配（Assign）：
将缺陷状态为接受的缺陷分配给相关人员进行问题定位和修复。
相应的缺陷状态被置为分配。
打开（Open）：
当缺陷处于打开状态时，说明开发人员已经开始对该缺陷进行修复。
交付（Deliver）：
解决缺陷的方法已经找到，并且已经将修改后的代码等打上标签，交付给版本经理。
解决（Resolved）：
版本经理将相关的标签等合入某个版本，交付给相关的开发小组进行验证，测试通过，则缺陷状态置为解决。
已修改（Fixed）：
版本经理将已经解决的缺陷标签合入某个版本，交付给相关的测试小组进行确认测试，测试通过，则缺陷状态为已修改。
结束（Closed）：
缺陷状态处于已修改后，缺陷评审委员会对整个缺陷修复过程进行评审，评审通过后将缺陷状态修改为结束状态。
上面介绍的缺陷状态是在缺陷管理过程中主要的状态，或者是在缺陷处理顺利时所经历的状态。
实际上，缺陷还有一些其他的状态，分别是：
研究（Investigate）：
当缺陷分配给开发人员时，开发人员并不是都能直接找到相关的解决方案。
开发人员需要对缺陷和引起缺陷的原因进行调查研究，这时候可以将缺陷状态改为研究状态。
询问和回答（Query&Reply）：
假如负责缺陷修复的人员认为缺陷描述的信息不够明确，或希望得到更多与缺陷相关的配置和环境条件等，可以将缺陷状态改为询问和回答。
拒绝（Declined）：
缺陷评审委员会通过讨论研究，认为提交的问题不是缺陷；或通过开发人员的研究分析，认为不是缺陷，开发人员可以将具体的理由加入到缺陷描述中，缺陷评审委员会据此将缺陷状态修改为拒绝。
重复（Duplicated）：
缺陷评审委员会认为该缺陷和某个已经提交的缺陷描述的是同一个问题，可以将该缺陷状态设置为重复。
延期（Deferred）：
缺陷不在当前版本解决。
无计划（Unplanned）：
在用户需求中没有要求或计划。
（3）严重程度
缺陷的严重程度指的是假如缺陷没有修复时，软件缺陷对软件质量的破坏程度，即此软件缺陷的存在对软件功能特性和非功能特性产生的影响。
缺陷的严重程度关注的是缺陷引发的问题对客户的影响程度。
在给缺陷确定严重程度的时候，应该从软件最终用户的角度进行判断，即根据缺陷会对用户使用造成的影响程度来确定。
软件缺陷的严重程度和缺陷发生的可能性没有直接的关系。
一般而言，缺陷的影响越大，缺陷的严重程度越高。
下面是该项目的缺陷严重程度的分类，缺陷的严重程度被分为四个等级。
严重程度1（致命的）：
产品在正常的运行环境下无法给用户提供服务，并且没有其他的工作方式可以补救；或者软件失效会造成人身伤害或危及人身安全，例如：
问题会自发地影响系统的数据传输。
用户使用正常的操作步骤就会影响系统提供的服务。
软件的操作系统崩溃，造成数据丢失。
无法提供系统的主要功能。
可能会造成人身伤害。
严重程度2（严重的）：
极大地影响系统提供给用户的服务，或者严重影响系统要求或者基本功能的实现，例如：
系统中的一些硬件单板会自动重启，但没有影响它们所提供的传输性能。
用户使用正常的命令会导致系统重启或挂起，但不影响系统的数据传输。
软件的某个子菜单不起作用，或者会产生错误的结果。
严重程度3（一般的）：
系统功能需要增强或存在缺陷，但有相应的补救方法解决这个缺陷，例如：
系统的一块硬件单板失效了，但系统没有上报相应的告警。
功能特征设计不符合系统的需求，不影响系统的业务，并且有相应的补救方法。
本地化软件的某些字符没有翻译或者翻译错误。
严重程度4（轻微的）：
细小的问题，不需要补救方法或对功能进行增强；或者操作不方便，容易使用户误操作，例如：
上报的信息不符合系统的需求，描述不精确或可能对用户有些误导。
GUI界面问题，不精确或可能产生歧义。
（4）优先级
优先级是处理软件缺陷的先后顺序的指标。
确定缺陷的优先级更多的是站在软件开发和软件测试的角度来进行考虑。
确定缺陷的优先级有时候可能并不是纯技术的问题，还需要考虑修复缺陷的难度和存在的风险，因此，缺陷优先级的确定是一个复杂的过程。
同时，优先级的确定也需要考虑缺陷发生的频率和对目标用户的影响。
该项目中，缺陷的优先级被分为四个等级：
优先级1（立即）：
用户的业务或工作过程受阻，或运行中的测试无法继续。
该问题需要立即修复，或必要的话采取临时措施（如：
打补丁的方式）。
优先级2（下次发布）：
在下次常规的产品发布或下次（内部）测试对象版本交付时实施修正。
优先级3（必要时）：
在受影响的系统部件应当进行修订时进行修正。
优先级4（未决）：
尚无修正计划。
缺陷的严重程度和优先级是含义不同但相互联系密切的两个概念，它们从不同方面描述了软件缺陷对软件质量、用户、开发过程的影响程度和处理方式。
一般来说，严重程度高的缺陷具有较高的优先级。
严重程度高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件的瑕疵，可以稍后处理。
但是优先级和严重程度并不总是一一对应的，也存在优先级低但严重程度高的缺陷，或者优先级高但严重程度低的软件缺陷。
修改软件缺陷并不是纯技术的问题，有时候需要考虑软件版本发布和质量风险等因素。
下面是关于缺陷严重程度和优先级设置方面的一些建议：
如果某个严重的缺陷只在非常极端的条件下产生，则可以将缺陷的优先级设置得比较低。
如果修正一个软件缺陷需要重新修改软件的整体架构，可能会产生更多的潜在缺陷，而且市场要求尽快发布软件版本，那么即使这个缺陷严重程度很高，也需要仔细考虑是否需要修改。
对于有些缺陷，可能它的严重程度很低，例如：
界面单词拼写错误，但假如这是公司的名称或者商标，则这个缺陷的优先级就很高，必须尽快进行修复，因为这个关系到软件系统和公司在市场上的形象。
正确区分和处理缺陷严重程度和优先级，是软件质量保证的重要环节。
因此，正确处理和区分缺陷的严重程度和优先级是所有的软件开发和测试相关人员的重要职责，需要正确理解缺陷严重程度和优先级的含义，同时认识到这是保证软件质量的重要环节，应该引起足够的重视。
将比较轻微的缺陷设置成高严重程度和高优先级的缺陷，夸大缺陷的严重程度，将影响软件质量的正确评估，耗费开发人员辨别和处理缺陷的时间；而将严重的缺陷报告成低严重程度和优先级的缺陷，这样会掩盖许多严重的缺陷。
如果在项目或者软件发布前，发现还有很多由于不正确分配优先级造成的严重缺陷，将需要投入很多人力和时间进行修改，影响软件的正常发布；或者这些严重的缺陷成为漏网之鱼，随着软件一起发布出去，就会影响软件的质量和降低用户使用软件的信心。
升级会员 