如何避免因BUG级别定义错误带来的问题？

Bug级别定义很重要。

通常我们定义Bug级别，不是为了统计各个级别的Bug数/缺陷率方便，更多是会和我们处理Bug的策略有关系。比如，我们可能会要求“严重以上Bug不能存在，一般性Bug可以遗留2%～5%”，那么如果你将Bug级别从严重级别错误地定义为一般级别，那么开发可能会将这个Bug遗留下来，结果到了用户那里这样的Bug却不能接受，从而严重影响了用户满意度。

造成这种现象的原因是Bug级别定义规则太过单一。比如，这样的Bug级别定义：

Bug级别特征描述致命错误软件崩溃、死机、死循环；数据库死锁；重要功能丧失严重错误流程错误；功能不符；接口错误；计算错误一般错误界面显示不清楚，不好理解；打印内容、格式错误；拼写错误；删除操作无提示次要错误界面风格不统一；操作复杂，提示不友好；帮助描述不清楚；刷新有闪烁测试建议需求未明确定义的建设性处理意见；符合用户使用习惯的建议

这种常见的Bug级别定义就是只从功能角度出发作出的定义，没有考虑用户使用频率、使用体验等其他的角度。所以，这种定义容易出现因为不同的人对定义理解的不一致，给出错误的Bug级别。

为了避免这种情况发生，可以参考下表对Bug级别进行二维定义：

影响面\Bug级别致命错误严重错误一般错误次要错误测试建议法律法规不符合行业的法律、法规定义，可能导致人身伤害、财产损失



功能性能软件崩溃、死机、死循环数据丢失或破坏、流程错误、接口错误等导致主要功能性能丧失或受到影响次要功能或性能丧失或受到影响，如刷新慢，打印格式错误等界面个别字符串显示不全，但不影响理解需求没明确定义的建议处理意见用户体验
严重影响用户使用，可能引起用户不满、投诉影响用户使用，但不会引起投诉不影响用户使用，用户很难察觉的问题符合用户使用习惯的建议生产效率
严重影响生产效率


品牌形象
明显影响公司形象和声誉可能对公司形象和声誉有损

使用频率用户高频使用的功能用户常用功能用户不常用但给用户使用的功能不影响用户使用但存在缺陷

使用类似上述的二维方式从多角度来定义Bug级别，有助于避免出现Bug级别定义错误而带来的问题。

这正是：

简单定义有问题，二维定义可避免
Bug级别咋定义，还望大家多考虑

参考书目: 软件测试之魂：核心测试设计精解，作者：肖利琼，出版社：电子工业出版社