BUG管理标准规范与作业流程.doc

BUG管理步骤和规范目 录1概述51.1编写目标51.2适用范围52关键角色及应负责任53BUG步骤图64活动描述65BUG书写规范85.1测试人员BUG提交85.1.1专题85.1.2步骤85.1.3实际结果85.1.4预期结果85.1.5备注95.2开发人员处理BUG96BUG严重等级106.1致命106.2严重106.3通常116.4优化117BUG优先级127.1紧急127.2高127.3中127.4低128BUG处理方案128.1设计如此128.2反复bug128.3已处理128.4无法重现128.5延期处理128.6新增/变更需求129BUG状态129.1激活129.2已处理139.3关闭1310其它要求1311相关文件1312附件13 1 概述1.1 编写目标本文档定义bug整个生命周期，规范bug管理步骤。Bug在流转过程中有章可循。规范bug严重等级和bug处理优先级，使开发人员和测试人员能依据此文档正确判定bug严重程度并加以处理。1.2 适用范围本文档适用测试人员、开发人员。2 关键角色及应负责任序号角色应负责任01测试工程师1) 提交bug，用bug等级反应bug严重程度，2) 验证bug是否已被处理02测试责任人1) 审核测试人员提交bug ；2) 定位测试工程师提交bug优先级3) 定时对bug库进行分析，描绘出曲线图等，汇报现实状况、估计趋势，在测试总结汇报中给出意见。4) 分析项目测试过程中存在风险03开发工程师1) 分析bug，写出问题原因，修改bug，2) 实施bug优先标准，严重程度5个以上，停止新功效开发。04开发责任人1) 天天对bug进行分配，标注处理意见2) 定时对bug库分析，对bug多模块，进行代码走查。3) 分析bug修复进度，对项目标质量、进行风险评定。4) 跟踪被需求确定可延期处理bug05系统工程师1) 解释需求，给出处理意见，2) 将bug库中提议整理成为需求文档3) 当开发和测试存在意见分歧时，进行需求确定。3 Bug步骤图Bug状态：激活，已修复，已关闭处理方案：设计如此，反复Bug，已处理，无法重现，延期处理，新增/变更需求4 活动描述序号活动名称参与角色活动描述输入、输出信息处理时限01提交bug测试工程师具体书写Bug，指派给对应测试责任人输入信息：无输出信息：在禅道上提交bug-02Bug确定和分配测试责任人依据判定是否是Bug，给出意见输入信息：测试人员提交bug，测试用例，软件需求输出信息：确定bug优先级，指派给开发责任人。0.5个工作日03分析确定并指派Bug开发责任人依据判定是否是Bug，给出意见输入信息：测试责任人指派bug，软件需求，程序源代码等输出信息：分析Bug，指派给对应开发工程师，不是bug或应该需求变更时，指派给相关人员0.5个工作日04修复Bug开发工程师修改Bug，给出处理方案，修复再次激活bug。输入信息：开发责任人确定指派bug，软件需求输出信息：Bug处理方案，产生bug原因，指派给对应测试工程师0.5个工作日05验证Bug测试工程师验证Bug，给出验证结果输入信息：开发工程师指派已修复Bug，需求确定转为变更或新增需求bug输出信息：假如Bug未修改，激活并指派给对应开发工程师；假如Bug已修改或系统工程师确定转为需求bug，关闭bug，0.5个工作日06确定bug延期测试主管分析bug，确定bug是否能延期处理输入信息：开发或系统工程师指派延期bug输出信息：确定是否能延期处理，对应延期bug在开发修复版本进行激活视实际情况而定07Bug仲裁系统工程师依据判定是否是Bug，给出处理意见输入信息：测试主管指派延期bug或需要系统工程师确定bug，开发主管指派新增/变更需求bug。输出信息：给出明确处理结果，属于新增/变更需求bug需要在需求文档中统计相关需求。0.5个工作日5 BUG书写规范5.1 测试人员BUG提交5.1.1 专题用一个简短句子描述问题，不要写成一大段以进入问题模块路径开头，方便项目经理分配任务，和开发人员定位问题描述问题时要具体、简练、抓住关键点，直接切入正题，不要罗嗦不要夸大或缩小问题严重程度5.1.2 步骤用数字编号，一步步描述重现问题全部操作步骤提供明确再现问题步骤，避免问题被以“不能重现”关掉设置区域需要具体描述，如：各设置项值为默认、*值更改为“”，其它设置项值为默认；尽可能用动词作为开头，描述每个步骤。如：打开、点击、设置、选择、插入、双击等不要在一个步骤中描述不相关多个操作。假如是相关一系列操作，能够使用“”来连接描述。根据你写步骤去实施，看问题能否重现不要在步骤中使用含糊不清缩写词描述5.1.3 实际结果实际只描述一个问题一样操作步骤产生多个现象，要在一个缺点汇报中加以描述不一样操作步骤产生不一样问题，分别报bug假如有截图，请列出所附图片信息5.1.4 预期结果不要加入实际结果描述信息描述要清楚，不要使用含糊不清缩写词描述假如有截图，请列出所附图片信息5.1.5 备注避免写成大段落，要写得简单、易读问题特征出现问题后处理方法对终端用户影响情况假如有必需，列出产生问题配置环境5.2 开发人员处理BUG1.BUG原因。2.BUG修改方法3.BUG能够在哪个版本上进行验证。4.测试人员验证bug时，需要写明：验证了什么，在什么版本验证，是否经过，假如不经过需写明原因。假如在验证目前bug时有新现象产生阻碍了验证此bug，则该bug不能关闭，写明没有验证原因，并为新现象提bug。举例1：现象：修改后：6 BUG严重等级6.1 致命不能实施正常工作功效或关键功效，因软件原因造成系统死机等，须立即修正致命错误。通常有以下情况：1.内存泄漏2.因为实施程序引发数据库发生死锁3.用户数据丢失或破坏4.系统瓦解5.死机6.程序无法开启或异常退出7.因错误操作造成程序中止8.功效设计和需求严重不符6.2 严重影响系统功效或操作，应用模块错误使业务中止无法进行后续操作，关键功效存在严重缺点，但不会影响到系统稳定性。具体基础上可分为：1.功效未实现2.功效错误3.业务中止，无法进行后续操作4.数据库表、业务规则、缺省值未加完整性等约束条件5.数据库表结构错误，字段长度不够，缺乏表、存放6.语音或数据通讯错误7.数值计算错误8.前台提醒存放报错9.系统所提供功效或服务受显著影响6.3 通常影响系统正常运行缺点，关键功效出现错误，影响到产品使用。比如：次要功效不能正常实现； 查询错误，数据错误显示；简单输入限制未放在前台进行控制具体基础上可分为：1.操作界面错误（包含数据窗口内列名定义、含义是否一致）2.报表打印内容、格式错误、取值错误3.页面查询结果错误，自动读值项取值错误4.边界条件下错误5.提醒信息错误（包含未给出信息、信息提醒错误等）6.简单输入限制未放在前台进行控制7.长时间操作无进度提醒8.光标跳转设置不好，鼠标（光标）定位错误6.4 优化使操作者不合理或不方便或操作碰到麻烦，但它不影响实施工作功效或关键功效，次要功效，对产品使用影响不大。比如：程序在部分显示上不美观，不符适用户习惯，或是部分文字错误。具体基础上可分为：1.界面格式等不规范2.辅助说明描述不清楚3.操作时未给用户提醒4.可输入区域和只读区域没有显著区分标志5.部分不影响产品了解错别字6.文字排列不整齐等部分小问题7.提醒窗口文字未采取行业术语7 BUG优先级7.1 紧急阻止和此亲密相关功效深入测试,需要立即修复7.2 高必需修改，发版前必需修正7.3 中必需修改，不一定立即修改，但需确定在某个特定里程碑结束前须修正7.4 低对系统影响较小，假如时间许可应该修改8 BUG处理方案8.1 设计如此设计如此，测试人员了解错误，无需改动，即无效bug8.2 反复bug以前已经有一样bug。8.3 已处理Bug已经被修更正确，待测试进行验证8.4 无法重现依据测试写重现步骤，无法重现bug。8.5 延期处理确实是bug，但现在不处理，以后处理。8.6 新增/变更需求分析确实是存在问题，但需求没有描述清楚，应指派给需求确定，进行需求新增或变更。9 BUG状态9.1 激活1.新创建bug；2.已关闭bug重新出现需要再次激活 ；3.已处理但验证未经过bug。9.2 已处理开发已经修改完成bug。9.3 关闭已验证经过bug或系统工程师确定转为需求bug。10 其它要求Bug描述和Bug流向严格遵守步骤规范。11 相关文件文件编号文件名称12 附件文件编号文件名称保留时间保管部门附件