bugzilla的安装与使用.docx

bugzilla的安装与使用.docx

《bugzilla的安装与使用.docx》由会员分享，可在线阅读，更多相关《bugzilla的安装与使用.docx（11页珍藏版）》请在冰豆网上搜索。

bugzilla的安装与使用

实验三Bugzilla的安装与使用

实验所属系列：

计算机系统与软件实验教学—软件系列实验对象：

本科生

相关课程及专业：

软件配置管理，计算机应用专业

实验类型：

操作性实验实验时数：

2学时

一、实验目的

在掌握Bugzilla安装方法的基础上，通过配置和使用subversion，培养学生培养学生分析和解决实际问题的能力，并增强学生的动手能力。

具体目的如下：

1.Bugzilla系统管理员的基本职责和常用命令

2.Bugzilla系统中一个变更项的状态跟踪及处理方法

3.以小组为研发团队基本单位，能相互配合完成变更项的生命周期管理，能与subversion工具进行配合解决某个版本中的代码缺陷。

二、实验原理

Bugzilla是一个拥有强大功能的错误跟踪系统。

它可以使我们更好的在软件开发过程中跟踪软件错误的处理过程，为开发和测试工作以及产品质量的度量提供数据支持，从而有效的保证软件产品的质量。

Bugzilla中bug的生命周期：

三、实验内容

1.Bugzilla系统管理员的基本职责和常用命令

*创建变更项

2.Bugzilla系统中一个变更项的状态跟踪及处理方法

*Bugzilla中的操作员角色设定；变更项的生命周期管理；

四、实验步骤

1.用户登陆

输入服务器地址http:

//192.168.xx.xx/bugzilla/

在登陆界面输入安装bugzilla时填入的账户（邮箱地址）、密码。

对于可以使用邮件功能的用户来说，还可以在登陆页面上点击【createanewaccount】申请一个账户。

在下图中填入你的邮箱地址，稍后会受到包含激活你账户的邮件。

账户激活以后就可以使用了。

管理员登录后自动进入查询页面；

一般用户登陆以后，会给出一些常用操作的链接：

2.修改密码及设置

点击Preference链接进入个人设置页面

【GeneralPreferences】进行BUG显示属性项的设置；

【EmailPreferences】这里由于没有使用Email，所以可以不用设置；

【SavedSearches】这里进行查询条件的编辑与设定；

【NameandPassword】进行密码修改；

【Permissions】页面可以查询自己拥有的权限，并对特定的子权限进行设置；

3.管理

点击页面中任意一个Administrator链接，进入下面的管理页面

【Parameters】系统参数设置

在AdministrativePolicies项中将allowbugdeletion和allowuserdeletion设置为On.系统默认是不能删除用户的，只能禁用。

默认情况下只能删除没有关联bug的产品。

在BugFields项中将useqacontact设置为On;

【Users】用户管理

在这里为每个小组成员创建账户，比如：

user1,user2,user3

【Products】添加、修改和删除产品。

点击产品名字，可以修改产品属性，【Add】添加产品，【Delete】删除产品。

这里我们添加一个产品Matrix：

提交以后提示没有构件：

点击【Editcomponents】进入构件页面

此时显示没有任何构件，这里我们添加三个构件，分别分配给不同的组员。

点击【Add】添加构件

三个构件创建好后，如下图：

4.创建Bug报告

报告一个bug之前先进行查询，确认要提交的bug报告不会在原有纪录中存在，若已经存在，不要提交，若有什么建议，可在原有纪录中增加注释，告知其属主，让bug的属主看到这个而自己去修改；若Bug不存在，创建一份有效的bug报告后进行提交。

查询bug

可以直接在任意页面顶部的查找框中进行快捷查询；

也可以点击顶部的search链接，进入专门的查询页面：

在高级搜索中还有更多搜索条件供选择：

我这里搜索segment找到一个bug：

报告Bug

找到页面顶部的【New】链接，点击后进入如下选择产品界面：

选择Matrix

填表注意：

【Assignedto】：

为空则默认为设定的owner,也可手工定制。

【CC】：

表示当bug报告发生变化时要通知哪些人。

有多人时需用"，"隔开。

【Desription】中要详细说明下列情况：

①发现问题的步骤；

②执行上述步骤后出现的情况；

③期望应出现的正确结果。

【Initialstate】为New或Unconfirmed。

操作结果：

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

5.指派处理人员

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

操作如下：

点击【AssignedTo】右边的edit链接

进入修改assignee界面：

修改好以后更改bug状态为ASSIGNED

最后点击【Commit】提交修改。

6.处理Bug

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

1．给出解决方法并填写AdditionalComments，还可创建附件（如：

更改提交单）

2．修改状态

具体填表项：

其中RESOLVED对应五个RESOLUTION选项：

　　FIXED：

描述的问题已经修改

　　INVALID：

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

　　WONTFIX：

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

　　DUPLICATE：

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

　　WORKSFORME：

所有要重新产生这个bug的企图是无效的。

如果有更多的信息出现，请重新分配这个bug，而现在只把它归档。

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

1．测试人员查询开发者已修改的bug，即Status为"Resolved"，Resolution为"Fixed"，进行重新测试。

（可创建testcase附件）

2．经验证无误后，修改Resolution为VERIFIED。

待整个产品发布后，修改为CLOSED。

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

五、实验操作方式

1．分组实验，每组3人。

2．实验授课4学时，介绍与实验相关的理论知识和软件平台。

3．实验时间估计2学时。

六、实验设备与环境

1．基本环境要求

①宽敞整洁专用实验室

②必备的基本实验工具

2．最低设备要求

①计算机CPU不小于800MHZ；

②计算机内存不小于128M；

③系统平台要求：

Unix。

3．软硬件要求

①网络通畅

②subversion已安装并配置好（实验一）

七、实验评分标准

1．评分标准（A优秀、B良好、C中等、D及格、E不及格）

2．测评方式

A：

完成实验步骤中的所有操作，并且所有操作都有正确的截图

B：

完成实验步骤中的所有操作，并且大部分操作的有正确的截图

C：

完成实验步骤中前4步操作，并且截图基本正确

D：

完成实验步骤中前4步操作，但是错误较多

E：

未完成实验步骤中前4步操作

八、实验指导教师

段翰聪