资源bug管理流程.doc

1、关键角色及职责序号角色名称角色职责1测试工程师1＞按照模板提交问题2、验证问题是否修改2测试主管1、 审核提交的bug2、 确定问题的严重程度和 优先级3、 分析问题，报告现状， 预测趋势4、 分析测试过程中存在的 风险3研发工程师2、分析问题，写出原因并 修改问题4研发主管1、 按时分配bug,并提出 解决意见2、 定期分析bug,多问题 多的模块，找到相应的 解决方案3、 跟踪bug处理进度，评 估项目质量、风险4、 跟踪延期处理问题5CCB由管理、需求，研发主管、 测试主管及相应的研发和 测试人员组成，存在争执不 下的需求，bug时，己会议 决定处理方案2、bug管理流程CUWI0:1: ■久険学二3主E3°片緝woT7:祜工 d#T|•久?<3>0:• ?fRers>：Fxx«^oT1ETio:■<小|二絢・0Cr12雳丘|栽天丘縄: LT13 ■■只・盘；丸綽■栏令才&冷丄*0菱3-0 D3、活动描述活动编号活动名称处理角色活动描述1提交bug测试工程师按照模板输入bug信 息2测试确认是否为问题测试工程师在提交测试主管前， 如果测试工程师已经 确认为非问题，则关 闭问题单3,4,5测试主管审核问题单测试主管根据需求及用例，确 定是否为问题；修订 bug的优先级；根据 是否为问题，指派给 测试工程师或者研发 主管6CCB仲裁仲裁委员会判定是否为问题，并 给出处理意见7,8分析并指派bug研发主管确认是否为问题；给 出处理意见并指派给 相应的研发工程师9, 10修改bug研发工程师给出问题解决方案，修改bug,修复再次 激活的bug,并将bug 指派给问题提交人11, 12, 13验证bug测试工程师按照模板验证bug并 给岀验证结果；通过 则关闭问题；未通过 则修改bug状态为激 活，指派给测试主管解决方案名称描述设计如此重复bug外部原因已解决无法重现延期处理不予解决转为需求4、问题书写规范4.1提交问题单模板【前置条件】写明问题出现前的坏境，设置的参数等信息【操作系统版本】【浏览器类型及版本】【操作步骤】【实际结杲】【预期结果】【修改建议】4.2研发修改问题规范研发工程师修改完问题单后，需要按照模板填写好相关信息。

[bug原因】[bug修改办法】【可验证版本】【测试建议】4.3测试工程师验证问题规范测试工程师验证bug时，按照如下模板进行【验证版本】【重现步骤】【实际结果】【预期结果】【验证结论】通过/失败5、bug严重程度问题严重程度对应问题级别描述1致命系统不能正常运行或者某些 重要功能不能运行，因软件原 因导致的系统崩溃、死机等， 功能设计与需求严重不符2严重影响系统功能或者操作；模块 错误使业务终止无法进行后 续操作，主要功能存在严重缺 陷但不影响系统稳定3一般影响系统运行，主要功能出现 问题，影响到产品使用4提示不影响系统功能，但是给操作 者带来了不便或者影响了美 观6、bug优先级优先级优先级对应级别描述1紧急阻止相关功能的测试，需要 马上修复2高发版本前必须修改3中必须修改，但不一定马上修 改，需要确定在某个特定的 里程碑修改4低对系统影响小，时间允许应 该修改。