zoukankan      html  css  js  c++  java
  • bug生命周期

    bug的生命周期&bug状态处理
    bug的定义:
    软件的bug狭义的是指软件程序的漏洞或缺陷,广义概念除此之外还包括测试工程师或用户发现和提出的软件可改进细节,或与需求文档存在差异的功能实现等。
    我们的职责就是发现这些bug,提交给开发,让开发去修改
     
    bug是怎么来的?
    1.缺乏有效沟通
    2.软件的复杂度
    3.编程错误
    4.不断变更的需求
    5.时间的压力
     
    bug的类型:
    要确定一个bug类型,需要对项目(或产品)有比较深的理解,这个划分对开发定位问题影响较小,但对于问题类型的统计就比较重要了。常见的bug类型划分:代码错误,界面优化,设计缺陷,配置相关,安装部署,安全相关,性能问题,标准规范,测试脚本,其他。
     
    其他划分:功能类,界面类
                     性能类    易用性类
                     兼容类    其他
    缺陷的等级
    bug的等级一般分为四级,也有分五级的,如果是等级越高,那么对应的优先级也会高一些,然后有些公司还会根据你提的bug数量和bug等级,作为绩效考核的一部分。
    (1)致命性错误
         1.常规操作引起的系统崩溃,死机,死循环
         2.造成数据泄露的安全性问题,比如恶意攻击造成的账户私密信息泄露
         3.涉及金钱
         4.用户数据受到破坏,或者危及人身安全
    (2)严重错误
         1.重要功能不能实现
         2.错误的波及面广,影响到其他重要功能实现
         3.非常规操作导致的程序崩溃,死机,死循环
         4.数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务受到明显影响
    (3)一般错误
         不影响产品的运行,不能成为故障起因,但对产品外观和下道工序影响较大的缺陷
         1.次要功能能不能正常实现
         2.操作界面错误(包括数据窗口内列名定义,含义不一致)
         3.查询错误,数据错误显示
         4.简单的输入限制未放在前台进行控制
         5.删除操作未给出提示
    (4)细微错误
         程序在一些显示上不美观,不符合用户习惯,或者是一些文字的错误
         1.界面不规范
          2.辅助说明描述不清楚
          3.提示窗口文字未采用行业术语
         4.界面存在文字性错误
    优先级分为4级,一般问题越严重,其处理的优先级越高
     
    bug的生命周期:
    就是一个bug被发现到这个bug被关闭的过程。
    生命周期中的一般缺陷状态:
    新建——指派——已解决——待验——关闭
    如果待验的bug在验证时没有解决好,我们需要重新打开(激活)——指派——已解决——待验,循环这个过程。中间状态拒绝——延期等
     
    bug处理流程
    1.发现bug--提交bug---指派bug---研发确认bug------(否)设计如此  重复bug,无法重现                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            
    2.发现bug--提交bug---指派bug---研发确认bug-------(是)研发是否解决-------(否)不予解决,延期
    3.发现bug--提交bug---指派bug---研发确认bug-------(是)研发是否解决-------(是)回归验证bug---是否通过验证-----(是) 关闭bug
    4.发现bug--提交bug---指派bug---研发确认bug-------(是)研发是否解决-------(是)回归验证bug---是否通过验证-----(否) 激活------指派bug~~~~~~~~~~
     
    1.激活bug:已经指派给开发的,要关注bug走向,随时跟踪,如果一直未修复,提醒开发修改,如果已经修复等待测试环境更新后进行验证
    2.已解决bug:等待测试环境更新后进行验证,验证通过则关闭,验证不通过则重新打开指派给开发
    3.重复bug:先去查看下是否跟开发指定的bug重复?如果确定是重复则庀:如果不重复,说明原因,重新打开指派给开发
    4.无法重现:确认开发环境是否跟测试环境一致,包括操作步骤,浏览器,特定账号等,如果多个版本验证之后,如果开发说重现不了,依据bug的严重程度跟产品,开发一起确认关闭,如果找到重现原音,注明清楚并在此指派给开发
    5.不予解决:找产品经理进行确认,确认不予解决进行关闭,确认需要解决请备注原因,并打开指派给开发
    6.设计如此:找产品经理进行确认,确认设计如此进行关闭,确认是问题,备注原因重新指派给开发
    7.延期修改:请看下bug严重程度,是否影响当前版本发布,与产品经理确认,不予延期请根据情况进行激活与情况说明,确认延期则做好记录,后续版本进行关注。
     
     
    面试题:
    有没有你印象深刻的bug?
    有很多印象深刻的bug,比如说后台播放 av source时rev on开启back camera后,关闭,重复开启-关闭几次后机器出现重启。
     
    bug的生命周期
    新建bug指派给开发--开发已解决----评价验证bug,修复后---关闭bug
     
    当你打开了一个bug,但开放不认为是bug,如何处理?
    首先查找需求说明书和式样书,寻找确切的依据,如果是用户体验票,侧从用户的角度来说明为什么是bug,如果开发依然认为不是bug的话,交由产品经理来判定
     
    对于复现率不高的bug如何处理?你再发现bug并确认bug的过程中
    复现率不高的bug要立马录像,拍照片,截取log,保留现场,直接叫开发来调查问题。
    如果现场已经被破坏,只能在以后每天的测试中带着再现,把这个问题在测试人员中展开一下,别的测试人员也可以帮忙验证。
     
     
     
     
     
     

  • 相关阅读:
    6.linux下指定项目使用特定jdk
    5.linux 执行shell报bad interpreter:No such file or directory错误
    定时任务基础版本
    同一台电脑安装两个jdk切换问题
    接口如何设计?安全如何保证?签名如何实现?防重如何实现?
    spring boot常见get 、post请求参数处理
    bat例子
    1.Volatile关键字详解
    1.linux目录
    解析xml报文,xml与map互转
  • 原文地址:https://www.cnblogs.com/nuonuozhou/p/8644826.html
Copyright © 2011-2022 走看看