文章详细介绍了Bug的不同级别，如Blocker、Critical、Major和Minor，以及Bug的生命周期，包括从新建到关闭的各个状态。同时，提到了如何有效地向开发人员报告Bug，强调了创建Bug时需提供的关键信息，以及在与开发人员产生争执时的处理建议，如采用批判性思维、提供解决方案和召开Bug评审会议。
目录
一、Bug的级别
为什么Bug也要存在级别？不同的Bug等级，惩罚机制不一样，同时也跟开发人员的开发质量有直接关系（与开发能力挂钩）；
bug的定义每个公司都不一致，在定义级别之前需要查看公司规范，以下给出一个参照~
Blocker（崩溃）：
造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错 误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁；
Critical（严重）：
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失。如：功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出；
Major（一般）：
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询 时间长、格式错误、边界条件错误，删除没有确认框；
Minor（次要）：
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格 式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置 不正确；
二、Bug的生命周期
测试人员再执行测试的过程中，若发现Bug，需要再对应的Bug管理平台来创建Bug，直到最后Bug被关闭；
具体的生命周期如下图：
解释：
new：测试人员创建了一个Bug；
open：开发人员要确认是否是Bug，是Bug状态就改为open，不是Bug就拒绝（rejected）；
fixed：开发人员在修复完成后，将Bug状态设置为fixed；
rejected：确认不是Bug的标志；
dalay：确认是Bug后，若Bug的优先级较低且开发人员不能立即修复Bug，状态改为delay；
closed；Bug确认修复完成，测试人员将Bug改成closed；
reopen：Bug确认修复未完成，测试人员将Bug状态改为reopen；
三、如何向开发人员提出Bug（如何创建Bug）?
首先要明确创建Bug的要素：问题出现的版本、问题出现的环境、出现步骤、预期结果、实际结果等；
例如下图Bug：
创建Bug如下：
标题（注意强调影响）：二维码被登录模块遮挡，导致二维码扫描失败；
问题出现的版本：谷歌浏览器版本 108.0.5359.125（正式版） （64位）；
问题出现的环境：Windows家庭版；
问题出现的步骤：1、打开谷歌浏览器，输入网址www.xxx.com；2、页面渲染完成，结果与预期不符；
预期结果：二维码与登录模块不会出现遮挡，二维码可以正常扫描；
实际结果：二维码被登录模块遮挡，二维码扫描失败；
Bug归属：前端问题；
Bug等级：严重；
四、跟开发产生争执怎么办？（面试高频）
这里回答不统一，只是给出一些建议；
1、批判性思维，多反思自己，是不是Bug创建的适合描述不清楚；
2、开发人员对Bug级别不认可、Bug定级一定要有理有据；（测试人员要明确企业Bug定级规范，拿规范与开发人员沟通）；
3、有好沟通，站在用户的角度反问：如果你是用户，你能接受这样的功能吗？
4、不仅能够发现问题，最好也能提出解决方案（供开发参考）；
5、若确实是Bug，友好沟通不能解决问题，就召开Bug评审，需要找相关代表参加：产品代表、开发代表、测试代表等；评审内容主要是：如何解决Bug？如何预防类似的Bug再发生？
扫一扫
3587
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
