缺陷管理规程

密级：内部公开文档编号：版本号：V0.1缺陷管理规程编制：生效日期：2010年12月14日审核：批准：

文件更改摘要:日期版本号修订说明修订人审核人批准人2010-12-14V0.1初稿刘会林目录TOC\o"1-5"\h\z\o"CurrentDocument"目的4\o"CurrentDocument"角色与职责4\o"CurrentDocument"入口准则4\o"CurrentDocument"输入4\o"CurrentDocument"主要步骤4\o"CurrentDocument"定义缺陷4\o"CurrentDocument"5.1.1缺陷属性5\o"CurrentDocument"5.1.2缺陷类型5\o"CurrentDocument"5.1.3缺陷严重程度5\o"CurrentDocument"5.1.4缺陷优先级6\o"CurrentDocument"5.1.5缺陷状态6\o"CurrentDocument"5.1.6缺陷发现的阶段6\o"CurrentDocument"5.1.7缺陷引入的活动6\o"CurrentDocument"缺陷管理流程7\o"CurrentDocument"缺陷报告8\o"CurrentDocument"遗留缺陷跟踪8\o"CurrentDocument"缺陷分析9\o"CurrentDocument"输出9\o"CurrentDocument"出口准则9\o"CurrentDocument"引用文档9\o"CurrentDocument"使用模板9目的缺陷管理的最终目标是最大限度地减少缺陷的出现率，从而提高软件产品的质量。细分为：1）从缺陷发生到结束的全生命周期进行跟踪管理，尽可能发现所有的缺陷，确保每个被发现的缺陷都能够被解决；2）收集缺陷数据并根据缺陷趋势图识别测试过程的阶段；可以通过缺陷趋势图来确定测试过程是否结束；3）在已收集到的缺陷数据的基础上进行统计分析。总结缺陷出现的原因、类型和规律，采取相应措施避免该类型缺陷再次出现，并在开发过程的早期阶段予以确定，起到缺陷预防的作用，并作为组织的过程财富。本规程规定了缺陷管理流程以及缺陷统计分析要求，项目组必须严格遵循本规程要求保证在较短的时间内高效率地解决所有缺陷，缩短软件开发测试进程，提高软件质量，减少开发和维护成本。角色与职责角色职责项目经理评审缺陷QA提交、评审缺陷测试工程师提交，验证缺陷项目组成员修改缺陷CM工程师在缺陷管理中受控已解决的配置项入口准则缺陷发生时输入无主要步骤5.1.定义缺陷是对软件产品预期属性的偏离现象。它包括检测缺陷和残留缺陷。每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质

量根本。5.1.1缺陷属性属性名称描述缺陷标识缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识。缺陷类型缺陷类型是根据缺陷的自然属性划分的缺陷种类。缺陷严重程度缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。缺陷优先级缺陷的优先级指缺陷必须被修复的紧急程度。缺陷状态缺陷状态指缺陷通过一个跟踪修复过程的进展情况。缺陷发现的阶段缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。缺陷引入的活动缺陷来源指引起缺陷的起因。5.1.2缺陷类型缺陷类型编号缺陷类型描述10功能影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷。20逻辑需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷。30接口与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。40标准编码/文档的标准问题，例如缩进、对齐方式、布局、组件应用、编码和拼写错误等50性能处理速度慢、因文件的大小而导致系统崩溃等60语法不符合所用程序设计语言的语法规则70设计缺陷设计错误。5.1.3缺陷严重程度#缺陷严重等级描述1致命缺陷不能执行正常工作功能或重要功能。或者危及人身安全。2严重缺陷严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）3一般缺陷比较严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）4轻微缺陷使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。

#缺陷优先级描述1立即解决缺陷必须被立即解决。2高优先级在立即解决之后，要解决的，不用排队，如果发现要立即解决的3正常排队缺陷需要正常排队等待修复或列入软件发布清单。4低优先级缺陷可以在方便时被纠正。5建议5建议其它错误。5建议其它错误。5.1.4缺陷优先级5.1.5缺陷状态缺陷状态描述Submitted已提交的缺陷Open确认“提交的缺陷”，等待处理Rejected拒绝“提交的缺陷”，不需要修复或不是缺陷Resolved缺陷被修复Configed缺陷涉及到的代码被受控Reopen缺陷未通过验证Verify缺陷验证通过Closed确认被修复的缺陷，将其关闭5.1.6缺陷发现的阶段缺陷起源描述需求阶段在需求阶段发现的缺陷设计阶段在设计阶段发现的缺陷编码阶段在编码阶段发现的缺陷测试阶段在测试阶段发现的缺陷发布阶段在发布阶段发现的缺陷发布后在产品发布给客户之后5.1.7缺陷引入的活动缺陷来源描述需求由于需求的问题引起的缺陷构架由于构架的问题引起的缺陷设计由于设计的问题引起的缺陷编码由于编码的问题引起的缺陷

测试集成由于测试的问题引起的缺陷由于集成的问题引起的缺陷5.2.缺陷管理流程测试集成对于缺陷管理（注1）,从发现缺陷到最终解决的流程图如下:图4-2缺陷管理流程图【注1】可以手工管理，也可以采用自动化的bug管理工具进行管理。例如bugzilla等开源的bug管理工具。（1）缺陷的提交发现的缺陷均提交给项目内指定人员（可以是项目经理或者开发经理），缺陷的状态为:NEW,由指定人员进行评审、分配。提交缺陷必须填写：缺陷的描述、优先级、严重性、缺陷的状态、解决人、发现缺陷的阶段，缺陷引入的阶段等信息。这些信息由提交缺陷的人负责填写。（2）缺陷的分配项目组内对缺陷评审，决定缺陷计划解决的版本、时间和负责人员。分配缺陷后的状态可能为：Open&Rejected缺陷分配必须修改：缺陷的状态、解决人、计划关闭的版本和评审信息。这些信息由缺陷的解决人（一般是项目经理、开发经理或者是模块负责人）负责填写。（3）缺陷的解决缺陷由指定的开发人员解决后，经过单元测试或代码走查，填写缺陷修改完成时间和缺陷处理结果描述。解决后的缺陷的状态为：Resolved解决缺陷必须修改：缺陷的状态、解决人、涉及到的代码等信息。这些信息由解决缺陷的人（对应的开发人员）负责填写。（4）缺陷的代码受控CM工程师筛选Resolved后的缺陷，将缺陷涉及到的代码统一受控。受控后缺陷的状态为：Configed受控缺陷必须修改：缺陷的状态、解决人、涉及到的代码等信息。这些信息由CM工程师负责填写。（5）缺陷的验证测试工程师筛选状态为Configed的缺陷，出产品包进行验证测试。验证通过后状态为：Verify否则为：Reopen缺陷的验证必须修改：缺陷的状态、解决人、解决的版本等信息。这些信息由测试工程师负责填写。（6）缺陷的关闭经过验证后的缺陷由测试专员关闭，状态为Closedo缺陷验证后的关闭必须修改：缺陷的状态、实际关闭缺陷的版本、解决的版本等信息。这些信息由测试专员负责填写。5.3.缺陷报告阶段性的测试完成后，测试工程师将该阶段发现的缺陷进行统计分析，可以作为测试报告的一部分，包括：缺陷的数量、缺陷类型分类、缺陷分类百分比等。5.4.遗留缺陷跟踪•跟踪遗留缺陷对于让步发布的产品，需要跟踪产品发布后的运行情况。对遗留的缺陷跟踪记录并分析其影响范围，直到遗留缺陷形成解决结果。•产品发布后发现的缺陷产品发布后的缺陷来源有：客户服务部门客户服务人员、咨询实施部项目实施工程师、客户、开发和测试人员。该类缺陷的发现后需要提交给项目组，纳入缺陷管理，该类缺陷的发现阶段标识为“发布后”，便于分析原因。5.5.缺陷分析通过缺陷的数据分析，总结缺陷出现的原因、类型和