Bugzilla使用手册（四）

Bugzilla的组成结构与流程

 

一、Bug记录按产品分类，每种产品按功能拆分成几类。以Bugzilla产品为例，它由以下部分构成：

Administration        平台管理

Bugzilla-General      平台基本功能

Creating/Changing Bug   创建/修改错误

Documentation     文档记录功能

Email        bug邮件提交功能

Installation    组件安装

Query/Buglist     bug审阅

Reporting/Charting     bug提交/展示

User Accounts  用户账户管理

Changing Passwords 修改密码

User Interface    用户接口

 

二、Bug处理流程：

 

1、测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或分配人员；

2、项目组长根据具体情况，重新resssigned分配给bug所属的开发者；

3、开发者收到Email信息后，判断是否自己的修改范围。

 （1）若不是，重新resssigned分配给项目组长或应该分配的开发者；

 （2）若是，进行处理，resolved并给出解决方案。

4、测试人员查询开发者已经修改的bug,进行测试。

（1）经验证无误后，修改状态为VERIFIED。待整个产品发布后，修改为CLOSED；

（2）若还有问题，REOPENED，状态重新变为NEW,并发邮件通知；

（3）解决情况不是需要Fixed的缺陷，验证通过，暂时可以不改。

5、如果bug一周内无人处理，Bugzilla通过Email通知属主，直到采取行动。管理人员可以设定最迟采取行动的期限。

6、bug提交，先进行查询工作。

（1）确定要提交的bug报告不会在原有记录中存在，若已经存在，可在原有记录中添加注释，告知其属主。

（2）确定你发现的bug是在最新版本中发生的。

对于bug的属主处理问题,提出解决意见及方法 。给出解决方案 并填写附加说明,还可以创建附件。

填表提示：

   FIXED 描述的问题已经修改，该bug已经修复并检查过，源文件已经检入CVS库；

  INVALID 描述的问题不是一个bug(输入错误后，通过此项取消)；

  WONTFIX 描述的问题将永远不会被修复；

  LATER 描述的问题将不会在产品的这个版本解决；

  DUPLICATE 描述的问题时一个存在的bug的附件；

  WORKSFORME 所有要重新产生这个bug的企图是无效的。如果有更多的信息，重新分配这个bug,现在只把它归档。

 

三、一个Bug的生存周期:

 

 

　　对BUG的一些描述字段：

3.1 STATUS：（状态）

　　状态字段表明了bug的一般的状态，只有某些特定的状态转换是允许的，状态之间是可以转换的。

3.2 UNCONFIRMED：（未证实）

　　表明bug是最近加入到数据库，没有人正式这个bug的存在。拥有“确定/取消Bug"的用户可以对转变bug的状态为：

　　1. 确认这个bug，改变他的状态为新(NEW)

　　2. 解决这个bug，标志为已解决(RESOLVED)

3.3 NEW（新BUG）

　　这个bug已经分发给某位开发人员处理。这个状态的bug可以转变为以下状态：

　　1. 接受该bug，状态转变为指派(ASSIGNED)

　　2. 指派给别的开发人员，状态维持为新(NEW)

　　被解决，状态转变为被解决(RESOLVED)

3.4 ASSIGNED（已经指派）

　　这个bug尚未解决，但已经被指派给正确的人进行解决。这个状态的bug可能转换为以下状态

　　1. 指派给别的开发人员，状态转变为新(NEW)

　　2. 被解决，状态转变为被解决(RESOLVED)

3.5 REOPENED（重新打开）

　　这个bug曾经被解决了，但是解决方案是不正确的。例如，一个处于对我有效（WORKSFORME）的bug，当获得了更多的信息并且能够被再现时，将转变为重开(REOPENED)状态。 这个状态的bug只能转换为以下状态：

　　1. 指派(ASSIGNED)给某名开发人员

　　2. 被解决，状态转变为被解决(RESOLVED)

3.6 RESOLVED（已经解决）

　　已经确定了一种解决方案，这种方案正在等待QA的确认。此状态的bug可转化为以下状态:

　　1. 重新开放，转变为重开放(REOPENED)

　　2. QA确认后，转变为已验证(VERIFIED)

　　3. QA确认后，转变为关闭(CLOSE)

3.7 VERIFIED（已经证实）

　　QA已经确认对于这个bug的解决方案是成功的。处于这种状态的bug当他们所存在的产品正式发布之后，状态将转变为关闭(CLOSE)

3.8 CLOSED（已经关闭）

　　bug处于这种状态可视为已死亡，其解决方案是正确的。出于这种状态的bug要重新得到处理，只能通过转变他的状态为重开(REOPEN)。

3.9  Resolution：（解决方案）

　　解决方案字段表明对bug是如何处理的。

　　FIXED（已经修复）

　　　　对这个bug的源代码做了修改，放入代码库并且经过了测试。

　　INVALID（无效）

　　　　BUG确认人员认为所描述的问题不是一个BUG，因此也不会被修复。

　　WONTFIX（不做修改）

　　　　所描述的问题是一个bug，但由于某种原因不会进行修改。

　　LATER（以后修复）

　　　　所描述的问题是一个bug，但当前版本不会修改这个bug。

　　REMIND（延时提醒）

　　　　所描述的问题是一个bug，但尚未确定是否在当前版本进行修改。

　　DUPLICATE（重复）

　　　　所描述的问题是一个已存在bug。必须使用一个已存在的bug id对该bug进行标志。

　　WORKSFORME（不可重现）

　　　　无法根据描述对bug进行重现，阅读代码也无法解释所描述的问题。