0


软件测试中对Bug的详解

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的产生,且有利于我们日后进入公司后对流程的把控与熟悉。


本文转载自: https://blog.csdn.net/yss233333/article/details/130044681
版权归原作者 yss233333 所有, 如有侵权,请联系我们删除。

“软件测试中对Bug的详解”的评论:

还没有评论