不断地学习新知识,做一个受尊重的测试人员。
Bug描述规范_草稿
上一篇 /
下一篇 2014-05-06 14:25:04
/ 个人分类:测试技术
Bug描述规范-草稿
准确、简洁、完整、规范的描述Bug,有利于分析错误产生的原因,定位错误以及修改。
1. Bug标题
一个好的Bug,要写好Bug标题;
a) bug描述包括三要素:位置、操作、现象;
位置:首先应说明操作进行的位置,通常是系统中的某一模块。另外是具体的出错位置,可能是某一字段、某一页面。
操作:详细的、有次序的、每一步的操作步骤,包括输入的数据
现象:具体的错误描述,包括界面显示、错误信息。
b) bug描述要求:清晰明确且简明扼要
然而,描述清楚的同时,我们又比较容易遇到另一个问题,就是冗长,开发者看到一堆文字就头大了。不愿意花时间去仔细读(自己回头再看也容易晕)所以我们写bug描述一定要清晰明确且简明扼要;
c) 每条Bug只能包括一个错误;
每条错误报告只包括一个错误,可以使错误修正者迅速定位一个错误,集中精力每次只修正一个错误。校验者每次只校验一个错误是否已经正确修正。
d) 避免重复
提交Bug时,按照功能模块去提交,提交前确定之前没有提过;如果之前提过,直接激活即可;也可通过“搜索”功能进行查找之前是否提过,避免提交重复Bug.
2. 重现步骤
一个好的BUG,还要写好重现步骤;
a) 步骤:写好重现步骤
b) 结果:说清楚什么地方出错,添加必要截图
c) 期望:期望应当是什么结果
3. 附件
根据缺陷或错误类型,选择截图、录屏文件,附加必要的特殊文档、个人建议和注解;
4. 历史记录
开发人员填写“原因、解释”内容。
5. 基本信息
Bug基本信息包括所属产品、所属模块、Bug类型、严重程度、优先级、Bug状态、激活次数、是否确认、当前指派、操作系统、浏览器、关键词。
所属产品:选择Bug所属产品;
所属模块:选择Bug所属模块;
Bug类型:代码错误、界面优化、设计缺陷、配置相关、安装部署、安全相关、性能问题、标准规范、测试脚本、数据类、建议类、其他;
严重程度:致命(1)、2严重(2)、一般(3)、较小(4);
优先级:立即解决(1)、高优先级(2)、正常排队(3)、低优先级(4);
Bug状态:激活、已解决、已关闭;
激活次数:此Bug被重新激活;
是否确认:开发人员是否确定是Bug;
当前指派:指派给谁;
操作系统:当前操作系统 ;
浏览器:当前浏览器;
关键词:
6. Bug的一生
由谁创建:
影响版本:选择影响版本号;
由谁解决:解决Bug人员;
解决版本:解决Bug版本;
解决方案:选择解决的方案是设计如此、重复Bug、外部原因、已解决、无法重现、延期处理、不予解决、转为需求;
由谁关闭:最后修改是谁?
7. 项目/需求/任务
填写BUG单时,要写清楚所属项目名称;比如:是IDPRE2.5?还是IDPRE3.0?
8. 其它相关
抄送给:一Bug可同时抄送给其他人;
相关Bug:标注相关Bug号;
相关用例:标注相关用例号;
转需求:将Bug转需求
转任务:将Bug转任务
收藏
举报
TAG: