在一些大厂，关于bug的定义和定性，是有一整套非常完整的文档的，因为它涉及到测试员的绩效考核，严重的有效bug往往意味着更高的奖励。但是在小公司，bug的定义可能没有那么严格规范，但是对于版本质量的评估，安排开发解决问题的顺序都是有重大意义的。

以tapd管理bug系统举例简单说下：

【bug提交原则】

bug全部录入tp系统，不建议口头传递bug

【bug提交模板】

【bug严重程度和优先级定义】

bug严重程度

致命：严重阻塞问题，导致版本打回

严重：阻塞部分功能

一般：不耽误测试功能

提示：文案提示类问题

建议：非bug，从用户角度出发提交的优化建议

bug优先级

紧急：需要立即解决的问题，阻塞用例执行

高：需要优先解决的问题，相同原因引发的一系列问题

中：正常节奏处理

低：可解可不解的问题

【bug必要信息】

缺陷提交时的收集：

缺陷的严重等级、所在模块、发现的时间、发现版本、发现者、修改者

缺陷关闭时的收集：

缺陷关闭的时间、关闭的版本、修复缺陷而改动的代码行数、产生缺陷的根本原因（需求、分析、编码）

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

从以上总结可以看出，bug的等级判定主要是考察对用户的影响，如果用户无感知，这就是个轻微bug，如果用户明显觉得卡顿，点击页面都没有反应，无法进行下一步操作，那问题就比较严重了。其次，观察当出现问题的可恢复程度，如果页面崩掉，提交的数据没有保存，用户无法从当前的问题黑洞中脱离，必须清除数据或者卸载软件才可以，那这直接是致命bug无疑了。