Bug 状态流程图 对 Bug 的处理 开发组长/经理 每天对Bug 进行分配,标注处理意见,给定优先级(发版前必须三方:需求、开发、产品共同确定)
问题分配时,应尽可能将咨询类、理解错误类等问题处理掉,而不是留给开发人员
有可能是需求的问题,分配给需求人员
定期对Bug 库分析,找出常出错的模块,进行代码审查 开发人员 分析Bug,写出问题原因,修改Bug;实行Bug 优先原则,严重程度B-Major 类或紧急程度3-High类以上(包含)bug5 个或5 个以上,停止新功能的开发
需求人员 解释需求,给出处理意见,将Bug 库中的建议整理成需求文档
评审确定后列入开发计划 测试人员 不参与问题的优先级的定位,只用Bug 级别反映Bug 的严重程度
验证Bug 是否已被解决 测试组长/经理 审核测试人员提交的Bug
定期对Bug 库进行分析,描绘出曲线图等,报告现状、预测趋势
在测试总结报告中给出意见 产品人员 可以对优先级和处理意见等进行审核,如果有意见,和项目组商量定夺 Bug 状态(Status):指缺陷通过一个跟踪修复过程的进展情况
包括New、 Open、 Reopen、 Fixed、Closed 及 Rejected 等 新建(New) 测试人员报告一个新bug 并且没有指派给具体的开发人员修改是的状态
打回(Feedback) 开发人员认为此bug 不需要修改,就将其反馈
测试人员和开发人员讨论评估后,决定是否将其关闭 公认(Acknowledged) 该 bug 在大部分模块中或页面中出现,将其设为Acknowledged(由开发人员确认) 已确认(Confirmed) 开发人员(QA)确认存在此bug,并准备修改,将其设为confirmed 已分派(Assigned) 将新建bug 指派给某个指定的开发人员后,状态为Assigned(一般由项目经理做