缺陷管理流程.docx
《缺陷管理流程.docx》由会员分享,可在线阅读,更多相关《缺陷管理流程.docx(8页珍藏版)》请在冰豆网上搜索。
缺陷管理流程
CompanyDocumentnumber:
WUUT-WUUY-WBBGB-BWYTT-1982GT
缺陷管理流程
缺陷管理流程
2011-04-18
文档修订记录
版本
编号
变化
状态
简要说明(变更内容和变更范围)
日期
变更人
批准日期
批准人
*变化状态:
建立,修改,增加,删除
文档审批信息
版本
编号
审批人
角色
审批日期
签字
备注
1.概述
.编写目的
.适用范围
.读者对象
2.登记缺陷流程
3.缺陷管理流程说明
.发现阶段
.测试类型
.严重级别
.缺陷状态
.上线版本
.缺陷类型
.缺陷优先级
.缺陷引入阶段
4.附:
缺陷登记注意事项
.验证测试规则
.历史遗留问题处理规则
.缺陷优先级流程
1.概述
1.1.编写目的
用于规范公司内部的缺陷管理流程,使整个测试过程顺利进行。
1.2.适用范围
本文档适用于公司内部的整个测试过程。
1.3.读者对象
测试人员与相关开发人员。
2.登记缺陷流程
3.缺陷管理流程说明
3.1.发现阶段
序号
发现阶段
描述
1
1-系统测试
测试环境测试发现有的缺陷
2
2-验收测试
内部验收测试发现有的缺陷,由质量部进行
3.2.严重级别
序号
级别
描述
1
0-建议
建议增加或修改优化操作
2
1-轻微
微小的问题,几乎不影响功能;如界面上错误字
3
2-中等
次要功能未实现
4
3-较高
功能无法完成,配置错误,程序异常错误
5
4-高
操作无法完成,数据库对象存在问题
6
5-紧急
主机功能都未实现,出现严重的问题
3.3.缺陷状态
序号
状态
描述
1
New
测试过程中新提交的缺陷
2
Open
新提交并指派给开发人员处理的缺陷
3
Fixed
开发人员已修复的缺陷,等待测试人员验证
4
Reopen
缺陷修改未达到目标,重新指派给开发人员处理
5
Closed
缺陷已修复并已经通过测试人员验证
6
Rejected
开发拒绝的缺陷,不需要修复或者不是缺陷
7
Pending
当前版本不能修复的缺陷
8
Distract
在上线前仍未修复,后续跟踪的缺陷
9
ISN’TBUG
问题不是缺陷的最终状态
3.4.缺陷处理权限
权限
角色
New
Open
Fixed
Reopen
Closed
Rejected
Pending
Distract
测试人员
√
√
×
√
√
√
×
×
开发人员
×
×
√
√
×
√
×
×
项目经理
×
×
√
√
×
√
√
√
3.5.上线版本
序号
上线版本
描述
1
上线时间未定
测试任务上线时间不确定的缺陷
2
各系统上线时间
各个项目的具体上线时间,确定到日
3.6.缺陷类型
序号
缺陷类型
描述
1
01-基础功能未实现
页面无法打开,或打开报错,无法正常操作
2
02-提交不完整
功能设计说明书中的功能模块部分未提交
3
03-功能未实现
指的是功能不可用或虽然功能可用、但某些方面不能像所希望的那样起到相应的作用
4
04-数据丢失或错误
指的是对应数据无记录或数据计算错误、数据约束错误等
5
05-操作界面
指的是功能可用但是界面不友好或界面信息错误;用户图形、图表界面有错误
6
06-接口问题
指的是与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷
7
07-版本和环境配置
指的是编译、版本问题或其他支持系统问题
8
08-文档问题
指的是设计文档与需求不一致类问题
9
09-致命错误
指的是服务器崩溃、死机等系统类问题
10
10-性能问题
指的是响应时间不合理、CPU等系统资源被占用率太高
3.7.缺陷优先级
序号
优先级
描述
平均时间
1
1-低
暂时不影响继续测试;可以在方便时解决
3天
2
2-中
部分功能无法继续测试;需要优先解决
2天
3
3-高
测试暂停,无法进行;必须立即解决
1天
3.8.缺陷引入阶段
序号
引入阶段
描述
1
测试
缺陷是由测试理解或环境错误造成
2
开发
缺陷是由开发错误造成
3
设计
缺陷是由设计理解错误造成
4
需求
缺陷是由原始需求分析错误引起来的
3.9.项目
序号
项目
描述
1
XXXX各个具体项目
具体的项目名称(如:
配电GIS完善化项目)
2
XXXX各个具体项目
具体的项目名称
3.10.子系统
序号
子系统
描述
1
XXXX子系统名称
子系统的项目名称(如:
配电WebGIS)
2
XXXX子系统名称
3
XXXX子系统名称
子系统的项目名称
4
XXXX子系统名称
4.附:
注意事项
4.1.历史遗留问题处理规则
1、测试人员发现问题登记在测试工作中,指派给开发人员;
2、开发人员认为不是本需求引入而是历史问题,上升项目经理;
3、项目经理确定在此版本是否修复;
1)如修复重新指派给开发人员,走正常流程
2)如不修复,则将状态置为“Pending”,后续跟踪。
.客户反馈缺陷登记流程
1、客户反馈的缺陷首先在测试环境中验证是否存在,存在登记缺陷,类型选择客户反馈,缺陷登记后走缺陷处理正常流程,不存在同客户确认问题原因,是否是客户环境与系统版本问题。
2、用户反馈的缺陷的严重级别和优先级按最高处理
3、在规定的处理时间内客户反馈的缺陷没有解决的将缺陷升级至项目经理.
4、用户反馈的优化类建议或设计上的修改不走缺陷流程,按优化类需求处理提交至项目经理。
开发人员缺陷处理限定
1、功能模块提交后若开发人员发现缺陷,必须走缺陷管理流程,登记缺陷,严禁开发人员私自修改代码以及私自做代码优化类的修改。
缺陷分析
1、项目上线后对验证测试阶段和客户反馈的缺陷进行分析,明确缺陷的原因。
原因类别:
1、测试原因:
如测试用例未覆盖,测试方法有问题等
2、开发原因:
如版本冻结后私自修改代码,版本提交错误.
3、设计原因:
如功能设计不符要求
4、环境原因:
如测试环境与客户的生产环境不一致。