5、BUG的生命周期
　　BUG初始状态（Unconfirmed&New态）
　　BUG分配状态（Assigned态）
　　BUG重新分配状态（Reassigned态）
　　BUG修复状态（Resolved&Fixed态）
　　BUG验证状态（Vertified&Fixed态）
　　BUG重新打开状态（Reopen态）
　　BUG关闭状态（Closed&Fixed态）
　　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已经被完全解决。
　　8、BUG的解决关键字
　　已经修复（Fixed），该BUG被正确修复了，并且得到了测试人员的确认。
　　无法修复（Wontfix），发现的BUG永远不会被修复，或者该BUG牵涉面太广需要委员会决定。
　　下版本解决（Later），发现的BUG不会在产品的这个版本中解决，将在下一个版本中被修复。
　　无法确定（Remind），发现的BUG可能不会在产品的这个版本中解决，也可能会。
　　重复的（Duplicate），发现的BUG是一个已存在BUG的复件。
　　无法证实（Incomplete），用了所有的方法都不能再现这个BUG，没有更多的线索来证实这BUG的存在，即使看程序源代码也无法确认这个Bug的出现。
　　测试错误（NotaBUG），BUG报告出现了错误，将正确的软件过程报告成BUG了。
　　无效的（Invalid），描述的问题不是BUG，属于测试人员输入错误，通过此项来取消。
　　问题归档（Worksforme），所有要重现这个BUG的企图都是无效的，如果该BUG有更多的信息出现，则重新分配这个BUG，而现在只把它列入问题归档。
　　9、BUG的严重等级
　　危急的（Critical)，能使不相关的系统内软件（或整个系统）损坏，或造成严重的信息遗失，或为安装该软件包的系统引入安全漏洞。
　　重大的（Grave)，使该软件包无法或几乎不可用，或造成数据遗失，或引入一个允许侵入此软件包用户之帐号的安全漏洞。
　　严重的（Serious)，该软件包违反了“必须”或“必要”的规定，或者是软件包维护人员和测试人员认为该软件包已不适合发布。
　　锁定的（Blocker)，这个Bug阻碍了后面的操作，需要马上或者尽快排除。
　　重要的（Important)，该错误影响了软件包可用性，但不至造成所有人都不可用。
　　常规的（Normal)，为默认，适用于大部份的错误。
　　轻微的（Minor)，该错误不致影响软件包的使用，而且应该很容易解决。
　　微不足道的（Trivial)，该错误无关紧要，多指外观GUI上的字符拼写错误，不影响整个项目。
　　10、BUG处理的优先等级
　　立刻修复（Immediate），这个BUG已经阻碍了开发工作或者测试工作，需要立刻修改。
　　马上修复（Urgent），这个BUG阻碍了软件的一部分应用，如果不修复它将妨碍下面计划的实施。
　　尽快修复（High），真实存在的并不是很严重，在版本发布之前修复。
　　正常修复（Normal），有充足的时间来修复这个问题，并且这个BUG给现行的系统的影响不大。
　　考虑修复（Low），不是什么关键BUG，当时间允许的时候可以考虑修复。