敏捷开发bug管理流程

1. 概述
   1. 编写目的

对由本组负责处理的BUG进行管理，通过对BUG的提交、跟踪解释、验证流程进行规范，提高BUG处理效率。

1. 1. 适用范围

测试团队以及其他团队进行的BUG提交、跟进与解释、验证工作。

1. BUG管理流程

   

    

 

1. BUG提交要求
   1. 要求

提交BUG要求分类准确、描述简洁、步骤清晰、有实例、复杂问题有据可查（日志或截图）。各部门进行审核，以开发人员的角度来审查提交的BUG，确认测试人员已将BUG描述清楚。具体要求为：

• 一个禅道问题只针对一个Bug。
• 所有BUG必须统一录入禅道系统，不可以口头沟通私下解决。
• 提交BUG前需进行充分测试，尽量排除数据源、网络环境和配置等外部因素，确定提交的BUG是由程序导致的。
• 不允许仅仅用抽象、模糊和主观色彩的词语描述BUG，比如“有错误”、“不太好”、“好像、”“似乎”、“大概之类”。
• 提交人需尽量简洁清晰地描述BUG，描述时应尽可能简洁明了，只解释事实、演示和描述BUG相关的必要细节，避免无关信息。提交人可以写上自己对问题原因的主观分析，但不能和客观描述混杂在一起表述。
• 提交人在提交BUG前，应再次仔细检查报告中是否有可能产生误解的地方。尽量避免使用模糊的、可能产生歧义的主观性词语。
  1. 禅道填写说明

• *产品模块和所属项目：必须填写正确。
• *影响版本：需填写
• *当前指派：指派给对应的研发人员，如果不知道对应的研发人员可以指定给对应的研发负责人，让其分派给具体研发人员。
• *BUG标题：在某种前提下+简述操作过程+最后的结果。如：对会员数据，进行查询，结果无数据显示且无任何提示。
• *重现步骤：【步骤】【结果】【期望】三者写清楚。
• *相关需求：暂时不做要求。
• *相关任务：暂时不做要求。
• *严重程度：BUG级别分为1-4级；

严重性	Bug等级说明	常见现象
1级	无法正常运行，因软件原因导致系统死机、数据丢失等，该级别需要程序员立即修改；	程序报错无法进行其他业务的运行，引起无响应或者服务器直接宕机等；
		功能设计与需求严重不符；
		数据库发生死锁、数据丢失、数据通讯错误等；
2级	主要功能丧失，严重影响系统要求或功能的实现，该级别需要程序员尽快修改；	程序报错但能继续运行；
		无法完成功能的正常操作；
		数据错误；
		不符合需求定义范围；
		性能与需求不一致；
3级	影响系统正常运行，主要功能出现错误，该级别需要程序员修改；	非常规操作出现错误；
		删除操作未给出提示；
		常规操作未给提示；
		可编辑区域和只读区域没有区分标志；
		用户体验较差，操作不方便，但不影响功能实现；
		数据输入没有边界值限定或不合理；
4级	操作不合理或者不方便，建议类错误，不影响执行工作功能，对软件的改进意见或建议，该级别问题程序员可时间充足时再修改；	易用性问题（未给出提示信息或提示信息不统一）；
		缺少注释或注释表达不清晰；
		查询等操作响应时间过长；
		建议类问题；
		界面设计不规范，如UI不统一、文字排列不整齐、出现错别字、字体不一致等问题；

• 附件：对于不易通过文字描述的BUG，提交人应将界面截图作为附件上传；对于崩溃、宕机现象，必须将程序日志作为附件上传。
• 其他内容：都为选填。

1. 跟进与解释

在BUG“新建”到“已关闭”期间，尽量使用禅道系统的注释功能进行沟通。

当BUG被以“不必改”、“无法重现”理由关闭，测试人员应仔细阅读研发人员的注释内容，再次检查报告中是否有遗漏和歧义的地方，确认无误后再进行处理。

1. BUG验证
   1. 响应速度要求

在问题被研发人员设置为“已解决”后，测试人员应在新版本形成后一周内完成验证或以注释形式说明情况。

• 1. 验证步骤
• 如果该BUG已解决，则在禅道中关闭问题；
• 如果该BUG仍然出现，则在禅道中反馈问题并说明情况；
• 如果验证过程中发现了新BUG，则在禅道系统中新建问题进行跟踪。