《bug处理流程》《bug处理流程》.doc

BUG处理流程说明 BUG处理流程图： 流程描述： 测试人员发现bug提交给开发。 开发人员判断是否是bug。 如果是bug，进行修改，修改完成后更改bug状态为已解决。 如果不是bug，退回给测试人员并描述退回原因，或为设计如此，或为外部原因，或者不能重现。 开发人员修改完成的bug，由测试人员进行验证，确认修改正确，关闭bug。 验证未通过的bug重新激活，开发人员继续修改，直至验证通过，关闭bug。 测试人员需要对开发人员退回的bug进行确认。 确认不是bug关闭。 如与开发人员意见不一致，认为是bug，需提交项目负责人仲裁。 10、项目负责人确认是bug由开发人员修改，不是bug由测试人员关闭。 注：除提交项目负责人仲裁环节外，其他环节都可以在禅道上完成。 各角色应关注的状态 开发人员：激活、重新打开 激活：开发人员要对处于激活状态的bug进行处理，处理后将其状态置成“已解决”、“设计如此”、“无法重现”、“外部原因”、“重复bug”或“延期处理”。 重新打开：重新打开的bug是已解决的bug经过测试人员验证，未修改正确，需要继续修改。 测试人员：已解决、无法重现、设计如此、外部原因、延期处理 已解决：测试人员发现状态为“已解决”的BUG，要及时验证，如果确实已解决，要将其置为“关闭”。否则“重新打开” 无法重现：测试人员发现状态为“无法重现”的BUG，要及时修改，把步骤描述清楚，并将其状态置为“重新打开”。 设计如此：测试人员发现状态为“设计如此”和“外部原因”的BUG，要及时通知项目经理，由项目经理来决定是否修改；对“延期处理”的问题要进行定期跟踪，如发现问题没有按注释进行修改要及时通知开发人员或汇报给相关负责人。 项目经理：设计如此、外部原因、延期处理 设计如此：因为这些BUG都是测试人员和开发人员有争议的BUG，因此项目经理必须及时关注这些BUG，及时给出合理的定夺，如果不需修改把状态置成“关闭”，如果需要立刻解决置成“重新打开”，否则置成“以后解决”。同时，项目经理也要关注“延期处理”的BUG，以免其被漏掉或遗忘从而影响到项目上线。 缺陷严重级别及类型定义 致命错误包括： 造成系统崩溃、死机 造成程序非法退出、死循环、通讯中断或异常 严重错误包括： 功能不符数据流错误程序接口错误2/www/index.php 测试人员提交bug 登录成功后，选择测试试图，然后从下拉列表中选择项目，进入对应项目。 点击创建bug，进入bug编辑界面。 选择bug影响版本、当前指派人、输入bug标题和bug重现步骤。 选择bug类型及严重程度、选择bug出现的系统及浏览器、抄送给项目负责人或其它相关人员、插入bug截图，点击保存bug提交完成。 开发人员处理bug 开发人员登录系统后，点击测试试图下的缺陷管理，选择自己所在的项目，进入相关bug页面，发现有指派给自己的bug，点击bug标题，进入bug详细描述。 在浏览bug重现步骤定位bug后，进行bug的修改，bug处理完成后点击解决，进入下一步。如果认为该bug不是问题，也点击解决，进入下一步处理。 如果bug修改完成，解决方案选择已解决；如果认为不是bug，请选择设计如此；如果bug没有重现，请选择不能重现；如果确实bug但近期内无法解决，请选择延迟处理；如还有其他问题，请选择所对应的解决方案。填写备注信息，以说明bug处理情况。点击保存，完成bug修改流程。 测试人员验证bug 测试人员登录系统后，发现指派给自己的bug，点击bug进入bug详细描述。 查看bug解决方案及bug状态，如果为已解决，则验证bug是否确定修改，如果修改完成，点击关闭，如果bug没有修改正确，点击激活重新打开bug。 如果bug状态为无法重现，则需要自己重现bug，如确实无法重现，关闭，如果可以重现，激活并与开发人员沟通或现场演示bug的重现。 如果为其他状态，请与开发人员协商解决。