bug处理流程总结

bug的状态

1、新建
2、打开
3、已修复
4、已关闭
5、拒绝
6、延迟
7、激活

不同状态bug对应的场景

1、新建 —测试人员新建，标出bug发现的版本（指派给研发）
2、打开 —开发人员确认bug后，将bug改为打开状态
3、已修复 —开发人员修复后，改为此状态。
（并标出修复版本和bug产生原因）
4、已关闭 —测试人员验证通过后，关闭bug，并标出验证版本
5、拒绝 —该bug逻辑错误或和需求不符，更改状态时，标注原因
6、延迟 —因优先级原因，并经项目经理同意后，推迟到下个版本 解决，更改状态时，标注原因
7、激活 —bug验证不通过，更改状态时，标注原因

注：
1、bug各阶段要有版本号做标记跟踪
2、暂不修改的问题，是出于delay状态，不能改成拒绝（码云目前没有delay状态，可以不改状态，在下面做上文字标记）
3、bug闭环，任何类型的bug，最终都由测试人员关闭

bug被关闭的情况

bug任何种类的bug最终都将由测试人员关闭
1、回归通过的bug----直接关闭
2、研发拒绝的（要与测试人员沟通）
测试人员认可----直接关闭
测试人员不认可----找项目经理协商，若问题不紧急可暂不处理
3、重复问题----测试人员确认后关闭
4、遗留问题
1、需研发、测试、产品、项目经理开会讨论如何处理
注：偶发性bug，验证通过不关闭，可先降低优先级，三个以上正式版本都未复现可暂时关闭，后面发现再提，若是现场反馈问题，优先级最高，建议持续观察，直到版本交付

工作中bug处理问题

测试：
bug等级设定不严谨
截图、日志上传不全
研发：
暂不解决的问题直接拒绝
解决问题后，bug产生原因的描述很少
里程碑：
新增bug都绑定最近的里程碑，但事实上不会将所有问题解决掉，建议根据版本发布时间，bug优先级，由项目负责人进行绑定