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

缺陷管理Bug状态流程图
2

———————————————————————————————— 作者：
———————————————————————————————— 日期：

个人收集 仅供参考学习 勿做商业用途
Bug状态流程图
对Bug的处理
开发组长/经理
每天对Bug进展分配，标注处理意见，给定优先级〔发版前必须三方：需求、开发、产品共同确定〕。问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出错的模块，进展代码审查
开发人员
分析Bug，写出问题原因，修改Bug；实行Bug优先原那么，严重程度B-Major类或紧急程度3-High类以上〔包含〕bug5个或5个以上，停顿新功能的开发。
需求人员
解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发方案
4

个人收集 仅供参考学习 勿做商业用途
测试人员
不参与问题的优先级的定位，只用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分配者〔开发组长/经理〕指定。
5-Urgent
阻止相关开发人员的进一步开发活动，立即进展修复工作；阻止与此密切相关功能的进一步测试
4-Very High
必须修改，发版前必须修正
4

个人收集 仅供参考学习 勿做商业用途
3-High
必须修改，不一定马上修改，但需确定在某个特定里程碑完毕前须修正
2-Medium
如果时间允许应该修改
1-Low
允许不修改
功能模块(Subject)：TD中需在Test Plan页中定义好Subject，才能在Defects页中使用。
问题描述、附件附图 请参见后面第四局部‘Bug描述要求’的有关内容。