软件测试中对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的生命周期，我们可以通过画图的形式来进行表示：

 

---

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

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

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

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

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

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

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

6. 总结

Bug作为测试人员测试过程中经常遇到且需要进行处理的问题，对Bug进行了解，有助于提高测试人员的测试质量，并减少Bug的产生，且有利于我们日后进入公司后对流程的把控与熟悉。