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

致命bug:不能完全满足系统要求,系统停止运行,系统的重要部件无法运行,系统崩溃或者挂起等导致系统不能正常运行. 修改优先级为最高,该级别问题需要立即修改. 1.系统崩溃 2.导致程序重启,死机或非法退出 3.死循环 4.数据丢失或异常 5.数据通讯错误. 6.硬件故障,系统悬挂 严重bug:严重地影响系统要求或基本功能的实现,且没有更正办法(重新安装或重新启动该软件不属于更正办法).使系统不稳定.或破坏数据.或产生错误结果,或部分功能无法执行,而且是常规操作中经常发生或非常规操作中不可避免的主

bug级别分类 2014-10-20 10:02 6403人阅读 评论(0) 收藏 举报  分类: SQA(17)  版权声明:本文为博主原创文章,未经博主允许不得转载.   目录(?)[+]   由于要做bug数据分析,要了解缺陷管理系统的分类方法,去网上搜索到如下分类法: 英文参考: BUG的严重级别分类 Severity This field describes the impact of a bug. Blocker: Blocks development and/or testing

一.主要分类 BUG类型标准主要分两类: Ø 依据优先级分类. Ø 依据严重程度分类. 二.主要内容 依据优先级分类标准 定义 优先级:指一个BUG相对于其他BUG对于公司的影响,解决的及时性. 分类标准 紧急 ² 系统无法工作 ² 测试无法继续正常工作 ² 特殊情况:如重要客户(项目重要性) 高 ² 需求问题 ² 实现与需求不符 ² 出现调试代码 ² 功能性错误 ² 关联性错误 ² 前后模块不一致 ² 链接错误 ² 特殊性的程度性能低下 ² 程序引起的安全问题 注:涉及所有关于数据流的错误 中

缺陷种类 缺陷级别 详细说明 功能缺陷 Urgent (V级) 1.操作系统无法正常使用,死机,出现致命错误 2.数据丢失 3.被测试系统频繁崩溃,程序出错,使功能不能继续使用 4.性能与需求不一致 5.系统资源弓|发性能问题 6.系统配置引发错误 7.安全性问题 Very High (IV级) 1.功能与需求不致,或功能未实现 2.功能有错误,影响使用 3.数据传输有错误 4.安装与卸载问题 High (III级) 1功能有错误,但不影响使用 2.界面错误 3.边界条件出错 Medium (I

通过图片另存为 或者 放大浏览器倍率 查看.

3月25日,阿里的淘宝APP在IOS系统上出现BUG: 在打开淘宝APP以后,用户就会收到系统弹窗通知:“您使用的程序是测试/内测版本,将于当地时间2020-03-28到期,到期后将无法使用,请尽快下载最新版本.” 而且,很多网友发现,把手机时间设置为3月28日18时后,淘宝APP仍然会弹跳出一个页面,并提示“您使用的程序是测试内测版本,目前已经过期,请更新到最新版本”.点击确认后,APP会自动闪退,用户无法浏览淘宝页面. 这也就意味着,如果到28号仍然无法修复这个bug,淘宝这个APP将不能再

生活中有这么一种现象:如果你关注某些东西,它就会经常出现在你眼前,例如一个不出名的歌手的名字,一种动物的卡通形象,某个非常专业的术语,等等等等.这种现象也叫做“孕妇效应”.还有类似的一种效应叫做“视网膜效应”,它讲的是:你有什么东西或者特质你就特别容易在别处发现你有的这类东西和特质.干了多年测试的我就会经常发现日常使用的系统中有很多的bug,而我老婆就发现不了.今天要说的事儿是“重现难以重现的bug”,这件事儿在本周共遇见了4次:第一次是微博上有一篇<程序员,你调试过的最难的 Bug 是?>(

一.提单模板 标题:[项目组][模块][子模块][发生原因]问题简要描述描述:[预置条件] 有就写清楚,没有就写无[操作步骤]1.XXXXX2.XXXXXX3.XXXXX[实际结果] XXXXX[预期结果] XXXXXX[问题发生时间]——偶现的问题必须要写,必现问题可以不用写[设备信息]机器人SN号[复现概率]3/3[备注]如果有一些其他信息,可以写在这里 二.偶现bug 在上述提交bug要求上添加:1.填写复现概率(30次以上),寻找规律协助开发定位2.截图3.记录时间点4.记录设备编号5.

[Bug规范] Bug标题中需包含Bug的具体位置并以[]标注 举例:[模块-子模块-页面]XXXXXXXXXXXX Bug标题尽量简明 做什么操作 + 出现什么结果,比如(点击提交按钮,出现卡顿现象) 字数一般不超过15个字 Bug标题中切勿出现错别字 错误示例: 奔溃(崩溃),电击(点击),登陆,(登录),重置(充值),现实(显示) 当所发现Bug前提条件为空时,需要填无.特殊条件下的Bug必须详细描述产生Bug的前提. 示例:只有在使用附件中的图片(大图片:60M)时,会出现此Bug. 描

Bug有效性 1.交付过程中测试者需按照专家设定好的模块,对Bug进行归类提交: 2.Bug的类型默认为UI问题.功能问题.崩溃问题,提交Bug时不能弄错: 3.需求是否明确.前提条件是否满足.输入数据是否正确.操作步骤是否清楚.Bug是否唯一性: 4.避免提交设计如此.操作错误.重复的.已知的Bug: 5.尽量少花时间在边界值.页面显示问题上,多提业务逻辑功能.交互测试方面的问题: Bug标题 Bug标题要求简明扼要的阐述问题本质,使查看人员能快速了解Bug内容.需要写明在哪个页面执行什么操作

[线上故障与线上Bug界定] 一.线上故障: 1.  故障参照公司规范稍做调整: a)         1级故障:资讯首页或主App首页无法打开:多条业务线同时不可用:超过15分钟: b)         2级故障:任意业务线主页面无法打开,主要功能无法使用:超过15分钟. c)         3级故障:单个CDN节点故障:影响任意业务线关键功能使用的高概率闪退性Bug:超过15分钟. d)         4级故障:内部支持系统无法使用,超过60分钟. 2.  故障通报范围: a)     

一个程序员在没有成长成为架构师之前,几乎都要跟 Bug为伴,程序员有很多时间都是花在了查找各种 Bug上. 我印象深刻的一个Bug, 是一个服务器网络框架无锁队列的 Bug .那个 Bug 连续查找了五天的时间,才最后定位出来. 当时我们的分布式存储系统出现了性能瓶颈,定位后发现瓶颈是在服务器网络框架上,所以我们决定为此替换一个最新研发的网络框架.这个新的网络框架为了追求高的性能,采用了无锁队列的设计. 第一天编码测试完成后.测试环境跑,完全正常,特地搞了一堆 log 来重放请求,程序跑得特别欢

bug定义 狭义:软件程序的漏洞或缺陷 广义:测试工程师或用户所发现和提出的软件可改进的细节(增强型.建议性)或需求文档存在差异的功能实现 职责:发现bug,提给开发,让其修改 bug类型--了解 代码(功能)错误---最常见--优先级偏高 界面优化--UI测试--优先级偏低 设计缺陷--优化建议:需求就不合理--优先级偏低 bug的等级--优先级 致命错误--blocker 常规操作引起的系统崩溃.死机.死循环.闪退 造成数据泄露的安全性问题,比如恶意攻击造成的账户私密信息泄露 涉及金钱计算-

前言:工作三年了,工作内容主要是嵌入式软件开发和维护,用的语言是C,毕业后先在一家工业自动化控制公司工作两年半,目前在一家医疗仪器公司担任嵌入式软件开发工作.软件开发中,难免不产生bug:产品交付客户使用后,难免不产生问题,那么关于bug分析和异常处理则是软件开发和维护中无法躲避的工作内容.工作至今,我一直在思考关于bug分析和异常处理,有没有一些原则性.规律性的东西可循,以减少bug,提高bug分析的效率,对于一些异常,基于什么原则进行处理,才能达到客户的要求.这些问题每个行业.每个职位上的人

bug已经成为程序员工作中的一部分,作为从事嵌入式软件开发已有三年的我,经手的bug也不少了.先说说自己对于bug的心态变化吧,刚开始工作的时候,自己还是很喜欢bug的.那时,自己是负责维护别人的代码,如果发现了bug,说明自己工作有成绩:后来,自己开始码代码,这个时候测试人员告诉我有bug,自己就有些心烦,尤其是当领导知道了这个bug以后,就会感到很大压力:再后来,经手的bug变多了,也变得淡定多了,而且还逐渐建立自己分析bug的工具箱和分析流程:现在,经过几年的工作,积累了一些经验,开始在设

开发背景: 公司目前使用Teambition里面的task作为bug管理系统,既没有bug的当前状态,也不能写上bug的详细复现步骤,被assign了任务(该修复bug或者验证bug是否被修复)也没有邮件通知 也不能查看自己名下当前有多少bug待修复,分别属于哪些项目. 收获: 1. 前台jsp: 1.1. <a href="mailto:邮箱地址"> 安装了outlook后点击此链接会打开一个新建邮件界面 1.2. <meta http-equiv="re

一.引子 RT,本篇博客记录的是马三的一次解决 LuaFunction has been disposed 的bug的全过程,事情还要从马三的自研框架 ColaFrameWork 说起.最近,马三在业余时间维护了一款基于Unity的客户端自研框架,起名叫 ColaFrameWork ,寓意是希望写代码能像喝小可乐一样享受和轻松.为了在Lua层可以监听到UI事件,马三制作了UGUIEventListener.UGUIDragEventListenner和UGUIMsgHandler等这样几个UI组

Bug级别:(由高到低) 1.critical:系统直接崩溃,瘫痪.无法正常打开使用产品 2.Block:逻辑出现严重问题,流程卡住,无法进行下一步 3.Major:部分功能出现闪退,功能没有实现,但不影响使用,功能菜单缺失 4.Normal:产品可以满足业务要求,部分小限制不符合验收标准,内容显示错误 5.Minor:界面等UI问题显示错误 Bug状态: 1.待处理(new):测试人员或用户发现新问题后提交的状态 2.已确认(open):经测试人员及研发人员讨论后确认是bug,提交的状态,由测

摘要: 除了吃瓜,还是得吸取教训啊同学们! 这次,我从纯技术角度分析腾讯云与前沿数控的磁盘数据丢失事件,不站队. 硬盘门 这里说的硬盘门不是10年前陈老师的那一次,而聊的是最近"腾讯云"用户"前沿数控"的磁盘数据丢失. 关于这次事件,腾讯云是这样说的: 近日,腾讯云用户北京清博数控科技有限公司所属"前沿数控"平台一块操作系统云盘,因受所在物理硬盘固件版本bug导致的静默错误(写入数据和读取出来的不一致)影响,文件系统元数据损坏. 腾讯云多少有点打