软件测试中对Bug的详解

这篇具有很好参考价值的文章主要介绍了软件测试中对Bug的详解。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

1. 什么是Bug

2. Bug的要素

3. Bug的级别

4. Bug的生命周期

5. 在Bug上与开发产生争执怎么办

6. 总结

1. 什么是Bug

Bug是指在软件开发或使用过程中发现的软件缺陷或错误，也称为故障或缺陷。通常表现为软件的不正常行为或功能无法正常使用，会对软件的质量和用户体验产生负面影响。

比如说一些规格说明书中存在的功能，但是并没有实现相应的功能，这也算bug；或者说规格说明书中没有提到，但是某项功能影响了用户的正常使用，那么这也算bug

2. Bug的要素

Bug的要素通常为：

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

即我们在什么环境下，通过什么步骤，引发出了什么意料之外的结果，即可正确的描述出一个bug

3. Bug的级别

对于Bug而言，其也存在不同的Bug级别

当我们区分出不同的Bug级别时，其的惩罚机制也是不同的

同时区分出不同的Bug等级，也可以看出一个开发人员的开发质量相挂钩

对于Bug的级别，其实每个公司的定义都是不一致的，因此我们具体定义Bug级别的时候要查阅好公司的规范

但是我们对于Bug级别的定义，往往可以定义成以下几个级别：

Blocker(崩溃)：阻塞开发或测试工作的问题，如造成系统崩溃、死机、死循环、导致数据库数据丢失

Critical(严重)：系统重要功能部分丧失，数据库保存调用错误，用户数据丢失

Major(一般)：功能没有完全实现但不影响使用，如操作时间长，查询时间长等

Minor(次要)：界面、性能缺陷，建议类问题，可以优化的方案等

通过定义Bug级别，可以帮助开发团队在处理Bug时更加有针对性，将更多的精力投入到处理高级别Bug上，以确保软件的稳定性和可靠性。同时，Bug级别也是衡量软件质量的重要指标之一，可以帮助产品经理和其他相关人员评估软件的稳定性和可用性，从而做出更好的决策。

4. Bug的生命周期

与其他类似，Bug也存在Bug的生命周期，即从最开始创建到最后消失的过程

我们往往可以将Bug的生命周期阶段定义为以下几个：

New: 新发现的bug，未经评审是否指派给开发人员修改

Open：确认是Bug，并且认为需要修改，指派给开发人员

Fixed: 开发人员修复完成之后将Bug状态修改为fixed

Rejected: 并不是bug

Delay: 确认是bug，bug优先级不高且开发人员无法立即修复bug

Closed:Bug确认修复完成

Reopen: Bug修复未完成，修改为reopen

对于一个新发现的bug，我们将其状态设置为New，添加至Bug管理平台上

经过评审后，会分为两个阶段：

如果该Bug并不是Bug，我们将其状态设定为Rejected，同时该Bug修改为Closed状态，即Bug已经修复完毕；
如果该Bug是Bug，我们将其阶段设定为Open，将该Bug指派给开发人员，此时如果bug的优先级不高，且开发人员暂时无法进行bug的修复，此时bug的状态会被设置为Delay，再过一段时间后再进行修复
如果该Bug并没有被设置为Delay，则会由开发人员修复后设置为Fixed状态，然后由测试人员再次进行测试，如果Bug修复未完成，则设置为Reopen状态，重新由开发人员进行修改；
如果Bug修复完成，则设置为Closed状态，Bug确认修复完毕

对于以上Bug的生命周期，我们可以通过画图的形式来进行表示：

软件从bug,bug,单元测试,测试工具

5. 在Bug上与开发产生争执怎么办

在Bug上与开发产生争执是测试面试中的高频面试题，这个面试题其解决方式如下：

先反思自己bug创建的时候描述的不太清楚

开发人员对bug级别不认可，bug级别一定有理有据(企业的bug定义规范)

开发人员觉得bug是小问题，不想解决，我们站在用户的角度，合理友好的进行沟通

测试人员不光要提出问题，最好能够提出解决方案，减少开发人员负担

确实是bug，但是友好沟通无法解决问题，就发起bug评审