• bug提单规范


    一。提单模板

    标题:【项目组】【模块】【子模块】【发生原因】问题简要描述
    描述:
    【预置条件】
    有就写清楚,没有就写无
    【操作步骤】
    1.XXXXX
    2.XXXXXX
    3.XXXXX
    【实际结果】
    XXXXX
    【预期结果】
    XXXXXX
    【问题发生时间】——偶现的问题必须要写,必现问题可以不用写
    【设备信息】机器人SN号
    【复现概率】3/3
    【备注】如果有一些其他信息,可以写在这里

    二。偶现bug

    在上述提交bug要求上添加:
    1.填写复现概率(30次以上),寻找规律协助开发定位
    2.截图
    3.记录时间点
    4.记录设备编号
    5.必须截取日志
    6.单机复现的问题要带上设备号
    7. 对bug进行评估,确定优先级,如果优先级高的话,将bug单发给组内的同事,让大家帮忙关注

    三。BUG验证

    验证Resolved状态,且在测试名下的BUG。
    验证问题时,请按照如下要求写,严禁不添加任何验证结果直接关闭或指给研发处理的情况!
    1).通过情况,bug单状态:closed
    验证版本:
    验证次数:
    测试结果:pass
    备注:有需要就写
    2).不通过情况,bug单状态:feedback,同时BUG需要指派给开发
    验证版本:
    测试步骤:
    验证次数:
    验证结果:fail,后面写上实际现象,并给出log
    备注:功能性问题给出新版本的log
    3)测试阻塞暂无法回归,bug单状态:postphone
    验证版本:
    当前状态:如其他功能阻塞/新引入bug#导致该bug无法回归

    四。偶现BUG验证&跟踪

    1.如果是resolved状态,需要在新版本验证,如果当时版本都没有复现,需要跟踪3个版本,状态改为verfied,如果3个版本都未复现,这样的bug可以关闭处理。
    2.如果非resolved状态,只是研发打回需要重新提供log之类,也是跟踪3个版本,但状态不要修改,,如果3个版本都未复现,这样的bug可以关闭处理。3个版本要复现50次以上,并从开机开始截取日志,最好是记录下曾经的操作过程;如果是log中看不出关键信息,则要求开发立即出一个针对复现他这个bug的版本(开发在版本中添加打印log)

    五,bug等级定义

  • 相关阅读:
    项目管理
    智能硬件如何确定需求:场景约束
    产品设计
    产品设计之前,如何分析业务需求和用户痛点?
    微信小程序挑一挑辅助
    C#实现冲顶大会辅助工具(截图+图像识别+搜索)
    读取配置文件--AppConfig
    文件各种上传,离不开的表单
    使用C#委托来实现异步编程
    Table 组件构建过程中遇到的问题与解决思路
  • 原文地址:https://www.cnblogs.com/yinlili/p/9590574.html
Copyright © 2020-2023  润新知