如何说服团队成员“ mandelbug”的存在

我们正在开发一个应用程序；它包括由另一个编码器开发的库，该库通过多个网络连接与服务器通信，并且涉及多个线程一起工作。服务器端代码非常复杂，我们无法访问源代码。

最近，我发现了一个Mandelbug有时会使应用程序崩溃。我可以重现一次并获得堆栈跟踪，因此打开了一个错误报告。该错误本身易于修复（后台线程之一中未捕获的Web异常，这使CLR终止程序）。

问题是开发人员拒绝修复该错误，因为“他不相信它的存在”。不幸的是，老板对我表示支持，并说除非我创建一个“可靠的测试用例”以证明该错误的存在并进行单元测试以确认该错误已消失，否则无法修复该错误。由于bug的性质，基本上是不可能的。

有什么建议吗？

如果可能，请花一些时间检查是否可以通过在应用程序代码中放置一些睡眠或阻止来重现此缺陷。但是不要花太多时间。由于此问题是由于多头处理（以及您所观察到的）所致，所以这种情况很少发生。

我的建议是不要为此付出太多。继续你的工作。每当您遇到此崩溃时，请使用堆栈跟踪更新您的错误报告，并说这是重复发生，并将所有者更改为库开发人员。让管理人员/领导根据其频率决定是否修复。

同时尝试了解开发人员的心态。您说“未捕获的Web异常”。在此阶段，开发人员可能无法完全确定抓住这一点的其他影响。因此，他/她可能不愿意触摸该代码。

因此，从您或多或少的澄清意见中，我是这样得到的：

您确定仅缺少简单的其他异常处理，并且您已经知道lib中的哪行代码有问题以及如何修复lib。

那么，为什么不自己将一些缺少的代码行添加到库中呢，请团队友好地测试更改后的库呢？确保这是一个低风险的更改，负责lib的开发人员易于理解。可能发生的最糟糕的情况是，如果您的修复导致一些新的意外行为，则有人必须还原VCS中的更改。

大多数人更容易说服工作何时完成。同样，他们对“这是一个改进的解决方案”有更好的反应，而不是“此代码是错误的，请以某种方式解决”。

编辑：当开发人员仍然拒绝添加该更改时，最好的选择是尝试使有问题的代码在隔离的测试工具中工作，在其中模拟网络错误。与遗留代码的有效合作描述了许多有关如何解决此类问题的技术。例如，您可以创建该库的测试版本，仅包含有问题的模块和功能，并在该库周围创建一个“模拟环境”，以便在受控条件下模拟“网络异常”。乍看之下，这似乎耗费了很多精力，但是一旦有了这样的环境，就可以向它添加很多其他测试（而且我猜想这是有道理的，因为lib的作者拒绝添加缺少的内容一处处理异常

对于此类错误，自动化的模糊测试（也称为随机测试）可能有助于重现该错误。通过将一组固定的参数（或输入）随机分配到您要测试的对象中，这可以自动发现错误。每次测试运行时，参数都会记录到日志文件中，包括时间戳等，以便当发生崩溃时，您可以（理论上）仅使用相同的参数来重放测试以重现它。

由于它是自动化的，因此测试过程可以在短时间内运行许多测试。通常，它可以整夜运行，而在早晨，您可以检查日志文件以查看它是否重现了崩溃。

魔鬼的拥护者提出了另一条道路。

另一位开发人员断然声明那里没有错误。

您能否提出一种方法来从他所谓的不存在的错误中释放出麻烦，并使其更频繁地崩溃？

堆栈跟踪清楚地表明了该错误的存在，或至少在某个特定版本中确实存在。您所没有的就是该错误已修复的证据。他们无视它是愚蠢的。在多个系统上进行成千上万次自动尝试之后，我曾经有“无法重现”的错误，这些错误在客户系统上每次触发一次。

每年我都会收到一些类似的错误，大多数错误甚至没有堆栈跟踪的好处。在几乎每种情况下，即使我无法事先复制它，也可以在修复后很容易地对其进行自动化测试。

例如，几个月前，我修复了一个错误，该错误仅在用户键入速度超过每分钟96个单词时才发生。在我修复它之前，我只知道该错误“有时”发生。对我来说，编写用于快速打字的单元测试永远不会发生。但是，在我知道了根本原因之后，对其进行测试是微不足道的。

即使在极少数情况下，即使修复了错误也无法再现错误，您也可以通过代码检查将其关闭。