BUG管理规范与流程.docx

1、BUG管理规范与流程BUG管理流程与规范 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库进行分析，描绘出曲线图等，报告现状、预测趋势，在测试总结报告

2、中给出意见。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，已解决，无法重现

3、，延期处理，新增/变更需求4 活动描述序号活动名称参与角色活动描述输入、输出信息处理时限01提交bug测试工程师详细书写Bug，指派给对应的测试负责人输入信息：无输出信息：在禅道上提交bug-02Bug确认与分配测试负责人根据判定是否是Bug，给出意见输入信息：测试人员提交的bug，测试用例，软件需求输出信息：确定bug优先级，指派给开发负责人。0.5个工作日03分析确认并指派Bug开发负责人根据判定是否是Bug，给出意见输入信息：测试负责人指派的bug，软件需求，程序源代码等输出信息：分析Bug，指派给对应的开发工程师，不是bug或应该需求变更时，指派给相关人员0.5个工作日04修复Bug开

4、发工程师修改Bug，给出解决方案，修复再次激活的bug。输入信息：开发负责人确认指派的bug，软件需求输出信息：Bug的解决方案，产生bug的原因，指派给对应的测试工程师0.5个工作日05验证Bug测试工程师验证Bug，给出验证结果输入信息：开发工程师指派的已修复的Bug，需求确认转为变更或新增需求的bug输出信息：如果Bug未修改，激活并指派给对应的开发工程师；如果Bug已修改或系统工程师确认转为需求的bug，关闭bug，0.5个工作日06确认bug延期测试主管分析bug，确认bug是否能延期处理输入信息：开发或系统工程师指派的延期bug输出信息：确认是否能延期处理，对应延期的bug在开发修

5、复的版本进行激活视实际情况而定07Bug仲裁系统工程师根据判定是否是Bug，给出处理意见输入信息：测试主管指派的延期bug或需要系统工程师确认的bug，开发主管指派的新增/变更需求的bug。输出信息：给出明确处理结果，属于新增/变更需求的bug需要在需求文档中记录相关需求。0.5个工作日5 BUG书写规范5.1 测试人员BUG提交5.1.1 主题用一个简短的句子描述问题，不要写成一大段以进入问题模块路径开头，方便项目经理分派任务，以及开发人员定位问题描述问题时要详细、简练、抓住要点，直接切入正题，不要罗嗦不要夸大或缩小问题的严重程度5.1.2 步骤用数字编号，一步步的描述重现问题的所有操作步骤

6、提供明确的再现问题的步骤，避免问题被以“不能重现”关掉设置区域需要详细描述，如：各设置项值为默认、*值更改为“”，其他设置项值为默认；尽量用动词作为开头，描述每个步骤。如：打开、点击、设置、选择、插入、双击等不要在一个步骤中描述不相关的多个操作。如果是相关的一系列操作，可以使用“”来连接描述。按照你写的步骤去执行，看问题能否重现不要在步骤中使用含糊不清的缩写词描述5.1.3 实际结果实际只描述一个问题同样的操作步骤产生多种现象，要在一个缺陷报告中加以描述不同的操作步骤产生不同的问题，分别报bug如果有截图，请列出所附的图片信息5.1.4 预期结果不要加入实际结果的描述信息描述要清晰，不要使用含

7、糊不清的缩写词描述如果有截图，请列出所附的图片信息5.1.5 备注避免写成大段落，要写得简单、易读问题的特征出现问题后的解决方法对终端客户的影响情况如果有必要，列出产生问题的配置环境5.2 开发人员解决BUG1.BUG的原因。2.BUG的修改方法3.BUG可以在哪个版本上进行验证。4.测试人员验证bug时，需要写明：验证了什么，在什么版本验证，是否通过，如果不通过需写明原因。如果在验证当前bug时有新现象产生阻碍了验证此bug，则该bug不能关闭，写明没有验证的原因，并为新现象提bug。举例1：现象：修改后：6 BUG严重等级6.1 致命不能执行正常工作功能或重要功能，因软件原因导致系统死机等

8、，须马上修正致命错误。通常有如下情况：1.内存泄漏2.由于执行程序引发数据库发生死锁3.用户数据丢失或破坏4.系统崩溃5.死机6.程序无法启动或异常退出7.因错误操作导致的程序中断8.功能设计与需求严重不符6.2 严重影响系统功能或操作，应用模块错误使业务中止无法进行后续操作，主要功能存在严重缺陷，但不会影响到系统稳定性。具体基本上可分为：1.功能未实现2.功能错误3.业务中止，无法进行后续操作4.数据库的表、业务规则、缺省值未加完整性等约束条件5.数据库表结构错误，字段长度不够，缺少表、存储6.语音或数据通讯错误7.数值计算错误8.前台提示存储报错9.系统所提供的功能或服务受明显的影响6.3

9、 一般影响系统正常运行的缺陷，主要功能出现错误，影响到产品的使用。例如：次要功能不能正常实现； 查询错误，数据错误显示；简单的输入限制未放在前台进行控制具体基本上可分为：1.操作界面错误（包括数据窗口内列名定义、含义是否一致）2.报表打印内容、格式错误、取值错误3.页面查询结果错误，自动读值项取值错误4.边界条件下错误5.提示信息错误（包括未给出信息、信息提示错误等）6.简单的输入限制未放在前台进行控制7.长时间操作无进度提示8.光标跳转设置不好，鼠标（光标）定位错误6.4 优化使操作者不合理或者不方便或操作遇到麻烦，但它不影响执行工作功能或重要功能，次要功能，对产品使用影响不大。例如：程序在

10、一些显示上不美观，不符合用户习惯，或是一些文字的错误。具体基本上可分为：1.界面格式等不规范2.辅助说明描述不清楚3.操作时未给用户提示4.可输入区域和只读区域没有明显的区分标志5.个别不影响产品理解的错别字6.文字排列不整齐等一些小问题7.提示窗口文字未采用行业术语7 BUG优先级7.1 紧急阻止与此密切相关功能的进一步测试,需要立即修复7.2 高必须修改，发版前必须修正7.3 中必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正7.4 低对系统的影响较小，如果时间允许应该修改8 BUG解决方案8.1 设计如此设计如此，测试人员理解错误，无需改动，即无效的bug8.2 重复bug

11、以前已经有同样的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 附件文件编号文件名称保存时间保管部门附件