1.标题:【项目名称——简短的bug说明】
描述bug的最主要关键词,如xx项目——数据库输入输出数据不一致
2.项目名称:【项目名称+项目版本号】
3.Bug所属项目/模块:Bug所属项目和模块,最好能较精确地定位至模块;
4.严重等级:【紧急,严重,一般,微小】
紧急Bug:造成系统或应用程序崩溃(Crash)、死机、系统悬挂,或者造成数据丢失、主要功能完全丧失等。
严重的Bug:功能或者特性没有实现,主要功能部分丧失,次要功能完全丧失,或者致命错误声明。
一般的Bug:不太严重,虽然不影响系统的基本使用,但没有很好地实现功能,没有达到预期效果。如:次要功能丧失,提示信息不太准确,或用户界面差,操作时间长等。
微小的Bug:对功能几乎没有影响,产品及属性仍可使用,如有个错别字、文字排列不整齐等。
5.优先级:【P1,P2,P3,P4】
P1:立即解决,导致系统几乎不能使用或测试不能继续,需要立即修复;
P2:高优先级,严重,影响测试,需要优先考虑;
P3:正常排队,需要正常排队等待修复;
P4:可以在开发人员有时间的时候再纠正;
6. Bug状态:【New,Open, Fixed, Rejected, Delay ,Closed, Reopen】
New: 新发现的bug,开发人员尚未确认;
Open:确实是bug,并认为需要修改,指派给相应的开发人员;
Fixed:开发人员进行修改后标识成修改状态,有待测试人员的回归测试验证;
Rejected:如果认为不是bug,则决绝修改;
Delay:暂时不修改或者暂时不能修改,则延后修改;
Closed:fixed状态的Bug经测试人员回归测试验证通过,则关闭Bug;
Reopen:fixed状态的Bug经验证仍然存在,则需要重新打开Bug,开发人员重新修改;
新梦想技术分享
7.测试环境:【硬件设备环境,软件设备以及配置环境,具体到使用的版本号,类型号】
测试人员要充分说明测试环境的情况,以便开发人员可以快速定位错误,防止出现因开发环境与测试环境不符,而无法重现bug的情况。
8.重现步骤:【详细、精炼的描述bug出现的操作过程,一步一步地描述】
提供如何重复当前Bug的准确描述,应该简明而完备、清楚而准确;录入之前要多做几次尝试,尽量把操作步骤缩减到必须要执行才能重现错误的几个步骤;
9.期望结果:【需求给出的输出结果,即正常结果】
按照设计规格说明书和用户需求,在上述步骤之后,所期望的结果,即正确结果;要描述清楚产品需求制定的正确结果是什么,避免开发人员因产品需求不明,而产生不必要的沟通开销;
10.实际结果:【实际测试输出的结果,即错误的结果】
客观反映事实。如:程序抛出异常信息如下…
11.出现频率:【必现,通常,有时,很少】描述bug出现的可能性1%~100%;
必现:总是出现这个Bug,产生频率为100%;
通常:按照测试用例,通常情况下回产生这个Bug,频率大概80%~90%;
有时:按照测试用例,有的时候会产生这个Bug,频率大概30%~50%;
很少:按照测试用例,很少产生这个Bug,频率大概是1%~5%;
12.问题隔离:【描述环境的版本,类型等的单一变化和组合状态下,是否出现】
13.必要的附件:【图片,Log文件】
对于某些只用文字描述还不足够清楚的Bug,使用图片,错误日志等必要的附加;对于软件崩溃等现象,需要捕捉到日志文件作为附件提供给开发人员。