Bugzilla 使用指南

Bugzilla安装见前一篇博客，本篇文章主要关注于如何高效合理的使用Bugzilla，作为为公司内部人员的培训使用指南。

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

 

1. 基本概念

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

    待确认的      unconfirmed

    新提交的      new

    已分配的      assigned

    问题未解决的 reopened

    待返测的       resolved

    待归档的       verified

    已归档的       closed

 

Bug处理意见（Resolution）

    已修改的      fixed

    不是问题       nvalid

    无法修改       wontfix

    以后版本解决  later

     保留           remind

     重复           duplicate

     无法重现      workforme 

2. 使用方法

1. 新建一个Bugzilla账号

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

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

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

2.  Bug的生命周期

  

3. 创建项目

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

4. 测试人员提交Bug流程

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

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

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

 

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

具体流程图如下：

 

 

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

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

，重新测试

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

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

如下图所示：

 

3. Bugzilla的备份与恢复

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

 

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

Technorati 标签: Bugzilla, 测试