2012年09月21日 17:41供稿中心:兆隆教育
一、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的总结
·精简:不要有多余的步骤和语言
·无歧义:语言明确
·中立:无批评性语言
·讨论:将要发出的报告送其他测试人员讨论