Bug管理规范

1BUG定义

1.1Bug状态

BUG状态标记BUG当前所处的状态,是用来处理BUG流程的主要参数,JIRA缺陷管理平台有以下一些状态:  

新增(New):测试人员新发现的系统Bug;  

打开(Open):测试人员通知开发人员需要修改的BUG;  

修改(Modify):开发人员正在修改的BUG;  

固定(Fixed):开发人员通知测试人员已修复的BUG;

跟踪(Trace):测试人员短时间内很难确定是否已经修复的BUG;  

已关闭(Close):测试人员经回归测试后确定已修复的BUG;  

已否决(Rejected):被开发人员否决了的BUG;  

重新打开(Reopen):Bug未被修复,重新出现在新的测试版本中;   

延迟修改(Wait):因为种种原因需要等待延期修复的Bug。  

无效bug现在及以后都不需要改代码的bug;

无效bug处理流程:

1 测试理解错误,不需要改代码解决的问题,开发直接选择解决方式是无效bug,算无效bug; 

2 测试理解正确,PRD没有明确说的,但是经过产品确认现在以后都不需要解决的问题;研发或者产品增加备注,然后解决方式为无效bug,算无效bug;

3  Prd修改但是测试没有得到通知,根据旧prd报的bug,开发选择解决结果是无效bug,解决方式选择 “需求理解偏差”,算无效bug;

4  PRD没有写,但产品确认需要改,bug提给产品/经办人改成产品,bug引入阶段改成需求,研发改完,产品修改bug状态为已完成/已修改,不算无效bug;

5  体验类优化的问题,前端组件不支持,算已解决-未解决, 产生原因 外部原因,不算无效bug;

1.2Bug优先级

紧急

导致产品无法正常运行或需要优先处理的任务

重要

系统崩溃、丢失数据或内存溢出等严重错误

一般

一般性错误

次要

程序功能出现错误,但可通过其他手段解决

无关紧要

不影响程序运行的错误,如拼写错误等

1.3BUG自测是否应发现

否:该缺陷不属于研发自测应发现范畴

是,在开发自测用例中:在本次所给自测用例可发现范围内,属于自测应发现情况

是,不在开发自测用例中:在冒烟用例集中,并未在本次项目/需求所给自测用例内,但属于自测应发现范围;

1.4缺陷严重程度

(1)致命错误

致命错误通常有如下情况:

1、需求书中的重要功能未实现;

2、造成系统崩溃、死机,并且不能通过其它方法实现功能;

3、常规操作造成程序非法退出、死循环、通讯中断或异常,数据破坏丢失或数据库异常、且不能通过其它方法实现功能的。

(2)严重错误

严重错误通常使系统不稳定、不安全、或破坏数据、或产生错误结果,而且是常规操作中经常发生或非常规操作中不可避免的主要问题,通常有如下情况:

1、重要功能基本能实现,但系统不稳定、一些边界条件下操作会导致run-time error、文件操作异常、通讯异常、数据丢失或破坏等错误;

2、重要功能不能按正常操作实现,但可通过其它方法可实现;

3、错误的波及面广,影响到其它重要功能正常实现;

4、密码明文显示;

5、C/S、B/S模式下,利用客户端某些操作可造成服务端不能继续正常工作的。

(3)一般错误

程序的功能运行基本正常,但是存在一些需求、设计或实现上的缺陷;次要功能运行不正常,通常有如下情况:

1、次要功能不能正常实现;

2、操作界面错误(包括数据窗口内列名定义、含义不一致);

3、打印内容、格式错误;

4、查询错误,数据错误显示;

5、简单的输入限制未放在前台进行控制;

6、删除操作未给出提示;

7、数据库表中有过多的空字段;

8、因错误操作迫使程序中断;

9、找不到规律的时好时坏;

10、数据库的表、业务规则、缺省值未加完整性等约束条件;

11、经过一段时间运行后,系统性能或响应时间会变慢;

12、重要资料,如密码未加密存放(包括配置文件中的密码),或其它存在安全性隐患的;

13、 硬件或通讯异常发生恢复后,系统不能自动正常继续工作(需要过多的人工干预才行);

14、系统兼容性差,与其它支持系统一起工作时容易出错,而没有充分理由说明是由支持系统引起的;或者由于使用了非常规技术或第三方组件造成不能使用自动化测试 工具进行测试的。

(4)优化建议

可以提高产品质量的建议,包括新需求和对需求的改进,以及程序在一些显示上不美观,不符合用户习惯,或者是一些文字的错误,通常有如下情况:

1、界面不规范;

2、辅助说明描述不清楚;

3、输入输出不规范;

4、长操作未给用户提示(或长操作结束后提示没有消失);

5、提示窗口文字未采用行业术语;

6、可输入区域和只读区域没有明显的区分标志;

7、界面存在文字错误;

8、在功能实现方式上如果需求中没有明确定义,而没有按常规实现,并且不比常规方式实现优越的;( 如用户名第一位用数字或特殊字符)

1.5缺陷产生原因

1、 产品需求问题:

需求不清晰或错误,导致设计目标偏离客户的需求,从而引起功能或产品特征上的缺陷;

2、 编码错误:

程序逻辑问题,包括对程序逻辑路径或数据范围的边界考虑不够周全,漏掉某些边界条件,造成容量或边界错误。

3、 需求变更:

4、  关联系统/模块影响分析不足

为考到上下游系统的或内部模块间的相互关联及影响造成的缺陷;

5、 第三方工具引起的问题

6、 新技术不熟悉:

新技术的采用,可能涉及技术或系统兼容的问题,事先没有考虑到。

7、 设计错误:

系统结构非常复杂,而又无法设计成一个很好的层次结构或组件结构,结果导致意想不到的问题或系统维护、扩充上的困难;即使设计成良好的面向对象的系统,由于对象、类太多,很难完成对各种对象、类相互作用的组合测试,而隐藏着一些参数传递、方法调用、对象状态变化等方面问题;

8、 环境问题:

系统运行环境复杂,包括硬件环境及软件外部依赖环境,依赖接口不稳定等因素造成的缺陷;

1.6缺陷类型

  1. 1. 功能遗漏:

未按需求文档实现,功能缺失

  1. 2. 程序逻辑错误

需要进行逻辑分析代码修改,如循环条件、计算顺序错误、逻辑顺序错误等;

  1. 3. 程序校验错误
  2. 4. 界面错误

前端页面排版、显示等交互问题;

  1. 5. 兼容问题:

服务端与前端兼容问题、软件间

  1. 6. 用户体验问题/优化提升
  2. 7. 接口问题

模块接口间调用问题,如参数问题

  1. 8.性能问题

不满足系统可测量的属性值,如、执行时间,事务处理速率等缺陷;

  1. 9. 安全问题
  2. 10.环境问题

由于设计、编译、运行环境引起的问题

2BUG的生命周期

1、测试人员在测试中发现BUG需要将其添加记录到JIRA中,并制定给对应的开发/产品人员进行处理。

2、开发人员修改好BUG后需要在注释框中填写说明信息,并将BUG的状态设为“已修正”状态,同时开发人员如果认为有的缺陷没有必要修改、无法重现、延期修改等,可将其设置为对应的“被拒绝”、“重复的”、“信息不足”、“无法重现”、“延期修改”等状态。

3、开发人员处理完毕BUG后需要测试人员对BUG进行验证,验证通过后就把其状态设置为“已关闭”状态,若验证不通过则把状态设置为“重现开启”状态。

4、对被置为‘被拒绝’状态的BUG,测试人员与开发人员协商后同意关闭,则置为‘已关闭’;若测试人员不同意关闭,则把BUG状态置为“重新开启” ,然后开发人员继续修改;若不用再修改则置为‘已关闭’;若延期处理则置为‘延迟修改’。  

5、对被置为“信息不足”状态的BUG需要测试人员补全信息;然后重新开启让开发人员继续修复。

3BUG管理规范

合理的BUG流程管理有助于提高整个项目的效率与质量。BUG管理规范要求在BUG提交、BUG分配、BUG处理、BUG验证、BUG跟踪等环节都要进行规范。以下为各个环节的具体规范要求。

3.1BUG提交规范

BUG 描述的清楚与否,可以很好的帮助开发人员快速定位、解决问题,而且还可以提高测试人员基本测试技能。因此,建立标准的BUG描述规范是十分重要、也是十分必要的。

 首先清晰的BUG 描述可以帮助开发人员快速定位、解决问题。软件测试部门中员工的水 平各有不一,对于 bug 的认知、描述侧重面也会存在不同。因此,如同一个问题,由不同测试人员描述 bug,就有可能会存在描述不一致的问题。这就会造成让开发人员理解不清晰,从而延误解决问题的周期。

其次标准的BUG描述可以提供测试人员的基本测试技能。如有新入职员工,他可以先从BUG库中查找BUG了解公司产品的整个开发、 研制中产生的问题。 而标准清晰的BUG描述可方便快速的使其尽早、尽快的融入我测试部门。另外,对于BUG的追踪验证时, 由于是不同测试人员进行验证,所以规范的BUG描述,可以提高测试人员验证问题的效率。

你可能感兴趣的:(bug)