6、BUG生命历程的5种典型过程
（1）BUGStart--> BUG初始状态 -->BUG分配状态-->BUG重新分配状态 --> BUG修复状态 -->BUG验证状态 --> BUG关闭状态
测试人员发现BUG并且将该BUG标记为Unconfirmed&New状态，下一步测试人员在排除BUG的登记错误后，将该BUG置为Assigned状态。实现人员接到该BUG通告进行BUG确认，确认成功后该BUG状态被置为Reassigned状态，当实现人员修复BUG后该BUG置为Resolved&Fixed状态。测试人员对实现人员修复后的BUG进行确认测试，如果该BUG被正确修复了，那么其状态被置为Closed&Fixed状态，同时意味着该BUG的整个生命周期终结了
（2）BUGStart--> BUG修复状态 --> BUG验证状态 -->BUG关闭状态
回归测试后，如果部分登记BUG再次出现，测试人员可直接将已登记的Closed&Fixed状态的BUG转入修复流程，等实现人员修复BUG后将该BUG置为Resolved&Fixed状态。测试人员对实现人员修复后的BUG进行确认测试，如果该BUG被正确修复了，那么其状态被置为Closed&Fixed状态，同时意味着该BUG的整个生命周期终结了
（3）BUGStart--> BUG初始状态 --> BUG分配状态-->BUG重新分配状态
测试人员发现BUG并且将该BUG标记为Unconfirmed&New状态，下一步测试人员在排除BUG的登记错误后，将该BUG置为Assigned状态。实现人员接到该BUG通告进行BUG确认，确认失败后该BUG状态被置为Reassigned状态并发送回BUG起始阶段
（4）BUGStart--> BUG初始状态 --> BUG分配状态-->BUG重新分配状态 --> BUG修复状态 -->BUG重新打开状态
测试人员发现BUG并且将该BUG标记为Unconfirmed&New状态，下一步测试人员在排除BUG的登记错误后，将该BUG置为Assigned状态。实现人员接到该BUG通告进行BUG确认，确认成功后该BUG状态被置为Reassigned状态，当实现人员修复BUG后该BUG置为Resolved&Fixed状态，但是实现人员发现该BUG与其他实现人员的BUG有关联关系，可能导致本次修复无效，所以实现人员将该BUG置为Reopen状态发送回BUG起始阶段
（5）BUGStart--> BUG初始状态 --> BUG分配状态-->BUG重新分配状态 --> BUG修复状态 -->BUG验证状态 --> BUG重新打开状态
人员接到该BUG通告进行BUG确认，确认成功后该BUG状态被置为Reassigned状态，当实现人员修复BUG后该BUG置为Resolved&Fixed状态。测试人员对实现人员修复后的BUG进行确认测试，验证成功后测试人员怀疑该BUG并非真正修复，将该BUG置为Reopen状态发送回BUG起始阶段
7、BUG的流转状态关键字
● 未确定的（Unconfirmed）。这个BUG最近才被发现，还没有人确认它是否真的存在，如果有别的测试人员碰到了同样的问题，就可以将这个Bug标志为New，或者将这个Bug删除，或者做上closed标记。
● 新加入的（New）。这个BUG最近被测试人员添加到Bug列表中，已经被证实存在且必须修改的。即将被分配，如果分配了可以标志为Assigned，未分配则将保留New标志，或者做上Resolved标记。
● 确认分配的（Assigned）。测试人员将BUG的修复任务分配给具体的实现人员，如果BUG不属于被分配实现人员的范围，可置为Reassigned，等待被重新指定相关修改人员。
● 重新分配的（Reassigned）。该BUG不属于被分配实现人员的范围，可置为 Reassigned等待被重新指定相关修改人员。
● 需要帮助的（Needinfo）。测试人员或实现人员无法对发现的BUG进行精确定位或描述，需要相关实现人员协助，以更深刻地认识和修复这个Bug。
● 重复出现的（Reopened）。该BUG已经不是第一次被发现，它可以被标志为Assigned或者Resolved。
● 已解决的（Resolved）。实现人员对被分配给自己的BUG进行修改，修改完以后，修改状态。
● 重新启用的（Reopen）。当实现人员发现某些BUG具有关联性，即使该BUG被正确修复了，也会被发送到起始状态等待回归再次确认。或测试人员发现该BUG没有被真正修改后，重置状态。
● 正在验证的（Verified）。测试人员对标记为Resolved状态的BUG进行验证。
● 安全关闭的（Closed）。该BUG已经被完全解决。
