1 、 用户登录及设置流程： 打开浏览器， 进入 Bugzilla 主页面。 进入主页面后，点击【新建帐号】，进入注册页面。 在注册页面中输入 E-Mail 和 真实姓名（为了统一，这里我们都使用计算机名） ，然后，点击【 Create Account 】，随后，你将收到一封包含初始密码的 E-Mail 。 在收到 E-Mail 之后，点击【登录】，在帐号栏输入注册时使用的 E-Mail 地址，在密码栏输入邮件里通知的初始密码，然后，点击【 Login 】。 如忘记密码，在登陆页面中输入注册用户名，点击【 Submit Request 】 , 根据收到的邮件进行重新设置密码。 成功登录后，点击【 Edit 属性】 -> 【帐号设置】，进行密码修改。 点击【 Edit 属性】 -> 【邮件设置】，进行邮件通知设置。 点击【 Edit 属性】 -> 【权限】，进行权限查询。 2 、 BUG 处理流程 �6�1 测试人员或开发人员发现 bug 后，判断属于哪个模块的问题，填写 bug 报告后，系统会自动通过 Email 通知项目组长或直接通知开发者。 �6�1 项目组长根据具体情况，重新 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 程序运行的平台。 ◎操作系统 (OpSystem) ：选择存在 bugs 程序所运行的操作系统。
