一篇文章讲清楚如何对软件缺陷进行管理(7)

需要帮助的（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)，该软件包违反了“必须”或“必要”的规定，或者是软件包维护人员和测试人员认为该软件包已不适合发布。

原文转自：http://www.uml.org.cn/Test/201611161.asp