背景：

前期项目/迭代过程中，存在bug修复时间长、bug状态流转不及时、以及如何流转回测试的过程中存在有疑问，不太利于新人接手bug单处理。

目标：

明确bug单流转和bug处理时间的规范，减少因bug修复带来的项目风险。

状态流转：

总体状态：

流转填写说明：

1、流转至【已拒绝】：

必须要添加评论，说明具体情况；缺少拒绝说明/评论，bug单将流转至重新打开

2、流转至【已解决】：

可直接从【已接受】状态流转至【已解】，跳过【已处理】； 必须选择对应缺陷原因分类； 必须添加评论：增加问题原因、解决方案的总结描述； 前后端问题，当一方（前端/后端）处理完毕后，先完成的一方进行主动确认，另一方是否已处理。若另一方已处理，则验证通过后流转；若另一方未处理完成，则处理人中可将本人去掉，由后完成的处理人单独流转；

3、流转至【重新打开】：

4、流转至【延期】：

需要通过bug review会议，研发发起，产、研、测达成一致后，由测试统一流转为延期和遗留池迭代； 后续迭代中，建议研发安排工时，每月修复不少于30个遗留池bug单；【建议】

【当前迭代】修复说明：

1、【提测期间】bug日清规则：

紧急bug：

当天修复并提交代码，测试验证通过，直到bug单关闭；

高优bug：

当天16点前提交，当天修复并提交，测试验证通过，直到bug单关闭； 当天16点后提交，次日中午12点前修复并提交，次日16前完成测试验证通过，直到bug单关闭；

中优bug：

48小时内修复并提交，测试验证通过，直到bug单关闭；

低优bug：

根据研发人力资源安排，在后续的bug review会议确认是否延期流转； 不延期的，需要一周内安排修复完成或关闭； 延期的，需要一个月内安排修复完成或关闭；

2、【提测期间】测试验证bug：

每日20点前完成，紧急bug、高优bug的验证关闭；

3、【提测期间】未满足日清规则bug清单统计反馈：

每日统计紧急、高优bug的日清结果，邮件同步研发TL做反馈说明； 每周统计中优bug的日清结果，邮件同步研发TL做反馈说明；