BUG编写标准和管理办法

1、目的

BUG的编写标准的规范，主要为是为了规范测试人员提交BUG的格式；可以使开发人员快速根据BUG进行定位，根据BUG现象迅速定位问题的本质，同时也方便测试人员对BUG进行重现，在回归版本发布后能够根据BUG描述有效的进行回归测试。

2、范围

此文档适合测试人员内部使用，适合于任何产品和项目。

3、BUG编写标准及方法

3.1、产品名称：每个要测试的软件项目都有唯一的名称，在bug管理工具

中添加测试的项目，在录入bug时先自行选择所测试的项目。

3.2、缺陷ID:bug的唯一标识，由bug管理工具自动生成。

3.3、测试版本：报告错误时，一定要正确填写产生错误的软件版本号，录入

bug时可选择相应的版本号。

3.4、基本信息：bug的类型、严重程度以及处理的优先级；bug所属模块；

测试者名称；测试时间；指派的开发人员；这些项都在bug录入时进行选择。

3.5、缺陷标题：简明扼要地对bug进行概要描述。 3.6、bug详细描述：

A、环境：缺陷应该描述缺陷测试的基本环境，因为在某种特定的环境下，才能重现缺陷，所以环境对于一个BUG来说非常重要。软件环境：操作系统和其他必要的软件程序（比如：操作系统：Windows XP Professional SP3 32 位；浏览器：Microsoft Internet Explorer 8.0）；硬件环境：测试计算机和其他设备的配置信息（比如：处理器（CPU:英特尔酷睿；速度：3.20GHz）；内存：3.47GB；屏幕分辨率：1024 x 768；可用硬盘空间：100G）。

B、步骤：测试人员需要详细描述BUG产生的步骤，是因为什么样的操作步骤才会产生对应的操作步骤；如果不按照测试人员描述的操作步骤，是不能

重现所产生的BUG；这样开发人员就无法对这个BUG进行重新，认为这不是一个有效缺陷；因此必须要描述BUG的操作步骤。

C、实际结果：描述实际测试后得到的结果。 D、预期结果：描述满足设计要求的结果。

E、文字注释与附图：测试者的建议或者对问题的补充说明（比如错误出现的频率等）与必要的附图，附加的现象图便于确认错误的表现形式和错误的位置，同时也可以作为缺陷的证据。

4、缺陷格式及范例

5、缺陷生命周期

从一个软件的BUG产生开始到结束，总共存在七种状态：新建，拒绝，暂不处理，打开，已修复，重新打开，关闭。见下图：

➢ ➢

【新建】状态：任何一个人员新增一个软件缺陷，软件自动设置为：新建； 【暂不处理】状态：项目经理或开发小组负责人认为BUG实现比较难；或者短时间实现不了；或者当前版本排不了计划等原因，则需要将BUG状态设置为：暂不处理；

➢

【拒绝】状态：项目经理或者开发小组负责人认为当前BUG不是一个有效BUG，可能是需求的理解偏差；或者当前BUG无法重现等，则需要将BUG状态设置为：拒绝；

➢

【打开】状态：应用于BUG确认，项目经理或者开发小组负责人针对新建的BUG，对其进行分配对应的开发人员，设置缺陷处理的优先级，然后再将BUG状态设置为：打开；

➢ ➢

【已修复】状态：当BUG已经修复之后，需要将BUG状态设置为：已修复； 【重新打开】状态：已修复的BUG，经过回归测试验证之后，发现此BUG问题仍然存在，则需要将此BUG状态设置为：重新打开；

➢

【关闭】状态：针对已修复的BUG，经过回归测试验证之后，发现BUG问题已解决，则需要将此BUG状态设置为：关闭。

6、BUG状态转换

针对产品不同的使用角色，状态的转变是不同的，且状态变化是单向的，详细见下图中的说明：

6.1.项目经理角色：

针对BUG的状态转换，只能从《新建》到《打开》，《新建》到《拒绝》，《新建》到《暂不处理》；《重新打开》到《拒绝》；《重新打开》到《暂不处理》；且

每次更换BUG状态后需要进行注视说明；项目经理每天需要对《新建》状态的BUG进行分配，然后设置为《打开》状态。

6.2.开发人员角色：

➢

【打开—>已修复】：开发人员登录到缺陷管理平台，找到分配给自己的且缺陷状态为《打开》状态的缺陷，修复完成之后，设置缺陷状态为已修正且加上备注；

➢

【打开—>暂不处理】：针对测试人员的BUG，经过对应的开发人员分析和验证后，发现难以修改或修改时间较长，在不影响整体功能的情况下可暂不进行处理，但是一定要进行注释；当然测试人员也有权重新开发，如果争议不断可以申请仲裁；

➢

【重新开放—>已修复】：根据测试人员对BUG进行重新开放，开发人员如果确认此BUG确实存在，需要进行修正，将BUG状态设置为《已修正》；如果对测试人员将BUG重新开放有异议，可以申请仲裁将问题关闭；

➢

【暂不处理—>已修复】：针对暂不处理的BUG，开发人员在有时间可修复的并修复完成后，可设置缺陷状态为已修正且加上备注。

6.3.测试人员角色：

➢

【新建】：测试人员按照规范记录BUG，BUG递交之后状态默认为新建；BUG一定要包含详细的步骤及说明，需要包含贴图等附加更多的信息帮助开发人员分析BUG，从而快速定位修复BUG；

➢

【已修复—>关闭】：针对开发人员已修正的问题，在发布回归版本之后，对BUG进行回归验证测试，若问题已解决，则对问题进行关闭；

➢

【已修复—>重新打开】：针对开发人员已修正的问题，在发布回归版本之后，对BUG进行回归验证测试，若问题已解决，则对问题进行重新打开；

➢

【拒绝—>关闭】：针对开发人员拒绝的问题，通过分析和讨论之后不是一个有效BUG，测试人将对BUG进行关闭处理；

➢

【拒绝—>重新打开】：针对开发人员已修正的问题，在发布回归版本之后，对BUG进行回归验证测试，若问题未解决，则对问题进行重新打开；

➢

【关闭—>重新打开】：针对开发人员已修正且测试人员确认无误关闭的问题，如在进行回归其他问题时，发现此问题再次出现，可对问题进行重新打开。

7、附件

《缺陷等级划分标准》