aurain
技术文摘
posts - 137,  comments - 268,  trackbacks - 0

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 需求不明确

posted on 2014-07-04 11:13 阅读(13827) 评论(0)  编辑 收藏 引用 所属分类: 项目管理

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理



<2014年7月>
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

常用链接

留言簿(17)

随笔分类(138)

随笔档案(137)

网络开发

最新随笔

搜索

  •  

积分与排名

  • 积分 - 488082
  • 排名 - 36

最新随笔

最新评论

阅读排行榜

评论排行榜