◎ 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 程序运行的平台。 ◎操作系统