3.2、Bug的不同处理情况

　　3.2.1 Bug的属主 （owner） 处理问题后，提出解决意见及方法。

　　1）给出解决方法并填写Additional Comments，还可创建附件（如：更改提交单）

　　2）具体操作（填表项如下）

　　3）填表注意：

　　FIXED 描述的问题已经修改

　　INVALID 描述的问题不是一个bug （输入错误后，通过此项来取消）

　　WONTFIX 描述的问题将永远不会被修复。

　　LATER 描述的问题将不会在产品的这个版本中解决.

　　DUPLICATE 描述的问题是一个存在的bug的复件。

　　WORKSFORME 所有要重新产生这个bug的企图是无效的。如果有更多的信息

　　出现，请重新分配这个bug，而现在只把它归档。

　　3.2.2 项目组长或开发者重新指定Bug的属主。（owner）

　　1）为此bug不属于自己的范围，可置为 Assigned，等待测试人员重新指定。

　　2）为此bug不属于自己的范围，但知道谁应该负责，直接输入被指定人的Email， 进行Ressigned。

　　3）操作：（可选项如下）

　　* Accept bug （change status to ASSIGNED）

　　* Reassign bug to

　　* Reassign bug to owner and QA contact of selected component

　　4）操作结果：此时bug状态又变为New，此bug的owner变为被指定的人。

　　3.2.3 测试人员验证已修改的 Bug

　　1）测试人员查询开发者已修改的bug，即Status为“Resolved”，Resolution为“Fixed”.进行重新测试。（可创建test case附件）

　　2）经验证无误后，修改Resolution为VERIFIED。待整个产品发布后，修改为CLOSED。

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

　　3）具体操作（可选择项）

　　（1）Leave as RESOLVED FIXED

　　（2）Reopen bug

　　（3）Mark bug as VERIFIED

　　（4）Mark bug as CLOSED

　　3.2.4 Bug报告者（reporter）或其他有权限的用户修改及补充Bug

　　1）可以修改Bug的各项内容。

　　2）可以增加建立附件，添加一些评论来解释你正在做些什么和你为什么做。

　　3）操作结果：每当一些人修改了bug报告或加了一个评论，他们将会被加到CC列表中，bug报告中的改变会显在要发给属主、写报告者和CC列表中的人的电子邮件中。

　　3.2.5 测试人员确认开发人员报告的Bug是否存在

　　1）查询状态为“Unconfirmed”的Bug，

　　2）测试人员对开发人员提交的Bug进行确认，确认Bug存在。

　　3）具体操作：选中“Confirm bug（change status to New）”后，进行commit.

　　4）操作结果：状态变为“New”。

　　3.3 查询Bug

　　1）直接输入Bug Id，点击find 查询。可以查看Bug的活动纪录。

　　2）查询Bug活动的历史。

　　也可以在search页面设置搜索的条件然后搜索想要的bug列表。对于终比较满意的结果还可以将搜索结果保存，这样每次进入系统，在下面可以直接点击My Bugs旁边你保存的列表来查看已保存的bug列表。

　　4、报告（Reports）

　　Bugzilla 可以支持各种方式查看和追踪缺陷数据库的状态。

　　搜索（Search）       显示缺陷列表集。

　　表格状报告（Tabular reports）    以HTML或CSV形式，可以选择3个维度显示缺陷数目。

　　图形状报告（Graphical reports）    折线图、条杆图或饼状图。

　　选择不同的缺陷属性作为缺陷统计的坐标轴，也可以通过选择下面的 查询来精确定位统计的结果集。

　　横坐标： Horizontal

　　纵坐标： Vertical Axis

　　多表显示： Multiple Tables

　　设置好横、纵坐标选择项，还可以在下面进行更加详细的数据筛选。完成所有设置点击Generate Report生成报表。

　　5、BUG处理流程

　　1）测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，通过Email通知项目组长或直接通知开发者。

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

　　3）开发者收到Email信息后，判断是否为自己的修改范围.

　　（1）若不是，重新reassigned分配给项目组长或应该分配的开发者。

　　（2）若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明）

　　4）测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件）

　　（1）经验证无误后，修改状态为VERIFIED。待整个产品发布后，修改为CLOSED。

　　（2）还有问题，REOPENED，状态重新变为“New”，并发邮件通知。

　　5）如果这个BUG一周内一直没被处理过。Bugzilla会一直用email骚扰它的属主，直到采取行动。