1、 用户登录及设置流程：
打开浏览器， 进入 Bugzilla 主页面。
进入主页面后，点击【新建帐号】，进入注册页面。
在注册页面中输入 E-Mail 和 真实姓名（为了统一，这里我们都使用计算机名） ，然后，点击【 Create Account 】，随后，你将收到一封包含初始密码的 E-Mail 。
在收到 E-Mail 之后，点击【登录】，在帐号栏输入注册时使用的 E-Mail 地址，在密码栏输入邮件里通知的初始密码，然后，点击【 Login 】。
如忘记密码，在登陆页面中输入注册用户名，点击【 Submit Request 】 , 根据收到的邮件进行重新设置密码。
成功登录后，点击【 Edit 属性】 -> 【帐号设置】，进行密码修改。
点击【 Edit 属性】 -> 【邮件设置】，进行邮件通知设置。
点击【 Edit 属性】 -> 【权限】，进行权限查询。
2、 BUG 处理流程
• 测试人员或开发人员发现 bug 后，判断属于哪个模块的问题，填写 bug 报告后，系统会自动通过 Email 通知项目组长或直接通知开发者。
• 项目组长根据具体情况，重新 reassigned 分配给 bug 所属的开发者。
③ 开发者收到 Email 信息后，判断是否为自己的修改范围 .
1 ） 若不是 , 重新 reassigned 分配给项目组长或应该分配的开发者。
2 ） 若是，进行处理， resolved 并给出解决方法。（可创建补丁附件及补充说明）
④ 测试人员查询开发者已修改的 bug ，进行重新测试。（可创建 test case 附件）
1 ） 经验证无误后，修改状态为 VERIFIED 。待整个产品发布后，修改为 CLOSED 。
2 ） 还有问题， REOPENED ，状态重新变为“ New" ，并发邮件通知。
⑤ 如果这个 BUG 一周内一直没被处理过。 Bugzilla 就会一直用 email 骚扰它的属主，直到采取行 动。管理员可以设定最迟采取行动的期限，比如说 3 天，系统默认为 7 天。
3、 Bug 的提交过程
点击 【新建】 —〉选择发现的 bug 所在的产品名称。
在选择的产品 bug 提交页面中，选择或者输入 bug 信息。
◎模块：点“模块”两个字，可以查看关于这个产品的模块的详细信息。
◎平台、操作系统：可以根据发现 bug 的实际情况来选择，如果确定这个 bug 可以发生在所有的平台，选择 all 好了！
◎优先级： P1 至 P5 优先级逐渐减弱。
◎严重级： blocker 到 enhancement 严重程度降低。
Blocker: 阻碍了项目开发或者测试的继续进行。
Critical: 冲突，数据丢失和严重的内存泄漏等问题。
Major: 较大的功能缺陷。
Minor: 较小的功能缺陷。
Trivial: 拼写、对齐类的错误。
Enhancement: 需要改进的。
◎初始状态：开发人员的默认状态为“ unconfirmed”( 这个要由管理员设置，参见管理员操作指南 ) ，测试人员或者管理员此处为可选状态： unconfirmed 和 new.
◎ Assigned to: 为空时默认为管理员指定的 owner, 也可手工制定。
◎ CC: 可为多人，需用 " ， " 隔开。
◎ URL: bug 的定位（可选）。
◎注释：是对 bug 的概述（必须填写）。
◎ Desription 中要详细说明下列情况：
1 ） 发现问题的步骤
2 ） 执行上述步骤后出现的情况
3 ） 期望应出现的正确结果
◎关键字：单击“关键字”三个字，会显示管理员已经设定的关键字，选择其一，便于以查询。注意：此处不可以随意添加，必须使用已经存在的关键字才好。另外，如果管理员没有创建关键字的话，那么此项缺省。
◎依赖：直接输入与当前 bug 有依赖关系的 bug 的编号。简单地说，比如说这里输入“ 3 ”，那么就是说当前提交的 bug 有依赖关系，不是由于 3 导致了当前 bug ，就是当前 bug 导致了 bug3 。
确认无误后，“ commit”!
提交之后，系统会提示： bug 已经提交。在此页面的下半部分，会再次显示刚才提交的 bug 的详细信息，你可以在这里进行修改，重新 commit, 也可以在此增加新的附件或是附加说明来进一步说明 bug 。
4、对于 Bug 的不同处理情况
4.1 Bug 的属主 (owner) 处理问题，提出解决意见及方法。
给出解决方法并填写附加说明（ Additional Comments ），还可创建附件（如：更改提交单）。
填表提示：
FIXED 描述的问题已经修改， 该 bug 已经修复并检查过，源文件已经检入 CVS 库。
INVALID 描述的问题不是一个 bug ( 输入错误后，通过此项来取消 )
WONTFIX 描述的问题将永远不会被修复。
LATER 描述的问题将不会在产品的这个版本中解决。
DUPLICATE 描述的问题是一个存在的 bug 的复件。
WORKSFORME 所有要重新产生这个 bug 的企图是无效的。如果有更多的信息出现，请重新分配这个 bug ，而现在只把它归档。
4.2 项目组长或开发者重新指定 Bug 的属主。
① bug 不属于自己的范围，可置为 Assigned , 等待测试人员重新指定。
② bug 不属于自己的范围，但知道谁应该负责，在 Reassign bug to 的输入框中 直接输入被指定人的 Email 。
③操作结果：此时 bug 状态又变为 New ，此 bug 的 owner 变为被指定的人。
4.3 测试人员确认开发人员报告的 Bug 是否存在 .
查询状态为“ Unconfirmed" 的 Bug,
测试人员对开发人员提交的 Bug 进行确认，确认 Bug 存在。
具体操作：选中“ Confirm bug(change status to New)" 后，进行 commit.
操作结果：状态变为“ New".
4.4 测试人员验证已修改的 Bug
① 测试人员查询开发者已修改的 bug ，即 Status 为 "Resolved", Resolution 为 "Fixed". 进行重新测试。（可创建 test case 附件）
② 经验证无误后，修改 Resolution 为 VERIFIED 。待整个产品发布后，修改为 CLOSED 。
若测试之后发现还有问题， REOPENED ，状态重新变为“ New" ，并发邮件通知。
5、查询
登录 Bugzilla 缺陷跟踪系统后，点击查询，可以按照指定的一个或者多个查询条件进行查询。
◎摘要 (Summary) ： 下拉列表框选择查询规约。在其后的输入框中输入包含的信息，此信息的指定与提交bug时的注释信息相一致。
◎ 产品 (Product) ：选择所要查找的 bugs 所在的产品。
◎ 模块 (Component) ：选择 bugs 所在的模块。
◎ 版本 (Version) ：选择 bugs 版本。
◎注释 (Comments) ：可在下拉列表框中选择将要输入的包含信息的规约，其后指定包含的信息。此信息的指定根据提交 bugs 时所填写的描述信息。
◎ URL ： 指定关于 bugs 所在的 URL 。
◎关键字 (Keywords) ：指定包含或不包含该关键字的 bugs 。每个 bug 可以被指定关键字， bugs 报告人或者管理员可以编辑关键字。
◎ 状态 (Status) ：选择 bugs 状态。
◎ 处理 (Resolution) ：选择 bugs 处理的结果。
◎ 严重性 (Severity) ：选择 bugs 的严重级别。
◎ 优先级 (Priority) ：选择 bugs 的优先级别。
◎ 硬件 (Platform) ：选择存在 bugs 程序运行的平台。 ◎操作系统
