缺陷管理Bug状态流程图.docxVIP

 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 为测试人员新问题提交所标志的状态。 Open 为任务分配人（开发组长/经理）对该问题准备进行修改并对该问题 分配修改人员所标志的状态。Bug 解决中的状态，由任务分配人改变 对没有进入此状态的 Bug，程序员不用管。 Reopen 为测试人员对修改问题进行验证后没有通过所标志的状态；或者已经 修改正确的问题，又重新出现错误。由测试人员改变。 Fixed 为开发人员修改问题后所标志的状态，修改后还未测试。 Closed 为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改 变。 Rejected 开发人员认为不是 Bug、描述不清、重复、不能复现、不采纳所提意 见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或 者测试人员提错，从而拒绝的问题。由 Bug 分配人或者开发人员来设 置。  Bug 严重级别(Severity，Bug 级别)：是指因缺陷引起的故障对软件产品的影响程度。由测试人员指 定。  A-Crash 错误导致了死机、产品失败（“崩溃”）、系统悬挂无法操作； B-Major 功能未实现或导致一个特性不能运行并且不可能有替代方案； C-Minor 错误导致了一个特性不能运行但可有一个替代方案； D-Trivial 错误是表面化或微小的（提示信息不太准确友好、错别字、UI 布局 或罕见故障等），对功能几乎没有影响，产品及属性仍可使用； E-Nice to Have（建议） 建设性的意见或建议。  Bug 优先级(Priority)：指缺陷必须被修复的紧急程度。由 Bug 分配者（开发组长/经理）指定。  4-Very High 必须修改，发版前必须修正 3-High 必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修 正 2-Medium 如果时间允许应该修改 1-Low 允许不修改  功能模块(Subject)：TD 中需在 Test Plan 页中定义好 Subject，才能在 Defects 页中使用。 问题描述、附件附图 请参见后面第四部分‘Bug 描述要求’的有关内容。 处理意见:开发组长/经理(或具体 Bug 分配人员) 在审核新 Bug 时、将 Bug 分配给开发人员解决前， 需要给出该 Bug 的处理意见。  Fixable 可修改。表示 Bug 可以被修复或更正 Duplicated 重复。表示该 Bug 已经被其它测试人员找出来了（‘纯粹’重复）， 或者开发认为原因是相同的（但从测试来看，认为出现的地方有所不 同、表现有所不同等） Postponed 延后。由于时间、进度、重要程度或者技术/需求等方面的原因，认 为不能解决、须延期解决、或者本版不做留待到后续版本解决的 Bug。 （注：因‘Bug 状态’字段中也有该值，根据各组各自使用情况，可 以只保留一个，或者开发/测试各有侧重地使用这两个 Postponed） By Design 因设计结构问题无法修改。测试人员认为是 Bug，不符合逻辑，也不 符合用户的要求，但开发人员则认为是按照设计做的、只能如此处理 否则修改代价太大 Can’t Reproduce 不可复现。不能重现（如因 Bug 出现的环境重现不了了），或以前出 现的某个 Bug 自动消失了（可能是在处理其他 Bug 的时候把这个 Bug 一并修复掉了）。 （注：因 TD 本身亦带有‘是否复现(Reproducible)’字段，根据各 组各自使用情况，