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的人,抄送的人等等的邮箱地址。
转自春城伊巴的博客