在软件工程理论中,BUG严重级别(severity)是用于指示软件质量问题导致的负面影响的程度。但在大部分实际的软件开发组织中,对BUG严重级别(severity)的定义和使用常常充斥着大量的争议和分歧。甚至有些组织即使有专门的BUG严重级别定义文档,但是由于其描述的宽泛和模糊性,使得争议和分歧并没有得到有效的减轻。本文将尝试探讨工程实践中的一些具体问题,并提出笔者的一些观点。

BUG严重级别定义对于软件开发组织来讲,是一个非常重要的事情。因为它影响了如下几个方面:

  • 影响修复某个BUG的必要性和优先级
  • 衡量软件质量的重要因子之一

接下来探讨下工程实践的具体问题:

  1. 没有明确的BUG严重级别定义,或者BUG严重级别定义非常宽泛和模糊
    这个问题是一个普通存在的问题,也是测试团队和开发团队争议的重要源头。有些测试团队会把所有的软件崩溃重启问题都设置为较高严重级别,但是有时会遭到开发团队的反对,理由是此种崩溃重启问题只发生在一些不重要的功能的异常处理路径上。这个问题可以用汽车故障作类比,汽车行驶过程中行车电脑出现崩溃问题和车机娱乐系统连接某款手机的蓝牙出现崩溃问题,一般人都不会把两个问题放在一个严重级别,因为前者的影响是极大可能导致交通事故,而后者的影响只是使用某款手机带来不便。还有一些测试团队将某项重要功能的任何发现BUG都设置为较高严重级别,但是其问题在于,BUG发生在主路径(happy path)和异常处理路径具有明显不同的影响程度。后者在用户实际使用过程中执行到的概率较低,且通常可以有办法可以避开。最后提到一点,多数情况下测试团队和开发团队对同一功能同一执行路径下的BUG严重等级通常具有相当的共识,一般都认同导致系统无法启动的问题比起功能输出错误结果的问题有更高的严重等级。因此,BUG严重级别定义问题的根源常常在于没有考虑功能重要等级的明确定义和主路径/异常处理路径的区分。
  2. 随意指定BUG的严重级别导致开发团队问题修复的工作优先级混乱或者无法评估软件质量
    基于BUG严重级别是衡量软件质量的重要因子,开发团队应当根据BUG的严重级别来调整BUG修复工作的优先级。但在工程实践中,BUG报告者有两种极端:一种极端是将所有发现的BUG一律设置为最高或较高等级,究其原因是某些BUG报告者希望他所报告的问题都能以较高优先级处理;另外一种极端是将所有发现的BUG一律设置为最低等级,这种情况一般是BUG系统默认严重级别为最低,而报告者没有意识到他应该根据实际情况设置真实的严重级别或者报告者不知道如何定义严重级别。如果开发团队按照错误的BUG严重级别制定工作优先级计划,会导致整个团队以错误的优先级来开展工作。但在工程实践中,理智的开发团队领导者通常会根据实际自己的严重性级别判断来制定修复计划。但这也意味着BUG严重级别被完全忽略,软件质量的评估变得异常困难。
  3. 将BUG严重级别和BUG重现概率混淆在一起
    当测试团队报告了一个较高严重等级的BUG。但是开发团队提出异议,认为这个BUG虽然会导致使用某项主要功能出现问题但是复现概率低(<10%),所以严重等级应该降低。这个就是将BUG严重级别和BUG重现概率混淆在一起。BUG严重级别和BUG重现概率是两个相互独立的指标,可以认为没有交叠的地方。BUG重现概率一般来说与测试有前置条件相关,如果测试前置条件充分,理论上所有的BUG都可以100%复现。重现概率低于100%只能说明执行当前测试用例产生某个或多个未知的前置条件的概率小于100%,或者说执行当前测试用例出现这种负面影响的概率小于100%。而BUG严重级别是指示出现这个负面结果的影响。举一个例子,如果某个BUG在之前的测试复现概率为10%, 后面测试用例经过修改后测试复现概率变为80%。很明显,这个BUG的严重等级不应该因为测试用例的修改而改变。对于是否要修复某个BUG,应同时考虑严重等级和重现概率两个因素,这个依赖于开发组织特定的质量控制策略。一般来说,如果某个BUG严重性极高但复现概率低,采取的行动策略应该是设法改进测试用例或者创建新的测试用例提高复现率,以提高问题修复的可能性。如果严重性和复现概率都很低,不需要浪费开发资源在这类问题上。对于只出现过一次再不能复现的BUG,笔者的建议是一般情况下不做修复,因为不能复现的问题常常缺少必要的信息用于问题的定位,即使修复后也不能通过测试加以验证。补充一次,如果测试团队经常性上报此类问题,通常意味测试用例或测试环境的一致性有很大的问题,应该优先对此加以改进。

笔者对BUG严重级别管理有如下建议:

  1. 每个开发组织应该有一份公开且经过评审的文档明确定义BUG严重级别。
  2. BUG严重级别应该由功能的重要等级,主路径/异常处理路径,BUG产生错误的影响共同决定。BUG产生错误的影响一般可分为三级:不可恢复错误(系统无法启动,系统无法升级等),影响功能使用,不影响功能使用(字符显示拼写错误等)
  3. 在BUG管理系统中,严重级别不应该允许被直接设置,而应该由BUG报告者输入对应的用例名称/路径,BUG产生错误影响级别,由系统自动生成对应的严重级别。

谈谈BUG严重级别(severity)管理的更多相关文章

  1. itest(爱测试) 4.2.0 发布,开源BUG 跟踪管理 & 敏捷测试管理软件

    itest 入选 2019 年度最受欢迎开源中国软件 开源工具的发展,离不开你我的支持,需要您投上宝贵的一票  去投票 v4.2.0下载地址 :itest下载 itest 简介:查看简介 itest ...

  2. itest(爱测试) 4.2.1 发布,开源BUG 跟踪管理 & 敏捷测试管理软件

    itest 入选 2019 年度最受欢迎开源中国软件 开源工具的发展,离不开你我的支持,需要您投上宝贵的一票  去投票 itest 简介:查看简介 itest 开源敏捷测试管理,testOps 践行者 ...

  3. itest(爱测试) 4.1.5 发布,开源BUG 跟踪管理 & 敏捷测试管理软件

    v4.1.5下载地址 :itest下载 itest 简介:查看简介 itest 开源敏捷测试管理,testOps 践行者.可按测试包分配测试用例执行,也可建测试迭代(含任务,测试包,BUG)来组织测试 ...

  4. itest(爱测试) 4.1.1 发布,开源BUG 跟踪管理 & 敏捷测试管理软件

    v4.1.1下载地址 :itest下载 itest 简介:查看简介 itest 开源敏捷测试管理,testOps 践行者.可按测试包分配测试用例执行,也可建测试迭代(含任务,测试包,BUG)来组织测试 ...

  5. 迎国庆 itest(爱测试) 4.1.0 发布,开源BUG 跟踪管理 & 敏捷测试管理软件

    v4.1.0 下载地址 :itest下载 itest 简介:查看简介 在线体验 https://itest.work/demo/ V4.1.0 根据用户反馈,共增加了23个更新:其中有11个功能增强和 ...

  6. itest(爱测试) 3.5.0 发布,开源BUG 跟踪管理& 敏捷测试管理软件

    v3.5.0 下载地址 :itest下载 itest 简介:查看简介 V3.5.0 增加了 9个功能增强,和17个BUG修复 ,详情如下所述. 9个功能增强 : (1)增加xmind(思维导图) 转E ...

  7. itest(爱测试) 3.3.7 发布,开源BUG 跟踪管理& 敏捷测试管理软件

    v3.3.7 下载地址 :itest下载 itest 简介:查看简介 V3.3.7 增加了 5个功能增强,和8个BUG修复 ,详情如下所述. 5个功能增强 :(1)任务看板中,除了显示任务外,增加测试 ...

  8. itest(爱测试) 4.5.0 发布,开源BUG 跟踪管理 & 敏捷测试管理软件

    itest 简介 test 开源敏捷测试管理,testOps 践行者.可按测试包分配测试用例执行,也可建测试迭代(含任务,测试包,BUG)来组织测试工作,也有测试环境管理,还有很常用的测试度量:对于发 ...

  9. itest(爱测试) 4.4.0 发布,开源BUG 跟踪管理 & 敏捷测试管理软件

    itest 简介 test 开源敏捷测试管理,testOps 践行者.可按测试包分配测试用例执行,也可建测试迭代(含任务,测试包,BUG)来组织测试工作,也有测试环境管理,还有很常用的测试度量:对于发 ...

随机推荐

  1. Python网络爬虫四大选择器用法原理总结

    前几天小编连续写了四篇关于Python选择器的文章,分别用正则表达式.BeautifulSoup.Xpath.CSS选择器分别抓取京东网的商品信息.今天小编来给大家总结一下这四个选择器,让大家更加深刻 ...

  2. windows 下部署 .netcore 到 iis

    园子里已经有许多 ASP.NET Core  部署的相关文章,不同环境有不同的配置方法,建议同鞋们在动手之前也看看官方说明,做到心中有数.我在实践的时候用的是 win8.1 + .net core 3 ...

  3. 贪心法-------Saruman's army

    此题的策略是选取可用范围最右边的点,一般来说该点辐射两边,左侧辐射,右侧辐射,所以用两个循环,第一个循环找出该点,第二个循环求出最右边的点 源代码: #include<iostream># ...

  4. Java基础之常用知识点博客汇总

    正则: 正则表达式 :https://www.cnblogs.com/lzq198754/p/5780340.html 正则表达式大全:https://blog.csdn.net/zpz2411232 ...

  5. 性能分析(2)- 应用程序 CPU 使用率过高案例

    性能分析小案例系列,可以通过下面链接查看哦 https://www.cnblogs.com/poloyy/category/1814570.html 系统架构背景 其中一台用作 Web 服务器,来模拟 ...

  6. zabbix 监控nginx状态

    1. 安装nginx,参考其它 [root@iZ2zeapnvuohe8p14289u6Z /]# vim /etc/nginx/nginx.conf # 加上下面 location /nginx_s ...

  7. 代码扫描Sonar使用教程

    Sonar是一个用于代码质量管理的开源平台,用于管理源代码的质量,可以从多个维度检测代码质量: 可靠性 安全性 可维护性 覆盖率 重复率 通过插件形式,可以支持包括Java,C#,C/C++,PL/S ...

  8. 如何用Keil MDK5创建新项目

    1.安装相应软件 2.创建与Build项目 创建项目 下载与调试— ST-Link

  9. “随手记”开发记录day17

    继续开发账单的图形展示这一部分,丰富“随手记”的显示方法,对我们的APP进行添砖加瓦.

  10. Javascript注意点

    Javascript注意点 在img标签中的src如果为相对路径, 但是在js获取的时候会转为全路径 候选框中, 在执行onclick之前, 会由于html的特征先设置checked属性 为a标签添加 ...