bug管理规范及流程审批稿

b u g管理规范及流程 YKK standardization office【 YKK5AB- YKK08- YKK2C- YKK18】
bug管理规范及流程
1、概述
本文档定义bug的整个生命周期，规范bug的解决方案及管理流程。

Bug在流转的过程中有章可循。

规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决；
2、关键角色及职责
?
3、Bug生命周期
4、Bug书写规范
BUG标题
1)以一个简短的句子描述某个模块存在的问题；或者某个操作导致了什么问
题；
2)描述问题时要简练、直接切入主题，但是要抓住要点；
3)偶现bug在主题前标注出现的次数；
4)有些模块功能比较多，可以在主题描述前标注上具体得操作；
示例：
【偶现3次】【账号切换】登录非本机手机号，切换回本机号码登录后，收不到消息
【偶现2次】添加载体库时程序停止运行
重现步骤
说明区域包括：步骤、预计结果、实际结果、测试环境、bug出现时间、截图、日志
1) 用数字编号，一步步的描述问题的重现步骤；
2) 不同的操作步骤产生不同的问题，需分别报bug；尽量做到一个bug汇报一个问题；
3) 偶现问题必须明确bug出现的时间、提供截图以及日志；
5、Bug解决方案
当天提交的新建状态bug，对应的开发人员需在2天内全部审核一遍，将bug分成以下3类：拒绝、进行中、延期、反馈（给产品）；
开发已修复的bug：将bug状态置为已解决；同时添加说明验证版本号、错误原因、解决办法；
示例：
验证版本：（1101表示在11月1号可以验证）
问题原因：未作条件判断
解决方法：进行合理边界判断
开发认为不是bug：将bug状态置为已拒绝；指派给bug提出者；同时注明拒绝理由；
示例：
参考XXX设计，测试人员理解错误；
bug缺乏必要的信息，无法重现：将bug状态置为已拒绝（无法重现）；指派给bug提出者；同时注明拒绝理由；
示例：
缺少必须日志；
开发已修复，测试验证通过的bug：将bug状态置为关闭，并注明通过版本号；
示例：
验证通过
开发已修复，测试验证不通过的bug：将bug状态置为打回（激活），并根据实际情况注明反馈理由；
示例：
版本验证此问题仍然存在；
步骤：XXX
出现时间：XXX
测试环境：XXX
截图、日志；
测试、开发有争议的bug：指派给对应产品经理，进行讨论确认修改方案；由产品经理编辑bug状态为激活/不予处理/转为需求，并注明理由。

示例：
测试认为ip地址设置错误，应该提示用户，而不应该程序出现停止运行；
无法修复的bug：将bug状态修改为公认(外部原因/不予解决)，并注明公认理由；
无法重现的bug：主要依赖日志分析问题原因，然后进行对应的修改；开发修改后，测试追溯3个版本、或者使用测试工具反复测试，如没有重现则先关闭；并注明关闭版本号；
示例：
暂未复现，先关闭；
需延期的bug：将bug状态修改为低，计划完成日期修改为计划解决bug的日期；并注明延期理由；
示例：
需求变更，改动量很大，影响版本发布时间；
产品确认需要修改的bug：将bug状态修改为打回，指派给对应的开发人员，并注明修改内容；
产品确认不需要修改的bug：将bug状态修改为已解决，并注明不需要修改原因；
不是本端的bug：由bug所在端（本端）人员给出分析说明，转给对应端和开发人员，并口头通知；
6、Bug跟踪类别
bug：测试人员判定为bug的问题；
优化：功能已实现，需要做性能优化的问题；
建议：测试对于产品的一些改进建议；
需求：需要产品重新梳理的需求问题；
7、Bug状态
新建：测试人员新提交的bug、优化或者建议的问题状态；
进行中：开发人员已确认是bug，需要修改的问题状态；
已解决：开发人员已修复的问题状态；
已关闭：测试验证，确定已解决的问题状态；
已拒绝：开发认为不是bug，拒绝给测试的问题状态；
反馈：反馈给产品确认的问题状态；
公认：确认是bug，但是无法解决的问题状态；
打回：测试验证已解决bug，仍然没有修复的问题状态；
?
8、Bug严重程度
致命：不能执行正常的功能操作，或者因产品原因导致系统死机，需马上修复的问题示例：
程序无法启动，或者登录；
程序崩溃、停止运行，系统死机，无法进行下一步的操作
严重：部分功能存在严重缺陷，尚可继续测试，不影响产品稳定性；
示例：
偶现的程序崩溃、停止运行
功能未实现
数据不同步
功能错误，无法进行后续操作
一般：次要功能或者界面存在的一些错误，不影响正常测试；
示例：
界面UI显示和效果图不一致；
提示语不正确；
错别字；
查询结果显示错误
建议：测试对于产品的一些改进建议；
9、Bug优先级
4低：对产品的影响比较小，在时间不允许的情况下可以暂时不修改；
3中：必须修改，不一定马上修改，需讨论确定在某个特定的里程碑前修改完；2高：必须在版本发布之前修改完；
1紧急：影响测试，需立即或者下一个版本修复；
10、其他注意事项
1) 开发人员没有关闭bug的权限，所有问题均需经过测试验证无误后才可关闭；
2) 开发、测试双方有争议的bug，必须经过产品的确认才可进行下一步的操作；
3) 测试需及时验证已修复bug；
4) 产品人员可以根据产品的阶段性需求重新分配bug解决的优先级；
5) 重新指派bug后，需要口头或者QQ告知对方；
6) bug的优先级划分比较重要；
11、禅道bug提交流程参考：
附件：
禅道bug管理规范
禅道系统bug严重程度（即bug等级）
1=致命bug，
2=严重bug，
3=一般bug，
4=建议。

致命bug：
不能完全满足应用要求导致应用闪退和应用停止运行
严重bug：
严重地影响应用需求或基本功能的实现，使应用不稳定、或破坏数据、或产生错误结果，或部分功能无法执行。

一般bug：
使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能
建议：
希望提出的建议进行修改，但不强制要求修改。

不会给发布的准确性或可用性带来任何严重影响。

Bug类型：
代码错误取1、2、3，默认值取3；
界面优化取3、4，默认值取4；
设计缺陷取1、2，设计缺陷默认取2。

BUG类型指派说明：
代码错误----程序问题---开发人员
界面优化----建议------产品经理
设计缺陷----需求-------产品经理。