BUG管理规范与流程.doc

BUG管理流程与规目录1 概述 编写目的 适用围 52 关键角色及应负责任 53 BUG流程图 64 活动描述 65 BUG书写规 测试人员BUG提交 主题 步骤 实际结果 预期结果 备注 开发人员解决BUG 96 BUG严重等级 致命 严重 一般 优化 117 BUG优先级 紧急 高 中 低 128 BUG解决方案 设计如此 重复bug 已解决 无法重现 延期处理 新增/变更需求 129 BUG状态 激活 已解决 关闭 1310 其他要求 1311 相关文件 1312 附件 13概述编写目的本文档定义bug的整个生命周期,规bug的管理流程。Bug在流转的过程中有章可循。规bug严重等级与bug解决优先级,使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决。适用围本文档适用测试人员、开发人员。关键角色及应负责任序号角色应负责任01测试工程师提交bug,用bug级别反映bug的严重程度,验证bug是否已被解决02测试负责人审核测试人员提交的bug;定位测试工程师提交的bug优先级定期对bug库进行分析,描绘出曲线图等,报告现状、预测趋势,在测试总结报告中给出意见。分析项目测试过程中存在的风险03开发工程师分析bug,写出问题原因,修改bug,实行bug优先原则,严重程度5个以上的,停止新功能的开发。04开发负责人每天对bug进行分配,标注处理意见定期对bug库分析,对bug多的模块,进行代码走查。分析bug修复进度,对项目的质量、进行风险评估。跟踪被需求确认可延期处理的bug05系统工程师解释需求,给出处理意见,将bug库中的建议整理成为需求文档当开发和测试存在意见分歧时,进行需求确认。Bug流程图Bug状态:激活,已修复,已关闭解决方案:设计如此,重复Bug,已解决,无法重现,延期处理,新增/变更需求活动描述序号活动名称参与角色活动描述输入、输出信息处理时限01提交bug测试工程师详细书写Bug,指派给对应的测试负责人输入信息:无输出信息:在禅道上提交bug----02Bug确认与分配测试负责人根据<<软件需求>>判定是否是Bug,给出意见输入信息:测试人员提交的bug,测试用例,软件需求输出信息:确定bug优先级,指派给开发负责人。<<软件需求>>判定是否是Bug,给出意见输入信息:,软件需求,程序源代码等输出信息:分析Bug,指派给对应的开发工程师,不是bug或应该需求变更时,指派给相关人员04修复Bug开发工程师修改Bug,给出解决方案,修复再次激活的bug。输入信息:开发负责人确认指派的bug,软件需求输出信息:Bug的解决方案,产生bug的原因,,给出验证结果输入信息:开发工程师指派的已修复的Bug,需求确认转为变更或新增需求的bug输出信息:如果Bug未修改,激活并指派给对应的开发工程师;如果Bug已修改或系统工程师确认转为需求的bug,关闭bug,,确认bug是否能延期处理输入信息:开发或系统工程师指派的延期bug输出信息:确认是否能延期处理,对应延期的bug在开发修复的版本进行激活视实际情况而定07Bug仲裁系统工程师根据<<软件需求>>判定是否是Bug,给出处理意见输入信息:测试主管指派的延期bug或需要系统工程师确认的bug,开发主管指派的新增/变更需求的bug。:给出明确处理结果,属于新增/变更需求的bug需要在需求文档中记录相关需求。BUG书写规测试人员BUG提交主题•    用一个简短的句子描述问题,不要写成一大段•    以进入问题模块路径开头,方便项目经理分派任务,以及开发人员定位问题•    描述问题时要详细、简练、抓住要点,直接切入正题,不要罗嗦•    不要夸大或缩小问题的严重程度步骤•    用数字编号,一步步的描述重现问题的所有操作步骤•    提供明确的再现问题的步骤,避免问题被以“不能重现”关掉•    设置区域需要详细描述,如:各设置项值为默认、**值更改为“”,其他设置项值为默认;•    尽量用动词作为开头,描述每个步骤。如:打开、点击、设置、选择、插入、双击等•    不要在一个步骤中描述不相关的多个操作。如果是相关的一系列