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等级定义