2.4Bug的分类与严重程度

Orlando_奥尔兰多

已于 2022-02-07 11:17:44 修改

阅读量3.7k

点赞数 2

分类专栏：软件测试-功能测试文章标签：软件测试测试用例功能测试 Bug缺陷

于 2022-02-07 10:35:38 首次发布

本文链接：https://blog.csdn.net/qq_41612292/article/details/122805102

版权

软件测试-功能测试专栏收录该内容

5 篇文章 0 订阅

订阅专栏

Bug的分类与严重程度

bug分类（禅道为例）

1）功能缺陷：业务流程未实现
2）代码错误：错误页面404、500
3）界面优化：UI问题、图文显示
4）安装部署：安装失败、无法访问等
5）性能问题：响应时间久、加载慢
6）安全相关：密码明文显示
7）其他：易用性、兼容性
8）设计缺陷：需求缺陷

bug严重程度

1)致命的（最高）：系统崩溃、死机、死循环、数据库数据丢失、数据库连接失败、主要功能丧失、重要的一级菜单不可用
2)严重的（高）：主要功能部分丧失，数据库保存、提交调用错误、功能设计与需求严重不符、自动退出，稳定性差、数值计算统计错误
3)一般的（中）：功能没有完全实现存在缺陷但不影响系统稳定性（查询时间长、格式错误、边界值错误、删除没有确认、数据表字段过多——一般12个左右）
4)轻微的（低）：兼容性、界面优化，不影响正常功能使用，错别字、页面显示重叠、提示语丢失
5)建议性（很低）

bug优先级（开发修改问题的顺序）——开发选择

1）非常紧急
2）紧急
3）一般
4）不重要

面试题：严重程度越高优先级就越高吗？

不一定，严重程度高的优先级可能会相对紧急一些。
例如：12306的登录页面吧录字写成了大陆的录，使用用户很多，直接影响到了使用感受，这就是一个紧急而不严重的问题。

bug状态

1、待确认（提交–激活）：测试人员或用户发现新问题后提交的状态
2、已确认：经测试开发讨论确认是bug,提交的状态，由开发人员点确认按钮
3、已处理（已解决）：开发确认是bug后修复的状态，修改还没验证，由开发人员来设置状态
4、已修改（已关闭）：bug的最终状态，测试通过，由测试人员来设置
5、仍存在（重新打开）：测试未通过，bug未修复成功，问题仍然存在，由测试人员设置
6、不是bug：研发认定不是bug/建议或者意见决定不采纳，开发人员来设置
7、暂不处理（挂起）：当前版本不做修改，后续版本再考虑，或不确定是不是要解决需要时间来确定，由测试或者开发来设置

bug跟踪流程：

**测试人员发现问题之后有2种情况**：
一种是不确定时找领导确认，如果领导确认这是个问题那么就创建问题，如果大家一致认为不是一个问题就放弃掉；
另一种是测试人员确定这是个问题就直接创建问题；

创建问题之后提交给开发，开发判断拿到这个问题之后判断是不是问题，如果不是直接放弃，如果是进行修复，修复解决完问题之后，测试人员来验证问题；

验证通过之后问题直接关闭，如果验证不通过仍然存在问题时重新开启，再次提交给开发，开发再次进行处理，解决问题之后我们再次验证直至验证通过问题关闭。

bug详细描述

【所属项目】关联的项目名称
【影响版本】问题出现的版本
【当前指派】处理人
【截止时间】处理的截止时间
【bug类型】bug分类
【操作系统】测试使用的什么系统
【浏览器】测试使用的浏览器
【bug标题】描述问题，简明扼要
【重现步骤】使用1、2、3的形式进行说明
【结果】操作后出现的问题描述
【预期】操作后出现的正确现象

提bug的目的

1、记录对应的问题，避免因为没有对应的记录过程而导致开发漏修复和测试人员漏测
2、阐述对应的操作步骤
3、整个问题从提出到修改，到解决形成一个闭环，毕竟bug的过程有可能会有不同的流程走向

创建高质量的bug

1)标题：简明扼要的描述bug,可以让人快速了解问题
2)测试环境：发现问题的软件/硬件系统，什么版本，如果需要还要注明哪个硬件平台
3)前提条件：用户测试步骤前的系统环境信息
4)提交步骤：在执行什么的操作时，发现的问题
5)实际结果：在测试软件的过程中，软件本身表现出的结果，可能与预期结果有出入
6)预期结果：软件设计所要求达到的需求本身达到的目的，预期目标
7)附件：图片说明

与开发沟通

1)确保自己提交的是个bug，并且可以重现
2)如果开发有疑问，或者说没有bug的时候，我们可以从用户的角度去解释使用系统时的，用户这样操作的不便
3)bug需要写清楚，或者描述清楚，开发人员在了解问题后，可以准确的定位
4)跟开发人员确定清楚、修改这块后，主要影响那里，会对其他的模块有影响没，有的话，我们需要重新关注
5)注意语言和沟通的用词
提单是基于需求的粒度去提单