在软件工程理论中,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. ubuntu DEBIAN_FRONTEND环境变量用法

    DEBIAN_FRONTEND环境变量,告知操作系统应该从哪儿获得用户输入.如果设置为"noninteractive",你就可以直接运行命令,而无需向用户请求输入(所有操作都是非交 ...

  2. 基于Python爬虫采集天气网实时信息

      相信小伙伴们都知道今冬以来范围最广.持续时间最长.影响最重的一场低温雨雪冰冻天气过程正在进行中.预计,今天安徽.江苏.浙江.湖北.湖南等地有暴雪,局地大暴雪,新增积雪深度4-8厘米,局地可达10- ...

  3. Java基础之Bridge method(桥接方法)

    1.什么是桥接方法 桥接方法是 JDK 1.5 引入泛型后,为了使Java的泛型方法生成的字节码和 1.5 版本前的字节码相兼容,由编译器自动生成的方法. 判断方法 我们可以通过 Method.isB ...

  4. spring学习(三)属性注入

    用的是IDEA的maven工程,pom.xml文件导包依赖省略 本文主要写set方式注入 (一).一般类型注入 一.写两个实体类Car.User public class Car { private ...

  5. ~~并发编程(十四):Queue~~

    进击のpython ***** 并发编程--Queue 进程其实就提过这个Queue的问题,我们为什么在进程使用Queue? 是因为当时我们想要对共享数据进行修改,同时也希望它能够自动的给我加个锁 基 ...

  6. integrator.setTimeout 设置一个超时时间,超过这个时间之后,扫描的 Activity 将会被 finish 。

    integrator.setTimeout 设置一个超时时间,超过这个时间之后,扫描的 Activity 将会被 finish . +++++++++++++++++++ 经查,没有这个功能

  7. SpringSecurity匹配规则介绍

    SpringSecurity匹配规则一 URL匹配 requestMatchers() 配置一个request Mather数组,参数为RequestMatcher 对象,其match 规则自定义,需 ...

  8. springmvc的原理与流程

    springMVC中的几个组件: 前端控制器(DispatcherServlet):接收请求,响应结果,相当于电脑的CPU. 处理器映射器(HandlerMapping):根据URL去查找处理器 处理 ...

  9. 每日一道 LeetCode (1):两数之和

    引言 前段时间看到一篇刷 LeetCode 的文章,感触很深,我本身自己上大学的时候,没怎么研究过算法这一方面,导致自己直到现在算法都不咋地. 一直有心想填补下自己的这个短板,实际上又一直给自己找理由 ...

  10. functools 中的 reduce 函数基本写法

    reduce 返回的往往是一整个可迭代对象的 操作结果 reduce(函数,可迭代对象) 注:lambda x,y 两个参数 2020-05-04