[测试]软件测试的生命周期,bug的级别及生命周期

文章目录

      • [1. 软件测试的生命周期](#1. 软件测试的生命周期)
      • [2. BUG](#2. BUG)
        • [2.1 bug的概念](#2.1 bug的概念)
        • [2.2 描述bug的要素](#2.2 描述bug的要素)
        • [2.3 bug级别](#2.3 bug级别)
        • [2.4 bug的生命周期](#2.4 bug的生命周期)
        • [2.5 与开发产生争执怎么办(高频考题)](#2.5 与开发产生争执怎么办(高频考题))

1. 软件测试的生命周期

软件测试贯穿于软件的整个生命周期。 软件测试的生命周期是指测试流程,这个流程是按照一定顺序执行的一系列特定的步骤,去保证产品质量符合需求。每个阶段有不同的目标和交付产物。

需求分析 测试计划 测试设计、测试开发 测试执行 测试评估 上线 运行维护

各阶段具体内容:

需求分析 测试计划 测试设计与开发 测试执行 测试评估 上线 运行维护
用户角度: 软件需求是否合理 制定测试计划 参考需求文档、技术文档等编写测试用例 充分利用测试用例和测试工具对项目尽可能做到全方面测试 测试是否通过,本次测试是否有遗留的BUG,最终测试人员需要产出一个测试报告 项目测试结束后,将项目发布到线上环境,测试人员需跟踪上线并测试线上环境下软件的运行是否正确 测试人员需要参与项目的实施工作,收集问题并及时反馈给相关负责人

2. BUG

2.1 bug的概念

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

准确的来说:

  1. 当且仅当规格说明是存在的并且正确,程序与规格说明之间的不匹配才是错误。
  2. 当需求规格说明书没有提到的功能,判断标准以最终用户为准:当程序没有实现其最终用户合理预期的功能要求时,就是软件错误。
2.2 描述bug的要素
  • 问题出现的版本
  • 问题出现的环境
  • 问题出现的步骤
  • 预期结果
  • 实际结果

案例:

  • 问题出现的版本:谷歌浏览器版本 123.0.6312.123(正式版本) (64 位)
  • 问题出现的环境:Windows家庭版
  • 问题出现的步骤
    1. 打开谷歌浏览器,输入网址https://www.10leduyun.com/
    2. 等待首页页面渲染完成
  • 预期结果:二维码与登陆模块不会出现遮挡,二维码可以正常扫描
  • 实际结果:二维码被登陆模块遮挡,二维码扫描失败
2.3 bug级别

通过定义bug的级别,能够明确看出问题的严重程度。工作中开发人员通常需要按照bug的级别来分配优先级来处理bug,除此之外,通过bug级别也能够体现出开发人员的开发质量。

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

崩溃 严重 一般 次要
阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环,导致数据库数据丢失,与数据库连接错误 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符,模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等。 功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性。如:操作时间长、查询时间长、格式错误、边界条件错误,删除没有确认框、数据库表中字段过多等 界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等。如:错别字、界面格式不规范,页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置不正确,用户体验感受不好,可以优化性能的方案等
2.4 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

2.5 与开发产生争执怎么办(高频考题)

遇到争执不要怕,要理性的分析和反馈问题。

  1. 先检查自身,是否bug描述不清楚
  2. 站在用户角度考虑并抛出问题
  3. 2.5.3 BUG定级要有理有据
  4. 提高自身技术和业务水平,做到不仅能提出问题,最好也能给出解决方案

注意: 可以给出解决方案,但是不能喧宾夺主,命令式让开发人员按照自己的想法来修改。

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

bug评审主要解决两个问题:

  1. 决定如何处理bug
  2. 分析缺陷产生的原因,找出预防的对策

bug评审至少需要项目组各个方面的代表参加:

  1. 测试代表

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

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

    • 产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见。
相关推荐
爱学习的张哥1 天前
IP层之分片包的整合处理---BUG修复
单片机·tcp/ip·bug
MegatronKing2 天前
Reqable项目日志——JSON语法高亮性能200倍提升
前端·flutter·测试
丁总学Java2 天前
小程序渲染之谜:如何解决“加载中...”不消失的 Bug(glass-easel)
前端·小程序·bug·glass·glass-easel·easel
大话性能2 天前
提示词工程的十大认知误区
测试
CCSBRIDGE2 天前
OpenManus测出死循环bug
bug
用键盘当武器的秋刀鱼2 天前
bug修改模板(日志)
java·开发语言·bug
阿华的代码王国3 天前
【性能测试】Jmeter下载安装、环境配置-小白使用手册(1)
测试开发·jmeter·性能测试·测试·jmeter使用
阿华的代码王国3 天前
【性能测试】Jmeter如何做一份测试报告(3)
开发语言·jmeter·性能测试·测试·测试报告
哟哟耶耶3 天前
bug-Ant中a-select的placeholder不生效(绑定默认值为undefined)
bug