通过隔离错误，我的意思是既查找生成应用程序错误输出的输入类别，又查找哪个组件，配置文件或代码段中包含导致错误的原因。
我听说过的某些方法有时结合在一起（或多或少直观）是：
科学方法。我假设可能的原因，然后进行可重复的实验以进行验证。我对输入进行采样，并将实际程序输出与预期输出进行比较。即使找不到原因，我也可能会找到可重现该错误的最小输入。
调试。我使用调试器工具或通过添加其他日志记录指令（例如
printf）来检查正在运行的程序（堆栈，变量）的状态。特别好，当重新启动应用程序时，我可能会丢失发生错误或应用程序不在我的远程计算机上的状态。阅读并理解代码库，日志，堆栈跟踪和配置文件。我想了解为什么此代码库产生此输出。
二进制搜索问题空间。如何使您的Bug孤独：错误隔离提示，可以系统地支持科学方法。
根本原因分析。我试图将问题缩小到由Software Testing Primer定义的可能的根本原因类之一。我确保测试案例或环境配置中都不存在错误。然后我检查代码本身。
在最后一种情况下，我有时还会尝试了解问题是由另一个错误还是由模棱两可/不完整的需求/设计引起的。 >您的方法是什么？您能推荐我一些阅读，视频，专业知识吗？谷歌在这里找到正确的关键词是什么？
#1 楼
除了“其他评论者所说的话”，还有其他一些我的经验：查找相似的错误-您的错误是否发生在已知的系统区域中有问题吗？它看起来很像已经记录的东西吗？变更区域-该错误是否发生在正在开发的系统的一部分中？在我工作的地方，系统的某些部分会做很多工作：了解这些内容并与在该部分工作的开发人员核对可以找到您的第一手理由。
刚刚修复-您在系统上仅应用了修复程序的区域中的错误吗？如果是这种情况，更正的可能性很可能会导致您的问题。
最简单的复制-这与调整输入并不完全相同：它重复了复制错误的过程，但是却忽略了多余的步骤来确定手动复制的最短，最简单的步骤集（并非总是可行的）。例如，在我工作的地方，我们使用基于交易的测试，在该交易中，我们将使用各种修改功能进行销售和招标付款，这些功能在选择要购买的商品和付款之间进行。为了隔离错误，我们将删除诸如增加折扣之类的修改，直到我们拥有最细粒度的复制过程为止（我们发现的许多错误在特定情况下都与税收计算有关，因此没有可使用的跟踪日志：我们唯一的信息来源是应用程序的行为方式以及交易的最终金额是否与应有的金额相匹配）。
根据我的经验，并没有一套用于隔离bug的快速简便的方法-过了一会儿，人们就会熟悉测试中特定系统常见的错误类型，并且不考虑与该错误类型无关的方法。
评论
对我来说，这些是非常实用的解决方案。我将前三项放在一般的风险区域“伞”下。因此，我还将包括一些我们所知的应用程序部分，这些部分是在高峰期+模棱两可的要求+由初级程序员实现的区域等设计的。这些区域由用于确定测试内容的相同标准定义。
– dzieciou
2012年6月4日19:38
+1表示“一段时间后，人们熟悉了特定系统常见的错误类型”。我没有足够的经验来确认这一点，但是我想对于社区提出有关特定错误或错误类别的问题会更有用，例如：我在以下系统中存在以下缺陷，我该怎么办？隔离吗？
– dzieciou
2012年6月4日22:01
dzieciou-可以工作，只要系统本身不是太专有。在过去的7年中，我一直在使用“企业对企业”的销售点和准入跟踪系统，因此我对此非常熟悉，但是除了广泛的概述之外，我无法在此进行讨论，因为它既是专有的，在使用它的企业之外也未广为人知。
–凯特·保罗（Kate Paulk）
2012年6月6日上午10:55
#2 楼
那是一个很好的清单。我最重要的调试建议是：“一次只更改一件事”。您可以将其应用于诊断几乎所有内容，从软件错误到损坏的计算机。评论
我既同意也不同意这种回应。如果您知道问题出在哪里，那么一次更改一件事情就很有意义。但是，如果您有数百个输入，而其中任何一个都可能成为问题；使用二进制搜索并一次更改1/2可以减少隔离问题所需的时间。
–xQbert
2012年6月2日下午16:51
@Qbert我同意“一次只更改一件事”并不总是解决所有调试问题的最佳方法。
–user246
2012年6月2日17:33
@Qbert正确，有时更改一半的输入比更改单个输入的耗时少。例如。更换复杂的配置文件可能比更换硬件要快。
– dzieciou
2012年6月2日17:43
#3 楼
缺陷隔离和调试在方法和性质上非常相似，实际调试定义为“从计算机硬件或软件中识别和消除错误的过程”。在这个问题的背景下，我几乎将隔离定义为“在没有源代码的情况下进行调试，或者消除错误。使用您在问题中所述的科学方法，并概述了如下过程：
a。收集产生缺陷的数据。
b。分析收集的数据并形成关于缺陷的假设。
c。通过测试程序
或检查代码，确定如何证明或反驳假设。 。
d。使用步骤c。确定的过程证明或证明假设。
e。如果未发现缺陷，则应用收集的数据并返回步骤a。
（我添加了步骤e）。从开发人员的角度来看，《代码完成》的第23章是对该主题的详尽且详尽的阅读，并且大部分适用于测试。 />
评论
+1相关书籍章节！我会按照您的解释：隔离=不使用源代码进行调试=黑盒调试
– dzieciou
2012年7月14日15:18
#4 楼
到目前为止，这里所说的一切都很好。我要补充：如果可能，请询问该项目的开发人员。
如果您有更多的信息，有时bug可能更有意义，而开发人员往往会拥有这些信息。您可能会认为错误来自业务逻辑中的X区域，但实际上它是基于数据库存储调用的Y代码。至少，询问开发人员（或经理，其他测试人员等）有时可以帮助您避免朝错误的方向隔离错误。
#5 楼
从其他测试人员和开发人员的故事中学习。“如何使您的Bug孤独：错误隔离的提示”中的示例故事演示了测试人员在浏览器中隔离真正讨厌的错误的步骤。
但是这个故事可能不适用于您的系统，因为您的错误可能只针对您的系统或所使用的技术。可能需要测试人员“非常熟悉”系统和技术（正如Kate Paulk所说）。
因此，我在以前的工作中开始尝试的是询问开发人员和测试人员对系统及其技术更有经验或更熟悉：
如何找到此原因？
如何隔离此错误？
您采取了哪些步骤？
您在过程中使用了哪些工具/命令？
每当其他开发人员隔离出不重要的bug时，我都会尝试执行此操作。
评论
这里有类似的问题：sqa.stackexchange.com/questions/769/…