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描述，可以提高测试人员验证问题的效率。