一。提单模板
标题:【项目组】【模块】【子模块】【发生原因】问题简要描述
描述:
【预置条件】
有就写清楚,没有就写无
【操作步骤】
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等级定义