缺陷管理规程.docx
《缺陷管理规程.docx》由会员分享，可在线阅读，更多相关《缺陷管理规程.docx（11页珍藏版）》请在冰点文库上搜索。
缺陷管理规程
密级：
内部公开
文档编号：
版本号：
V0.1
缺陷管理规程
编制：
生效日期：
2010年12月14日
审核：
批准：
文件更改摘要:
日期
版本号
修订说明
修订人
审核人
批准人
2010-12-14
V0.1
「初稿
刘会林
1.目的4
2.角色与职责4
3.入口准则4
4.输入4
5.主要步骤4
5.1.定义缺陷4
5.1.1缺陷属性5
5.1.2缺陷类型5
5.1.3缺陷严重程度5
5.1.4缺陷优先级6
5.1.5缺陷状态6
5.1.6缺陷发现的阶段6
5.1.7缺陷引入的活动6
5.2.缺陷管理流程7
5.3.缺陷报告8
5.4.遗留缺陷跟踪8
5.5.缺陷分析9
6.输出9
7.出口准则9
8.引用文档9
9.使用模板9
1.目的
缺陷管理的最终目标是最大限度地减少缺陷的出现率，从而提高软件产品的
质量。
细分为：
1）从缺陷发生到结束的全生命周期进行跟踪管理，尽可能发现所有的缺陷，确保每个被发现的缺陷都能够被解决；
2）收集缺陷数据并根据缺陷趋势图识别测试过程的阶段；可以通过缺陷趋势图来确定测试过程是否结束；
3）在已收集到的缺陷数据的基础上进行统计分析。
总结缺陷出现的原因、类型和规律，采取相应措施避免该类型缺陷再次出现，并在开发过程的早期阶段予以确定，起到缺陷预防的作用，并作为组织的过程财富。
本规程规定了缺陷管理流程以及缺陷统计分析要求，项目组必须严格遵循本规程要求保
证在较短的时间内高效率地解决所有缺陷，缩短软件开发测试进程，提高软件质量，减少开
发和维护成本。
2.角色与职责
角色
职责
项目经理
评审缺陷
QA
提交、评审缺陷
测试工程师
提交，验证缺陷
项目组成员
修改缺陷
CM工程师
在缺陷管理中受控已解决的配置项
3.入口准则
缺陷发生时
4.输入
无
5.主要步骤
5・1・定义缺陷
是对软件产品预期属性的偏离现象。
它包括检测缺陷和残留缺陷。
每一个软件组织都知道必须妥善处理软件中的缺陷。
这是关系到软件组织生存、发展的质
量根本。
5.1.1缺陷属性
属性名称
描述
缺陷标识
缺陷标识是标记某个缺陷的一组符号。
每个缺陷必须有一个唯一的标识。
缺陷类型
缺陷类型是根据缺陷的自然属性划分的缺陷种类。
缺陷严重程度
缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
缺陷优先级
缺陷的优先级指缺陷必须被修复的紧急程度。
缺陷状态
缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
缺陷发现的阶段
缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。
缺陷引入的活动
缺陷来源指引起缺陷的起因。
5.1.2缺陷类型
缺陷类型编号
缺陷类型
描述
10
功能
影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。
并且设计文档需要正式的变更。
如逻辑，指针，循环，递归，功能等缺陷。
20
逻辑
需要修改少量代码，如初始化或控制块。
如声明、重复命名，范围、限定等缺陷。
30
接口
与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
40
标准
编码/文档的标准冋题，例如缩进、对齐方式、布局、组件应用、编码和拼写错误等
50
性能
处理速度慢、因文件的大小而导致系统崩溃等
60
语法
不符合所用程序设计语言的语法规则
70
设计缺陷
设计错误。
5.1.3缺陷严重程度
#
缺陷严重等级
描述
1
致命缺陷
不能执行正常工作功能或重要功能。
或者危及人身安全。
2
严重缺陷
严重地影响系统要求或基本功能的实现，且没有办法更正。
（重
新安装或重新启动该软件不属于更正办法）
3
般缺陷
比较严重地影响系统要求或基本功能的实现，但存在合理的更正办法。
（重新安装或重新启动该软件不属于更正办法）
4
轻微缺陷
使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
5
建议
其它错误。
5.1.4缺陷优先级
#
缺陷优先级
描述
1
立即解决
缺陷必须被立即解决。
2
高优先级
在立即解决之后，要解决的，不用排队，如果发现要立即解决的
3
:
正常排队
缺陷需要正常排队等待修复或列入软件发布清单。
4
低优先级
缺陷可以在方便时被纠正。
5.1.5缺陷状态
缺陷状态
描述
Submitted
已提交的缺陷
Open
确认“提交的缺陷”，等待处理
Rejected
拒绝“提交的缺陷”，不需要修复或不是缺陷
Resolved
缺陷被修复
Configed
缺陷涉及到的代码被受控
Reopen
缺陷未通过验证
Verify
缺陷验证通过
Closed
确认被修复的缺陷，将其关闭
5.1.6缺陷发现的阶段
缺陷起源
描述
需求阶段
在需求阶段发现的缺陷
设计阶段
在设计阶段发现的缺陷
编码阶段
在编码阶段发现的缺陷
测试阶段
在测试阶段发现的缺陷
发布阶段
在发布阶段发现的缺陷
发布后
在产品发布给客户之后
5.1.7缺陷引入的活动
缺陷来源
描述
需求
由于需求的问题引起的缺陷
构架
由于构架的问题引起的缺陷
设计
由于设计的问题引起的缺陷
编码
由于编码的问题引起的缺陷
测试
由于测试的问题引起的缺陷
集成
由于集成的问题引起的缺陷
52缺陷管理流程
对于缺陷管理（注1）,从发现缺陷到最终解决的流程图如下:
图4-2缺陷管理流程图
【注1】可以手工管理，也可以采用自动化的bug管理工具进行管理。
例如bugzilla等开源
的bug管理工具。
（1）缺陷的提交
发现的缺陷均提交给项目内指定人员（可以是项目经理或者开发经理），缺陷的状态为：
NEW,
由指定人员进行评审、分配。
提交缺陷必须填写：
缺陷的描述、优先级、严重性、缺陷的状态、解决人、发现缺陷的阶段，
缺陷引入的阶段等信息。
这些信息由提交缺陷的人负责填写。
（2）缺陷的分配
项目组内对缺陷评审，决定缺陷计划解决的版本、时间和负责人员。
分配缺陷后的状态可能为：
Open&Rejected
缺陷分配必须修改：
缺陷的状态、解决人、计划关闭的版本和评审信息。
这些信息由缺陷的解决人（一般是项目经理、开发经理或者是模块负责人）负责填写。
（3）缺陷的解决
缺陷由指定的开发人员解决后，经过单元测试或代码走查，填写缺陷修改完成时间和缺陷处
理结果描述。
解决后的缺陷的状态为：
Resolved
解决缺陷必须修改：
缺陷的状态、解决人、涉及到的代码等信息。
这些信息由解决缺陷的人（对应的开发人员）负责填写。
（4）缺陷的代码受控
CM工程师筛选Resolved后的缺陷，将缺陷涉及到的代码统一受控。
受控后缺陷的状态为：
Configed
受控缺陷必须修改：
缺陷的状态、解决人、涉及到的代码等信息。
这些信息由CM工程师负
责填写。
（5）缺陷的验证
测试工程师筛选状态为Configed的缺陷，出产品包进行验证测试。
验证通过后状态为：
Verify否则为：
Reopen
缺陷的验证必须修改：
缺陷的状态、解决人、解决的版本等信息。
这些信息由测试工程师负责填写。
（6）缺陷的关闭
经过验证后的缺陷由测试专员关闭，状态为Closed。
缺陷验证后的关闭必须修改：
缺陷的状态、实际关闭缺陷的版本、解决的版本等信息。
这些信息由测试专员负责填写。
5・3・缺陷报告
阶段性的测试完成后，测试工程师将该阶段发现的缺陷进行统计分析，可以作为测试报
告的一部分，包括：
缺陷的数量、缺陷类型分类、缺陷分类百分比等。
5.4.遗留缺陷跟踪
跟踪遗留缺陷
对于让步发布的产品，需要跟踪产品发布后的运行情况。
对遗留的缺陷跟踪记录并分析
其影响范围，直到遗留缺陷形成解决结果。
产品发布后发现的缺陷
产品发布后的缺陷来源有：
客户服务部门客户服务人员、咨询实施部项目实施工程师、
客户、开发和测试人员。
该类缺陷的发现后需要提交给项目组，纳入缺陷管理，该类缺陷的发现阶段标识为“发布后”，便于分析原因。
5・5・缺陷分析
通过缺陷的数据分析，总结缺陷出现的原因、类型和规律，采取相应措施避免该类型缺陷再次出现，提高产品质量。
产品缺陷趋势图
统计项目组阶段缺陷的趋势图，用于分析产品的质量。
o/c图分析
测试人员在每个项目在每轮测试结束后，将缺陷分析结果写在《测试报告》中，提交项目经理审批。
6.输出
《测试工作阶段报告》
《测试缺陷报告》
《测试报告》
7.出口准则
缺陷关闭
8.引用文档
无
9.使用模板
《测试报告》
《测试工作阶段报告》
《测试记录表》
《测试缺陷报告》
《缺陷跟踪表》
《集成测试报告.》
《验收测试报告》
升级会员 