如何处理无法复制的错误？

我有一个测试人员，在测试时会发生错误（到目前为止，还可以），但随后他经常立即报告该错误。然后，我们（开发人员）后来发现测试人员没有尝试重现该问题，并且（当被问到）找不到找到使该问题再次发生的方法。

现在这些仍然是错误，我不想忽略它们。但是如果没有复制步骤，我会陷入困境。有时会有堆栈跟踪（尽管通常它没有用，因为它是紧凑的框架，没有行号）。但是，如果有一个，我可以跟踪堆栈并破解代码并开始猜测，但这不会导致可测试的“修复”。

在这种情况下您会做什么？

没有上下文的错误不是错误，这是fl幸。问题可能出在您的代码上，可能是第三方库，可能是硬件，也可能是太阳辐射，导致一点点翻转。如果您不能以一定的规律性重现它（即使只是“它每X发生10或20次，就发生一次”），那也不比测试人员告诉您“某处出了点问题-修复它”要好得多。 。

您可能需要向您的测试人员解释说，他的工作不仅仅是在出现问题之前生成输入。如果是这样，您可以用一个随机数生成器代替他。他的工作之一是识别错误，这需要确定如何产生错误。

最终，如果开发人员和测试人员都无法重现该错误，则应将其关闭，但应对此进行标记。

但是，达到这一点需要花费多长时间是值得商。的。

有人会争辩说，如果它不能立即重现，则应立即将其关闭。

我通常会努力尝试从问题的发起者那里获得更多信息。他们可能在原始报告中忘记了某些东西。讨论所需步骤通常可以揭示丢失的信息。

最后一个想法-封闭为“ no-repro” 并不意味着已解决。如果存在真正的问题，它将早晚显示出来，并且拥有所有信息，可以在您最终重现问题时提供帮助。

其他一些建议：

1. 将日志记录（而不仅仅是键盘记录器：}）添加到您的产品代码中。“无可复制”错误可能是偶然现象，但它们可能是内存或状态损坏，仅在以意想不到的方式（例如，客户计算机）使用的脏系统上发生。记录或跟踪信息可以帮助您找出测试人员发现the幸时可能出了什么问题。

2. 扫描数据库中其余的“禁止复制”错误（或用于错误追踪的任何错误）。通常，吸油团在产品的一个区域聚集在一起。如果看起来一个组件有故障，则代码会检查该组件是否存在脆弱性，或向该组件添加其他日志记录-或两者同时进行。

3. 花半个小时左右的时间观看测试仪测试。他们的方法可能使您知道出了什么问题（例如“有趣-我不知道您可以通过这种方式进入该对话框”）。您可能还会发现他们无意间跳过了对话框或配置步骤。花点时间投入他们的脑袋是值得的。

我对大型商业代码进行质量检查，这种令人讨厌的情况确实经常出现。通常，这表明没有在我们支持的所有平台上构建二进制文件的过程。因此，如果开发人员构建自己的代码（调试和修复该代码），并且没有遵循相同的构建过程，则系统依赖的错误可能会神奇地消失（或出现）。 。当然，这些错误通常会在错误数据库中被“为我工作”关闭，并且如果它们在下次运行该问题时失败，则可以重新打开该错误。每当我怀疑某个错误可能与系统有关时，我都会尝试在各种平台上进行测试并报告在什么情况下发生。如果损坏的数据的大小足以导致崩溃，通常会出现内存损坏问题onlt。某些平台（硬件和操作系统的组合）可能会崩溃，更接近损坏的实际来源，这对于必须调试的可怜人来说非常有价值。

测试人员需要做一些增值工作，而不仅仅是报告其系统出现故障。我花了大量时间来筛选误报-可能是相关平台超载，或者网络出现故障。是的，有时候您可以获得真正受随机定时事件影响的东西，硬件错误通常像原始示例：如果两个数据请求返回的时钟周期完全相同，并且用于处理潜在冲突的硬件逻辑有问题，那么该错误只会间歇性地显示。与并行处理类似，除非经过精心设计，否则您将解决方案约束为与哪个处理器发生速度更快无关，那么您可能会得到仅在一次蓝月亮中发生一次的错误，并且其统计上的不便性使调试成为一场噩梦。

同样，我们的代码通常每天进行多次更新，以跟踪确切的源代码修订版本号（何时向南移动）可能是调试工作中非常有用的信息。测试人员不应与调试人员和开发人员处于敌对关系，他是团队的一员，以提高产品质量。

有两种无法重现的错误：

1）测试人员（或用户）曾经看过但未能或未尝试复制的内容。

在这些情况下，您应该：

• 非常简短地检查显示缺陷的基本操作过程，以确保其不可复制。

• 与测试人员/用户交谈，以查看是否还有其他可能有用的信息。

• 将它们与可能与之相关的任何其他缺陷进行交叉引用，以查看您是否具有足够的信息来基于多个实例对其进行研究。您可能会发现此问题并没有为您提供足够的信息，但是当您与其他许多问题结合使用时，可能会向您建议一些不正确的值得研究的问题。

• 如果仍然没有足够的信息，那么您需要向用户/测试人员说明您没有足够的信息。有礼貌地向他们概述需要什么样的信息以及为什么需要它。

2）无法可靠复制的内容，但是有足够的证据（就反复出现而言）表明缺陷确实存在，那么我倾向于看到这些是开发人员问题，并且开发人员受测试人员支持/用户-需要调查。

这可能会很慢且很痛苦，您可能不得不遍历代码，添加更多日志记录，查看数据并与测试人员/用户进行深入交谈，但是如果有足够的证据表明它很可能存在，这是您确实需要拥有所有权并做任何必要的工作以修复它的问题。

听起来这似乎是相对频繁发生的-这让我感到奇怪，是因为大多数错误确实难以修复，还是由于其他原因他没有尝试？您知道他为什么不尝试重现该问题吗？是因为他不知道这对您有多重要？抑或是他还有其他压力-例如，一位测试经理只希望他快速完成分配的测试并将漏洞扔到墙上？也许他只是不确定如何去做？

我同意其他人的观点，即更好地记录日志是当务之急。同时，如果您怀疑缺乏测试人员的技能/信心可能是一个问题，那么我真的很喜欢Danny Faught的这篇文章中有关错误隔离的文章 -您可以首先指出他。

如果问题确实是由于管理压力造成的，那么您将表示同情，因为这是一个很难克服的问题，尤其是当测试人员和程序员向不同的经理报告时，并且经理不倾向于“帮助”另一个团队时。

通常，我注意到它是不可重现的，但是在完成那批测试或迭代之前，请保持打开状态。

如果该点尚未被复制，则将其关闭，但是如果再次遇到它，则可以将其重新打开。

在此测试仪的工作站上粘贴键盘记录器！

好吧，首要任务是拥有可重现的测试系统。测试人员必须有一个定义明确的过程-尽可能自动执行。

具备以下三个条件：

• 相同的二进制
• 相同步骤
• 同一台机器

如果在上述3种情况下偶尔出现该错误，请开始进一步隔离。考虑系统堆栈的每个级别及其配置。

检测内存管理错误的一种方法是在具有多个编译器的多个OS上运行该程序。Valgrind也可以提供帮助。

但是，通常并行系统易于引发非复制错误。诸如缓冲区大小和处理速度，异步io，数据库锁定，可变内存写入交错之类的东西；所有这些都会产生问题。依此类推。

首先，您应该有一个严格的测试程序（但是我了解您，在我公司中您所描述的情况经常发生）。

根据错误的严重程度，您可以花一些时间在该错误上，或者（最好）忽略它，直到提供了repro步骤为止。