当前位置：首页 > news >正文

SoftwareTest3 - 要了人命的Bug

news 2026/1/14 9:19:40

软件测试基础篇

一 . 如何合理的创建一个 Bug
二 . Bug 等级
- 2.1 崩溃
- 2.2 严重
- 2.3 一般
- 2.4 次要
三 . Bug 的生命周期
四 . 跟开发产生争执应该怎么解决

Hello , 大家好 , 又给大家带来新的专栏喽 ~
这个专栏是专门为零基础小白从 0 到 1 了解软件测试基础理论设计的 , 虽然还不足以让你成为软件测试行业的佼佼者 , 但是可以让你了解一下软件测试行业的相关知识 , 具有一定的竞争实力 .
那也欢迎大家订阅此专栏 : https://blog.csdn.net/m0_53117341/category_12427509.html
希望大家都能够拿到好的 Offer

本篇文章重点 :

如何合理的认识 Bug
Bug 级别
Bug 的生命周期
跟开发产生冲突怎么办

一 . 如何合理的创建一个 Bug

创建 Bug 的目标就是为了能够让其他人可以尝试复现
创建 Bug 的要素 :

问题的版本
发现问题的环境
发现问题的步骤
预期结果
实际结果
Bug 等级
Bug 类型
等等

假如存在这样的一个场景 : 下拉框选项有 100 个 , 用户找到想要的标签非常困难 , 针对这样的 Bug , 我们怎么创建

问题的版本 : 谷歌浏览器 94.0.4606.61（正式版本）（64 位）即以后
发现问题的环境 : Windows10家庭版
发现问题的步骤 : 省略…
预期结果 : 用户可以通过输入框快速定位到想要的标签
实际结果 : 没有可用的输入框 , 用户只能一个一个查找 , 对于用户来说体验感不好
Bug 等级 : 优化建议
Bug 类型 : 需求问题

二 . Bug 等级

一般分为四个等级：崩溃、严重、一般、次要
举个例子：
次要：男朋友多看了一眼别的女孩子
一般：男朋友加了别的女孩子
严重：男朋友私下跟别的女孩子吃饭
崩溃：男朋友脚踏两只船

2.1 崩溃

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）

2.2 严重

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）

2.3 一般

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）

2.4 次要

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

那么为什么要提 Bug 等级呢 ?

Bug 的等级跟优先级有关 : 崩溃以及严重的 Bug 一定要优先解决
出现线上问题需要进行问题定级 : 定级会涉及到对应的惩罚范围

线上问题复盘会议 (批斗大会)
能避免就要避免 !!!

三 . Bug 的生命周期

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

举个栗子 , 来帮助大家记住这七种状态

那么通过这个例子 , 我们要得到 Bug 真正的生命周期是怎样的

四 . 跟开发产生争执应该怎么解决

先检查自身 , 是否 Bug 描述不清楚 , 是否确实提出了一个错误的 Bug
站在用户的角度去考虑问题 , 可以反问 : 如果你是用户 , 你可以接受这种实现吗 ?
Bug 定级要有理有据

Bug 等级其实也是跟程序员水平有关的 , Bug 等级越严重 , 说明程序员在实现的产品问题比较严重 , 就有可能上升到态度问题、水平问题

不光要提出 Bug , 最好也要能提出解决方案

要注意 : 工作中不能喧宾夺主 , 你不能命令人家怎样做怎样处理 , 只需要给开发人员提建议即可

组织 Bug 评审 ( 终极大招 : 工作中并不常用 , 实在没招了才能去召开 )
1. 邀请代表参加 : 产品经理代表、开发人员代表、测试人员代表等
2. Bug 评审会议里要解决以下问题 :
  1. 如何修改 Bug
  2. 如何避免类似的问题再发生
3. 一般来说不会造成不愉快，秘诀就是：对事不对人