bugzilla的使用说明

BUgzilla使用

1. 描述

bugzilla是一个叫mozilla组织开发的缺陷跟踪系统，一般来说可能使用到的bugzilla的人有软件设计人员，开发人员，测试人员以及将来的维护人员等等。通过bugzilla，软件开发人员、测试人员、维护人员等等，就可以对软件的缺陷、有关软件的一些建议等等进行跟踪、记录和交流。对于测试人员来讲，bugzilla更是不可缺少的工具。

具体来说，bugzilla就是一个报告BUG和把BUG指派给合适开发人员的一个系统，这里所指的BUG可以是对于提高软件质量的一些建议等。一般来说，bugzilla的前台基于WEB页的形式，后台采用基于UNIX或LINUX的MYSQL数据库来存储、处理这些BUG。

2. 使用

2.1 开设账户

目前bugzilla服务器IP地址是http://192.168.0.254:8080/ 在使用Bugzilla前，必须在bugzilla系统中拥有你自己的账户，如果没有，可以开设。一般来说，如果连接到bugzilla的开始页面，会有一个[Open a new bugzilla Account]的标签，或在其它的页面，在左下角会有一个[New Account]标签，点击它，可以进行账户的开设，按它的指示填写好内容之后，系统会发一封电子邮件到你的邮箱里去，从邮件中你可以获得你登录bugzilla的密码。登录之后，通过点击[Edit Prefs]进行密码更改和个人资料的设置。设置好账户之后，你就可以在bugzilla报告和查询BUG了。

2.2 报告BUG

2.2.1 BUG内容的填写

登录后，进入查询页面，在页面的左下角会有一个[New]标签，点击它，连接到新建BUG的页面，选择一个产品进入Enter BUG页面，选择版本，组件等。目前在component栏里包括以下几部分：account（出账），billing（计费），card-广通（广通卡业务），营业受理，settlement（结算），采集，计费预处理，库表设计等。

选择软件运行的硬件平台，操作系统，优先级别和严重性等。对于优先级和严重性，可能测试人员和开发人员的看法可能不一样，测试人员认为是比较严重的BUG，而开发人员可能不那么认为，其基本标准请参考本文后面部分所描述的即可。

对于指派（Assigned To）的人，一般是这个模块的开发人员。bug的状态转变为新的(NEW)，并分配到该开发人员的bug列表中。进行默认查询时，状态

设置为新(NEW)，已分配(ASSIGNED)和重开(REOPENED)。当需要查找已经解决或验证的bug时，需要正确地对状态设置。对于抄送(CC)的人,一般为程序模块的负责人，或者测试组的负责人等。然后填写好BUG的内容，即可提交（commit）,对于BUG的SUMMARY一般应尽量短，同时最能描述出所出现的问题。

当BUG提交后，系统会根据你填写的内容及个人的资料配置自动发送邮件给与此BUG相关的人员。如果提交的BUG在一定的时间内没有被关注，对于它的状态字没有被修改，那么根据系统的配置，系统将发出邮件，提醒与BUG相关的人员，促使他们早日对BUG进行处理。

2.2.2 对BUG的一些描述字段

2.2.1.1 STATUS：（状态）

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

UNCONFIRMED：（未证实）

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

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

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

NEW（新BUG）

这个bug已经分发给某位开发人员处理。这个状态的bug可以转变为以下状态： 1. 接受该bug，状态转变为指派(ASSIGNED)

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

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

ASSIGNED（已经指派）

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

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

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

REOPENED（重新打开）

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

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

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

RESOLVED（已经解决）

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

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

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

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

VERIFIED（已经证实）

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

CLOSED（已经关闭）

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

2.2.1.2 Resolution：（解决方案）

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

FIXED（已经修复）

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

INVALID（无效）

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

WONTFIX（不做修改）

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

LATER（以后修复）

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

REMIND（延时提醒）

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

DUPLICATE（重复）

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

WORKSFORME（不可重现）

无法根据描述对bug进行重现，阅读代码也无法解释所描述的问题。如果以后能够提供更多的细节，再做处理，现在暂时存档。

2.2.1.3 Severity：（严重性）

用于描述BUG的严重级别。

BLOCKER（阻碍进度）：阻碍开发或测试的进行。

CRITICAL（严重）：崩溃，丢失数据，严重内存泄漏等等。

MAJOR（较大的BUG）：缺少主要的功能，或功能不能完成。