这是一个很好的清单。我最重要的调试建议是“一次只改变一件事”。您可以将其应用于诊断几乎任何事情，从软件错误到损坏的机器。

除了“其他评论者所说的话”之外，还有我的经验中的其他一些项目：

• 找到类似的错误 - 您的错误是否出现在系统中已知有问题的区域？它看起来很像已经记录的东西吗？
• 变化的领域 - 错误是否出现在系统中处于大量开发中的部分？在我工作的地方，系统的某些部分会做很多工作：了解这些并与在该部分工作的开发人员核对可以让您获得第一次通过的原因。
• 刚刚修复 - 您的错误是否在系统的某个区域中刚刚应用了修复？如果是这种情况，纠正很有可能导致您的问题。
• 最简单的再现 - 这与调整输入并不完全相同：它重复再现错误的过程，但省略了似乎无关的步骤，以确定手动再现的最短、最简单的步骤集（这并不总是可行的）。例如，在我工作的地方，我们使用基于交易的测试，我们将使用在选择要购买的物品和付款之间调用的各种修改函数进行销售和投标付款。为了隔离错误，我们将删除添加折扣等修改，直到我们获得最精细的再现过程（我们发现的许多错误都与特定情况下的税收计算有关，因此没有可使用的跟踪日志：

根据我的经验，没有一套硬性和快速的方法可以用来隔离错误 - 一段时间后，人们会熟悉测试中特定系统常见的错误种类，以及与那种风格无关的方法错误往往不被考虑。

缺陷隔离和调试在方法和性质上非常相似，实际上调试被定义为“从计算机硬件或软件中识别和消除错误的过程”。

在这个问题的上下文中，我几乎将隔离定义为“在没有源代码的情况下进行调试，或者删除错误。

在Code Complete中，Steve McConnell 建议使用科学方法，正如您在问题中所述，并概述了这样的过程：

一种。收集产生缺陷的数据。

湾。分析收集到的数据并形成关于缺陷的假设。

C。通过测试程序或检查代码来确定如何证明或反驳假设。

d。使用步骤 c 确定的程序证明或反驳假设。

e. 如果未发现缺陷，则应用收集的数据并返回步骤 a。

（我添加了步骤 e）。从开发人员的角度来看，Code Complete 的第 23 章是关于这个主题的精彩而详细的阅读，其中大部分内容适用于测试。

到目前为止，这里所说的一切都非常好。

我要补充一点：如果可能，请询问项目的开发人员。

有时，如果您拥有更多信息，则错误可能会更有意义，而开发人员往往拥有此类信息。你可能认为一个 bug 来自业务逻辑中的 X 区域，但实际上它来自基于数据库存储调用的 Y 代码。至少，询问开发人员（或经理，或其他测试人员等）有时可以帮助您避免为了隔离错误而走错方向。