BUG库管理

版本：1.0

变更记录

文件编号：  所属类别：工程-TS-模板

*简要说明：要求注明变更内容和变更范围

目录

1    简介    3

1.1    目的    3

1.2    适用范围    3

1.3    参考文件&资料    3

1.4    术语表&缩写    3

2    Bug状态流程图    4

3    各角色对Bug的处理    4

4    Bug状态(Status)及描述    5

5    Bug严重级别（Severity）    5

6    Bug优先级（Priority）    6

7    缺陷来源（Source）    7

8    缺陷类型（Issue type）    7

9    项目组各角色在Bug库中的权限    9

10    Bug描述要求    9

11    小结    11

1简介

1.1目的

为了规范Bug管理，明确项目经理、开发人员、测试人员各自的角色和职责特制定本文档。

1.2适用范围

本文档适用于TD中对于Bug的管理。

1.3参考文件&资料

TD中对于Bug生命周期的描述

1.4术语表&缩写

●缺陷与Bug：系统开发过程中发现的问题统称为缺陷，包括测试及评审过程发现的所有问题。Bug是“缺陷”的英文描述，本文档中不做Bug与缺陷的区分，但优先使用缺陷的概念。

●TD：测试管理工具TestDirect的简写

2Bug状态流程图

3各角色对Bug的处理

项目经理

对Bug进行分配，标注处理意见，给定优先级。问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。定期对Bug库分析，找出经常出错的模块，进行代码审查

开发人员

分析Bug，写出问题原因，修改Bug；实行Bug优先原则。

测试人员

不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度；验证Bug是否已被解决。

测试主管/经理

审核测试人员提交的Bug；定期对Bug库进行分析，报告现状、预测趋势。在测试总结报告中给出意见。

4 Bug状态(Status)及描述

Bug状态(Status)：指缺陷通过一个跟踪修复过程的进展情况。包括New、Open、Reopen、Fixed、Closed、Rejected、Delay

New：为测试人员新bug提交所标志的状态。

Open：为任务分配人（开发组长/经理）对该问题准备进行修改并对该问题分配修改人员所标志的状态。Bug解决中的状态，由任务分配人改变。对没有进入此状态的Bug，程序员不用管。

Reopen：为测试人员对修改问题进行验证后没有通过所标志的状态。由测试人员改变。

Fixed：为开发人员修改问题后所标志的状态，修改后还未测试。由开发人员设置。

Closed：为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改变。

Rejected：开发人员或项目经理认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议或虽然是个错误但还没到非改不可的地步故可忽略不计或者测试人员提错，从而拒绝的问题。由项目经理来设置。

Delay：开发人员或项目经理认为因开发进度等原因，当前无法解决，需留到以后版本解决的Bug。由项目经理来设置。

5Bug严重级别（Severity）

A类——严重，包括：

1.由于程序所引起的死机，非法退出；

2.死循环；

3.导致数据库发生死锁；

4.操作系统崩溃、死机；

5  严重的数值计算错误。

B类——高，包括：

1.主要功能未实现或不符；

2.数据通讯错误；

3.严重的数值计算错误；

4.数据流错误；

5.程序接口错误。

C类——中，包括：

1.次要功能未实现或错误；

2.轻微的数值计算错误；

3.打印内容、格式错误；

4.简单的输入未放在前台进行控制；

5.删除操作未给出提示。

D类——低，包括：

1.辅助说明描述不清楚；

2.界面错误；

3.显示格式不规范；

4.长时间操作未给用户进度提示；

5.提示窗口文字未采用行业术语；

6.可输入区域和只读区域没有明显的区分标志；

7.系统处理未优化。

E类——测试建议（非缺陷）

6Bug优先级（Priority）

Low：允许不修改。

Medium：如果时间允许应该修改。

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

Very High：必须修改，发版前必须修正。

Urgent：阻止相关开发人员的进一步开发活动，立即进行修复工作；阻止与此密切相关功能的进一步测试。

7缺陷来源（Source）

需求：由于需求问题引起的缺陷。

架构：由于架构问题引起的缺陷。

设计：由于设计问题引起的缺陷。

编码：由于编码问题引起的缺陷。

集成：由于集成问题引起的缺陷。

测试：由于测试问题引起的缺陷。

8缺陷类型（Issue type）

功能类 

A. 重复的功能 ；

B. 多余的功能 ；

C. 功能实现与设计要求不相符 。

易用性类 

A.功能使用性、方便性、易用性不够 。

界面类 

A. 界面不美观 ；

B. 控件排列、格式不统一 ；

C. 焦点控制不合理或不全面。 

数据处理类 

A. 数据有效性检测不合理； 

B. 数据来源不正确 ；

C. 数据处理过程不正确； 

D.数据处理结果不正确 。

提示信息类 

A. 提示信息重复或出现时机不合理 ；

B. 提示信息格式不符和要求 ；

C. 提示框返回后焦点停留位置不合理 。

建议类 

A. 功能性建议 ；

B. 操作建议 ；

C. 检校建议 ；

D. 说明建议 。

性能类 

A. 并发量 ；

B. 数据量 ；

C. 压缩率 ；

D. 响应时间 。

兼容性类

A.系统软件不兼容（例如IE，操作系统等）；

B.系统硬件不兼容。

偶发性类

A.偶然发生的，不可再现的bug。

常识类

A. 违背正常习俗习惯的，比如日期 / 节日等 。

特殊类 

A.不符合 OEM 版本或 DEMO 版本特殊要求的。

9项目组各角色在Bug库中的权限

测试主管/经理：全部权限。

测试人员：可添加Bug，不可删除Bug；可添加注释评论；不可修改他人所提Bug；可调整：Bug概要(题目，Summary)、问题描述、附件附图(Attachments)、Bug状态（New置为Open或Fixed置为Reopen或Fixed置为Closed）、Bug级别、测试版本、功能模块（subject）、问题定位、责任人等。

开发人员：可添加Bug；不能删除Bug；可添加注释评论；可调整：注释评论、Bug状态（由Open置为Fixed）、问题定位。

项目经理：可添加Bug；不能删除Bug；可添加注释评论；调整Bug状态（New置为Open或Open置为Fixed或Open置为Delay或Open置为Rejected或Delay置为Open）、优先级别、问题定位、责任人。

不属于项目组成员的其他人：如研发中心经理组成员等，有必要查看TD库的话，可分配给其用户ID及查看的权限。

10Bug描述要求

Bug描述的要求为：分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查（截图或其它形式的附件）。测试主管/经理把关，以开发人员的角度来审查Bug描述，看其是否描述清楚了Bug，不好描述的把工程文件或截图作为附件提交。具体要求为：

∙原则：每个bug都有相应的测试用例与之对应；

∙问题描述一般格式：问题描述时，建议分几步描述：模块或功能点=>测试步骤=>期望结果=>实际结果=>其它信息，可依实际情况调整；

∙单一：尽量一个报告只针对一个软件缺陷，报告形式应方便阅读。需要合并的bug也要指明每个的具体位置，以方便回归； 

∙简洁：每个步骤的描述应尽可能简洁明了。只解释事实、演示和描述软件缺陷必要的细节，不要写无关信息； 

∙再现：问题必须在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标明）； 

∙复杂的问题应附截图补充说明或直接通知指定的修改人；考虑到网络数据传输效率，截图的文件格式建议用JPG或GIF，不建议用BMP；抓图可用TD自带的功能，亦可用HyperSnap之类的专用抓图工具； 

∙报告中不允许使用抽象词句：比如“有错误”之类；

∙简明扼要地对Bug进行概述，让人看标题就知道大概出现了什么问题（写清楚什么地方出现了什么问题）；

∙详细描述要对Bug描述清晰准确，能让开发人员根据描述重现bug（最好描述出现bug的原因，至少也要说明出现bug的规律）；

∙Bug中的Severity 、Issue type及Source项按照 ‘缺陷严重程度定义’、‘缺陷类型定义’及‘缺陷来源’中的相关说明来填写；

∙有关操作系统特征问题：应在不同操作系统上进行操作，看是否能重现，并在Bug报告中标识。

注：所有项目采用TD进行Bug管理，该工具能从测试步骤自动生成Bug报告，因此对于Bug描述要求在测试方案用例设计（在Test Plan页中）阶段就可以进行控制。

附：好的Bug报告应满足以下几方面的要求：

∙结构清晰 ；

∙复现故障再写报告 ；

∙隔离Bug：更改条件复测 ；

∙归纳：是否其他模块也有相同的Bug；

∙比较：其他测试用例是否使用到此Bug ；

∙总结：报告的开头有Bug的总结 ；

∙精简：不要有多余的步骤和语言 ；

∙无歧义：语言明确 ；

∙中立：无批评性语言 ；

∙讨论：将要发出的报告送其他测试人员讨论 。

11小结

∙通过专业的技术测试出精确的Bug； 

∙通过准确的文档报告Bug； 

∙通过良好的沟通使Bug尽快解决。