项目缺陷管理流程(20140108).doc

项目缺陷管理规范
1 目的
为了及早发现现网系统缺陷问题、明确职责、定位问题原因，从而提高现网系统质量，缩短现网系统解决时长，制定了此现网系统缺陷管理规范。
2 现网缺陷管理流程
3 现网缺陷管理内容描述
步骤
流程任务
流程责任角色
输入
输出
操作说明
1
缺陷问题提出
系统各使用人员：
广东移动业务部门
文讯各系统使用人员
缺陷描述
缺陷问题列表
缺陷描述要求见“6、缺陷描述要求”
2
缺陷问题分析、
分配
开发组长/开发经理
缺陷问题列表
缺陷问题列表
（处理优先级、处理人员、处理意见等）
开发组长对缺陷问题进行分析、分配：
Ø 分析时，将咨询类、理解错误类等问题处理掉，不留给开发人员；
Ø 对缺陷进行分配，与需求分析、或业务运营人员确定缺陷处理优先级，并标注处理意见；
Ø 进行缺陷来源判断，进行对应的处理方案：
1、代码开发问题：分配给开发人员进行处理；
2、需求问题: 与需求分析人员确认，需求分析人员给出解释，给出处理意见
3、使用/理解有误问题：走回归测试流程
3
修改BUG
开发人员
缺陷问题列表（处理优先级、处理意见等）
BUG问题原因分析、BUG解决方案、BUG开发代码
开发人员根据缺陷问题列表信息，分析缺陷问题，编写缺陷问题原因及具体的解决方案，修改BUG
4
测试
4.1
测试人员缺陷测试
测试人员
缺陷问题列表、
修改的缺陷功能
测试报告
验证开发人员修改的BUG功能是否通过：
u 通过后提交给缺陷提出人进行回归验证；
u 不通过，则提交给开发组长进行缺陷问题分析及分配。
4.2
回归测试
缺陷问题提出人
缺陷问题列表、
修改的缺陷功能、测试报告
回归测试结果报告
缺陷问题提出人，对使用理解有误问题以及测试人员验证缺陷通过的问题进行回归测试:
u 通过后,回归通过则缺陷关闭；
u 不通过，则提交给开发组长进行缺陷问题分析及分配。
5
问题关闭
测试人员
回归测试结果报告
缺陷问题列表（更新）
缺陷提出人回归测试通过后，测试人员关闭完成处理的缺陷问题
4 角色职责说明
角色名
角色职责
开发组长及经理
1、 缺陷分析时，将咨询类、理解错误类等问题处理掉；
2、 对缺陷进行分配，与需求分析、或业务运营人员确定缺陷处理优先级，并标注处理意见
3、 根据缺陷来源进行缺陷分配；
4、 定期对缺陷库分析，找出常出错的模块，进行代码审查及提出优化、改进建议及方案
开发人员
分析Bug，写出问题原因及解决方案，修改Bug
缺陷问题提出人
提出缺陷问题，回归验证
需求分析人员
1、解释需求，给出处理意见
2、将缺陷库中的建议整理成需求文档。评审确定后列入需求版本开发计划
测试人员
验证Bug是否已被解决，对验证通过的缺陷进行关闭
5 缺陷描述要求
缺陷描述的要求为分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查（截图或其它形式的附件）。测试组长/经理把关，以开发人员的角度来审查缺陷描述，看其是否描述清楚了缺陷，不好描述的把截图作为附件提交。具体要求为：
l 单一：尽量一个报告只针对一个软件缺陷（在EXCEL表格中表显为一行），报告形式应方便阅读
l 简洁：每个步骤的描述应尽可能简洁明了。只解释事实、演示和描述软件缺陷必要的细节，不要写无关信息；
l 再现：问题尽量要在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标明）；
l 有据可查：复杂的问题应附截图补充说明或直接通知指定的修改人；考虑到网络数据传输效率，截图的文件格式建议用JPG或GIF，不建议用BMP；亦可用HyperSnap之类的专用抓图工具；
l 用词准确：报告中不允许使用抽象词句：比如“有错误”之类；
有关操作系统特征问题：应在不同操作系统上进行操作，看是否能重现，并在缺陷报告中标识；
缺陷描述示例：
例一：
功能点：用户管理中删除功能
操作步骤：

期望结果：
实际结果：
例二（模块或功能点也可在‘功能模块’字段中规定，则Bug描述中就不必写了）
操作：
1.打开新建向导；
2.在“新建”中的“项目名称”中输入>80个字符；
3.点击“下一步”
期望结果：“项目名称”应<=80个字符，输入大于80个字符，点击“下一步”应有错误提示
实际结果：进入“比重调整”界面
例三（程序员知道期望结果的情况下）
云南98土建
操作：
1.输入13-170
2.F5
3.在F5中修改3240008的名称, 处于编辑状态
4.到人材机,再回来
实际结果： F5中变白板
注：若3不处于编辑态切换则正常
例四（建议、需求类）
功能：预算页，子目排序后可恢复原顺序
用途：用户误操作后可复原
6 缺陷列表各属性及角色说明
编号
属性名
角色
说明
1
缺陷描述
缺陷问题提出人
通过EXCEL表格填写
包括浏览器，IE分版本
2
菜单路径
3
操作步骤/过程
5
缺陷严重级别
6
实际结果
7
缺陷提出人及联系方式
8
缺陷优先级
开发组长

9
缺陷处理意见
开发组长

10
分配人/责任人/处理人
开发组长指定分配人

11
处理时间
责任人估计，开发组长填写
在BUG管理平台中填写
12
缺陷状态
不同阶段的人填写
以BUG管理平台为准
13
问题类型
开发人员

7 属性字典说明
缺陷严重级别
No
类别名称
说明
备注
1
崩溃
错误导致了死机、产品失败（“崩溃”）、系统悬挂无法操作

2
重要的
功能未实现或导致一个特性不能运行并且不可能有替代方案

3
次要的
错误导致了一个特性不能运行但可有一个替代方案；

4
微小的
错误是表面化或微小的（提示信息不太准确友好、错别字、UI布局或罕见故障等），对功能几乎没有影响，产品及属性仍可使用；

5
建议
建设性的意见或建议。

缺陷优先级
No
类别名称
说明
备注
1
5
阻止相关开发人员的进一步开发活动，立即进行修复工作；阻止与此密切相关功能的进一步测试

2
4
必须修改，发版前必须修正

3
3
必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正

4
2
如果时间允许应该修改

5
1
允许不修改

缺陷处理意见
No
类别名称
说明
备注
1
可修改
可修改。表示Bug可以被修复或更正

2
重复
重复。表示该Bug已经被其它测试人员找出来了（‘纯粹’重复），或者开发认为原因是相同的（但从测试来看，认为出现的地方有所不同、表现有所不同等）

3
延后
延后。由于时间、进度、重要程度或者技术/需求等方面的原因，认为不能解决、须延期解决、或者本版不做留待到后续版本解决的Bug。
（注：因‘Bug状态’字段中也有该值，根据各组各自使用情况，可以只保留一个，或者开发/测试各有侧重地使用这两个Postponed）

4
设计结构问题无法修改
因设计结构问题无法修改。测试人员认为是Bug，不符合逻辑，也不符合用户的要求，但开发人员则认为是按照设计做的、只能如此处理，否则修改代价太大

5
不可复现
不可复现。不能重现（如因Bug出现的环境重现不了了），或以前出现的某个Bug自动消失了（可能是在处理其他Bug的时候把这个Bug 一并修复掉了）。
（注：因TD本身亦带有‘是否复现(Reproducible)’字段，根据各组各自使用情况，可以用它来标识，或者不用它而在‘处理意见’字段中用该值标识出）

问题类型
No
类别名称
说明
备注
1
需求问题
由于需求的问题引起的缺陷

2
架构问题
由于构架的问题引起的缺陷

3
设计问题
由于设计的问题引起的缺陷

4
代码问题
由于编码的问题引起的缺陷

5
测试问题
由于测试的问题引起的缺陷

6
环境问题

7
部署、版本问题