bug-tracking - 有什么好的策略来处理 'not reproducible' 错误吗？

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 2 年前。

Improve this question

您经常会收到或提交“不可重现”缺陷的错误报告。它们可能可以在您的计算机或软件项目上重现，但不能在供应商的系统上重现。或者用户提供了重现步骤，但您无法在本地看到缺陷。当然，这种情况有很多变化，所以为了简化，我想我想要学习的是:

贵公司对“不可重现”错误的政策是什么？搁置它们、关闭它们、忽略它们？我偶尔会在第 3 方框架中看到间歇性的、不可重现的错误，这些错误几乎总是被供应商立即关闭……但它们是真正的错误。

您是否找到了有助于修复这些类型错误的技术？通常我所做的是从用户那里获取系统信息报告，以及重现的步骤，然后搜索关键字，并尝试查看任何类型的模式。

Answer 1

• 验证产生错误的步骤

通常，报告错误的人或重现错误的人会做错事，并且最终不会处于相同的状态，即使他们认为自己是这样。尝试与报告方一起完成整个过程。我有一个用户坚持认为管理员权限没有正确显示。我尝试重现该错误，但无法重现。当我们一起检查时，发现他在这种情况下是以普通用户身份登录的。

• 验证用于产生错误的系统/环境

我发现了许多“不可重现”的错误，后来才发现它们可以在运行 X 版本 Safari 的 Mac OS (10.4) 上重现。这不仅仅适用于浏览器和渲染，它可以适用于任何东西；当前正在运行的其他应用程序，无论用户是 RDP 还是本地用户、管理员还是用户等……在称其为不可重现之前，请确保您的环境尽可能接近他们的环境。

• 收集屏幕截图和日志

一旦您验证了用户所做的一切都是正确的，但仍然遇到了错误，并且您正在做他们所做的事情，并且您没有遇到错误，那么就该看看您实际上可以做些什么它。屏幕截图和日志至关重要。您想确切地知道它是什么样子，以及当时到底发生了什么。

日志可能包含一些您可以在系统上重现的信息，一旦您可以重现确切的场景，您就可以将错误隐藏起来。

屏幕截图也对此有所帮助，因为您可能会发现“X 部分已正确加载，但它不应该加载，因为它依赖于 Y”，这可能会给您一个提示。即使用户可以描述正在做什么，屏幕截图也能提供更多帮助。

• 从用户那里收集分步说明

责怪用户并且不相信他们所说的任何内容(因为他们将“用户控件”称为“东西”)是很常见的，但即使他们可能不知道他们所看到的内容的名称，他们仍然会能够描述他们所看到的一些行为。这包括在真正错误发生之前几分钟可能发生的一些小错误，或者某些通常很快的事情可能会很慢。所有这些都可以作为线索，帮助您缩小导致他们机器而不是您机器上的错误的方面。

• 尝试其他方法来产生错误

如果所有其他方法都失败，请尝试查看导致问题的代码部分，并可能重构或使用解决方法。如果您可以创建一个场景，从已有的一半信息(希望在 UAT 中)开始，请用户尝试该方法，并查看错误是否仍然发生。您是否最好创建替代但相似的方法，从不同的角度看待错误，以便您可以更好地检查它。