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

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

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

　　如果这个BUG一周内一直没被处理过。Bugzilla会一直用E-Mail骚扰它的属主，直到采取行动为止。

　　2.3 一个Bug的生存周期图示：

　　2.4 测试人员报告Bug的流程：

　　请先进行查询，确认要提交的bug报告不会在原有纪录中存在，若已经存在，不要提交，若有什么建议，可在原有纪录中增加注释，告知其属主，让bug的属主看到这个后自己去修改。

　　若Bug不存在，创建一份有效的bug报告后进行提交。

　　具体操作：点击【新建】，选择产品后，填写一个Bug报告的表格。填表注意：【指派给】为空则默认为设定的owner， 也可手工制定。【抄送】可为多人，需用逗号隔开。【描述】中要详细说明下列情况：

　　A. 发现问题的步骤;

　　B. 执行上述步骤后出现的情况;

　　C. 期望应出现的正确结果。

　　【平台】、【操作系统】、【优先级】、【严重级】，可以根据具体情况自行选择。

　　【依赖】是指与这个新Bug有关联的Bug号码。

　　【Blocks】不太清楚J

　　填写完毕之后，点击【Commit】提交，发送邮件通知给相关人员。

　　2.5 Bug的不同处理状态解释：

　　Bug的属主(owner)确认并接受这个Bug，然后给出解决方法，并填写【附加说明】，还可以【建立新的附件】(如：更改提交单)等等。

　　开发人员可以调整的Bug状态如下：

　　A. FIXED => 描述的问题已经修改;

　　B. INVALID => 描述的问题不是一个bug (输入错误后，通过此项来取消);

　　C. WONTFIX => 描述的问题将永远不会被修复;

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

　　E. DUPLICATE => 描述的问题是一个存在的bug的复件;

　　F. WORKSFORME => 所有要重新产生这个bug的企图是无效的。如果有更多的信息出现，请重新分配这个bug，而现在只把它归档。

　　测试人员收到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 关于权限的说明：

　　组内成员对bug具有查询的权利，但不能进行修改。

　　Bug的owner 和 reporter 具有修改的权利。

　　具有特殊权限的用户具有修改的权利。