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

密级 内部资料 软件BUG管理规范 (Version 1.0) XX科技有限公司 2015年1月  文档信息 文档名称 软件BUG管理规范 密级 内部资料 文档编号 发布版本 起草时间 2014-6 定稿时间 当前版本 1.0 起草人 姓名 部门 电话 电子邮件 审阅人 签发人 文档修改记录 序号 修改时间 修改人 主要修改 存档版本 1 2 3 4 5 6 7 8 9 10 软件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 其他注意事项 开发人员 把问题置为“已解决”就是把事情做完了—只有测试人员确认问题已解决并关闭了才算是真正解决了问题 测试是测试人员的事情—开发人员同样应该主动发现报告问题，并且有些测试只有开发人员才能做好 测试人员 把问题报告了，就是测试工作完成了—在程序员解决问题之后，还要确认问题是否解决了并最终关闭问题 问题关闭之后，就肯定没有