如何进行缺陷定级?先听听巴菲特怎么说...

缺陷等级,又称缺陷严重程度,通常划分为四个等级:阻塞、严重、一般、轻微。

当然,你也可以把“阻塞”称为“致命”,把“一般”称为“普通”,都不重要,反正要能明确表示出缺陷的级别。

开发人员在修复缺陷时,项目经理在盘点遗留缺陷时,“缺陷等级”都是很重要的参考字段。因此,如何合理进行缺陷定级,是软件研发流程中的大事,“不可不察也”。

然而,缺陷定级看起来似乎很简单,就是填个字段而已,有谁不会呢?但是平时开发测试因为缺陷定级意见不同而争论的情况(特别是公司对阻塞/严重缺陷数、消解时间有度量要求时),也并不少见。所以,今天我们就来谈一谈如何进行缺陷定级。

下面,先请股神巴菲特给大家讲一个故事吧。

巴菲特的左轮手枪

如何进行缺陷定级?先听听巴菲特怎么说...

股神巴菲特曾经提出一个灵魂拷问:如果左轮手枪的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、好的定级规则,有助于减少开发测试的争议,同时能够言之有据,体现测试人员的专业性。

源自公众号 软件测试启示录



留言