Bug流程处理指南.docx

资源描述

Bug流程处理指南.docx

《Bug流程处理指南.docx》由会员分享，可在线阅读，更多相关《Bug流程处理指南.docx（10页珍藏版）》请在冰点文库上搜索。

Bug流程处理指南.docx

Bug流程处理指南

2011.12.15

文件变化记录单

版本编号或者更改记录编号

*变化状态

简要说明

变更日期

变更人

1.0

ALL

2011-12-15

陈贺

*变化状态：

A——增加，M——修改，D——删除

第1章介绍5

1.1.目的5

1.2.背景5

1.3.范围5

1.4.裁剪指南5

1.5.参考文档：

第2章Bug流程处理6

2.1.可被视为软件Bug的情况6

2.2.Bug的生命周期6

2.3.Bug的管理流程6

2.3.1.登记Bug7

2.3.2.修改Bug8

2.3.3.验证Bug8

2.4.Bug的分类、分级9

2.4.1.Bug按照其危急程度分级9

2.4.2.Bug按照优先程度分级9

第3章填写Bug报告单及建立Bug管理库10

3.1.有效描述Bug的一些基本原则10

3.2.填写问题报告单（BugReport）的注意事项10

3.3.Bug报告单或Bug管理库中应收集的数据11

3.4.Bug报告单模板12

3.5.Bug跟踪管理工具使用指南12

介绍

目的

编写Bug流程处理指南的主要目的是：

a.定义Bug相关数据，指导对BUG相关数据的收集；

b.规范Bug的处理流程；

c.指导Bug跟踪管理工具的使用

背景

本文档作为规范BUG流程处理的相关文档，描述了需要收集的BUG相关数据，以及BUG管理的流程。

使测试阶段发现的每个BUG都能够被准确的记录，并被跟踪直到关闭。

范围

本BUG流程处理指南的使用范围为：

各个项目的BUG收集、管理。

Bug流程处理

可被视为软件Bug的情况

●软件未达到需求规格说明书标明的功能

●软件出现了产品说明书指明不会出现的错误

●软件未达到产品说明书虽未指出但应达到的目标

●软件测试人员认为软件难以理解、不易使用、运行速度缓慢

●软件功能超出了产品说明书指明的范围

●软件不能工作。

如死机、无反应等

●软件不兼容（新旧版本，运行环境等）

●软件产品界面、消息、提示不够准确，不友好

●软件文档与帮助信息中的缺陷也是Bug

Bug的生命周期

Bug生命周期通常有以下几种状态:

新建、打开、确认、不是问题、已解决、重新打开、关闭。

图1最简单的Bug生命周期

Bug的管理流程

因为软件缺陷对软件质量有着直接的关系，缺陷跟踪是必须的。

即从记录下缺陷开始，直到它们被关闭，我们需要一个完善的管理流程对软件缺陷跟踪过程进行管理。

图2Bug管理/状态流程图

登记Bug

Bug的发现的来源大致有两个：

●测试人员发现的Bug以及开发人员在测试阶段发现的Bug；

●客户或潜在客户发现的Bug（且客户委托开发方维护Bug管理库）；

根据Bug来源不同，登记方法略有不同。

测试人员发现的Bug以及开发人员在测试阶段发现的Bug：

a.测试人员发现的Bug由测试人员本人填写Bug现象，以及Bug严重等级等信息

b.开发人员在测试阶段发现的Bug也要提交给测试人员填写Bug现象，以及Bug严重等级等信息

修改Bug

c.项目经理根据Bug内容，确定Bug的责任者，并填写在“分配给”中，同时变更bug状态为“对策中”

d.程序员（责任者）原则上以Bug的严重程度为优先级来处理Bug。

e.首先重现Bug,然后确定Bug的原因和修改的对策。

f.如果Bug影响范围较大，或者解决方案需要商讨，程序员要与项目经理和其他开发人员讨论，并将修改方案在项目组内通报。

g.对于需要修改的Bug:

1.修改Bug。

2.修改完Bug后，程序员首先要自己验证Bug是否解决了。

3.修改完Bug后，程序员还与旧版本比较，确实所作修改符合解决方案，同时检查是否删除了不该删除的部分。

4.修改Bug之后,填写原因、解决方案、所修改的文件和其他信息。

（对于不作处理的Bug也要填写）同时变更Bug状态为“不是问题”。

h.当新版本产生后，项目经理安排项目组内其他人员再次确认Bug是否解决。

如果确认Bug已解决，则变更Bug状态为“已关闭”。

验证Bug

根据Bug来源不同，验证方法略有不同。

测试人员发现的Bug：

i.由测试人员对修改后的Bug进行验证。

如果验证正确，则变更Bug状态为“已关闭”。

Bug的分类、分级

Bug按照其危急程度分级

Bug严重程度表示Bug对产品和用户的影响。

根据目前的情况，建议至少将Bug的严重程度分为下面5级

1-紧急----影响测试不能正常执行；系统崩溃，内存溢出，丢失大量数据等

2-非常高----主要功能模块未实现

3-高----一般的产品功能模板缺陷，功能没有完全完成或者实现有误

4-中---与需求有较小差异，使用户产生歧义的信息提示

5-低----界面排版，文档问题（错字或者描述错误等）；建议级问题

Bug按照优先程度分级

Bug改正优先级表示改正Bug的重要程度和应该何时改正。

根据目前的情况，建议将Bug改正优先级分为下面5级

1-立即改正—阻止了进一步测试

2-产品发布前改正

3-如果时间允许应该改正

4-可能会改正，但也能发布

5-在产品正式发布时，可能不作修改，而在用户手册中注明

填写Bug报告单及建立Bug管理库

准确无误的记录Bug现象，跟踪管理Bug数据是一个复杂而重要的过程，需要使用大量信息来描述Bug的属性。

这些信息可以帮助开发和测试人员跟踪、解决那些应由他们负责的Bug。

也可以帮助项目管理人员掌握这些Bug从登记、解决到关闭的整个生命周期中的各种信息。

测试人员应该利用科学的方法和合适的工具确保找到的Bug被清晰无误的表达。

有效描述Bug的一些基本原则

●简短。

只解释事实和演示描述Bug必须的细节。

给出说明问题的一系列明确步骤。

●单一。

每一个报告只针对一个Bug。

Bug报告描述的是问题的症状，而不是问题的原因。

虽然几个Bug可能最终由一个原因引起。

在一个Bug报告中描述多个软件缺陷，可能只有第一个软件缺陷受到注意和修复，而其他的软件缺陷被忘记或忽略。

并且跟踪一个Bug报告中的几个软件缺陷也是不可能的。

●明显和通用。

使用通用的容易看懂的步骤描述软件的缺陷。

●再现。

Bug报告必须展示其再现能力。

按照规定的步骤可以使软件缺陷再现。

●在Bug报告中不做评价。

Bug报告是针对产品，而不是具体的人。

所以Bug描述只陈述事实，而不要带倾向性描述及个人观点。

测试人员应将以上这些原则运用到测试中。

从而使软件缺陷得以有效描述，并增加其被修复的可能性。

提交Bug的注意事项

j.文字描述还不够明确时，可以贴图（故障画面）；

k.记录故障出现时的环境（硬件/软件）；

l.避免操作错误，尽量思考探讨故障出现的规律性和可能原因。

Bug报告单或Bug管理库中应收集的数据

登记BUG：

●标识符。

制订软件缺陷的唯一ID，用于定位和引用。

●标题。

用简明扼要的事实陈述总结软件缺陷。

●测试的软件产品名。

●测试的软件产品版本号。

●发现日期。

●测试工程师。

描述BUG：

●缺陷细节。

用下列信息详细描述软件缺陷。

输入；操作步骤；预期结果；实际结果；有助于程序员定位软件缺陷的其他现象或信息。

●附件，附图。

用以辅助描述软件缺陷的图，或有助于再现缺陷的文件。

●运行环境。

BUG类型：

●严重程度。

参见“bug的分类分级”

●优先级。

参见“Bug优先级”

●缺陷关联ID。