3 . 填表注意：

　　FIXED 描述的问题已经修改

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

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

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

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

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

　　2.2.2 项目组长或开发者重新指定Bug的属主。(owner)

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

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

　　3. 操作：(可选项如下)

　　* Aclearcase/" target="_blank" >ccept bug (change status to ASSIGNED)

　　* Reassign bug to

　　* Reassign bug to owner and QA contact of selected component

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

　　2.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

　　2.2.4 Bug报告者(reporter)或其他有权限的用户修改及补充Bug

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

　　2. 可以增加建立附件，增加了相关性， 并加一些评论来解释你正在做些什么和你为什么做。

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

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

　　1. 查询状态为“Unconfirmed"的Bug，

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

　　3. 具体操作：选中“Confirm bug(change status to New)"后，进行commit.

　　4. 操作结果：状态变为“New".

　　2.3、查询Bug

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

　　2.点击Query，输入条件进行查询。

　　3.查询Bug活动的历史

　　4.产生报表。

　　5.帮助：点击Clue.

　　3、关于权限的说明

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

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

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