【测试篇】关于令人讨厌的BUG,你了解多少?

前言

🌟🌟本期讲解关于测试的BUG相关知识介绍~~~

🌈感兴趣的小伙伴看一看小编主页:GGBondlctrl-CSDN博客

🔥 你的点赞就是小编不断更新的最大动力                                       

🎆那么废话不多说直接开整吧~~

 

目录

📚️1.软件测试的生命周期

📚️2.BUG的故事

🚀2.1BUG的概念

🚀2.2BUG的描述

🚀2.3BUG的级别

🚀2.4BUG的生命周期

🚀2.5与开发认知不同咋办

📚️3.总结

 

📚️1.软件测试的生命周期

这里我们要注意软件测试的生命周期:

软件测试贯穿于软件的整个⽣命周期

如下所示:

需求分析——测试计划——测试设计,开发——测试执行——测试评估——上线——运行维护 

需求分析:用户需求是否合理,经过需求分析后得到软件需求,是开发测试的参考标准;

测试计划:制定测试计划,什么时候开始,什么时候结束;

测试设计,开发:测试人员参考文档 ,编写测试用例,撰写测试文档,明确使用的测试方法与工具;

测试执行:顾名思义,就是执行测试;

测试评估:判断是否在开发阶段遗漏的BUG;

上线:测试完成后,发布到线上环境,测试人员要进行跟踪,判断线上环境运行是否正确

运行维护:测试⼈员需要继续参与项⽬的实施⼯作,如参加用户使用培训工作,发现问题并反馈;

注意:线上环境与线下环境的区别是很大的,不能直接认为线下没有问题,线上就没有问题;

📚️2.BUG的故事

🚀2.1BUG的概念

当然在我们现阶段在写代码过程中,出现的爆红或者错误日志出现的具体代码,我们统一认为这个就是我们认知的BUG;

但是在测试工作中所谓的BUG是肯定有一定的依据的,所以什么是BUG?

~~当前仅当需求文档(软件需求)是存在并且是正确的,程序与需求文档之间的要求不匹配

~~在没有需求文档(软件需求)的情况下,没有实现其最终用户合理预期的功能要求,就是      错误

🚀2.2BUG的描述

在bug的描述中,不可以笼统的描述,某某有一个BUG,那么假如是CSDN,那么直接说CSDN在登录有一个BUG;那么这就太笼统了,不能达到快速定位的效果;

所以在BUG的描述中,我们要定义描述BUG的要素:

问题出现的版本——环境——步骤——预期结果——实际结果

目的:快速定位,降低工作成本,提高工作质量

那么上述的BUG我们就可以描述为:

在CSDN某个版本,然后浏览器版本,环境是(Windows,Mac....),然后步骤就是:打开edge浏览器,输入CSDN网址,找到登录窗口,输入正确密码,账号;预期结果是登录成功,进入首页;实际结果就是登录失败,弹出消息登录失败框;

🚀2.3BUG的级别

首先评选BUG的级别,为了评估程序员的开发能力,以及作为年终奖评估标准,给修复的BUG进行顺序排序,BUG级别越高的优先修复;

bug级别⼀般分为:崩溃、严重、⼀般、次要

崩溃:阻碍开发或测试工作,造成系统坏死,死循环,主要功能不能运行;

严重:主要功能部分丧失,数据库保存调⽤错误、⽤⼾数据丢失;

一般:功能没有完全实现,但是不影响使用;

次要:界面,性能缺陷,建议性问题;

🚀2.4BUG的生命周期

大致流程如下:

可能不大好看,但是大致流程就是如上所示;

解释:就是发现BUG后,如果开发人员与测试协商后,不认可,那么直接拒绝,反之进行修复,这里先修复BUG级别高的,BUG级别低的就暂时不修复,然后修复后,再次提交测试人员进行测试,通过就直接close掉,反之打回继续进行修复;

● New:新发现的Bug,未经评审决定是否指派给开发⼈员进⾏修改。
● Open:确认是Bug,并且认为需要进⾏修改,指派给相应的开发⼈员。
● Fixed:开发⼈员进⾏修改后标识成修改状态,有待测试⼈员的回归测试验证。
● Rejected:如果认为不是Bug,则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改,则延后修改。
● Closed:修改状态的Bug经测试⼈员的回归测斌验证通过,则关闭Bug。
● Reopen:如果经验证Bug仍然存在,则需要重新打开Bug,开发⼈员重新修改。

🚀2.5与开发认知不同咋办

我们上述的描述中,发现在拒绝中,要与开发人员协商,那么这里的协商假如我们认为这就是一个BUG,对方认为这是一个BUG吗?咋办呢?

1、反省自己:是不是在测试的时候出现了误操作,导致BUG描述不足,或者根本没有BUG;

2、站在用户角度:功能正常只是测试的一部分,当然我们要站在用户的角度,进行反问“你是用户,那么你会接受吗?”

3、BUG定级有依据:bug定级描述拿出来,将BUG表现与文档进行匹配;

4、提高自身水平:在提高自身水平,提高测试准确度,不仅要做到提出BUG问题,还要做到能够提出解决方案,提升自己的权威性;

5、最后进行BUG评审:邀请测试代表,开发代表,以及产品代表;(争执不下

测试代表:从Bug的具体表现、严重程度等⽅⾯提供信息,并提出⾃⼰对Bug的处理意⻅

开发代表:主要从修改缺陷的难度和⻛险出发,考虑缺陷修改需要付出的代价;

产品代表:主要从产品的整体计划、⽤⼾的要求等⽅⾯对缺陷的修改必要性

目的:决定如何处理BUG;以及分析缺陷产生原因,找出预防的策略;

📚️3.总结

本期小编主要讲解了关于软件测试的生命周期,以及BUG的概念,描述,级别,生命周期展开对于BUG的全面阐述;

🌅🌅🌅~~~~最后希望与诸君共勉,共同进步!!!


💪💪💪以上就是本期内容了, 感兴趣的话,就关注小编吧。

       😊😊  期待你的关注~~~

评论 52
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值