bug管理标准规范及作业流程.docx

bug管理规范及步骤1、概述本文档定义bug整个生命周期，规范bug处理方案及管理步骤。Bug在流转过程中有章可循。规范bug严重等级和bug处理优先级，使开发人员和测试人员能依据此文档正确判定bug严重程度并加以处理；2、关键角色及职责角色职责测试工程师1. 依据规范提交bug；2. 立即验证bug是否已处理；3. 立即关注开发拒绝bug，和相关人员沟通讨论处理方法；测试经理1. 审核测试工程师提交bug；2. 定时review bug，汇报现实状况，并给出处理意见；开发工程师1. 以优先级为依据分析处理bug开发主管1. 定时 review bug，对bug多模块加强code review和单元测试；2. 分析bug处理进度，对产品质量及进度进行风险评定；产品1、当开发和测试存在意见分歧时，进行需求确定2、从产品角度划分bug修改优先级；3、Bug生命周期4、Bug书写规范4.1BUG标题1) 以一个简短句子描述某个模块存在问题；或某个操作造成了什么问题；2) 描述问题时要简练、直接切入专题，不过要抓住关键点；3) 偶现bug在专题前标注出现次数；4) 有些模块功效比较多，能够在专题描述前标注上具体得操作；示例：【偶现3次】【账号切换】登录非本机手机号，切换回本机号码登录后，收不到消息【偶现2次】添加载体库时程序停止运行4.2重现步骤说明区域包含：步骤、估计结果、实际结果、测试环境、bug出现时间、截图、日志1) 用数字编号，一步步描述问题重现步骤；2) 不一样操作步骤产生不一样问题，需分别报bug；尽可能做到一个bug汇报一个问题；3) 偶现问题必需明确bug出现时间、提供截图和日志；5、Bug处理方案当日提交新建状态bug，对应开发人员需在2天内全部审核一遍，将bug分成以下3类：拒绝、进行中、延期、反馈（给产品）；开发已修复bug：将bug状态置为已处理；同时添加说明验证版本号、错误原因、处理措施；示例：验证版本：V1.0.1.1101（1101表示在11月1号能够验证）问题原因：未作条件判定处理方法：进行合理边界判定开发认为不是bug：将bug状态置为已拒绝；指派给bug提出者；同时注明拒绝理由；示例：参考XXX设计，测试人员了解错误；bug缺乏必需信息，无法重现：将bug状态置为已拒绝（无法重现）；指派给bug提出者；同时注明拒绝理由；示例：缺乏必需日志；开发已修复，测试验证经过bug：将bug状态置为关闭，并注明经过版本号；示例：V1.0.1.1103验证经过开发已修复，测试验证不经过bug：将bug状态置为打回（激活），并依据实际情况注明反馈理由；示例： V1.0.1.1103版本验证此问题仍然存在； 步骤：XXX 出现时间：XXX 测试环境：XXX 截图、日志；测试、开发有争议bug：指派给对应产品经理，进行讨论确定修改方案；由产品经理编辑bug状态为激活/不予处理/转为需求，并注明理由。示例： 测试认为ip地址设置错误，应该提醒用户，而不应该程序出现停止运行；无法修复bug：将bug状态修改为公认(外部原因/不予处理)，并注明公认理由；无法重现bug：关键依靠日志分析问题原因，然后进行对应修改；开发修改后，测试追溯3个版本、或使用测试工具反复测试，如没有重现则先关闭；并注明关闭版本号；示例： V1.0.1.1103暂未复现，先关闭；需延期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管理规范V1.0禅道系统bug严重程度（即bug等级）1=致命bug，2=严重bug，3=通常bug，4=提议。致命bug： 不能完全满足应用要求造成应用闪退和应用停止运行严重bug： 严重地影响应用需求或基础功效实现，使应用不稳定、或破坏数据、或产生错误结果，或部分功效无法实施。通常bug： 使操作者不方便或碰到麻烦，但它不影响实施工作功效或关键功效提议：期望提出提议进行修改，但不强制要求修改。不会给公布正确性或可用性带来任何严重影响。Bug类型：代码错误取1、2、3，默认值取3；界面优化取3、4，默认值取4；设计缺点取1、2，设计缺点默认取2。BUG类型指派说明：代码错误-程序问题-开发人员界面优化-提议-产品经理设计缺点-需求-产品经理