软件bug管理流程和规范

深圳市鼎智时代通讯技术有限公司

版权所有（2010~2011）

拟 制： 杨林红 审 核： 测 试： 文档管理：

修订历史： 版本号 修订内容 D0.0 D0.1 新编制 补充开发部分 修订人 杨林红 卢方 修订日期 2010-11-4 2010-11-4 2010年11月4日 Xxxx年xx月xx日 Xxxx年xx月xx日 Xxxx年xx月xx日 精品

可编辑

一、 软件错误的常用状态

新问题(New)：测试中新报告的软件缺陷；

已分配 (Assigned)：被确认并分配给相关开发人员处理；

已解决(Resolved)：开发人员已完成修正，等待测试人员验证； 不处理(Wontfix):拒绝修改缺陷或搁置不改；

再开启(Reopende): 修改验证未改，重新分配修改； 无效的(Invalid):不是缺陷

已关闭(Closed)：错误已被修复；

精品

可编辑

二、 Bug管理的流程

1. 测试人员提交新的Bug入库，错误状态为New。

2. 测试组长验证错误，如果确认是错误，分配给相应的开发人员并抄送给软件项目经理，设置状态为Open。如果不是错误，则拒绝，设置为Invalid (无效)状态。

3. 开发人员查询状态为Open的Bug，把Bug置为Assigned状态，表明已经开始处理该问题

4. 对于无效BUG, 开发人员把状态置为Invalid。

5. 对于普通BUG, 开发人员修复BUG后，把状态置为Resolved。

6. 对于暂时不能解决的BUG, 状态保留为Assigned，并添加相关备注。

7. 对于不能修改或者建议不修改的问题，及时反馈给项目经理，经开会讨论决议后，才能置为暂时不修改Wontfix

测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。

三、 软件BUG规范

1. 软件BUG提交报告包括头信息、简述、操作步骤和注释。

a) 头信息包括：测试软件名称、版本号、严重程度、优先程度、测试平台、

缺陷或错误范围。要求填写完整、准确。 b) 简述是对缺陷或错误特征的简单描述，可以使用短语或短句，要求简练、

准确，并描述清楚正确的应该是怎么样的，现在有什么错误，以及出现

几率。

c) 操作步骤是描述该缺陷或错误出现的操作顺序，要求完整、简洁、准确。

每一个步骤尽量只记录一个操作。结束时写上出现频率。 d) 注释一般是对缺陷或错误的附加描述。

e) 对于描述不清楚的问题，可以抓张图片说明，对于非必现的问题，需要

添加log附件。

2. 每个软件问题报告只书写一个缺陷或错误

这样可以每次只处理一个确定的错误，定位明确，提高效率，也便于修复错误后方便的进行验证。

3. 开发人员解决BUG时，需要写明：

a) BUG的原因。 b) BUG的修改方法

c) BUG可以在哪个版本上进行验证。

四、 软件BUG流程管理要点

1. 为了保证BUG的正确性，需要有丰富测试经验的测试人员验证发现的BUG是否是真正的

精品

可编辑

BUG，书写的测试步骤是否准确，是否能重复。

精品

可编辑

2. 每次对BUG的处理都要保留处理信息，包括处理方法，处理意见，Bug状态。 3. 拒绝或延期BUG不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同

决定。

4. BUG修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭BUG。 5. 开发人员应该首先着手自己重现问题，减少对测试人员的依赖 6. 对于某些不能重复的错误，加强测试人员与程序员的交流，可以请测试人员补充详细的

测试步骤和方法，以及必要的测试LOG信息。 7. 软件项目经理应该加强对BUG的关注，对于没有及时得到处理、长时间没有解决问题应

该进行跟踪。

8. 普通的研发版本，应该带上自动记录LOG的功能。 9. 无法重现的BUG，需要跟踪三个版本以上才能关闭。

10. . 11.

12.

精品