Bugzilla系统管理员培训手册

Bugzilla培训手册

系统管理员手册

前言.........................................................................1

培训前的故事.................................................................I

Bugzilla介绍.................................................................2

产生.....................................................................2

目的.....................................................................2

Bugzilla操作说明.............................................................3

1、用户登录及设置......................................................3

2、Bug的处理过程.......................................................3

4、BUG处理流程.......................................................5

Bugzilla管理员操作指南......................................................6

要紧工作内容：..........................................................6

基本操作：..............................................................6

管理group..............................................................................................................................6

管理Product与component.................................................................................................6

Bugzilla中的Bug流程........................................................7

前言

不论你有任何借口，只要你写程序，哪怕只是一个人的小组，假如你没有一个系统化的

管理软件BUG的工具，你写的程序的质量一定高不了。许多程序员觉得自己能够记得自己的

软件BUG。没门！我从来记不住超过2到3个软件BUG。而且第二天旦上起床后忙着去买这

买那，好不容易记住的软件BUG早忘掉了。你绝对需要一个系统来管住你的那些BUG。

软件BUG管理系统功能有多有少。但最少要管理下列几种信息：

•如何重复软件BUG的全面步骤

•正常情况（无BUG）应是如何

•现在情况（有BUG）又是如何

•谁来负责修补BUG

•问题是否具有解决

这就是公司搭建Bugzilla的意义所在。

培训前的故事

本段描述了软件工程开发中关于管理的重要性，可跳过阅读。

微软WindowsWord的第一版的开发项目曾被认为是“死亡之旅”项目。好象永远也做

不完，永远超时。所有人疯狂地工作，可怎么也完成不了任务。整个项目一拖再拖，大家都

觉得压力大得受不了。最后终于做完了这个鬼项目，微软把全组送到墨西哥的Cancun去度

假，让大家坐下来好好想想。

大家意识到由于项目经理过于强求程序员们按时交活，结果大家只能匆匆地赶活，写出

的程序毛病百出。由于项目经理的开发计划并没有考虑解决BUG的时间，大家只能把解决

BUG的任务往后推，结果BUG越积越多。有一个程序员负责写计算字体高度的程序，为了图

快，居然写一行“return12;”了事。他指望以后的质检人员发现这段程序有毛病后报告他

再改正。项目经理的开发计划事实上已变成一个列写程序功能的清单，而上面列的所谓程序

功能迟早都会成为软件BUGo在项目总结会上，我们称这种工作方法为“绝对劣质之路”。

记住：在任何时候，都要把解决现有程序里的问题作为首要问题来抓，然后再去写新程序。

通常说来，你越不及时地解决BUG,解决BUG的代价（时间与金钱）就会越高，随程序

开发进度而指数增长。比如，你写程序时打错了一个字，编译器马上告诉你，你很容易就把

它改正。你刚写好的程序在第一次运行时发现了一个问题，你也很快就能解决它，由于你对

你刚写的程序还经历犹新。假如你运行你的程序时发现了一个问题，可这个程序是几天往常

写的，你可能就需要折腾一会儿，还好，你还大致记得，因此不可能花太长时间。但假如你

在你几个月往常写的程序里发现了问题，就比较难解决了，由于你已经忘了许多细节。这时

候，你还没准儿正忙着解决别人程序里的BUG呐，由于这家伙到加勒比海阿鲁巴岛度假去了。

这时候，解决这堆问题的难度不亚于从事尖端科学研究。你定得小心翼翼地，井常系统

化地从事，而且你很难明白多长时间你才能把问题解决。还有更糟糕的，你的程序已交到用

户手里了，才发现问题，那你就等着套腰包吧。

总结起来，就一条：越早解决问题，越容易解决。

另外还有一个原因，刚写的程序里发现问题，你能够比较容易地估算解决它的时间。举

个例子，假如我问你写一•段程序去把•个列表排序需要花多长时间，你能够给我•个比较确

切的估计。假如你的程序，在InternetExplorer5.5安装以后，工作不正常。我问你要多

长时间把这个问题解决，你估计都估计不出来，由于你根本就不明白是什么原因造成了这个

问题。你可能要花三天时间才能解决，也有可能只花两分钟。

这个例子告诉我们，假如你的开发过程中有许多BUG没有及时解决，那你的开发计划确

信不可靠。反过来，假如你们已经把己知的BUG全部解决了，要做的事只是写新的程序，那

你的开发计划就会比较准确。

把已知的BUG全部解决，这样做还有一个好处：你能够对竞争对手快速反击。有些人把

这叫着“让开发中的产品随时处在能够交给用户的状态，假如你的竞争对于推出一个新的

功能想把你的客户抢走，你能够马上在你的产品里加上这个功能，立刻将新产品交付用户，

由于你没有一大堆积存下来的问题要解决。

Bugzilla介绍

产生

Bugzilla属于产品缺陷跟踪系统一种，创始人是TerryWeissman,开始时使用一种名为

“TCL”的语言创建的，后用Perl语言实现，并作为Opensource公布。

目的

也许你还没有看到•个错误管理系统所具有的价值；也许你正被大量的测试数据所淹没，而

迫切的需要一个产品缺陷的记录及跟踪的好帮手：也许你正在通过如：电子表格、数据库等各类

方式来不断的开发与完善一个错误跟踪系统。Mozilla公司向我们提供了一个共享的免费工具

Buzilla.作为一个产品缺陷的记录及跟踪工具，它能够为你建立一个完善的Bug跟踪体系，包含

报告Bug、查询Bug记录并产生报表、处懂得决、管理员系统初始化与设置四部分。并具有如下

特点：

1.基于Web方式，安装简单、运行方便快捷、管理安全。

2.有利于缺陷的清晰传达。本系统使用数据库进行管理.，提供全面详尽的报告输入项，产

生标准化的Bug报告。提供大量的分析选项与强大的查询匹配能力，能根据各类条件组合进行

Bug统计。当错误在它的生命周期中变化时，开发人员、测试人员、及管理人员将及时获得动态

的变化信息，同意你获取历史纪录，并在检查错误的状态时参考这一记录。

3.系统灵活，强大的可配置能力。Buzilla工具能够对软件产品设定不一致的模块，并针

对不一致的模块设定制定的开发人员与测试人员：这样能够实现提交报告时自动发给指定的责任

人；并可设定不一致的小组，权限也可划分。设定不一致的用户对Bug记录的操作权限不一致,

可有效操纵进行管理。同意设定不一致的严重程度与优先级能够在错误的生命其中管理错误，从

最初的报告到最后的解决，确保了错误不可能被忽略，同时能够使注意力集中在优先级与严重程

度高的错误上。

4.自动发送Email,通知有关人员。根据设定的不一致责任人，自动发送最新的动态信息，

有效的帮助测试人员与开发人员进行沟通。

下面我们将按照Bugzilla的操作说明、Dugzilla管理员的操作指甫两部分来说明这个工

具的具体使用。

Bugzilla操作说明

1、用户登录及设置

1.1用户登录

1.进入主页面后，点击【Lo义intoanexistingaccount],再点击【loginin]进入。

2.进入注册页面，输入用户名与密码即可登录。用户名为Email地址，初始密码为用户

名缩写。登录后自动进入查询页面。

3.如不记得密码，输入用户名，点击【submilrequest】，根据收到的邮件进行重新设置。

1.2修改密码及设置

1.Login登录后，【Editprefs]->[accoutsettings]进行密码修改。

2.[Editprefs]->【emailsettings]进行邮件设置。

3.[Editprefs]->[permissions]进行权限查询

2、Bug的处理过程

2.1报告Bug

2.1.1测试人员报告Bug

1.请先进行查询，确认要提交的bug报告不可能在原有纪录中存在，若已经存在，不要提

交，若有什么建议，可在原有纪录中增加注释，告知其属主，让bug的属主看到这个而自己去修

改。

2.若Bug不存在，创建一份有效的bug报告后进行提交。

3.操作：点击New,选择产品后，填写下表。

4.填表注意：Assignedto:为空则默认为设定的owner,也可手工制定。CC:可为多人,

需用"，"隔开。Desription中要全面说明下列情况：

1）发现问题的步骤

2）执行上述步骤后出现的情况

3）期望应出现的正确结果

选择group设置限定此bug对组的权限，若为空，则为公开。

5.操作结果：Bug状态（status）能够选择Initialstate为New或者Unconfirmed.

系统将自动通过Email通知项目组长或者直接通知开发者。

6.帮助：Bugwritingguidelines

2.1.2开发人员报告Bug.

1.具体方法同测试人员报告。

2.区别：Bug初始状态将自动设为Unconfirmed,待测试人员确定后变为“New”.

2.2Bug的不一致处理情况

2.2.1Bug的属主（owner）处理问题后，提出解决意见及方法。

1.给出解决方法并填写AdditionalComments,还可创建附件（如：更换提交单）

2.具体操作（填表项如下）

3.填表注意：

FIXED描述的问题已经修改

INVALID描述的问题不是一个bug（输入错误后，通过此项来取消）

WONTFIX描述的问题将永远不可能被修复。

LATER描述的问题将不可能在产品的这个版本中解决.

DUPLICATE描述的问题是一个存在的bug的复件。

WORKSFORME所有要重新产生这个bug的企图是无效的。假如有更多的信息出现，请重新分

配这个bug,而现在只把它归档。

2.2.2项目组长或者开发者重新指定Bug的属主。（owner）

1.为此bug不属于自己的范围，可置为Assigned,等待测试人员重新指定。

2.为此bug不属于自己的范围，但明白谁应该负责，直接输入被指定人的Email,进行

Ressignedo

3.操作：（可选项如下）

*Acceptbug（changestatustoASSIGNED）

*Reassignbugto

*ReassignbugtoownerandQAcontactofselectedcomponent

4.操作结果：如今bug状态又变为New,此bug的owner变为被指定的人。

2.2.3测试人员验证已修改的Bug.

1.测试人员查询开发者已修改的bug,即Status为"Resolved”,Resolution为"Fixed".

进行重新测试。（可创建testcase附件）

2.经验证无误后，修改Resolution为VERIFIED。待整个产品公布后，修改为CLOSED。

若还有问题，REOPENED,状态重新变为“New”,并发邮件通知。

3.具体操作（可选择项）

1.LeaveasRESOLVEDFIXED

2.Reopenbug

3.MarkbugasVERIFIED

4.MarkbugasCLOSED

2.2.4Bug报告者（reporter）或者其他有权限的用户修改及补充Bug

•能够修改Bug的各项内容。

•能够增加建立附件，增加了有关性，并加一些评论来解释你正在做些什么与你为什么做。

•操作结果：每当一些人修改了bug报告或者加了一个评论，他们将会被加到CC列表中，

bug报告中的改变会显在要发给属主、写报告者与CC列表中的人的电子邮件中。

2.2.5测试人员确认开发人员报告的Bug是否存在.

•查询状态为“Unconfirmed”的Bug,

•测试人员对开发人员提交的Bug进行确认，确认Bug存在。

•具体操作：选中“Confirmbug（changestatustoNew）”后，进行commit.

•操作结果：状态变为“New”.

2.3查询Bug

1.直接输入BugId,点击find查询。能够查看Bug的活动纪录。

2.点击Query,输入条件进行查询。

3.查询Bug活动的历史

4.产生报表。

5.帮助：点击Clue.

3、关于权限的说明

1.组内成员对bug具有查询的权利,但不能进行修改。

2.Bug的owner与reporter具有修改的权利。

3.具有特殊权限的用户具有修改的权利。

4、BUG处理流程

1.测试人员或者开发人员发现bug后，推断属于哪个模块的问题，填写bug报告后，通过

Email通知项目组长或者直接通知开发者。

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

3.开发者收到Email信息后，推断是否为自己的修改范围.

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

2）若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明）

4.测试人员查询开发者已修改的bug,进行重新测试。（可创建testcase附件）

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

2）还有问题，REOPENED,状态重新变为“New”,并发邮件通知。

5.假如这个BUG一周内一直没被处理过。Bugzilla就会一直用email骚扰它的属主，直

到采取行动。

Bugzilla管理员操作指南

要紧工作内容：

1.产品(Product)、版本号(versions)与模块(Components)的定义，同时指定模块相应的开

发者(owner)与测试人员(QAContact)。

2.小组的定义与划分

3.测试中Bug严重程度、优先级的定义

4.增加用户，并分别设定全部用户的分组、权限。

5.要紧参数(parameters)的设置

1)urlbase:输入bugzilla工具所在的服务器IP地址。

2)usebuggroupsentry:设为ON,能够分组。