虫(Bug)的分类,处理bug流程

  由于是突然想到要记录点什么,所以今天看到什么就写什么,希望对自己和一起加油的伙伴一点帮助。

  笔者还在学习阶段,所以这些东西都是摘自其它大神或者看了之后自己总结,不当之处还请见谅。

  看了一个前辈的文章将测试人员定义为虫师真是太合理也太有趣了故作虫师修炼手册

  bug常见的分类:

  calss A:

  代码错误

  设计缺陷

  界面优化

  配置相关

  安装部署

  性能问题

  标准规范

  class B:

  功能类(function)

  性能类

  UI(界面)

  兼容性

  缺陷等级:

  致命:导致系统无法运行,数据安全性泄漏

  严重:易于纠正的异常情况,易于修复的故障,难以接受的外观缺陷

  一般:不影响正常运行,对外观,下道工序有较大影响

  轻微:对产品外观和下道工序有轻微的影响

  建议:增加用户体验好感度的或者其他建设性意见

  随着越来多问题的出现,需要处理的问题越来越多,就需要知道处理问题的优先级:

  优先级划分:

  低——》中——》高——》紧急

  延迟处理——》正常排队——》优先处理——》紧急处理

  bug缺陷等级高不一定优先,低不一定不优先。

  处理流程:

  提交bug——》确认bug——》分配或转交bug——》处理bug——》回归测试(验证)——》关闭bug

  

时间: 2024-11-03 03:40:06

虫(Bug)的分类,处理bug流程的相关文章

Bug的分类和管理流程

1.按照严重程度划分 定义:是指Bug对软件质量的破坏程度,即BUG的存在将对软件的功能和性能产生怎样的影响 分类:系统崩溃.严重.一般.次要.建议 2.按优先级划分 定义:表示处理和修正软件缺陷的现后顺序的指标 分类:高(high).中(middle).低(low) 注意:一般情况下,严重程度高的软件缺陷具有较高的优先级 特殊情况下,此条件不成立 (1)严重程度告优先级不一定高 a.如过某严重的缺陷只是在非常极端的条件下产生,则没有必要马上解决 b.如修改一个软件缺陷,需要重新修改软件的整体结

【防火墙】防火墙分类,过滤流程

一.防火墙干嘛的 防攻击.优化路由表.优化网卡收发包.过滤策略 二.防火墙分类 四层:网络层防火墙,更快速 ->  包过滤型防火墙 七层:代理层网关防火墙,更安全,效率更低 ->  服务型防火墙 市面产品两者结合 四.防火墙工作流程 4. 1 包过滤防火墙工作原理 4.2 服务型防火墙工作原理 应用层上实现防火墙功能的.它能提供部分与传输有关的状态,能完全提供与应用相关的状态和部分传输的信息,它还能处理和管理信息. 以下为输入输出在服务器中数据传输过程 以下为iptables 表.链.规则关系

Java项目BUG记录(找BUG笔记)

原创作品,可以转载,但是请标注出处地址:http://www.cnblogs.com/V1haoge/p/6549150.html 1.针对那种有时会发生的错误,可能情况就是一个判断,某个分支有错误,当进入这个分支时就会报错,走另一条路就不会报错,这也就体现了时有发生的现象. 2.(持续补充中...)

产品经理【术语】更新ing

网络上关于产品术语的总结比较多,我主要从「部门对接工作」视角来归类.以一款产品开发迭代为例(下图),产品经理需要对接运营.设计.开发.测试等部门,类似信息中转站,那么对各部门的语言规范有所了解,会帮助我们更精准的传递信息,提高团队协作效率. 图片来源:ProcessOn官网    https://www.processon.com/view/5c1bb2f3e4b0d9d105a9970e 备注1:需求管理 1.工具可视化,可看历史变更,变更时间,变更人,版本号 2.主要人员共享 3.需求管理人

bug的处理流程

又属于一篇普及文,希望自己在被各种技术吸引的同时,能时常来整理和总结软件测试最基本的知识. 从刚工作时接触的第一个缺陷管理工具禅道,到redmine.JIRA.bugzilla ,再到现在的QC,当然还有其它种的开源的或商业的缺陷管理工具,它们的本质是一样的,就是来管理缺陷的生命周期. 其实,你理解任意的一款工具,其它的工具也一定能无师自通.这不谈某款工具,单把它本质的一些东西抽离出来与大家分享. Bug的属性 Bug重现环境 这个应该是我们重现bug的一个前提,如果没有这个前提,我们可能会无法

Bug跟踪的流程

本文以翼发云协同项目管理系统为例子来讲解Bug跟踪的流程,它以工作流为中心的集成式Bug跟踪软件,它广泛地应用于研发行业的产品缺陷管理 与跟踪.事务跟踪.问题跟踪.任务跟踪.查询跟踪.需求管理.变更跟踪.企业帮助台和客户服务台等诸多范畴. 该系统提供了一个可靠的中央数据库集中管理多渠道提交至系统的信息,然后由系统按事先定义的条件和流程, 自动分配任务给相关的负责人员.公司员工与部门.部门与 部门.公司与客户之间能在任何时间.任何地点通过简便易行的方式进行 协作和信息交流,并且使任何记录都有据可查

程序的bug排查流程总结

只要是人写的程序,不可能没有bug,那么解决bug,将伴随程序员的一生: ? 只会写代码,但不会排查bug的程序员,只能算是业余程序员 ? 能解决一般bug的,只能算是初级程序员 ? 代码写的质量较好,还能查找较难bug的,中级程序员 ? 代码写的质量好,注重性能,不但能排查疑难bug的,还能解决疑难bug的,高级程序员 ? 代码写的质量好,注重性能,稳定性,可靠性,架构设计合理,能解决绝大部分疑难问题,属于资深程序员 以上的话引自某个论坛网站,不一定说的绝对正确,但基本是有道理的. 面对出现的

BUG处理流程说明

一.        BUG处理流程图: 流程描述: 1.  测试人员发现bug提交给开发. 2.  开发人员判断是否是bug. 3.  如果是bug,进行修改,修改完成后更改bug状态为已解决. 4.  如果不是bug,退回给测试人员并描述退回原因,或为设计如此,或为外部原因,或者不能重现. 5.  开发人员修改完成的bug,由测试人员进行验证,确认修改正确,关闭bug. 6.  验证未通过的bug重新激活,开发人员继续修改,直至验证通过,关闭bug. 7.  测试人员需要对开发人员退回的bug

如何用Bugzilla系统管理产品研发过中相关需求和bug

目 录 1.Bug处理流程及状态说明 2.bugs字段说明 3.查询报表的使用 4.bug系统与需求系统的整合 5.流程和用户权限 1. Bug处理流程及状态说明(1) BUG状态流程图 BUG的状态说明 bug的处理状态说明 BUG的状态和处理状态图表说明 2.bugs字段说明(1) 3.查询报表的使用(1) 4.bug系统与需求系统的整合(1) 以前我们的需求,是放在另一个单独Bugzilla系统上.在新系统上,需求和bug 进行了整合. 需求作为一个bug,提交到Bugzilla上.并通过