软件测试——BUG概念

目录

一、软件测试生命周期

二、BUG

2.1BUG概念

2.2BUG要素

2.3BUG级别

 2.4 BUG的生命周期

2.5测试人员与开发人员因为BUG发生争执

2.6BUG评审

---

一、软件测试生命周期

软件测试贯穿于软件的整个生命周期

软件测试的生命周期指测试流程，每个阶段有不同的目标和交付产物

需求分析	从用户角度考虑软件需求是否合理 从技术角度考虑技术上是否可行，是否有优化空间 从测试角度考虑是否存在业务逻辑错误、冗余、冲突问题
测试计划	测试开始时间和结束时间
测试设计与开发	参考需求文档和技术文档编写测试用例 写测试文档，标注使用到的测试方法和测试工具、测试形式
测试执行	充分利用测试用例和测试工具对项目尽可能做到全面覆盖
测试评估	测试是否通过 测试是否有遗留BUG 产出一个测试报告
上线	测试人员跟踪上线，测试上线后是否能正常运行
运行维护	在试运行时，收集问题并反馈给相关负责人

二、BUG

2.1BUG概念

程序存在的错误、缺陷、疏忽、故障属于BUG,这些BUG使程序无法正确运行

BUG产生于程序的源代码或者程序设计阶段的疏忽或者错误

程序与规格说明之间的不匹配才是错误（规格说明是存在并且正确的）

当规格说明没有提到的功能，判断标准以最终用户为准

当程序没有实现最终用户合理预期功能时，就是软件错误。

2.2BUG要素

描述BUG的基本要素：

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

例如：101智慧课堂-您身边的智慧课堂－打造智慧教育生态圈在这个官网下，

在微软浏览器打开时会出现登录注册功能会遮挡二维码，而在Google浏览器下不会出现这种情况。 

那么我们在描述BUG时：

问题出现的版本：微软浏览器版本135.0.3179.73（正式版本）（64位）

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

问题出现步骤：

1、打开微软浏览器

2、输入网址101智慧课堂-您身边的智慧课堂－打造智慧教育生态圈

3、等待首页加载完成

预期结果：二维码不会被登录注册模块遮挡，可以正常扫描

实际结果：二维码被登录注册模块遮挡，不能正常扫描

2.3BUG级别

BUG级别，能够看出问题的严重程度

开发人员通常需要按照BUG级别来分配优先级来处理BUG

BUG级别也可看出来开发人员的开发质量

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

崩溃	阻碍开发或者测试人员工作的问题 系统崩溃、死机、死循环、数据库丢失、数据库连接错误、主要功能丧失、功能不能使用 例如：代码错误、死循环、数据库发生死锁 出现该问题时，中止当前测试
严重	系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，但不影响其他功能测试 功能与需求不符、模块无法启动、自动退出、关联程序间调用冲突、安全问题、稳定性 例如：软件中数据保存后数据库中显示错误、用户所要求的功能缺失、程序接口错误、数值计算统计错误 出现该问题时，可以继续测试
一般	功能没有完全实现但不影响正常使用、功能缺陷但不影响系统的稳定性 例如：操作时间长、查询时间长、格式错误、边界条件错误、删除没有确认框、数据库表中字段过多。
次要	界面、性能缺陷不影响操作功能的执行，可以优化性能的方案 例如:错别字、界面格式不规范、页面显示重叠、描述不清楚、提示语丢失、我文字排列不整齐、光标位置不正确。

 2.4 BUG的生命周期

测试人员发现BUG后，需要在对应的BUG管理平台创建BUG，创建后需要开发人员修复，测试人员持续跟踪和测试

创建BUG:未经评审决定是否给开发人员修改

查看BUG:确认是BUG,需要修改，给开发人员修改

修改BUG:开发人员修改后，将BUG标记为已修改状态

拒接修改BUG:开发人员认为不是BUG，拒绝修改，（BUG评审）

重新打开BUG:修改后验证不通过

关闭BUG:验证通过

2.5测试人员与开发人员因为BUG发生争执

检查自身BUG是否描述不清楚

站在用户角度抛出问题

BUG定级时需要站在用户角度定位BUG级别

提升自身业务能力，好的测试不仅能发现问题更能给出问题的解决方案

2.6BUG评审

BUG评审解决问题
1、决定如何处理BUG

2、分析缺陷产生的原因，找出预防对策

BUG评审参加人员：测试代表、开发代表、产品代表