软件测试/测试开发/全日制|关于bug,你需要了解的,全在这里了

在这里插入图片描述

简介

作为软件测试,bug是我们的老朋友了,我们的工作就是找到并且协助解决它,因此定义bug,发现bug,提交bug等就需要我们按照一套标准来建立一个标准化的流程,本文就给大家介绍一下对于测试,应该了解的关于bug的处理。

Bug

Bug的定义

bug就是一个电脑程序里的错误,而现在更是将其诞生为漏洞,或者一个程序不完善的地方。

Bug的分类

通常我们会以bug的严重程度来对bug进行分类,这样我们就能清楚地知道应该先处理哪些bug,bug主要有以下分类:

  1. 致命(一级bug):修改优 先级为最高,该级别问题需要立即修改。

致命bug:不能完全满足系统要求,系统停止运行,系统的重要部件无法运行,系统崩溃或者挂起等导致系统不能正常运行。

通常表现为:

  • 系统崩溃;
  • 导致程序重启,死机或非法退出;
  • 死循环;
  • 数据丢失或异常;
  • 数据通讯错误;
  • 硬件故障,系统悬挂。

比如:1.内存泄漏;2.严重的数值计算错误;3.系统容易崩溃;4.功能设计与需求严重不符;5.系统无法登录;6.循环报错,无法正常退出…

  1. 严重(二级bug):修改优先级为高,该级别需要程序员尽快修改。

严重bug:严重地影响系统要求或基本功能的实现,且没有更正办法(重新安装或重新启动该软件不属于更正办法)。使系统不稳定、或破坏数据、或产生错误结果,或部分功能无法执行,而且是常规操作中经常发生或非常规操作中不可避免的主要问题,系统无法满足主要的业务要求,性能、功能或可用性严重降低。

通常表现为:

  • 功能不符合用户需求 ;
  • 数据计算错误 ;
  • 业务流程错误 ;
  • 程序接口错误;
  • 因错误操作迫使程序中断;
  • 系统可被执行,但操作功能无法执行(含指令);
  • 功能项的某些项目(选项)使用无效(对系统非致命的);
  • 功能实现不完整,如删除时没有考虑数据关联;
  • 功能的实现不正确,如在系统实现的界面上,一些可接受输入的控件点击后无作用,对数据库的操作不能正确实现。

比如:1.功能未实现;2.功能存在报错;3.数值轻微的计算错误…

  1. 一般(三级bug):修改优先级为中,该级别需要程序员修改。

一般bug:系统可以满足业务要求,系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。

通常表现为:

  • 数据长度不一致;
  • 内容或格式错误 ;
  • 响应时间较慢 ;
  • 功能性建议 ;
  • 提示信息不太准确 ;
  • 操作界面错误(包括数据窗口内列名定义、含义是否一致);
  • 简单的输入限制未放在前台进行控制;
  • 虽然正确性不受影响,但系统性能和响应时间受到影响;
  • 不能定位焦点或定位有误,影响功能实现;
  • 增删改功能,在本界面不能实现,但在另一界面可以补充实现。

比如:1.边界条件下错误;2.容错性不好;3.大数据下容易无响应;4.大数据操作时,没有提供进度条…

Bug生命周期

在这里插入图片描述

对于一个问题,其处理过程是一个周期,周期的不同阶段,其所处的状态也是不一样的。不同状态所对应的处理人也是不一样的。

  • 提交(打开) : 表示问题被提交等待有人处理。首先尽量描述这个缺陷的属性,Bug重现环境,bug类型,bug等级,bug的优先级以及详细的重现步骤,结果与期望等。当然,我们在提交一个问题之前首先应该保证,这个缺陷是没有被提过的,以免造成重复缺陷单。如果是回归不通过的缺陷,其状态又会变为打开状态。

  • 指派(转交) : 问题被重新指派给某人处理。这一步不是必须的,跟项目模式有关,有些公司测试部门与开发部门独立,那么测试人员就不确定自己测试的模块是由哪位开发人员负责的,在这种情况下,测试人员统一把问题指派给项目组长或经理,由项目组长(或经理)对问题进行确认后再次分配给相应的开发人员。有些测试人员是穿插到不同研发团队中的,所以对不同的开人发员负责的开发模块非常清楚,这个时候就可以将问题直接指派给相应的开发人员。

  • 处理 : 问题在处理中,尚未完成。当开发人员接到一个缺陷时,首先是对其进行分析与重现,如果对其进行分析发现不是缺陷(可能由于测试人员不了解需求)或无法对此问题进行重现,那么就需要将此问题反回给测试人员,并注明原因。如果确认为缺陷则需要对其进行处理。在处理问题之后,还需要进行一次判断,是否需要推迟处理,有些需求已经确认了是问题,由于其可能在极端情况下才会出现,或需要对系统架构进行改动,或其优先级非常低,所以暂时不需要对此问题进行处理(或到下个版本进再进行修复)。

  • 固定 : 确认此问题存在,但暂时不进行处理。对于推迟处理的问题可以暂时进行固定(“固定”为QC中的叫法。)一般固定的问题需要经过项目经理与测试经理协商后才能固定。

  • 回归 : 对已经修复的问题进行回归确认。回归缺陷对于测试人员来说是非常重要的工作,其有三个入口两个出口。

确认非缺陷问题:对于提交的一个缺陷,开人员处理为非问题或无法重现,然后直接转交给测试人员回归。测试人员再次确认,如果真如开发人员所说,则将问题关闭。如果非开发人员所说,是由于问题描述模糊或其它原因喂重现问题,则再次注明原因转给开发人员。

确认修复问题:对开发人员修复的问题再次进行确认,确认能过,则关闭问题。确认不通过,将问题再次打开并转给开发人员。

确认固定问题:有计划的对固定问题进行确认,有些固定问题随着时间的推移,版本的更新或已经不存在了,对这类问题应该及时关闭。有些固定问题依然存在且变得紧急,对于这类问题应该及时打开交给开发人员处理。
  • 关闭 : 问题的最后一个状态。对于已经修复的缺陷进行关闭,这也是一个缺陷的最后一个状态。

Bug 单的要素

我们在提交bug的时候,需要附上bug单,bug单需要包括以下要素:

一个bug单包含的要素如下:

  • 所属的系统(产品)

  • 发现的版本(轮次)

  • 发现bug所属的模块

  • bug提交人

  • bug的错误类型:代码错误、界面优化、设计缺陷、配置相关、安装部署、安全相关、性能问题等(默认)

  • bug的重现概率: 必现 大概率重现 小概率重现 极小概率重现

  • bug的严重级别:致命 严重 一般 提示 (影响范围越大,严重级别越高)

  • bug的优先级:高 中 低

  • bug的标题 言简意赅说明是什么bug, 而不是把测试用例名字复制一遍

  • bug单号 一般系统自动生成

  • bug内容:发现的环境、 预制条件、重现步骤、预期结果、实际结果, 截图证明,bug错误说明,(当开发看到能容能够独立重现这个bug,说明写的还行)

  • 附件:测试用的数据或者出错的日志, 如果需要添加上日志

总结

Bug 是软件开发和测试过程中常见的问题,了解其定义、判定标准、严重程度和优先级有助于及时发现、记录和修复缺陷。在软件开发中,有效管理和处理Bug是确保软件质量和用户满意度的重要步骤。希望本文能够帮到大家!希望本文能够帮到大家!

获取更多技术资料,请点击!

推荐

Python全栈开发与自动化测试开发班
由浅入深实战进阶,从小白到高手

以Python全栈开发为基础,深入教授自动化测试技能,为学员打造全面的技术能力。通过系统学习和实际项目实战,学员将具备在职场中脱颖而出的竞争力。不仅能够灵活运用Python进行开发,还能够保障项目质量通过自动化测试手段。这是一个全面提升职业竞争力的机会。

课程详情
Python开发必备基础技能与项目实战
Pvthon 编程语言/算法和数据结构/面向对象编程Web后端开发/前端开发/测试管理平台项目实战

人工智能ChatGPT实战
人工智能辅助学习各种开发和测试技能/Pytorch深度学框架/平台开发实战

数据分析与自动化办公
数据采集/Pandas与数据处理技术/ECharts与数据可视化技术/爬虫实战/自动化办公/批量文件处理

UI自动化测试与高级项目实战
Web自动化测试/App自动化测试/ PageObject设计模式

接口自动化测试
接口协议分析/Mock实战/服务端接口测试

性能测试
性能测试流程与方法/JMeter 脚本参数化/Grafana监控系统搭建

简历指导与模拟面试
1V1简历指导/模拟真实面试/测试开发岗面试全攻略名企私教服务
名企专家1v1辅导/行业专家技术指导/针对性解决工作难题/绩效提升辅导与晋升复盘

课程亮点
名企私教服务 先学习后付费 高额奖学金
专属社群+晚自习在线答疑
5V1全方位辅导作业+考试强化学习效果
简历修改 模拟面试 就业内推 面试复盘

  • 20
    点赞
  • 18
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值