51Testing软件测试论坛

标题: bug规范初稿 [打印本页]

作者: 测试积点老人    时间: 2019-1-11 14:35
标题: bug规范初稿

一、背景

bug是开发和测试质量的重要指标,从bug数量、严重性等可以看出RD的开发质量,从发现问题的阶段可以看出QA的测试意识和测试质量,从问题分类、问题来源等可以看出产品开发、测试质量的一些固有模式,帮助RD和QA提升开发和测试质量。总之窥一斑而见全豹,因此统计和分析bug十分有必要。


各端都将bug管理工作迁移到效率云,正好可以在客户端各端建立统一的规则,既便于各端的质量分析,又便于横向对比。



二、bug规范

Bug记录包含内容和tag两部分。


2.1 内容模板

bug描述——bug的直观简短的描述

登录信息——如果需要登录才能复现的bug,提供登录的账号和密码,可缺省

bug复现步骤——对于操作步长超过3的,且RD难以理解怎么复现的问题,提供复现问题的步骤。

预期结果——描述需求预期的结果,必要时辅以截图说明

实际结果——描述RD实现后的实际结果,必要时辅以截图说明

2.2 tag

tag部分包括以下几项(必填):

优先级——需要RD修复的紧急程度,是问题严重性和对测试block程度的综合考虑

严重级别——问题严重程度,可理解为被用户接受的程度

问题分类——描述问题本身的属性,是最直接、最直观的一个分类方式

问题发现阶段——描述QA发现问题的阶段,是评估QA测试质量的重要指标

问题引入方式——评估RD开发质量的重要指标

问题来源——比较粗放的一种分类方式,作一个大体的分类

解决结果——描述bug修复情况

发现版本——发现问题的版本,统一为x.x.x

修复版本——修复问题的版本,统一为x.x.x


2.3 重要说明

关于问题分类、问题发现阶段、问题引入方式、问题来源的设计思路,做如下说明:

问题分类,描述问题本身的属性,是最直接、最直观的一个分类方式,也是我们关注最多的一种分类方式,可选项如下:


[attach]120929[/attach]


1-4一定是问题,是RD不能和QA argue的问题;

5,7是协商考虑是否接受和解决的问题(性能问题严重的不能接受);

6是在流程上要充分沟通和确认的问题,这部分容易引起RD的argue,会认为不是bug。


问题发现阶段描述QA发现问题的阶段,是评估QA测试质量的重要指标。可选项如下:


[attach]120930[/attach]


这里整体分为4个阶段,没有做更细的区分,是为了各端上都能统一,因为一些兼容性测试、回归测试等各端是灵活进行的。对QA而言,越早发现bug越好,最好95%的bug都在新功能测试阶段,而3在上线前的冒烟测试阶段发现问题则是比较危险的,这意味着很可能带着未知的bug上线,而4已上线阶段发现bug则是QA应该尽量避免的。


问题引入方式是评估RD开发质量的一个指标,可选项如下:


[attach]120931[/attach]


1-3是开发测试中应该尽量避免的问题,需要QA和RD做好几时的沟通,避免因为这类问题降低测试效率和测试质量。对于1-3类问题的界定,可以考虑由RD提供;5作为低频的、难以控制的问题,可以作为bad case积累;6是应该充分沟通,降低出现频率的问题。


解决结果描述bug的修复情况,可选项如下:


[attach]120932[/attach]


2,4是QA需要尽量避免的,这会给RD或PM质疑QA测试的专业性;对于5,QA应该在测试中关注并找到







欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2