Bug处理流程与考核Word文档下载推荐.docx
《Bug处理流程与考核Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《Bug处理流程与考核Word文档下载推荐.docx（8页珍藏版）》请在冰点文库上搜索。
7
审核已拒绝
......7
处理已推迟
......8
处理不是Bug的
8
处理描述不清
..8
处理无法重现
处理其它原因拒绝
Bug 9
Bug考核制
度
3-10
Bug
严重引起死机和系统异常退出
高
无法正确地处理数据，影响系统正常运行
非统计分析功能的每次操作后等待时间超过5秒
统计分析功能的每次操作后用户等待时间超过10秒
中
有系统报错信息出现，但不影响系统正常运行
非统计分析功能的每次操作后用户等待时间在3-5秒内
统计分析功能的每次操作后用户等待时间在5~10秒内
低不影响系统运行，属建议修改类问题
3如修改人在Bug发现地，则必须在接收日内做出修改，如修改人不在Bug发现
地，可延长至2个工作日。
2如修改人在Bug发现地，则必须在接收日开始的2个工作日内做出修改，如修改人不在Bug发现地，可延长至3个工作日。
1必须在接收日开始的5个工作日内做出修改
4-10
已建议
已推迟、重复
不是Bug
描述不清
其它原因
无法重现
已修复
保持原样
未修复
评审/测试通过
错误地关闭
评审/测试未通过
活动
已解决
已拒绝
已关闭
已批准
5-10
1.在公司的测试人员测试功能，并发现Bug；
2.测试人员将Bug录入到VSTS的对应的团队项目下，设置Bug状态为：
已建议，并认真填写发现环
境、发现途径、症状和重现步骤，如必要还可添加Bug的截图。
其中重现步骤必须详细到直接引
发Bug的每个用户操作（被操作的控件、被选择数据等等）；
3.测试人员确定Bug修改人，通常情况下，Bug所属功能的开发人员就是Bug修改人；
4.测试人员在VSTS中指派Bug的修改人；
5.如Bug修改人在现场实施，测试人员将Bug记录在“质量问题反馈表”中，并在每天下班前用邮
件方式通知该修改人，如必要可用其它方式及时通知。
ABug
1.1实施人员发现或收集Bug；
1.2实施人员将Bug记录在“质量问题反馈表”中，设置Bug状态为：
已建议，并认真填写发现环境、
发现途径、症状和重现步骤，如必要还可添加Bug的截图。
其中重现步骤必须详细到直接引发Bug
的每个用户操作（被操作的控件、被选择数据等等）；
1.3实施人员在每天的16:
30之前将“质量问题反馈表”发给本项目的在公司的测试负责人，如必要可
用其它方式及时通知。
；
1.4在公司的测试人员在每天17:
00接收现场的“质量问题反馈表”，并马上执行
“发布Bug”主流程
的步骤2。
BBug
3.1Bug非所属功能特有，为系统普遍现象，
3.2测试人员通知项目开发经理确定该Bug的修改人；
3.3测试人员执行“发布Bug”主流程步骤4。
CBug
3.1Bug修改人已离职或其它不可抗力原因无法修改Bug；
3.2测试人员通知项目开发经理确定该Bug所属功能的新修改人；
1.开发人员在每天上班的第一时间登录VSTS或接收邮件，查看需要修改的
Bug；
2.开发人员确定Bug的处理顺序，通常情况下，优先处理高严重级别和优先级别的Bug；
3.开发人员确定能够在规定时间内执行修改的Bug,将Bug状态改为“活动”；
6-10
2.1在Bug级别相同的情况下，开发人员优先处理容易的；
2.2开发人员执行“接收Bug”主流程步骤3。
B
3.1开发人员在以下情况下可以拒绝修改Bug；
?
无法在规定时间内执行修改
Bug重复
不是Bug,例如，Bug标识一个缺少的功能，而该功能是一个挂起的开发任务，或者Bug描述
的是一个变更
描述不清或错误
其它合理原因
3.2开发人员将Bug状态改为“已拒绝”，并设置正确的原因，然后在建议的修复方案中详细描述拒绝
的理由。
如果是推迟修改，则另需写明可以修改的具体日期。
如果是经领导批准
的推迟，则另需
写明领导姓名；
3.3流程结束。
1.开发人员确定在开发环境下可重现Bug；
2.开发人员修改Bug；
3.开发人员修改Bug成功，并测试被修改功能，在确定没有因修改而产生其它Bug之后，将Bug状
态改为：
已解决，原因改为：
已修复。
如在修改过程中遇他人大力协助，可在建
议的修改方案中
进行说明；
4.位于公司的开发人员在每天的16:
30之前将修改成功的代码签入VSTS。
位于现场的开发人员在每
天的16:
00之前将修正过的“质量问题反馈表”和修改成功的源代码发给相关测试人员。
5.位于公司的测试人员在16:
05接收现场开发人员发回的“质量问题反馈表”和
源代码，并在16:
30
之前更新VSTS中相关Bug信息和源代码。
2.1开发人员确定Bug所描述的是预期的系统情况或行为，将Bug状态改为“已解决”，原因改为“保
留原样”。
2.2开发人员执行“修改Bug”主流程步骤4。
1.1开发人员在以下情况下可以拒绝修改Bug
无法重现Bug
1.2开发人员将Bug状态改为“已拒绝”，会审为“挂起”，并设置正确的原因，然后在建议的修复方
案中详细描述拒绝的理由。
如果是经领导批
准的推迟，则另需写明领导姓名。
如果是无法重现Bug,则另需写明重现Bug过程中使用过的调试
环境和重现失败原因
1.3开发人员执行“修改Bug”主流程步骤4。
7-10
1.1开发人员在开发环境下无法重现Bug；
1.2如Bug发现地非开发人员所在地，旦开发人员所在地存在发现Bug的模拟环境，则开发人员应在
该环境下尝试重现Bug,否则应以远程方式登录发现Bug的环境尝试重现或者寻求现场人员协助以
确定Bug的位置；
1.3如重现成功，则执行“修改Bug”主流程步骤2,否则，开发人员执行“修改Bug”扩展流程B。
1.测试人员在每天上班的第一时间登录VSTS,查询Bug状态为“已拒绝”，会审为“挂起”的Bug；
2.测试人员执行“审核已拒绝Bug”流程，如通过审核，则将Bug状态为“已关闭”;
3.测试人员测试已解决的Bug,如确定Bug已解决，将Bug状态改为“已关闭”，否则改为“活动”；
4.测试人员发现新的Bug,执行“发布Bug”流程。
1.测试人员采取以下方式核对已拒绝的Bug的原因是否通过审核
已推迟：
核实推迟原因，确定Bug发现地项目主管和开发人员的直接主管在时间安排上是否
有分歧。
重复：
核对被重复Bug。
如存在重复，将Bug状态改为“已关闭”，否则改为“已建议”。
不是Bug：
确认是否为正在开发的功能，或者与Bug所属模块设计人员核对是
为 O
描述不清：
无法斫舒ug描述或与开发人员的直接领导核对拒绝原因。
不可重现：
确认开发人员按照“修改Bug”流程执行，确认在开发环境和Bug发现地的模拟环
境下是否可重现Bug,确认现场是否有可以进行调试的人员，确认现场是否有调试环境。
其它原因：
根据原因描述核对实际情况。
2.测试人员确定拒绝原因通过审核后，将Bug状态改为“已关闭”。
A
2.1测试人员确定拒绝原因没有通过审核后，
2.2测试人员通知项目开发经理进行处理；
2.3项目开发经理根据不同拒绝原因，分别执行以下流程：
处理已推迟Bug
处理不是Bug的Bug
处理描述不清Bug
处理无法重现Bug
处理其它原因拒绝Bug
2.4项目开发经理将处理结果通知测试人员；
2.5测试人员根据处理结果修改Bug状态，如通过审核，将Bug状态改为"
已关闭”，否则改为“已建
8-10
1.开发人员无故推迟修改Bug；
2.项目开发经理按考核的相关规定进行处理。
1.1Bug发现地项目主管和开发人员的直接主管出现分歧；
1.2项目开发经理进行协调，如协调不成功则通知技术总监进行处理，最终确定解决方案和执行时间。
1.1Bug修改需要变更设计，
1.2项目开发经理组织设计人员和开发人员交流，如交流不成功则通知技术总监进行处理，最终确定
解决方案和执行时间。
BugBug
1.设计人员和开发人员出现分歧，
2.项目开发经理组织协调，如协调不成功则通知技术总监进行处理，最终确定解决方案和执行时间。
1.开发人员和测试人员出现分歧；
1.项目开发经理通知Bug发现地的项目经理确定可以进行现场调试的时间和人员；
2.项目开发经理通知Bug修改人在指定时间内与现场调试人员联系，指导其确定出现Bug的代码位
置和相关变量信息；
3.Bug修改人执行“修改Bug”流程。
1.1Bug发现地没有可以进行现场调试的人员；
1.2项目开发经理在满足以下条件下派遣开发人员到现场进行处理；
Bug35210115
1.3派往现场的开发人员必须详细记录Bug的解决方法，并提交品质部整理保存。
9-10
1.1Bug发现地有可以进行现场调试的人员，但无调试环境;
1.2Bug发现地的项目经理组织人力和物力建立调试环境。
1.3执行“处理无法重现Bug”主流程步骤1。
1.项目开发经理组织相关人员讨论处理方案，如出现分歧则通知技术总监进行处理，最终确定解决
方案和执行时间
10-10
升级会员 