Bug定义规范

BUG定义规范Revision History

1.目的

对BUG概念、BUG提交和验证、BUG状态、BUG严重程度等内容进行定义和规范，以便进一步指导我们的测试工作

2.概念

BUG:软件中存在的瑕疵，可能会导致软件失效。简单的说就是软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷

3.BUG管理工具

以Quality Center 9.0为提交、跟踪等工具

4.BUG提交和验证要求

以QC中的字段为准

提交时必选字段有：摘要，跟踪类型，检测者，检查日期，计划关闭版本，可重现，分

派给，严重程度，状态，描述

验证后，需要修改字段：关闭于版本，关闭日期，状态BUG描述模板如下：

[问题概要]:

[重现步骤]:

步骤1.

步骤2.

[隔离分析]:

[期望结果]:

[重现概率]:

[Test Case No.]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称）

[Test Case]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称）

QC中优先级和严重程度的区别：优先级由软件开发人员填写，严重程度由测试人员填写

计划关闭版本定义：

有2重含义：1.由测试人员填写当前发现bug的版本号；2.开发人员必须在此版本上修改

5.BUG验证

开发人员必须提供修改此bug会涉及到的功能点列表，并将此信息填写到bug描述中。

测试人员除验证此bug外，还需要将开发列出的功能点逐一验证，同时写入自己考虑到的功能点验证情况

来自需求和测试自己提交的问题，测试人员都需要验证，并填写测试结果，其中来自自己的bug，若验证通过，则修改状态为“关闭”；来自需求人员的bug，则修改状态为“验证完毕”，由需求人员来关闭（适用于胜算组）。

6.BUG状态流程

在正在BUG生命周期中，可能会经历很多状态，如：新建、提交验证、已关闭、重新打开、已挂起、重复提交等。

新建：新发现的问题

提交验证：开发修改bug后，会将状态变为提交验证，让测试工程师来执行验证操作已关闭：测试工程师经过验证后，发现此问题已经被修复，则修改状态为已关闭

重新打开：测试工程师经过验证后，发现此问题未被完全修复，则修改状态为重新打开已挂起：暂时不作修改或无法修改的bug

重复提交：开发工程师发现此bug已经有人提交过，处于重复性bug，则修改状态为重复提交

验证完毕：针对来自需求的bug，需要测试人员验证，若通过，则修改其状态为验证完毕。由需求人员来关闭。

已关闭

重复提交已挂起

7.BUG严重程度

根据QC中的定义，bug共分为5个级别：低，中，高，非常高，紧急

（1）低级别

主要表现为易用性和建议性问题

辅助说明描述不清楚

操作时未给用户提示

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

个别不影响产品理解的错别字

文字排列不整齐等一些小问题等

（2）中级别

主要表现为界面和性能缺陷

操作界面错误（包括数据窗口内列名定义、含义是否一致）

边界条件下错误

提示信息错误（包括未给出信息、信息提示错误等）

系统未优化（性能问题）等

（3）高级别

主要表现为影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性

功能未实现

功能错误

轻微的数值计算错误

系统所提供的功能或服务受明显的影响等

（4）非常高

主要表现为系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定

内存泄漏

用户数据丢失或破坏

系统崩溃/死机/冻结

模块无法启动或异常退出

严重的数值计算错误

功能设计与需求严重不符

其它导致无法测试的错误

（5）紧急

系统出现死机/崩溃，导致不能正常执行测试工作