研发规范-软件BUG管理规范

软件BUG管理规范

(Version 1.0)

XX科技有限公司

2015年1月

软件BUG管理规范

1 目的 (4)

2 适用范围 (4)

3 软件BUG管理规范 (4)

3.1 BUG管理工具 (4)

3.2 BUG管理的主要角色 (4)

3.3 BUG状态 (4)

3.4 BUG严重等级 (4)

3.5 BUG处理流程 (5)

3.6 报告问题时要注意的事项 (5)

3.7 其他注意事项 (5)

1 目的

本规范是对研发中心软件BUG管理的一份指导性文件，保证产品中的BUG能够得到及时的发现和解决，并且完整的记录和存档解决BUG的过程细节。

2 适用范围

适用于研发中心相关项目和产品所有软件BUG的管理。

3 软件BUG管理规范

3.1 BUG管理工具

现阶段使用MANTIS进行BUG汇报和跟踪管理。

3.2 BUG管理的主要角色

●项目经理

主要职责：确认问题，分派任务，协调任务，重新打开问题

●开发人员

主要职责：修复问题

●测试人员（报告人员）

主要职责：报告问题，测试并确认问题得到解决

3.3 BUG状态

●新建：测试或报告人员报告一个新的BUG

●已分派：问题由管理人员或项目经理分派给具体的开发人员

●认可：问题分派到开发之后，开发告知问题已收到

●已确认：开发确认这是个问题（BUG）

●反馈：问题分派到开发之后，开发确认这不是个问题（BUG），或者测试认为这个问题没有

得到解决

●已解决：负责问题的开发已修复这个问题

●已关闭：测试人员确认问题已得到解决并且关闭问题

3.4 BUG严重等级

3.5 BUG处理流程

1.测试人员添加BUG到MANTIS系统，初始状态为‘新建’；或者分派给项目经理或已知问题相关开发人员，状态自动会置为‘已分派’状态

2.项目经理把状态为‘新建’的问题置为‘已分派’状态，通知问题相关开发人员修改

3.开发人员发现自己负责的BUG，状态置为‘认可’，表示已收到问题

4.开发人员确认问题存在，状态置为‘已确认’

5.开发人员对问题有疑问进行反馈时，状态置为‘反馈’

6.开发人员解决问题后，状态置为‘已解决’，根据实际处理的结果选择处理状况

7.测试人员看到‘已解决’状态的BUG会进行验收测试，通过后就把状态置为‘已关闭’状态;若验收不通过则状态置为“反馈”。

3.6 报告问题时要注意的事项

●每个软件问题报告只书写一个缺陷或错误：这样可以每次只处理一个确定的错误，定位明

确，提高效率，也便于修复错误后方便的进行验证

●对错误的描述要做到简洁、准确，完整，揭示错误实质

●明确指明错误类型和严重程度：根据错误的现象，总结错误的类型和严重程度，例如，是

功能错误？还是界面规范错误？该错误是属于特别严重的错误还是一般错误？是否影响软件的后续开发和发布？

●每一个步骤尽量只记录一个操作。简洁、条理井然，容易重复操作步骤，以便确认、修复、

验证该错误。

●复现的操作步骤要完整，准确，简短。保证快速准确的重复错误，“完整”即没有缺漏，“准

确”即步骤正确，“简短”即没有多余的步骤。

●附加必要的错误特征图像：为了直观的观察缺陷或者错误现象，通常需要附加错误出现的

界面，做为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或错误本质，可以捕捉缺陷或错误产生时的全屏幕，活动窗口和局部区域。

3.7 其他注意事项

●开发人员

⏹把问题置为“已解决”就是把事情做完了—只有测试人员确认问题已解决并关闭了才

算是真正解决了问题

⏹测试是测试人员的事情—开发人员同样应该主动发现报告问题，并且有些测试只有开

发人员才能做好

●测试人员

⏹把问题报告了，就是测试工作完成了—在程序员解决问题之后，还要确认问题是否解

决了并最终关闭问题

⏹问题关闭之后，就肯定没有问题了—定期要进行回归测试，即把已经测试关闭之后的

问题重新进行测试，因为后面问题的修改可能会影响到前面的问题，原来正确的地方

有可能错了