在诊断和修复缺陷之前坚持重现每个缺陷是否合理？

我在一家软件产品公司工作。我们拥有实施我们产品的大型企业客户，我们为他们提供支持。例如，如果有缺陷，我们会提供补丁等。换句话说，这是一个非常典型的设置。

最近，针对客户在日志文件中发现的与我方产品的集群实现中的并发数据库访问有关的异常，已发出并分配了票证给我。因此，此客户的特定配置对于此错误的发生可能很关键。我们从客户那里得到的只是他们的日志文件。

我向我的团队建议的方法是尝试在类似于客户的配置设置中重现该错误并获得可比的日志。但是，他们不同意我的方法，即我不需要重现该错误，因为该错误过于耗时，并且需要在VM上模拟服务器集群。我的团队建议我只是“遵循代码”以查看线程和/或事务不安全代码的位置，然后将更改放入简单的本地开发工作中，而不是像发生事件的环境那样的集群实现错误的来源。

对我来说，要制定一个抽象的蓝图（程序代码）而不是一个有形的，可见的表现形式（运行时再现）似乎很困难，所以我想问一个普遍的问题：

在诊断和修复缺陷之前坚持重现每个缺陷并对其进行调试是否合理？

要么：

如果我是高级开发人员，我是否应该能够阅读多线程代码并对其在所有用例场景中的工作情况有一个清晰的了解，而不是需要运行应用程序，亲自测试不同的用例场景并逐步完成代码一行一行？还是我对这种工作环境的要求很差？

调试sissies吗？

我认为，响应事故单提交的任何修复程序都应在模拟的环境中进行测试，该环境应尽可能接近原始环境。您还怎么知道它将真正解决该问题？这就像发布一款新车型时一样，没有用假人对它进行碰撞测试即可证明安全气囊确实有效。

最后但并非最不重要的一点，如果您同意我的看法：

我应该如何与我的团队交谈，以说服他们我的方法是合理，保守和防弹的？

在诊断和修复缺陷之前坚持重现每个缺陷并对其进行调试是否合理？

您应该尽力而为。我知道，有时还有条件是如此复杂，他们不能被复制的环境中准确，但你应该，如果你一定会试试的。

如果您从未复制过该bug并亲自看到了该bug，您怎么能百分百确定自己已真正修复该bug？可能是您提出的修复程序引入了其他一些细微的错误，除非您实际尝试重现原始缺陷，否则这些细小错误将不会显现。

如果我是高级开发人员，我应该能够阅读（多线程）代码并对其在所有用例场景中的工作情况有一个清晰的印象，而不是需要运行应用程序，测试不同的用例场景并逐步进行操作代码一行一行？还是我对这种工作环境的要求很差？调试sissies吗？

如果那是他们唯一的方法，那么我不会相信有人在他们的脑海中运行代码。这是一个很好的起点。重现该错误，并进行修复，然后证明该解决方案可以防止该错误再次发生-这是应该终止的地方。

我应该如何与我的团队交谈，以说服他们我的方法是合理，保守和防弹的？

因为如果他们从不重现该错误，则无法确定该错误已得到修复。而且，如果客户回来并抱怨该错误仍然存​​在，那不是一件好事。毕竟，他们为解决这个问题付出了很多钱。

如果您未能正确解决问题，则表示您已经（在某种程度上）与客户建立了信任关系，并且如果您的市场中存在竞争对手，那么他们可能就不会保留您的客户。

他们打算如何验证问题中的错误已修复？他们是否想将未经测试的代码发送给用户，让他们找出来？从来没有显示过能够重现错误的任何测试设置，都不能依靠它来表明没有错误。您当然不需要重现整个客户端环境，但是您确实需要重现该错误。

我认为在修复之前尝试重现每个错误并不是没有道理的。但是，如果您尝试复制它，但是您不能复制它，那么盲目补丁是否是一个好主意就成了更多的业务决策。

理想情况下，您希望能够重现每个错误，以便至少可以测试它是否已修复。

但是...这可能并不总是可行的，甚至在物理上也不可能。特别是对于“企业”类型的软件，其中每个安装都是唯一的。还有成本/效益评估。花费几个小时查看代码并对非关键性问题进行一些有根据的猜测，其成本可能远低于让技术支持团队花费数周的时间来尝试建立和复制客户环境，以期希望能够复制问题。回到我在“企业”环境中工作时，我们常常只是将编码员赶出现场，让他们在现场修复错误，因为没有办法复制客户的设置。

因此，在可以的情况下进行复制，但在不能的情况下进行复制，然后利用您对系统的了解，并尝试确定代码中的罪魁祸首。

我认为您不应将重现错误作为查看错误的要求。正如您所提到的，有几种调试问题的方法-应该使用所有这些方法。您应该算是幸运，他们能够给您一个日志文件！如果您或您公司的某人能够重现该错误，那就太好了！否则，您仍应尝试解析日志并查找发生错误的情况。正如您的同事建议的那样，有可能阅读代码，找出可能发生错误的条件，然后尝试自己重新创建场景。

但是，请勿发布未经测试的实际修复。您所做的任何更改均应通过标准开发，质量检查测试和集成测试例程。可能很难测试-您提到了多线程代码，众所周知，它很难调试。这是我同意您创建测试配置或环境的方法的地方。如果您在代码中发现问题，则应该更轻松地创建环境，重现问题并测试修复。

对我来说，这不是调试问题，而是客户服务问题。您已经收到客户的错误报告；您有责任进行尽职调查以发现问题并解决。

我认为……作为决策者，您必须能够证明自己的立场。如果三线支持部门的目标是在客户可接受的努力下在最短的时间内修复错误，那么任何方法都必须符合该目标。此外，如果可以证明该方法能够给出最快的预期结果，那么说服团队就没有问题。

经过支持，我一直很合理地期望客户能够给出他们为一致地重现该错误而执行的动作的“脚本”，如果不一致，则可以给出产生该错误的候选示例。

如果我是该系统的新手，并且没有代码的背景知识，那么我的第一步将是尝试确定错误的可能来源。日志记录可能不足以标识候选代码。根据客户端的不同，我可能会倾向于给他们一个调试版本，以便他们能够向您提供日志文件，从而提供有关违规代码位置的进一步线索。

如果我能够快速识别代码块，那么流程的可视化映射可能足以识别代码。如果没有，那么基于单元测试的模拟就足够了。设置客户端复制环境可能花费更少的时间，尤其是在存在大量问题可复制性的情况下。

我认为您可能会发现，您的方法应该是建议的解决方案的组合，并且知道何时退出一个方案并转到下一个方案是有效完成工作的关键。

我非常确定，团队会支持以下观点：如果有可能，他们的解决方案可以更快地发现错误，然后给他们适当的时间框架，以证明这对修复错误所花费的时间不会有太大影响您选择的路线。

在诊断和修复缺陷之前坚持重现每个缺陷并对其进行调试是否合理？

我说是，有一些警告。

• 我认为可以通读代码并尝试查找看起来可能有问题的地方。创建一个补丁，并将其发送给客户端，以查看是否可以解决问题。如果此方法继续失败，则可能需要研究其他选项。只要记住，虽然你可能会解决一个错误它可能不是该报道错误。
• 如果您无法在合理的范围内重现它，并且在代码中找不到任何危险信号，则可能需要与客户进行更紧密的协调。在进行现场调试之前，我已经飞往客户站点。这不是最佳的开发环境，但是有时候如果问题出在环境上，那么当您能够始终如一地重现它时，找到确切的原因将是最容易的。

在这种情况下，我一直在表的客户方面。我当时在一家美国政府办公室工作，该办公室使用了一个非常大的Oracle数据库集群（数TB的数据，每天要处理数百万条记录）。

我们遇到了一个奇怪的问题，我们很容易复制它。我们将该错误报告给Oracle，并与他们来回交流了数周，并向他们发送了日志。他们说他们无法重现该问题，但向我们发送了一些补丁程序，希望可以解决该问题。他们都没有。

他们最终派出了一些开发人员到我们的位置进行现场调试。那是当找到该错误的根本原因，并且以后的补丁正确解决了该问题时。

如果您对该问题不是很满意，那么您对解决方案也不会很满意。知道如何在至少一个测试案例中可靠地重现该问题，可以使您证明自己知道如何导致该错误，因此也可以使您从另一面来证明该问题已得到解决，原因是随后的缺失应用此修复程序后，在同一测试用例中出现错误的情况。

也就是说，竞争条件，并发问题和其他“非确定性”错误是开发人员最难以以这种方式确定的错误，因为它们不经常出现在负载和复杂性高于任何一个开发者副本的系统上程序，它们在以后在同一系统上重新运行任务时消失。

通常，最初看起来像是随机错误的错误最终都有确定性的原因，一旦您知道如何，该错误就可以确定性地再现该错误。真正的Heisenbugs（看似随机的bug在尝试在无菌，受监视的环境中进行测试时会消失的）违背了这一点，与时间相关的率为99.9％，一旦您了解了这一点，您的前进方向就会更加清晰；扫描是否有可能在代码执行过程中使其他人措手不及，如果发现某个漏洞，则在测试中尝试利用此漏洞，以查看其是否表现出您正在尝试的行为，从而导致失败。

在这些情况下，通常需要进行大量的深入代码检查。您必须查看代码，放弃有关代码应如何行为的任何先入为主的概念，并想象一下在某些情况下可能会导致客户观察失败的情况。对于每种情况，请尝试开发一种可以在当前的自动化测试环境中高效运行的测试（即，无需为此测试仅使用新的VM堆栈），这将证明或不证明代码的行为符合预期（取决于您的期望，这将证明或不证明此代码是造成客户问题的可能原因）。这是软件工程师的科学方法。观察，假设，测试，反映，重复。

在诊断和修复缺陷之前坚持重现每个缺陷并对其进行调试是否合理？

不，绝对不是。那将是一个愚蠢的政策。

我在您的问题和建议中看到的问题是他们无法区分

• 错误报告
• 失败（错误）
• 错误（有时也称为错误）

一个bug报告是关于一个错误的沟通。它告诉您有人认为有问题。关于什么是错的可能是或不是特定的。

错误报告是失败的证据。

一个失败是出乱子的事件。一种特定的故障，但不一定有任何可能的原因的线索。

故障可能是由错误引起的。

甲错误是失败的一个原因; 可以（原则上）更改某些内容，以防止将来引起的故障发生。

有时，当报告了一个错误时，立即找出原因。在这种情况下，重现错误是没有意义的。在其他时候，根本根本不清楚原因：错误报告没有描述任何特定的故障，或者确实如此，但是该故障使得它无法提供有关可能原因的线索。在这种情况下，我觉得您的建议是有道理的-但并非总是如此：在接受调查导致第一个坠毁的原因（控制软件中的特定错误）之前，一个人并不坚持让第二个3.7亿美元的太空火箭坠毁。

两者之间也有各种各样的情况。例如，如果一个错误报告没有证明但仅表明您已经意识到的潜在问题可能在起作用，那么这可能足以促使您仔细研究它。

因此，尽管在较困难的情况下坚持可重复性是明智的，但将其作为严格的政策来实施是不明智的。

与软件开发中的所有其他内容一样，正确的答案是一个折衷方案。

从理论上讲，如果无法证明错误存在，则永远不要尝试修复该错误。这样做可能会导致您对代码进行不必要的更改，最终无法解决任何问题。证明它意味着首先复制它，然后创建并应用修复程序，然后证明它不再发生。您的直觉会引导您朝着正确的方向发展-如果您想确信自己已解决了客户的问题，则首先需要了解导致问题的原因。

实际上，这并不总是可能的。该错误可能仅发生在大型集群上，该集群具有数十个用户同时访问您的代码。也许对触发该错误的特定数据集进行了特定的数据操作组合，而您不知道那是什么。也许您的客户在错误出现前100个小时不停地交互式运行程序。

在任何一种情况下，您的部门很有可能在开始工作之前就没有时间或金钱来重现该错误。在许多情况下，对于开发人员来说，对您而言，显而易见的是，代码中存在一个错误，可将您引导至正确的情况。一旦诊断出问题，便可以返回并重现它。这并不理想，但是与此同时，您作为高级开发人员的工作之一是要知道如何阅读和解释代码，部分是为了找到这些隐藏的错误。

我认为您正在关注问题的错误部分。如果您最终无法重现有问题的bug怎么办？让客户感到沮丧的莫过于听到“是的，我们知道您使程序崩溃了，但我们无法复制它，因此它不是错误。” 当您的客户听到此消息时，他们将其解释为“我们知道我们的软件存在错误，但我们不必费心去修复和修复这些bug，只需动动手指即可。” 将报告的错误“不可重现”还是将其关闭“不可重现，但我们已经进行了一些合理的更改以尝试提高稳定性”是否更好？

除非错误是明显的，明显的且琐碎的，并带有非常特定的错误消息等，否则，如果用户或维护者无法复制错误，通常很难修复。

此外，如果您无法复制步骤，您将如何向他们证明该错误已修复？

您的案例的问题在于用户既不知道如何发生错误，也就是不知道在什么屏幕上执行什么操作。他们只是简单地拥有日志。

我认为你的观点是合理的。如果您具有心理能力，则可能不会有薪工作。

我想你应该告诉你的老板，没有能够复制它会采取错误的时间UKNOWN量找出来，而且也根本没有garantee，你会的。

问题将是当您的某些同事纯粹出于运气而发现错误并加以修复时。

让我们将它带到一个极端，并假设您早已发现了该错误：在编写代码时就在您的代码中。这样一来，您就不会对在此处进行修复感到烦恼-您看到了刚编写的代码中的逻辑缺陷，它没有达到您想要的目的。您将不需要设置整个环境来表明它实际上是一个错误。

现在出现了错误报告。您可以执行几项操作。其中之一是返回代码并重新阅读。现在，假设在第二读中，您立即发现了代码中的错误-它根本没有按照您的预期去做，并且在编写时没有注意到。并且，它完美地解释了刚出现的错误！您解决了。花了你二十分钟。

这样是否解决了导致错误报告的错误？您不能百分百确定（可能有两个错误导致了同一件事），但事实确实如此。

您可以做的另一件事是尽可能多地复制客户的配置（几天的工作），并最终复制该错误。在许多情况下，存在时间和并发问题，这意味着您无法重现该错误，但是您可以尝试很多时间，有时还会看到同一件事。现在开始调试，在代码中找到错误，将其放入环境中，然后重试很多次。您不会再看到该错误了。

这样是否解决了导致错误报告的错误？您仍然不能百分百确定-一，您可能实际上已经看到了客户所做的一个完全不同的错误，二，您可能没有经常尝试，三，配置仍然稍有不同，固定在此系统上，而不是客户的。

因此，在任何情况下都不可能获得确定性。但是第一种方法是更快的方式（您也可以更快地为客户提供补丁程序），便宜的方式，并且，如果您找到一个清晰的编码错误来解释症状，那么实际上也更有可能找到问题。

因此，这取决于。如果设置测试环境便宜（或者更好：显示问题的自动测试），请执行此操作。但是，如果价格昂贵和/或错误显示的环境不可预测，那么最好先阅读代码来查找错误，这总是更好的选择。

阅读问题，我认为您的职位和团队之间没有任何根本的对立。

• 是的，您应尽最大努力重现客户端设置中出现的问题。但是尽力而为意味着您应该为此定义一个时间框，并且日志中可能没有足够的数据来实际重现该问题。

  如果是这样，那么一切都取决于与该客户的关系。它可以从您没有他的任何其他东西，到您可能会在现场派遣具有诊断工具并能够在故障系统上运行它们的开发人员。通常，我们介于两者之间，如果初始数据不足，则可以通过其他方法获得更多信息。

• 是的，高级开发人员应该能够阅读代码，并且很可能在日志内容之后找到问题的原因。实际上，经常可以在仔细阅读代码后编写一些能证明问题的单元测试。

  成功编写这样的单元测试几乎与再现破坏性的功能环境一样好。当然，此方法也不保证您会找到任何东西。仅通过阅读代码就很难发现导致某些多线程软件故障的确切事件顺序，并且实时调试的能力可能变得至关重要。

总而言之，我将同时尝试这两种方法，并要求一个存在问题的实时系统（并证明此问题随后已修复），或者要求进行一个破坏该问题的单元测试（并表明其在修复后已修复）。

尝试仅修复代码并在野外发送它，确实看起来非常冒险。在我发生的一些类似情况下（我们无法在内部重现缺陷），我明确指出，如果修补程序泛滥成灾，无法解决客户问题，或有任何其他意外的负面后果，那位建议的人它必须帮助支持团队找到实际问题。包括在必要时与客户打交道。

在我看来，您需要更详细的日志记录。

尽管添加更多的日志记录不能保证您不需要调试（在这种情况下，还是重现这种情况），但它可以使您更好地了解实际出了什么问题。

尤其是在复杂/线程化的情况下，或无法使用调试器的任何情况下，依靠“通过printf（）进行调试”可能是唯一的选择。在这种情况下，请尽可能多地记录日志（超出您的期望），并具有一些很好的工具可以从谷壳中过滤掉小麦。

在诊断和修复缺陷之前坚持重现每个缺陷并对其进行调试是否合理？

既然没有人说清楚，那就绝对不会！

像软件开发中的所有其他内容一样，错误修复意味着要牢记时间，风险和成本。在这两者之间寻求平衡是开发人员工作描述的一半。

有些错误不够重要，无法花费2天的时间，但重要的是花费10分钟来修复它们。其他错误是不确定的，您已经知道测试环境无法证明它们已得到修复。如果设置测试环境需要2天的时间，则不要针对这些错误进行设置。相反，您将时间花在了更聪明的事情上，例如找到了在5分钟而不是2天的时间内建立测试环境的方法。

当然还有一些错误，如果您弄错了，客户将损失$ 100'000 +。还有一些漏洞，客户每小时将损失$ 100'000 +的漏洞并没有得到修复。您需要查看错误并做出决定。将所有bug视为相同的一揽子声明不起作用。

很好的问题！我的意见是，如果您无法重现问题，那么您就不能100％肯定地说您所做的修复不会：

a）实际解决问题。b）创建另一个错误

有时会发生错误，而我会修复它，而不必费力去测试它。我知道100％可以肯定。但是，直到我们的质量检查部门说它正在工作，然后我仍然认为仍然存在错误……或从修复中创建新的错误。

如果您无法重现该错误，然后安装新版本并确认已修复，那么您不能以100％的确定性说该错误已消失。

我尝试了几分钟，想出一个类比来帮助您向他人解释，但实际上没有想到。输精管结扎是一个有趣的例子，但情况不尽相同:-)

[bug相关]并发数据库访问，集群实现，多线程

在诊断和修复缺陷之前坚持重现每个缺陷并对其进行调试是否合理？

我不会花太多时间尝试复制它。这看起来像是一个同步问题，而这些问题通常是通过推理（从您必须查明问题所在子系统的日志开始）而不是找到一种方法来重现并用调试器进行攻击而发现的。以我的经验，降低代码的优化级别，有时甚至激活额外的工具，足以增加足够的延迟或缺少同步原语，以防止错误显现出来。

是的，如果您没有办法重现该错误，则无法确定已修复该错误。但是，如果您的客户没有给您重现它的方法，那么您可能也在寻找具有相同结果但具有不同根本原因的类似产品。

两项活动（代码审查和测试）都是必要的，但都不够。

您可能需要花费数月的时间来构建实验来尝试修复该错误，如果您不看代码并形成一个假设来缩小搜索空间，那么您就永远找不到任何东西。您可能要花上几个月的时间来寻找可视化代码中的错误的肚脐，甚至可能以为您已经发现过一次，两次，三遍，只是让越来越不耐烦的客户说：“不，错误仍然存​​在。 ”

一些开发人员在一项活动（代码审查与构建测试）上相对优于另一项活动。完美的经理在分配错误时会权衡这些优势。团队合作的方法可能会更加富有成果。

最终，可能没有足够的信息来修复该错误，并且您必须让它暂存一段时间，以希望其他客户会发现类似的问题，从而使您对配置问题有更多的了解。如果看到该错误的客户确实希望修复该错误，则他们将与您合作以收集更多信息。如果此问题只发生过一次，即使客户很重要，也可能不是高优先级的错误。有时，不工作错误比浪费大量的人力来寻找真正的晦涩的缺陷而没有足够的信息要聪明得多。