bug严重级别和优先级别定义

bug严重级别和优先级别定义

Suggestion,Trivial,Minor,Major,Crash
建议,较小,普通,严重,致命
Low,Medium,High,Very High,Urgent
低,中,高,很高,紧急
Low,Medium,High,Very High,Urgent
低,中,高,很高,紧急
New,Open,Reopen,Fixed,Rejected,Closed,Postponed,Won’t Fix,Duplicated,By Design

[步骤]
1.
2.

[结果]

[期望]

[备注]

[步骤]
1.
2.

[验证]

[备注]

 
每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产品共同确定）。问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出错的模块，进行代码审查
　　
　　开发人员
　　分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B-Major类或紧急程度3-High类以上（包含）bug5个或5个以上，停止新功能的开发。
　　
　　需求人员
　　解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计划
　　测试人员
　　不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解决
　　
　　测试组长/经理
　　审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测趋势。在测试总结报告中给出意见
　　产品人员
　　可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺
　　
　　Bug：指缺陷通过一个跟踪修复过程的进展情况。包括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 必须修改，发版前必须修正
　　
　　3-High 必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正
　　
　　2-Medium 如果时间允许应该修改
　　
　　1-Low 允许不修改 
　　
　　
　　功能模块(Subject)：TD中需在Test Plan页中定义好Subject，才能在Defects页中使用。
　　
　　
　　处理意见:开发组长/经理(或具体Bug分配人员)在审核新Bug时、将Bug分配给开发人员解决前，需要给出该Bug的处理意见。
　　
　　Fixable 可修改。表示Bug可以被修复或更正
　　
　　Duplicated 重复。表示该Bug已经被其他测试人员找出来了（‘纯粹’重复），
　　
　　或者开发认为原因是相同的（但从测试来看，认为出现的地方有所不同、表现有所不同等）
　　
　　Postponed 延后。由于时间、进度、重要程度或者技术/需求等方面的原因，认为不能解决、须延期解决、或者
　　
　　本版不做留待到后续版本解决的Bug。
　　（注：因‘Bug状态’字段中也有该值，根据各组各自使用情况，可以只保留一个，或者开发/测试各有侧重地使用这两个Postponed）
　　
　　By Design
　　因设计结构问题无法修改。测试人员认为是Bug，不符合逻辑，也不符合用户的要求，但开发人员则认为是按照设计做的、只能如此处理，否则修改代价太大
　　
　　Can’t Reproduce 
　　不可复现。不能重现（如因Bug出现的环境重现不了了），或以前出现的某个Bug自动消失了（可能是在处理其他Bug的时候把这个Bug一并修复掉了）。
　　（注：因TD本身亦带有‘是否复现(Reproducible)’字段，根据各组各自使用情况，可以用它来标识，或者不用它而在‘处理意见’字段中用该值标识出）
　　
　　Disagree With Suggestion 不同意所提意见或建议，不采纳
　　
　　Not Error 不是问题。测试人员提错了
　　
　　Won’t Fix 这个Bug是一个错误，但还没有重要到非要更正不可的地步，可以忽略不计
　　
　　
　　说明：
　　1.定为Duplicated的Bug，必须注明和XXXbug重复
　　2.测试人员对标明为Duplicated的Bug复测，需要XXXBug修改后方可进行
　　3.定期回顾Can't Reproduce,Postponed
　　4.定期整理By Design
　　
　　其它一些字段（及所定义的枚举值）的定义解释，供有需要用到的组参考：
　　
　　测试状态（TestState）：新提交的Bug定位标准。由测试人员指定。一般有8个（提交Bug时给出）
　　
　　1－New Defects（或写成Defect） 新Bug
　　
　　2－Second Defects（或写成SB） 复测时新出现的Bug
　　
　　3－Faculative 偶发性
　　
　　4－Reappear 原来修改过的问题又重新出现
　　
　　5－By Requirement 需求要求但没有做的功能
　　
　　6－Suggestion 需求需要完善
　　
　　7－Differ With Requirement 与需求不一致
　　
　　8－By Design 设计要求但没有做的功能
　　
　　复测状态(ReTestState)：复测时给出的状态，测试人员对于经过验证的Bug应按以下几种标准进行定位。由测试人员指定。一般有1－OK、2－PD、3－DV、4－NB、5－NR、6－AR。
　　
　　OK 正确 
　　PD 此问题悬而不决 
　　DV 有错误可以暂时不考虑 
　　NB 不是错误 
　　NR 不能复现的错误 
　　AR 需求不明确