Bugzilla简明使用手则
1 简介：
Bugzilla 是 Mozilla 公司向我们提供的一个开源的免费缺陷跟踪工具。作为一个产品缺陷的记录及跟踪工具，它能够为你建立一个完善的 Bug 跟踪体系，包括报告 Bug 、查询 Bug 记录并产生报表、处理解决、管理员系统初始化和设置四部分。并具有如下特点：
l 基于 Web 方式，安装简单、运行方便快捷、管理安全。
l 有利于缺陷的清楚传达。本系统使用数据库进行管理，提供全面详尽的报告输入项，产生标准化的 Bug 报告。提供大量的分析选项和强大的查询匹配能力，能根据各种条件组合进行 Bug 统计。当错误在它的生命周期中变化时，开发人员、测试人员、及管理人员将及时获得动态的变化信息，允许你获取历史纪录，并在检查错误的状态时参考这一记录。
l 系统灵活，强大的可配置能力。 Bugzilla 工具可以对软件产品设定不同的模块，并针对不同的模块设定开发人员和测试人员；这样可以实现提交报告时自动发给指定的责任人；并可设定不同的小组。设定不同的用户对 Bug 记录的操作权限不同，可进行有效的控制管理。允许设定不同的严重程度和优先级，可以在错误的生命期中管理错误，从最初的报告到最后的解决，都有详细的记录，确保了错误不会被忽略，同时，可以让开发人员将注意力集中在优先级和严重程度高的错误上。
l 自动发送 Email 通知相关人员。根据设定的不同责任人，自动发送最新的动态信息，有效的帮助测试人员和开发人员进行沟通。
2 Bugzilla 操作流程：
2.1 用户登录及设置流程：
l 打开浏览器，输入 Bugzilla 服务器地址： http://server/bugzilla/
l 进入主页面后，点击【新建帐号】，进入注册页面。
l 在注册页面中输入 E-Mail 地址和用户代号，然后，点击【 Create Account 】，随后，你将收到一封包含初始密码的 E-Mail 。
l 在收到 E-Mail 之后，点击【登录】，在帐号栏输入注册时使用的 E-Mail 地址，在密码栏输入邮件里通知的初始密码，然后，点击【 Login 】。
l 如忘记密码，在登陆页面中输入注册用户名，点击【 Submit Request 】 , 根据收到的邮件进行重新设置密码。
l 如果成功登录后，点击【 Edit 属性】 -> 【帐号设置】，进行密码修改。
l 点击【 Edit 属性】 -> 【邮件设置】，进行邮件通知设置。
l 点击【 Edit 属性】 -> 【权限】，进行权限查询。
2.2 Bug 的处理流程概述：
l 测试人员或开发人员发现 bug 后，判断属于哪个模块的问题，填写 bug 报告后，通过 Email 通知项目组长或直接通知开发者。
l 项目组长根据具体情况，重新 reassigned 分配给 bug 所属的开发者。
l 开发者收到 E-Mail 信息后，判断是否为自己的修改范围。
A. 若不是，重新 reassigned 分配给项目组长或应该分配的开发者；
B. 若是，进行处理， resolved 并给出解决方法。（可创建补丁附件及补充说明）；
l 测试人员查询开发者已修改的 bug ，进行重新测试。（可创建 test case 附件）
A. 经验证无误后，修改状态为 VERIFIED 。待整个产品发布后，修改为 CLOSED 。
B. 还有问题， REOPENED ，状态重新变为“ New" ，并发邮件通知。
l 如果这个 BUG 一周内一直没被处理过。 Bugzilla 就会一直用 E-Mail 骚扰它的属主，直到采取行动为止。
2.3 一个 Bug 的生存周期图示：
2.4 测试人员报告 Bug 的流程：
l 请先进行查询，确认要提交的 bug 报告不会在原有纪录中存在，若已经存在，不要提交，若有什么建议，可在原有纪录中增加注释，告知其属主，让 bug 的属主看到这个后自己去修改。
l 若 Bug 不存在，创建一份有效的 bug 报告后进行提交。
l 具体操作：点击【新建】，选择产品后，填写一个 Bug 报告的表格。填表注意：【指派给】为空则默认为设定的 owner, 也可手工制定。【抄送】可为多人，需用逗号隔开。【描述】中要详细说明下列情况：
A. 发现问题的步骤；
B. 执行上述步骤后出现的情况；
C. 期望应出现的正确结果。
l 【平台】、【操作系统】、【优先级】、【严重级】，可以根据具体情况自行选择。
l 【依赖】是指与这个新 Bug 有关联的 Bug 号码。
l 【 Blocks 】不太清楚 J
l 填写完毕之后，点击【 Commit 】提交，发送邮件通知给相关人员。
2.5 Bug 的不同处理状态解释：
l Bug 的属主 (owner) 确认并接受这个 Bug ，然后给出解决方法，并填写【附加说明】，还可以【建立新的附件】（如：更改提交单）等等。
l 开发人员可以调整的 Bug 状态如下：
A. FIXED => 描述的问题已经修改；
B. INVALID => 描述的问题不是一个 bug ( 输入错误后，通过此项来取消 ) ；
C. WONTFIX => 描述的问题将永远不会被修复；
D. LATER => 描述的问题将不会在产品的这个版本中解决；
E. DUPLICATE => 描述的问题是一个存在的 bug 的复件；
F. WORKSFORME => 所有要重新产生这个 bug 的企图是无效的。如果有更多的信息出现，请重新分配这个 bug ，而现在只把它归档。
l 测试人员收到 Bug 的修改通知之后，还可以做如下的调整：
A. Leave as RESOLVED FIXED => 保持 FIXED 状态不变；
B. Reopen bug => 这个 bug 还有问题，重新打开；
C. Mark bug as VERIFIED => 这个 bug 确实被正确修改了；
D. Mark bug as CLOSED => 产品已经发布，将这个 bug 关闭。
2.6 关于权限的说明：
l 组内成员对 bug 具有查询的权利，但不能进行修改。
l Bug 的 owner 和 reporter 具有修改的权利。
l 具有特殊权限的用户具有修改的权利。