关于软件测试中的bug

软件测试的生命周期

软件测试贯穿于软件的整个⽣命周期，软件测试的⽣命周期是指测试流程，这个流程是按照⼀定顺序执⾏的⼀系列特定的步骤，去保证产品质量符合需求。

BUG

bug的概念

定义：⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障(fault)，这些bug使程序⽆法正确的运⾏。Bug产⽣于程序的源代码或者程序设计阶段的疏忽或者错误。

注：当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。

        当程序没有实现其最终⽤⼾合理预期的功能要求时，就是软件错误。

描述bug

描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果

如案例：

问题出现的版本：⾕歌浏览器版本 123.0.6312.123（正式版本） （64 位）

问题出现的环境：Windows家庭版
问题出现的步骤：
1、打开⾕歌浏览器，输⼊⽹址https://www.101eduyun.com/
2、等待⾸页页⾯渲染完成
预期结果：⼆维码与登陆模块不会出现遮挡，⼆维码可以正常扫描
实际结果：⼆维码被登陆模块遮挡，⼆维码扫描失败

bug级别

通过定义bug的级别，能够明确看出问题的严重程度。通过bug级别也能够体现出开发⼈员的开发质量。

bug级别⼀般分为：崩溃、严重、⼀般、次要

bug的生命周期

测试⼈员在执⾏测试的过程中如有发现bug，需要在对应的bug管理平台来创建bug（bug⽣命起
源），创建好的bug需要被开发⼈员修复，以及测试⼈员的持续跟踪和测试。

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

关于测试与开发产生争执了该怎么办的问题

1）要先检查自身，是否bug描述不清楚

如果测试⼈员发现在写完⼀个缺陷后，好像还有很多关于Bug的信息没有表达出来，或者很难⽤书⾯语⾔表达出来时，就应该在提交Bug后，⻢上找相关的程序员解释刚才录⼊的Bug，确保程序员明⽩Bug描述的意思，⽽不要等待开发⼈员找⾃⼰了解更多的信息。

2）站在⽤⼾⻆度考虑并抛出问题

站在⽤⼾⻆度考虑问题 应该让开发⼈员了解到Bug对⽤⼾可能造成的困扰，这样才能促使开发⼈员
更加积极地、⾼质量地修改Bug。在争执时，可以问⼀句：如果你是⽤⼾，你可以接受么？

3）BUG定级要有理有据

BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往⽤⼾的BUG级别和我们的是有区别的，需站在⽤⼾的⻆度定考虑定位级别。

4）提⾼⾃⾝技术和业务⽔平，做到不仅能提出问题，最好也能给出解决⽅案

提⾼⾃⾝的业务和技术⽔平，不但要做到能提出问题，还能够提出解决问题的思路。这样才能更让⼈信服。

5）bug评审

如果确实是bug，友好沟通不能解决问题，那么就召开bug评审。

bug评审主要解决两个问题：
1、决定如何处理bug
2、分析缺陷产⽣的原因，找出预防的对策
bug评审⾄少需要项⽬组各个⽅⾯的代表参加：
1、测试代表

测试代表主要从Bug的具体表现、严重程度等⽅⾯提供信息，并提出自己对Bug的处理意⻅。需要注意的是，测试⼈员不应该⼀味地要求对Bug进⾏修改，因为修改可能带来回归的⻛险，同时带来的是回归测试的⼯作量，如果时间⽐较紧迫，修改后剩余的时间若不足以做⼀次有效的回归测试，可能不修改是个明智的选择。

2、开发代表
开发代表主要从修改缺陷的难度和⻛险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的⻛险等，如果决定要修改，还要讨论出修改的初步⽅案。

3、产品代表
产品代表主要从产品的整体计划、⽤⼾的要求等⽅⾯对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见。

以上，关于bug，希望对你有所帮助。