Bugzilla 使用指南

本篇文章主要关注于如何高效合理的使用Bugzilla。

Bugzilla是一个开源的缺陷跟踪系统，它可以管理软件开发过程中缺陷的提交、修复、关闭等整个生命周期。

1. 基本概念

在Bugzilla中，Bug报告状态分为以下几种状态，

• 待确认的 unconfirmed

• 新提交的 new

• 已分配的 assigned

• 问题未解决的 reopened

• 待返测的 resolved

• 待归档的 verified

• 已归档的 closed

Bug处理意见（Resolution）

• 已修改的 fixed

• 不是问题 nvalid

• 无法修改 wontfix

• 以后版本解决 later

• 保留 remind

• 重复 duplicate

• 无法重现 workforme

2. 使用方法

2.1. 新建一个Bugzilla账号

当以个人身份登录Bugzilla系统时，需要新建一个账号，注册流程和一般的注册流程类似。

输入邮箱，点击确认后，修改自己的登陆密码，就完成注册流程。

如果用户忘记密码，可以在登陆界面中点击忘记密码就可以，通过注册邮箱来重置密码。

2.2. Bug的生命周期

2.3. 创建项目

管理员身份进入Bugzilla，点击Products创建新的Products。一个产品可以有多个模块，添加具体产品的对应模块，这样才提交Bug时，更有针对性。

2.4. 测试人员提交Bug流程

测试人员在提交Bug之前，请先进行查询，确认要提交的Bug不会在原有记录中存在，如果已经存在，不要提交，若有什么建议，可以再原有记录中增加注释，告知其属主，让Bug的属主看到这个后自己去修改。

在发现Bug后，先判断是属于哪个模块的问题，填写Bug报告后，通过Email通知项目组长或者直接通知开发者

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

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

具体流程图如下：

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

1. 测试人员查询开发者已经修改的Bug，即Status为“Resolved”，Resolution为“Fixed”

，重新测试

2. 经验证无误后，修改Resolutiong为VERIFIED，待产品发布后，修改为CLOSED

   若还有问题，将Bug改为REOPENED，状态重新变为“NEW”，并发邮件通知。

如下图所示：

3. Bugzilla的备份与恢复

Bugzilla的数据大部分放在数据库了，Bugzilla默认安装时的数据库为Bugs，我这里设置的也是一样的。备份的步骤是先备份Bugzilla数据库，然后备份整个Bugzilla的整个目录就可以。

恢复的过程很简单，把原来的备份和打包好的目录解压放在新机器相应的目录中，然后导入数据库。下图为恢复数据库的命令