bug规范初稿

1、背景性能

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

各端都将bug管理工做迁移到效率云,正好能够在客户端各端创建统一的规则,既便于各端的质量分析,又便于横向对比。优化

 

2、bug规范spa

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

2.1 内容模板接口

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

登陆信息——若是须要登陆才能复现的bug,提供登陆的帐号和密码,可缺省ci

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

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

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

 

2.2 tag

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

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

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

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

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

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

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

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

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

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

 

2.3 重要说明

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

问题分类,描述问题自己的属性,是最直接、最直观的一个分类方式,也是咱们关注最多的一种分类方式,可选项以下:

序号

名称

描述

1

NA逻辑实现问题

NA逻辑实现错误

2

Server逻辑实现问题

Server逻辑实现错误

3

NA和Server接口联调问题

接口名称、接口字段错误

4

NA兼容性问题

与机型、系统有关的兼容问题

5

视觉和体验问题

文案、样式、交互细节问题

6

需求问题

需求不明确、临时需求撤换、变动

7

性能问题

NA在流量、内存、CPU、电量等方面的问题

8

其余

不能归类为以上问题的问题

 

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

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

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

 

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

序号

名称

描述

1

新功能测试阶段

新功能测试阶段

2

集成测试阶段

新功能测试已完成,进入集成测试阶段

3

上线前冒烟测试阶段

新功能和系统集成测试已完成,进入

上线前的checklist检查的阶段

4

已上线阶段

已上线阶段

 

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

 

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

序号

名称

描述

1

历史遗留

历史遗留问题,在以前的版本中未解决

2

新功能致使老功能出问题

新老功能存在耦合,致使老功能出问题

3

修复bug引发问题

修复bug引发的问题

4

新功能出问题

新开发的功能自己有问题

5

重构与优化引发问题

重构或优化已有功能、模块引发问题

 

1越多,说明在以前的版本中开发和测试质量都不过关;2,3,5都考察RD在开发过程当中对总体工程的把握,对代码之间耦合的理解。

 

问题来源是一个比较粗放的分类,可选项以下:

序号

名称

描述

1

脏数据问题

由于脏数据致使的问题

2

代码提交问题

代码提交不全、代码合并致使的问题

3

代码配置问题

配置错误、线上线下配置错乱等

4

逻辑实现问题

代码逻辑实现不到位

5

第三方问题

第三方库、资源、sdk等引发的问题,一般不可控

6

需求问题

需求理解、沟通不一致引发的问题

 

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

 

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

序号

名称

描述

1

已修复

问题已修复

2

不是Bug

由于QA的理解错误,界定为bug,实际上不是bug

3

之后修复

由于排期、优先级或者技术实现不可达,后续再修复

4

重复

QA提了重复的bug

5

没法复现

bug真实存在过,可是难以复现

6

设计如此

虽然与需求不一致,可是PM承认这种实现,定义为设计如此

 

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

相关文章
相关标签/搜索