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（一般由项目经理做） 已解决(Resolved) 开发人员（QA）确认bug 以及解决，测试人员可以进行验证测试了 已关闭(Closed) 确认bug 已经解决，关闭 新建(New) 为测试人员新问题提交所标志的状态。 打开(Open) 为任务分配人（开发组长/经理）对该问题准备进行确认并修改 分派(Assign) 为任务分配人（开发组长/经理）对该问题分配修改人员所标志的状态。Bug 解决中的状态，由任务分配人改变。对没有进入此状态的Bug，程序员不用管。 重新打开(Reopen) 为测试人员对修改问题进行验证后没有通过所标志的状态；或者已经修改正确的问题，又重新出现错误。由测试人员改变。 已修正(Fixed) 为开发人员修改问题后所标志的状态，修改后还未测试。 已关...
