软件测试中bug的划分

最近的项目比较多,就是一个接一个的项目,写下个项目的case的同时测试着另一个项目,同时进行的样子,就要把bug管理好

一 真正测试出的bug

bug出现在项目中,自己测出bug,和平时网上看资料学习到的bug步骤还是有一点点差别的,就拿我现在来说

  1. 测试项目
  2. 出现bug
  3. 根据自己的测试项目的经验判断是否是影响后续的case执行
  4. 是的话,立刻发邮件,提bug
测试地址/环境/系统/app版本:
测试数据:    
[步骤]
1:
2:
[结果]:
[期望]:
  1. 如果不是的话,先发邮件出去,在接着测试,等测试完其他case,说不定就解决了
  2. 然后自己提的bug,要不断的跟进,直至解决,复测通过,关闭case
    注:我自己认为:有的时候系统报的错误提示,可能是数据的某个字段缺失了数据,只要是数据的问题,执行sql可以解决的事,开发告诉过一次解决办法之后,就要记得不要同样的问题问好几次,公司太大,人家开发很忙
    因为我刚开始也是一直问,后来我的师傅告诉我的

二 bug关闭

我们平时测试过程中,测出bug了,要提bug,bug一旦开启,就是要关闭的,我们测试是要对这个bug负责任的

三 bug等级

3.1 按照jira管理工具

按照jira管理工具,bug主要分五类:

3.1.1 Blocker

Blocker:阻碍开发或测试工作的问题

3.1.2 Critical

Critical:系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定
具体基本上可分为:
○ 内存泄漏
○ 用户数据丢失或破坏
○ 系统崩溃/死机/冻结
○ 模块无法启动或异常退出
○ 严重的数值计算错误
○ 功能设计与需求严重不符
○ 用户权限问题
○ 安全问题

3.1.3 Major

Major:影响系统功能或操作,主要功能存在严重缺陷,但不会影响到系统稳定性
具体基本上可分为:
○功能未实现
○ 功能错误
○ 系统刷新错误
○ 系统所提供的功能或服务受明显的影响

3.1.4 Minor

Minor:界面、性能缺陷
具体基本上可分为:
○ 操作界面错误
○ 边界条件下错误
○ 提示信息错误
○ 长时间操作无进度提示

3.1.5 Trivial

Trivial:易用性及建议性问题
具体基本上可分为:
○ 界面格式等不规范
○ 辅助说明描述不清楚
○ 操作时未给用户提示
○ 可输入区域和只读区域没有明显的区分标志

四 bug的状态

4.1 已指派的bug

1、跟踪、提醒开发、
2、已修复的,更新环境验证

4.2 已解决的bug

1、更新环境验证
2、验证通过,关闭
3、验证不通过,重新打开
4、回归验证时继续跟进bug,直到关闭bug

4.3 重复的bug

1、确认重复,关闭
2、不重复,写明原因

4.4 不是bug

1、首先确认开发环境和测试环境是否一致
2、不是缺陷关闭
3、是缺陷和开发沟通
4、未得到解决与产品沟通

4.5 无法重现

1、首先确认开发环境和测试环境是否一致
2、重现不了,与产品和开发一起确认关闭(依据bug的严重程度)
3、找到重现原因,写明清楚,指派给开发

4.6 不予解决

1、找产品经理确认
2、不予解决,关闭
3、要解决,写明原因给开发

4.7 设计如此

1、找产品经理确认
2、不予解决,关闭
3、要解决,写明原因给开发

4.8 延期修改

1、根据bug的严重程度,是否影响当前版本的发布
2、与产品经理确认
3、不予延期,写明情况,激活
4、确认延期,做好记录,后续版本进行关注

  • 1
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

测试小姐姐

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值