BUG管理.docx

BUG管理.docx

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

BUG管理

保密级别

内部资料

版本号

V1.0

CMMI

Bug创建管理指南

文档种类：

CMMI

撰写时间：

2011年6月23日

撰写部门：

EPG组

发行范围：

全公司

变更记录

版本号

修改点说明

变更人

变更日期

审批人

审批日期

V0.1

全部新增

黄小胜、王卉

2011.6.23

何江

V0.2

规范格式定义

黄小胜

2011.9.28

V1.0

公司研发体系全范围发行

EPG组

注：

对该文件内容增加、删除或修改均需填写此修订记录，详细记载变更信息，以保证其可追溯性。

目录

1.BUG管理4

1.1.BUG说法来源4

1.2.Bug创建标准4

1.3.Bug跟踪管理原则10

1.BUG管理

1.1.BUG

BUG—常称为“缺陷”，简单来说就是程序错误，是指在软件运行中因为程序本身有错误而造成的功能不正常、体验不佳、死机、数据丢失、非正常中断等现象。

1.2.BUG说法来源

故事发生在1945年9月9日，下午3点.一个炎热的夏天，房间没有空调，所有的窗户都敞开散热.GraceHopper中尉正领着她的小组构造一个称为"MARKII"的计算机.这还不是一个完全的电子计算机，它使用了大量的继电器.GraceHopper的小组日以继日的工作，机房是一间第一次世界大战时建的老房子.突然，MARKII死机了.技术人员试了很多办法，最后定位到板子F第70号继电器出错.GraceHopper观察这个出错的继电器，发现一只飞蛾躺在中间，已经被继电器打死.她小心的用镊子把它夹出，用透明胶布粘到"事件记录本"中，并注明"第一个发现虫子的实例"，然后计算机又恢复了正常。

从此以后，人们将计算机错误戏称为虫子（BUG）或臭虫，而把寻找错误的工作称为"找臭虫"（DuBug）.GraceHopper的事件记录器，连同这个飞蛾现在已经被陈列在美国历史博物馆中。

1.3.Bug创建标准

一、BUG描述十点要求：

1）Condense-精简，清晰而简短

2）Accurate-准确，确定是Bug

3）Neutralize-用中性的语言描述事实，不带偏见，不用幽默或者情绪化的语言

4）Precise-精确

5）Isolate-定位，尽量缩小这个问题的范围

6）Generalize-还有没有其他的某些地方存在这样的问题

7）Re-Create-如何引发和重现这个Bug?

（环境，步骤，前提条件）

8）Impact-影响，这个缺陷对客户的影响以及对测试的影响

9）DeBug-怎么做才可以让开发更容易来修改这个Bug?

（跟踪，截图，日志，直接访问等等）

10）Evidence-证据

Ø精简，清晰而简短

首先，去掉不必要的词；其次，不要添加无关的信息。

包含相应的信息是最重要的，但是确保这些信息都是有用的。

对于那些没有描述清楚如何重现或者难以理解的问题，都应该提供更多的信息。

但也要避免写过多的不必要的信息。

实例：

不恰当的描述:

当我正专心测试的时候，报内存错误，这时我发现一个我不熟悉的GUI（图形用户接口），我试了好多边界值以及错误的条件，但是运行正常，最后我清空了数据，并且点击了前进按钮，这时系统异常中止了，多次的反复尝试证明，在任务情况下，只要“产品描述”这个字段没有数据，点击前进或者退出甚至取消，系统都会中止。

恰当的描述：

在产品信息页面，如果产品的描述字段为空，前进、退出和取消的功能会使系统意外中止。

Ø准确，确定是Bug

确信是一个Bug，避免因为其他原因，导致提交了错误的Bug，需要考虑：

是否会因为安装的某个原因导致这个问题?

例如，是否安装了正确的版本而且各种先决条件也已经满足?

是否登陆，安全设定，命令或者操作的顺序有错误?

是否存在清除不干净，或者结果不完整，或者因为上次测试的某些更改导致?

是否是网络或者环境的问题?

是否理解了期望的结果?

中性的语言

客观的描述Bug，不要使用幽默的或者其他带有感情色彩的语句。

在提交Bug之前，仔细阅读Bug的描述，删除或者修改可能让人产生歧义的句子。

实例：

不恰当的描述：

输入任何的非法数据都会中止。

恰当描述：

功能ABC在任何非法的数据都会中止，例如：

-1，-36，-32767

Ø精确

当Bug的描述很长时，例如：

“我按了回车键，然后现象A出现，接着按了后退键，现象B出现，接着输入命令‘XYZ’，现象C出现”，看到这样的说明，很难明白到底想说明什么问题，三个现象中哪一个是错误的。

清晰准确并且客观的描述Bug，而不是简单说明发生了什么。

实例：

不恰当描述:

问题发生在取消打印时打印端口延时，打印机的就绪为始终不亮，此时打印机显示面板上显示“PrintingIpdsFrom……”

（说明：

这个描很难让人知道到底是什么问题，是打印端口延时还是打印机没有准备好或者是打印机的显示面板的信息不正确）

恰当描述：

当打印机正在打印时，取消打印会让打印机挂起——问题发生在取消打印时打印端口延时，打印机的就绪灯始终不亮，此时打印机显示面板上显示“PrintingIpdsFrom……”

（说明：

在描述之前，用简短的语言概述时如何发生的这个问题）

Ø定位，尽量缩小这个问题的范围

定位发现的问题。

在试图隔离一个问题的时候，需要考虑下面的几点：

尝试找到最短，最简单的步骤来重现这个问题。

查看是否是外部的什么特殊的原因引起的这个问题?

例如，系统挂起或延时，会不会是因为网络的问题?

对于一个存在多种输入条件的项目，尝试不断的改变输入值，并查看结果，直到确定哪个值导致的错误。

在问题描述中，在尽可能的范围内，精确描述所使用的测试输入值。

例如，如果在测试中发现打印一份脚本的时候会出错，首先判断是不是打印所有的这种类型的脚本都会出错。

Ø归纳

编写Bug时，采用合理的步骤来确定这个问题是通常会发生还是偶然一次出现或者是在特殊条件才出现。

实例：

不恰当描述：

当用非法字符做为文件名时，系统会出现“文件找不到”的错误提示信息

恰当描述：

当用非法字符做为文件名时，系统会出现“文件找不到”的错误提示信息，每一次插入字符时都存在这个问题，但是不插入字符就没有问题

Ø重现

如果测试时，可以重现Bug，那么，应该准确的解释重现Bug所必需的条件。

列出所有的步骤，包括精确的组合，文件名以及碰到或者重现这个问题的操作顺序。

如果确认这个问题在任何文件，任何的操作顺序等条件下都会发生，那也最好能够给出一个明确的示例用来帮助开发来重现。

如果测试时，不能重现Bug，那就提供尽可能多的有效的信息。

在开发没有重现或者开发没有解决之前，不要清除相应的测试数据，或者至少要备份这些数据。

Ø影响

发布产品时，需要判断未解决的影响问题。

例如，在某一个窗口发现一个排版错误或者拼写错误，这类Bug对测试人员来说可能是微不足道的，但对于客户来说，这是接触产品的第一件事，所以必须在给客户实施前修改好。

Ø调试

如果需要，在Report时，提供跟踪、截图、日志等对捕获这个Bug有帮助的信息。

Ø证据

提供Report的是一个Bug的证据信息，这些信息可能包括操作指导，文档，必备条件等等，还有可能是客户以前反馈过来的零碎的信息，或者是竞争对手的软件中的一些标准，又或者来源于以往版本中的结果。

二、BUG编写要点：

BUG编写要点：

BUG标题＋BUG严重等级＋BUG优先等级＋BUG产生环境＋BUG描述

ØBUG标题

Bug的标题是一个和项目组成员之间沟通的有力工具，在很多情形下PM、TeamLeader等只是查看Bug的标题。

Bug的标题编写要求：

✧通过Bug标题能够基本明确Bug的内容；

✧Bug标题基本组成：

在什么环境下，什么模块，做什么操作，产生什么现象；（一般情况下建议按此要求写，特殊情况下可进行调整）

ØBUG严重等级

等级

描述

说明

A-致命问题

发现可重复出现的致命问题

——重要功能、业务流程不能正常实现

——导致系统崩溃、死机，

——导致程序模块丢失

B-严重问题

重要功能实现，但系统不稳定、不安全、或破坏数据、或产生错误结果

——重要功能、业务流程基本能实现，但系统不稳定、出现程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常等问题

——操作过程中报内存错误

——C/S、B/S模式下，利用客户端某些操作可造成服务端不能继续正常工作的

C-一般问题

程序的主业务流程运行基本正常，但是存在一些需求、设计或实现上的缺陷；次要功能运行不正常

——次要功能运行不正常

——操作界面错误

——打印内容、格式错误

——查询错误，数据错误显示

——简单的输入限制未放在前台进行控制

——操作未给出提示（如删除、修改操作）

——找不到规律的时好时坏

D-轻微问题

程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误

——界面不规范

——输入输出不规范

——长操作未给用户提示（或长操作结束后提示没有消失）

——提示窗口文字未采用行业术语

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

——界面存在文字错误

——在功能实现方式上如果需求中没有明确定义，而没有按常规实现，并且不比常规方式实现优越的

E-建议

建议类错误

需求说明书、用户手册中未说明，但影响用户对软件使用的方便性等

ØBUG优先级

优先等级

描述

说明

1级

必须立即修改

一般情况下由研发经理指定，如果存在阻碍测试工作问题存在时，测试人员也可指定，建议解决时间1天

2级

需要在指定时间内解决

优先级由及解决时间由研发经理指定

ØBUG产生环境

准确描述BUG产生的环境：

如测试软件版本、操作系统、IE浏览器版本……

ØBUG描述（编写要求参照下面表格）

BUG概述

●概要性描述BUG内容，措辞要精简、定位问题要准确（精简、定位引用自BUG描述十点要求）

●如果其它功能有相同问题可在此一起归纳

操作步骤

1、…………

2、…………

（操作步骤包括：

重现Bug所必需的条件、尽可能简单的步骤、示例）

结果

（结果要简单准确，此项按情况选择填写）

Ø指派Bug修改人

如果能确认此bug对应模块及修改人，可以直接提交，如果不明确可以提交给项目开发负责人。

1.4.Bug跟踪管理原则

Ø提出必须验证

单人测试项目，编写完Bug后，需要按照Bug提交标准通读后，再提交Bug

多人测试项目，测试负责人是Bug质量的第一负责人，为了控制Bug质量，定测试计划时需要加上一定的测试管理时间，其中一部分用来进行bug验证。

验证标准—确定是否符合编写标准，是否是Bug，是否可重现，是否重复。

Ø修改的bug及时复测

测试人员对提交的问题进行跟踪，除了不进行修改问题外，都需要跟踪直至关闭。

在开发修改bug发布新版测试程序后第一时间进行bug复测。

说明：

开发人员反馈不进行修改和暂不修改问题，需要由本项目测试验证人找研发经理确定，并由研发经理进行标记