4）问题的根本原因：被测系统内部因素？硬件、软件、网络？

　　5）如何能修复问题，而不引入新问题？

　　6）系统变化都正确地调试了吗？

　　7）问题修复了吗？以前的测试现在能通过吗？其余部分是否影响？

　　步骤1证明错误并精化实践，步骤2步骤3测试人员隔离错误，步骤4、5、6开发人员执行调试任务，步骤7返回到测试。步骤3和步骤4之间是测试组织与开发人员关键转移界限，需要细化定义。

　　前4步容易混合，测试人员陷入调试过程，浪费资源。

　　评审错误报告，一定要确保清楚地回答步骤1～3的问题。这样才能划清界限，让测试人员集中精力测试。但当在开发实验室不能再现错误时，测试人员需协助开发人员调试。

　　5.4 引导错误生命周期：错误分类过程

　　除非错误有明显的高优先权且易于修改（如小于20分钟）和测试（如小于8分钟完成确认测试），可以直接与开发人员协商处理解决这类问题，一般应通过正式过程来管理关键转移和修复。

　　方法：通过错误分类或错误评审委员会、变更控制委员会（CCB）来决定如何开展修复工作。

　　错误分类或错误评审委员会：相关代表参加，一般定期开会（如每天一次）确定：错误是否修复？何时修复？进度、预算？影响其他测试进行的错误应优先修复。

　　变更控制委员会（CCB）：还要决定需求、设计、界面、配置、计划等的变更如何实施。

　　错误分类过程依据项目或组织背景变化，需要有效地控制周期和频率，每个错误的讨论不超过5分钟，决定修复或延时。频繁安排会议（如每天一次），让会议不超过一小时，这样易于随时解决测试发现的问题，但关系不太密切的会议参与人员可能不厌其烦，频繁召开的测试问题与软件修改会议只适合直接相关的人员参与，上级领导及其他利益相关方只适合听取阶段性的综合汇报与评审结论，或者参加关键问题的讨论，批准其中的取舍事项。

　　5.5 设置动态标识

　　为测试项目各项任务、活动、及发现的错误设置状态、所有人、预计修复日期、日志，记录进展情况。

　　6、为分析获取错误数据

　　1）与错误相关的信息：子系统、配置、质量风险，故障模式和效果分析。

　　2）错误来源：解决方案和根本原因

　　解决方案：记录编程人员是如何解决的，记录根本原因分析过程和错误分类。（除了本项目需要这些，还可用作后续项目的参考。）

　　错误可能隐藏，不引起可观察到的故障。此时需要全面完整的测试才能发现问题。

　　硬件错误：设计、产品或原料

　　设计错误：错误使用组件，错误理解芯片的局限，不适当的空气流，或者其他错误，如分析比较不够引起的选择失误。

　　产品错误：生产线上的错误，如CPU插入不正确。

　　原料错误：配件供应商的配件有问题，甚至其内置软件有问题。

　　软件错误方面：

　　a）功能：规格说明错误，功能实现错误，测试报告了伪错误。

　　b）系统

　　内部接口，硬件设备，操作系统，支持软件等。

　　软件体系结构：基本设计假设无效。

　　资源管理：设计假设正确，但有些实现的假设是错误的。