Bug相关知识全覆盖

上一篇 / 下一篇 2010-11-10 14:54:55 / 个人分类：测试理论基础

查看( 742 ) / 评论( 0 ) / 评分( 0 / 0 )

一、bug状态(Status)

指缺陷从报告(创建)到关闭的整个修复过程中的进展情况，包括：New(Created)、Open、Reopen、Fixed、Closed、Rejected等。如下图所示：

(1)New：是测试人员提交新缺陷的标志，表明该缺陷已经被记录，等待相关人员(经理等)Approved(确定优先级并分配给相关开发人员)或Rejected。

(2)Open：只有该缺陷被Approved了才会进入该状态，没有进入该状态的bug，程序员不用管。

(3)Fixed: 开发人员修改问题后所做的状态标志，但是还有经过测试人员的测试。

(4)Reopen：测试人员对开发人员修改的问题进行verify后，认为没有通过所作的状态标志。

(5)Closed：测试人员对开发人员修改的问题进行verify后，认为通过了所作的状态标志。

(6)Rejected：开发人员或经理认为不是bug、秒数不清、重复、不能重现等时所作的状态标志。

其实，有些公司定义的bug状态包括但不局限于这几个，例如我们公司还包括waiting for info，fixed in branch、in test等等。

二、bug的严重等级(Severity)

指有缺陷引起的故障对产品的影响程度的一个衡量，共分5个等级，数字越小越严重。由测试人员制定。

0：System is down(Crash)(导致死机、产品崩溃、系统悬挂无法操作)

1：loss of data、corruption of data、severe memory leak

2：Major loss of function

3：Non-major loss of function

4：Issue that can be viewed as trivial(eg：cosmeitc、UI、easily documented)

三、bug优先级(Priority)

指缺陷必须被修复的紧急程度，共分5个等级，数字越小优先级越高。由 Bug分配者（开发组长/经理）指定。

0-Blocking：阻止开发人员的进一步开发活动，立即进行修复工作。阻止与此密切相关功能的进一步测试

1-Critical：发布版本或新版本前必须修改

2-High：必须但不一定马上修改

3-Normal：时间允许应该修改

4-Low：运行不修改

四、bug描述要求

Bug描述的要求为分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查（截图或其

它形式的附件）。测试组长/经理把关，以开发人员的角度来审查Bug描述，看其是否描述清楚了Bug，

不好描述的把工程文件或截图作为附件提交。具体要求为：

· 问题描述一般格式：问题描述时，建议分几步描述，

模块或功能点=>测试步骤=>期望结果=>实际结果=>其它信息，可依实际情况调整；

· 单一：尽量一个报告只针对一个软件缺陷，报告形式应方便阅读。在主报告之后应注明不同

的条件；

· 简洁：每个步骤的描述应尽可能简洁明了。只解释事实、演示和描述软件缺陷必要的细节，

不要写无关信息；

· 再现：问题必须在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标明）；

· 复杂的问题应附截图补充说明或直接通知指定的修改人；

· 报告中不允许使用抽象词句：比如“有错误”之类；

· 有关OS特征问题：应在不同操作系统上进行操作，看是否能重现，并在Bug报告中标识；

好的Bug报告应满足以下几方面的要求：

· 结构清晰

· 复现故障再写报告

· 隔离 Bug：更改条件复测

· 归纳：是否其他模块也有相同的Bug

· 比较：其他测试用例是否使用到此Bug

· 总结：报告的开头有Bug的总结

· 精简：不要有多余的步骤和语言

· 无歧义：语言明确

· 中立：无批评性语言

· 讨论：将要发出的报告送其他测试人员讨论

Bug相关知识全覆盖

相关阅读: