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）：缺少主要的功能，或功能不能完成。

NOMAL（普通的BUG）：缺少一些普通的功能，或者一些用户不会轻易察觉的问题。

MINOR（次要的BUG）：缺少次要的功能，或者一些能够轻易解决的问题。

TRIVIAL（轻微的BUG）：很细小的问题如拼写错误，排版错误等。

ENHANCEMENT（增强）：一般对于增强软件质量或功能的一些建议。

2.2.1.4 Priority：（优先级）
P1 最重要
P2
P3
P4
P5 最不重要
其它还在几个字段为软件运行的硬件环境、操作系统等等。

2.3 查询BUG
在登录后，在页面底部会有[My Bugs]的标签，点击后显示与你有关的BUG。

如果要查询指定ID的BUG可以在页面底部的[BUG＃]文本框里输入BUG ID号，点击[find]按纽，可以查找指定的BUG，，对于一个BUG，你可以增加对BUG内容的描述，改变它的状态字等等。

对于比较复杂的查询，点击页面底部的[Query]标签即可进行不同条件组合的BUG查询。

其中大部分的条件就是我前面已经所说的那些BUG描述字段。

查询页中给出了Email地址输入栏，可以为指派人，报告BUG的人，抄送的人等等的邮箱地址。