【软件测试】4.Bug的级别

目录

1.软件测试的生命周期

2. BUG

2.1BUG的概念

2.2描述bug的要素

2.3bug的级别

2.4 bug的生命周期

2.5与开发起争执怎么办？

2.5.1先检查自身，是否bug描述不清楚

2.5.2站在用户角度考虑并抛出问题

2.5.3Bug定级要有理有据

2.5.4提高自身技术和业务水平，做到不仅能很好的提出问题，最好也能给出解决方案

2.5.5bug评审

2.5.5.1bug评审主要解决两个问题：

2.5.5.2bug评审至少需要各个项目组的代表参加：

---

1.软件测试的生命周期

软件测试贯穿于软件的整个生命周期，针对这句话我们一起来看一下软件测试是如何贯穿软件的整个生命周期。

软件的生命周期是指测试流程，这个流程是按照一定顺序执行的一系列特定的步骤，去保证产品质量符合需求。在软件测试生命周期流程中，每个活动都按照计划的系统的执行，=。每个阶段有不同的目标和交付产物。

各阶段的具体内容：

需求分析	测试计划	测试设计和开发	测试执行	测试评估	上线	运行维护
用户角度：软件需求是否合理 技术角度：技术上是否可行，是否还有优化空间 测试角度：是否存在业务逻辑错误、冗余、冲突等问题	指定测试计划：什么时候开发测试，什么时候结束测试测试，耗时多久	参考需求文档、技术文档等编写测试用例 写测试文档，明确标注使用到的测试方法，测试工具，测试形式等	充分利用测试用例和测试工具对项目尽可能做到全方面的测试覆盖	测试是否通过，本次测试是否有遗留的BUG，最终测试人员需要产出一个测试报告	项目测试结束后，将项目发布到线上环境，测试人员需求跟踪上线并测试先生环境下软件的运行是否正确	测试人员需要根据项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达的能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人

2. BUG

2.1BUG的概念

定义：一个计算机bug指在计算机程序中存在一个错误、缺陷、疏忽或者故障，这些不够使程序无法正确的运行。BUG产生于程序的源代码或者程序设计阶段的疏忽或者错误。

准确来说：

1. 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
2. 当规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

2.2描述bug的要素

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

例如：

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

问题出现的环境：Windows家庭版

问题出现的步骤：

1. 打开谷歌浏览器，输入网址https://www.101.eduyun.com/
2. 等待首页页面渲染完成

预期结果：二维码与登陆模块不会出现遮挡，二维码可以正常扫描。

实际结果：二维码被登陆模块遮挡，二维码扫描失败。

2.3bug的级别

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

崩溃	严重	一般	次要
阻碍开发或测试工作时间的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误，死循环、数据库发生死锁，重要的一级菜单功能不能使用等（该问题在测试中较少出现应立即终止当前版本测试）	系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他测试的情况下可以继续该版本测试）	功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等（该问题实际测试中存在最多）	界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案。如：错别字、界面格式不规范，页面显示重叠，不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

2.4 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

2.5与开发起争执怎么办？

2.5.1先检查自身，是否bug描述不清楚

2.5.2站在用户角度考虑并抛出问题

站在用户角度考虑问题，应该让开发人员了解到Bug对用户可能造成的困扰

2.5.3Bug定级要有理有据

不仅要参考bug的级别，还要考虑Bug是否会影响到流程，往往用户的Bug级别和我们的是由区别的，需要站在用户的角度考虑定位级别。

2.5.4提高自身技术和业务水平，做到不仅能很好的提出问题，最好也能给出解决方案

2.5.5bug评审

2.5.5.1bug评审主要解决两个问题：

（1）决定如何处理bug

（2）分析缺陷产生的原因，找出预防的决策

2.5.5.2bug评审至少需要各个项目组的代表参加：

（1）测试代表

测试代表主要从bug的具体表现、严重程度等方面提供信息，并提出自己对BUg的处理意见。需要注意的是，测试人员不应该一味地要求对bug进行修改，因为修改可能带来回归的风险，同时带来的是测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做一次有效的回归测试，可能不修改是个明智的选择。

（2）开发代表

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

（3）产品代表

产品代表主要从产品的整体计划、用户的要求等方面对缺陷修改的必要性。缺陷修改的时间和版本提出自己的意见。