软件测试——BUG概念
一、软件测试生命周期
软件测试贯穿于软件的整个生命周期
软件测试的生命周期指测试流程,每个阶段有不同的目标和交付产物
需求分析 | 从用户角度考虑软件需求是否合理 从技术角度考虑技术上是否可行,是否有优化空间 从测试角度考虑是否存在业务逻辑错误、冗余、冲突问题 |
测试计划 | 测试开始时间和结束时间 |
测试设计与开发 | 参考需求文档和技术文档编写测试用例 写测试文档,标注使用到的测试方法和测试工具、测试形式 |
测试执行 | 充分利用测试用例和测试工具对项目尽可能做到全面覆盖 |
测试评估 | 测试是否通过 测试是否有遗留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.6测试人员与开发人员因为BUG发生争执
检查自身BUG是否描述不清楚
站在用户角度抛出问题
BUG定级时需要站在用户角度定位BUG级别
提升自身业务能力,好的测试不仅能发现问题更能给出问题的解决方案
2.7BUG评审
BUG评审解决问题
1、决定如何处理BUG
2、分析缺陷产生的原因,找出预防对策
BUG评审参加人员:测试代表、开发代表、产品代表