软件bug管理流程和规范

软件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日 软件BUG管理流程和规范 密级：机密

作者

杨林红 更新日期 2010-11-2 版本 D0.1 打印日期 2022-4-27

一、 软件错误的常用状态

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

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

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

再开启(Reopende): 修改验证未改，重新分配修改；

深圳市鼎智时代通讯技术有限公司版权所有（2005~2005）

第 2页(共4页)

软件BUG管理流程和规范 密级：机密

作者

杨林红 更新日期 2010-11-2 版本 D0.1 打印日期 2022-4-27

无效的(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可以在哪个版本上进行验证。

深圳市鼎智时代通讯技术有限公司版权所有（2005~2005）

第 3页(共4页)

软件BUG管理流程和规范 密级：机密

作者

杨林红 更新日期 2010-11-2 版本 D0.1 打印日期 2022-4-27

四、 软件BUG流程管理要点

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

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

2. 每次对BUG的处理都要保留处理信息，包括处理方法，处理意见，Bug状态。

3. 拒绝或延期BUG不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共

同决定。

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

测试步骤和方法，以及必要的测试LOG信息。

7. 软件项目经理应该加强对BUG的关注，对于没有及时得到处理、长时间没有解决问题

应该进行跟踪。

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

深圳市鼎智时代通讯技术有限公司版权所有（2005~2005）

第 4页(共4页)