如何处理我认为已修复的错误，但我不确定

有些错误很难重现，很少发生，而且似乎是随机的。可能会发生，我找到了可能的原因，进行了修复，测试了程序，并且无法重现该错误。但是，由于不可能可靠地重现该错误并且它很少发生，因此如何在Bugtracker中指出呢？常见的做法是什么？

如果我将设置status为固定，并将设置solution为固定，则意味着完全固定了，不是吗？

是否通常将“ status固定”和“ solution打开” 设置为向测试人员表明“它可能是固定的，但需要更多注意以确保”？

编辑：大多数（如果不是全部）错误跟踪程序都具有两个用于错误状态的属性，也许名称不相同。通过status我的意思是新的，分配，固定，封闭等，并通过solution我的意思是开放的（新），固定的，无法解决的，不可重复的，重复的，而不是一个错误，等等。

是否通常将状态设置为“固定”并打开解决方案，以向测试人员表明“状态可能是固定的，但是需要更多注意以确保”？

无论是否常见，这都是正确的做法，而您却列出了自己的原因：无论如何，这都是一种很好的方法

向测试人员表明“它可能是固定的，但需要更多注意以确保”

旁注，即使特定的错误跟踪器没有您所描述的字段solution，开发人员也可以至少添加上面解释的自由格式注释。

_{...并且如果错误跟踪程序不允许在问题中添加评论，则必须将其替换为该问题。能够添加自由形式的说明是一项至关重要的功能，因为问题相差太大，无法适应某些预定义的形式。}

测试团队将决定问题是否已解决以及是否可以解决。如果有更多的回归，修复程序的副作用，或者修复程序本身在其他情况下无效，则该问题将重新出现。但是，如果您已经进行了足够的开发人员测试，则最好将其标记为已修复。

有些错误很难重现，很少发生，而且看起来是随机的。可能会发生，我找到了可能的原因，进行了修复，测试了程序，并且无法重现该错误。

实际上，如果没有可重现的测试方案，我什至不会尝试事先修复此类错误。如果您想让测试人员更多地关注它，请给他们一个创建可复制场景的机会。

例如，假设您更改了程序，测试人员花了1个小时尝试重现该错误，但该错误没有弹出-足够一个小时吗？还是因为该漏洞已得到修复而进一步测试浪费时间？

另一方面，当您不更改程序，并且错误在1小时内没有弹出时，测试人员很可能应该再花一个小时来尝试其他事情。当测试人员投入一天的时间而无法再复制该错误时，真的值得尝试修复它吗？

话虽如此，您可以考虑如何在错误跟踪系统中对该流程进行建模：不尝试对其进行修复并将其移交给测试人员可能是“打开”之类的错误状态。如果测试人员无法复制它，则显然是“不可复制的”。希望这不会发生，他们会找到可重现的方案，您可以找到错误的根本原因，进行修复，并将状态设置为“已修复”。尽量避免陷入“不知道它是否已修复”之类的问题。

有时，您仅有的唯一证据纯粹是统计信息，例如，每月发生一次或两次，但似乎与任何事物都没有联系。这些总体上来说是我所遇到的最糟糕的诊断和解决错误类型，因为您无法确定您的修补程序是否具有确定性。我必须解决的最后一个问题以统计学上的修正结束：症状的发生率降至我们开始时的10％。最后一块从来没有找到，或者也许是，但是没有人可以告诉。

我有两条建议：（1）假设可能有多种原因起作用，直到您另行知道为止；（2）假设症状可能如何存在，然后拆解甚至涉及很远的每条逻辑。深入的演练有时是达到令人满意的结果的唯一方法。