缺陷等级，又称缺陷严重程度，通常划分为四个等级：阻塞、严重、一般、轻微。
当然，你也可以把“阻塞”称为“致命”，把“一般”称为“普通”，都不重要，反正要能明确表示出缺陷的级别。
开发人员在修复缺陷时，项目经理在盘点遗留缺陷时，“缺陷等级”都是很重要的参考字段。因此，如何合理进行缺陷定级，是软件研发流程中的大事，“不可不察也”。
然而，缺陷定级看起来似乎很简单，就是填个字段而已，有谁不会呢？但是平时开发测试因为缺陷定级意见不同而争论的情况（特别是公司对阻塞/严重缺陷数、消解时间有度量要求时），也并不少见。所以，今天我们就来谈一谈如何进行缺陷定级。
下面，先请股神巴菲特给大家讲一个故事吧。
巴菲特的左轮手枪
股神巴菲特曾经提出一个灵魂拷问：如果左轮手枪的6个弹孔里只有1发子弹，让你对着自己的头开一枪，给你100万美元，你愿意吗？
大部分人的回答是不愿意，原因大家都懂的，这个风险太大了。
巴菲特接着说了，接下来我们把条件放宽一点：手枪有100个弹孔，还是只有1发子弹，对着自己的头开一枪，给你100万，你愿意么？
这回愿意的人肯定多了一些，在他们眼中，100万美元可以帮他们解决很多困难，俗语说“富贵险中求”“人生能有几回博”，干了！但是，愿意这么做的，肯定还是生活陷入严重困境的人。
如果我们把条件进一步放宽：手枪有100个弹孔和1发子弹，不是对着自己的头而是对着脚开一枪，给你100万，你愿意么？……
这个故事我们就讲到这里，相信已经引起了大家的思考。
故事中的子弹，其实就是风险。这个小故事，涉及到了风险评估的几个关键要素：
- 风险概率：1/6，还是1/100？
- 风险影响程度：人挂掉，还是脚废掉？
- 风险偏好：谨慎者、激进者？
缺陷定级，本质上正是对缺陷产生的风险进行评估，其实也就是考虑上面几个要素：
风险概率：出现问题的条件有多复杂？概率有多大？路径有多深？可能受影响的用户范围有多大？
风险影响程度：对用户的伤害有多大？能否自行恢复？用户有没有办法绕过问题路径达成目的？是否影响用户的数据和资产？
风险偏好：公司对质量问题的容忍程度如何？这一点在发版前的遗留问题评审时才要考虑，一般在提交缺陷时无需关注
所以，我们就得到了缺陷定级的两个核心要素：
- 缺陷发生概率
- 缺陷影响程度
这也正是互联网公司（如：谷歌）通用的缺陷定级思路。
还有必要强调一下，在分析“缺陷影响程度”时，我们是假定“缺陷已发生”的状况下来评估其影响，而不能再考虑发生概率（否则概率的权重被叠加了两次）。只有这样，才符合MECE原则（各要素相互独立、互不重叠）。
缺陷定级常见规则
确定了缺陷定级的要素之后，还需要确定执行规则。常见的缺陷定级规则包括以下几类：
1）按功能模块分级
案例：浏览器
核心模块（阻塞）：网页浏览、视频播放、信息流、搜索、下载、升级
重要模块（严重）：多窗口、语音搜索、二维码扫描、账号、积分、书签历史、文字编辑、分享
普通模块（一般）：字体大小、屏幕旋转、广告屏蔽、皮肤、天气等
依据：不同功能模块的影响程度不同，一个应用的核心功能出问题，和普通功能出问题，对用户的影响截然不同。
优点：对功能模块进行了明确分类，有章可循。
缺点：需要逐一列出功能模块名称，如果被测应用较多则不便记忆；同一个模块的缺陷现象层出不穷，只根据模块来“一棒子打死”的方式，在执行时难免会产生困惑。
2）按现象描述分级
案例：浏览器
阻塞：业务逻辑完全错误、主路径功能无法打开、关键数据丢失、系统崩溃、无法安装、无法启动。
严重：功能不可用、概率性闪退、基本功能问题、高概率的严重性能问题。
如何进行缺陷定级？先听听巴菲特怎么说...
一般：非基本功能问题、功能与需求不符但不影响主要流程、页面内容错误、低概率的严重性能问题。
轻微：文字提示错误、UI设计问题。
依据：从现象角度，综合考虑了问题发生概率和问题影响程度。
优点：缺陷等级没有和模块强制绑定，适用范围更广。
缺点：不便于记忆；实际可能遇到规则描述中未包含的场景。
3）简化规则（推荐）
案例：任何APP
阻塞：大量用例无法执行、用户数据丢失且无法恢复、核心功能不可用且难以恢复、概率性核心场景Crash/ANR。
严重：非核心功能不可用且难以恢复、概率性非核心场景Crash/ANR。
普通：功能可用但存在问题。
轻微：功能正常但影响体验。
依据：综合考虑了问题发生概率和问题影响程度，尽量简化描述。
优点：便于记忆，适用范围更广。
缺点：测试人员对核心场景需要有主观的判断；必要时需根据业务情况补充规则（如：安全合规问题、性能问题定义为阻塞）
关于缺陷定级，上面讲了很多，最后我们做一个小结：
1、缺陷定级的考虑要素，包括问题发生概率、问题影响程度两个维度，任何应用都是如此；
2、缺陷定级规则的制定，应尽可能简化，便于记忆和使用，同时要满足业务实际情况；
3、好的定级规则，有助于减少开发测试的争议，同时能够言之有据，体现测试人员的专业性。
源自公众号 软件测试启示录