Bug状态流程图.doc

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) 为开发人员修改问题后所标志的状态，修改后还未测试。 已关闭(Closed) 为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改变。 拒绝(Rejected) 开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题。由Bug分配人或者开发人员来设置。 Bug严重级别(Severity，Bug级别)：是指因缺陷引起的故障对软件产品的影响程度。由测试人员指定。 4-宕机(Block) 引起系统死锁的错误 3-崩溃(Crash) 引起系统崩溃的错误 2-很严重(Major) 不属于系统崩溃和死锁类的,但很严重的错误 1-小错误(Minor) 比较轻的问题,如button位置,数字格式,文字上的拼写错误 Bug优先级(Priority)：指缺陷必须被修复的紧急程度。由Bug分配者（开发组长/经理）指定。 5-特急(Immediate) 必须修改,并且需要立即进行修改 4-加急(Urgent) 一到两天之内必须修改并且版前必须修正 3-高(High) 将处于5和4优先级的bug修改完后再进行修改，但需确定在某个特定里程碑结束前须修正 2-中(Medium) 如果时间允许应该修改 1-低(Low) 低优先级留到最后解决,如果项目的进度很紧张可以在产品发布以前不解决 功能模块(Subject)：TD中需在Test Plan页中定义好Subject，才能在Defects页中使用。 问题描述、附件附图 请参见后面第四部分‘Bug描述要求’的有关内容。 处理意见:开发组长/经理(或具体Bug分配人员) 在审核新Bug时、将Bug分配给开发人员解决前，需要给出该Bug的处理意见。 未处理（Open） Bug没有被解决 已修正（Fixed） Bug的修改已经登记并经过测试 重新打开（Reopen） Bug曾经被解决，但是解决方案被认为不正确 无法重现（Unable to reproduce） 无法重现，被指派的开发人员想要再重现bug 进行修改的时候发现bug始终