搜档网
当前位置:搜档网 › (培训体系)系统管理员手册

(培训体系)系统管理员手册

Bugzilla

系统管理员手册

前言 (1)

培训前的故事 (1)

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的意义所在。

培训前的故事

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

微软Windows Word的第一版的开发项目曾被认为是“死亡之旅”项目。好象永远也做不完,永远超时。所有人疯狂地工作,可怎么也完成不了任务。整个项目一拖再拖,大家都觉得压力大得受不了。最后终于做完了这个鬼项目,微软把全组送到墨西哥的Cancun去度

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

大家意识到由于项目经理过于强求程序员们按时交活,结果大家只能匆匆地赶活,写出的程序毛病百出。由于项目经理的开发计划并没有考虑解决BUG的时间,大家只能把解决BUG的任务往后推,结果BUG越积越多。有一个程序员负责写计算字体高度的程序,为了图快,居然写一行“return 12;”了事。他指望以后的质检人员发现这段程序有毛病后报告他再改正。项目经理的开发计划事实上已变成一个列写程序功能的清单,而上面列的所谓程序功能迟早都会成为软件BUG。在项目总结会上,我们称这种工作方法为“绝对劣质之路”。

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

一般说来,你越不及时地解决BUG,解决BUG的代价(时间和金钱)就会越高,随程序开发进度而指数增长。比如,你写程序时打错了一个字,编译器马上告诉你,你很容易就把它改正。你刚写好的程序在第一次运行时发现了一个问题,你也很快就能解决它,因为你对你刚写的程序还记忆犹新。如果你运行你的程序时发现了一个问题,可这个程序是几天以前写的,你可能就需要折腾一会儿,还好,你还大致记得,所以不会花太长时间。但如果你在你几个月以前写的程序里发现了问题,就比较难解决了,因为你已经忘了许多细节。这时候,你还没准儿正忙着解决别人程序里的BUG呐,因为这家伙到加勒比海阿鲁巴岛度假去了。这时候,解决这一堆问题的难度不亚于从事尖端科学研究。你一定得小心翼翼地,非常系统化地从事,而且你很难知道多长时间你才能把问题解决。还有更糟糕的,你的程序已交到用户手里了,才发现问题,那你就等着套腰包吧。

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

另外还有一个原因,刚写的程序里发现问题,你能够比较容易地估算解决它的时间。举个例子,如果我问你写一段程序去把一个列表排序需要花多长时间,你可以给我一个比较确切的估计。如果你的程序,在Internet Explorer 5.5安装以后,工作不正常。我问你要多长时间把这个问题解决,你恐怕都估计不出来,因为你根本就不知道是什么原因造成了这个问题。你可能要花三天时间才能解决,也有可能只花两分钟。

这个例子告诉我们,如果你的开发过程中有许多BUG没有及时解决,那你的开发计划肯定不可靠。反过来,如果你们已经把已知的BUG全部解决了,要做的事只是写新的程序,那你的开发计划就会比较准确。

把已知的BUG全部解决,这样做还有一个好处:你可以对竞争对手快速反击。有些人把这叫着“让开发中的产品随时处在可以交给用户的状态”。如果你的竞争对手推出一个新的功能想把你的客户抢走,你可以马上在你的产品里加上这个功能,立刻将新产品交付用户,因为你没有一大堆积累下来的问题要解决。

Bugzilla介绍

产生

Bugzilla属于产品缺陷跟踪系统一种,创始人是Terry Weissman,开始时使用一种名为“TCL”的语言创建的,后用Perl语言实现,并作为Open source发布。

目的

也许你还没有看到一个错误管理系统所具有的价值;也许你正被大量的测试数据所淹没,而迫切的需要一个产品缺陷的记录及跟踪的好帮手;也许你正在通过如:电子表格、数据库等各种方式来不断的开发和完善一个错误跟踪系统。Mozilla公司向我们提供了一个共享的免费工具

Buzilla.作为一个产品缺陷的记录及跟踪工具,它能够为你建立一个完善的Bug跟踪体系,包括报告Bug、查询Bug记录并产生报表、处理解决、管理员系统初始化和设置四部分。并具有如下特点:

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

2.有利于缺陷的清楚传达。本系统使用数据库进行管理,提供全面详尽的报告输入项,产生标准化的Bug报告。提供大量的分析选项和强大的查询匹配能力,能根据各种条件组合进行Bug统计。当错误在它的生命周期中变化时,开发人员、测试人员、及管理人员将及时获得动态的变化信息,允许你获取历史纪录,并在检查错误的状态时参考这一记录。

3.系统灵活,强大的可配置能力。Buzilla工具可以对软件产品设定不同的模块,并针对不同的模块设定制定的开发人员和测试人员;这样可以实现提交报告时自动发给指定的责任人;并可设定不同的小组,权限也可划分。设定不同的用户对Bug记录的操作权限不同,可有效控制进行管理。允许设定不同的严重程度和优先级可以在错误的生命其中管理错误,从最初的报告到最后的解决,确保了错误不会被忽略,同时可以使注意力集中在优先级和严重程度高的错误上。

4.自动发送Email,通知相关人员。根据设定的不同责任人,自动发送最新的动态信息,有效的帮助测试人员和开发人员进行沟通。

下面我们将按照Bugzilla的操作说明、Bugzilla管理员的操作指南两部分来说明这个工具的具体使用。

Bugzilla操作说明

1、用户登录及设置

1.1用户登录

1.用户输入服务器地址http://19

2.168.1.9/cgi-bin/bugs/index.cgi。

2.进入主页面后,点击【Log in to an existing account】,再点击【login in】进入。

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

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

4.如忘记密码,输入用户名,点击【submit request】,根据收到的邮件进行重新设置。

1.2 修改密码及设置

1.Login登录后,【Edit prefs】->【accout settings】进行密码修改。

2.【Edit prefs】->【email settings】进行邮件设置。

3.【Edit prefs】-> 【permissions】进行权限查询

2、Bug的处理过程

2.1 报告Bug

2.1.1测试人员报告Bug

1.请先进行查询,确认要提交的bug报告不会在原有纪录中存在,若已经存在,不要提交,若有什么建议,可在原有纪录中增加注释,告知其属主,让bug的属主看到这个而自己去修改。

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

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

4.填表注意:Assigned to: 为空则默认为设定的owner, 也可手工制定。CC: 可为多人,需用","隔开。Desription中要详细说明下列情况:

1)发现问题的步骤

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

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

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

5. 操作结果:Bug状态(status)可以选择Initial state 为New或Unconfirmed.

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

6.帮助:Bug writing guidelines

2.1.2 开发人员报告Bug.

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

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

2.2 Bug的不同处理情况

2.2.1 Bug的属主(owner) 处理问题后,提出解决意见及方法。

1 . 给出解决方法并填写Additional Comments,还可创建附件(如:更改提交单)

2.具体操作(填表项如下)

3 . 填表注意:

FIXED 描述的问题已经修改

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

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

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

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

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

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

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

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

3. 操作:(可选项如下)

* Accept bug (change status to ASSIGNED)

* Reassign bug to

* Reassign bug to owner and QA contact of selected component

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

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

1.测试人员查询开发者已修改的bug,即Status为"Resolved",Resolution为"Fixed".进行重新测试。(可创建test case附件)

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

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

3.具体操作(可选择项)

1. Leave as RESOLVED FIXED

2. Reopen bug

3. Mark bug as VERIFIED

4. Mark bug as CLOSED

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

●可以修改Bug的各项内容。

●可以增加建立附件,增加了相关性, 并加一些评论来解释你正在做些什么和你为什么做。

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

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

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

●查询状态为“Unconfirmed"的Bug,

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

●具体操作:选中“Confirm bug(change status to New)"后,进行commit.

●操作结果:状态变为“New".

2.3 查询Bug

1.直接输入Bug Id,点击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,进行重新测试。(可创建test case附件)1)经验证无误后,修改状态为VERIFIED。待整个产品发布后,修改为CLOSED。

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

5.如果这个BUG一周内一直没被处理过。Bugzilla就会一直用email骚扰它的属主,直到采取行动。

Bugzilla管理员操作指南

主要工作内容:

1.产品(Product)、版本号(versions)和模块(Components)的定义,同时指定模块相应的开发者(owner)和测试人员(QA Contact)。

2.小组的定义和划分

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

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

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

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

2)usebuggroupsentry: 设为ON,可以分组。

3)whinedays:Bug在whinedays设定的期限内若未被处理,将自动重发mail,默认为7天。

4)defaultpriority:设定默认的优先级

5)commentonresolve:设为ON,系统将强制要求开发者处理完Bug 后,必须填写修改的内容。

基本操作:

1.创建默认的管理员用户。

运行checksetup.pl。若不小心删除管理员,重新运行checksetup.pl.

2.管理用户

1)增加新用户

点击页面右下角【users】,submit后,出现【Add new user】页面。输入相应输入即可。Login name: 一般为邮件地址,可以设为其他标识。

2)禁止一个用户

填写Disabled text 输入框即可。

3)修改用户

可以修改用户注册名、密码。

设置权限

QA的权限一般设为: Canconfirm, editbugs

Developer的权限设为: none

分组控制:group

管理group

1.增加group

edit groupàadd groups (New User Regexp可不填/active 选择则可选)->add

2.修改group ,submit 即可。

管理Product 和component

1)增加产品Product

2) 增加组件Component 对应一个owner(进行fixed),QA Contact(确保已fixed)

3) Component Number of Unconfirmed =10000,此产品将选择bug的初始状态(Unconfirmed,New)

Bugzilla中的Bug流程

相关主题