很多时候，您会收到或提交“不可重现”缺陷的错误报告。它们可能可以在您的计算机或软件项目上重现，但不能在供应商的系统上重现。或者用户提供了重现的步骤，但是你在本地看不到缺陷。当然，这种情况有很多变化，所以为了简化我想我想学习的是：
贵公司对“不可重现”错误的政策是什么？搁置它们，关闭它们，忽略它们？我偶尔会在 3-rd 方框架中看到间歇性的、不可重现的错误，而且这些错误几乎总是被供应商立即关闭……但它们是真正的错误。
您是否找到任何有助于修复这些类型错误的技术？通常我所做的是从用户那里获取系统信息报告，以及重现的步骤，然后搜索关键字，并尝试查看任何类型的模式。
通常情况下，报告错误的人或重现错误的人会做错事，并且最终不会处于相同的状态，即使他们认为是这样。尝试与报告方一起完成。我有一个用户坚持认为管理员权限没有正确显示。我尝试重现错误但无法重现。当我们一起浏览时，结果发现他在这种情况下是以普通用户身份登录的。
我发现了许多“不可重现”的错误，后来才发现它们在运行 X 版本的 Safari 的 Mac OS (10.4) 上是可重现的。这不仅仅适用于浏览器和渲染，它可以适用于任何东西；当前正在运行的其他应用程序，无论用户是 RDP 还是本地用户、管理员还是用户等……在将其称为不可复制之前，请确保您的环境尽可能接近他们的环境。
一旦您验证了用户所做的一切都是正确的并且仍然遇到错误，并且您正在做他们所做的事情并且您没有遇到错误，那么就该看看您实际上可以做些什么了。屏幕截图和日志至关重要。您想确切地知道它的样子，以及当时正在发生的事情。
日志可能包含一些您可以在系统上重现的信息，并且一旦您可以重现确切的场景，您就可以诱使错误隐藏起来。
屏幕截图也对此有所帮助，因为您可能会发现“X 部分已正确加载，但它不应该加载，因为它依赖于 Y”，这可能会给您一个提示。即使用户可以描述正在做什么，屏幕截图也可以提供更多帮助。
责怪用户是很常见的，并且不相信他们所说的任何东西（因为他们称“用户控件”为“东西”），但即使他们可能不知道他们所看到的东西的名称，他们仍然能够描述他们看到的一些行为。这包括在真正错误发生之前几分钟可能发生的一些小错误，或者某些通常很快的事情可能会变慢。所有这些事情都可以作为线索来帮助您缩小导致他们机器而不是您机器错误的方面的范围。
如果一切都失败了，请尝试查看导致问题的代码部分，并可能重构或使用解决方法。如果您可以创建一个场景，从已经存在的一半信息开始（希望在 UAT 中），请让用户尝试这种方法，并查看错误是否仍然发生。您是否最好创建替代但相似的方法，以不同的角度看待错误，以便您可以更好地检查它。
简短回答：对可疑的错误代码进行详细的代码审查，目的是修复任何理论上的错误，并添加代码以监控和记录任何未来的错误。
长答案： 举一个来自嵌入式系统世界的真实示例：我们制造工业设备，包含定制电子设备和在其上运行的嵌入式软件。
一位客户报告说，单个站点上的许多设备在随机的时间间隔内遇到相同的故障。他们的症状在每种情况下都是相同的，但他们无法确定明显的原因。
显然，我们的第一步是尝试在我们实验室的同一设备中重现故障，但我们无法做到这一点。
所以，相反，我们在部门内传播了可疑的错误代码，试图获得尽可能多的想法和建议。然后，我们召开了多次代码审查会议来讨论这些想法，并确定了一个理论：（a）解释了现场观察到的错误的最可能原因；(b) 解释了我们无法复制它的原因；(c) 导致我们可以对代码进行改进，以防止将来发生错误。
除了（理论上的）错误修复之外，我们还添加了监控和日志记录代码，因此如果故障再次发生，我们可以从有问题的设备中提取有用的数据。
据我所知，这个改进的软件随后被部署在现场，并且似乎取得了成功。
错误报告、日志文件和严厉要求“如果再次发生这种情况，请立即联系我”。
如果它发生在一种情况下，而不是另一种情况下，我们会尝试列举两者之间的差异，并消除它们。
有时这可行（例如，其他硬件、双核与超线程、笔记本电脑磁盘与工作站磁盘……）。
有时它不会。如果可能，我们可能会开始远程调试。如果这没有帮助，我们可能会尝试接触客户的系统。
但是，当然，我们一开始不会写太多的错误 :)
解决了“无菌”和“幽灵”
对于这种情况，我们有两个已关闭的错误类别。
无菌- 无法繁殖。
spooky - 它承认存在问题，但它只是间歇性地出现，不太容易理解，并且让每个人都感到毛骨悚然。
好吧，你尽你最大的努力去重现它，如果你做不到，你需要仔细考虑一下这个问题是如何出现的。如果您仍然不知道，那么您无能为力。
Visual Studio 2010 中的一些新功能会有所帮助。看：
我将日志记录添加到整个程序的异常处理代码中。您需要一种收集日志的方法（用户可以通过电子邮件发送等）
预先检查代码版本和健全的环境也是一件好事。如今，随着软件更新的方便，用户运行的代码和环境几乎肯定没有经过测试。当您发布代码时它不存在。
我目前正在开发一个网络项目，我正在做一些与您的技术非常相似的事情。我正在构建一个可以引导用户访问的页面，以收集诸如浏览器版本和操作系统等信息。我还将收集应用程序注册表信息，以便查看他们一直在做什么。
这是一个非常现实的问题。我只能为 Web 开发发言，但我发现用户很少能够向我提供调查该问题所需的基本信息。我怀疑完全有可能对其他类型的开发做类似的事情。我的计划是继续开发这个系统，让它变得越来越有用。
但是我的政策是永远不会仅仅因为我无法重现它而关闭一个错误，无论它有多烦人。还有一些情况是它不是错误，但用户只是感到困惑。我猜这是一种不同类型的错误，但同样重要。
您谈论的是可重现但仅在某些系统上的问题。这些很容易处理：
第一步：通过使用某种远程软件，您让客户告诉您如何在有问题的系统上重现问题。如果失败，则关闭它。
第二步：尝试在另一个系统上重现问题。如果失败，请制作客户系统的准确副本。
第三步：如果仍然失败，您别无选择，只能尝试在客户系统上进行调试。
一旦你可以重现它，你就可以修复它。在什么系统上无所谓。
棘手的问题是真正不可重现的问题，即只是间歇性发生的事情。为此，我必须附和报告、日志和严厉的要求态度。:)
有时，即使在与生产环境完全相同的预生产环境中，该错误也无法重现。并发问题因此而臭名昭著。
原因可能很简单，因为海森堡效应，即观察会改变行为。另一个原因可能是因为触发错误的事件组合的机会非常小。
有时你很幸运，你有可以回放的审计日志，大大增加了重现问题的机会。您还可以通过大量交易给环境带来压力。这有效地压缩了时间，因此如果每周发生一次错误，如果您将系统压力提高到生产负载的 7 倍，您可能能够在 1 天内可靠地重现它。
最后的手段是白盒测试，您可以在其中逐行编写单元测试。
重要的是对此类错误（很少重现）进行分类，并对它们采取与基于特定用户操作而经常重现的错误不同的处理方式。
清晰的问题描述以及重现和观察行为的步骤：明确的报告有助于整个团队理解问题，消除错误的结论。例如，用户报告空白屏幕不同于 HMI 冻结用户操作。步骤顺序和用户操作的大致时间也很重要。用户是在屏幕转换后立即选择选项还是等待几分钟？关于时间的一个有趣的错误是汽车对香草冰淇淋过敏，这让汽车工程师感到困惑。
系统配置和启动参数：有时甚至硬件配置和应用程序软件版本（包括驱动程序和固件版本）也可能起到一两个作用。版本或配置不匹配可能会导致难以在其他设置中重现的问题。因此，这些是需要捕获的重要细节。大多数错误报告工具都将这些详细信息作为在记录问题时报告的强制性参数。
广泛的日志记录：这取决于相关项目中遵循的日志记录设施。在使用嵌入式 Linux 系统时，我们不仅提供一般诊断日志，还提供系统级日志，如 dmesg 或 top 命令日志。您可能永远不知道错误的部分不是代码流而是异常的内存使用/ CPU使用。确定问题的类型并报告相关日志以供调查。
代码审查和演练：开发团队不能永远等待最终重现这些问题然后采取行动。应调查错误报告和可用日志，并在此基础上从设计和代码中识别出各种可能性。如果需要，他们应该针对可能的根本原因准备修补程序，并在包括识别它的测试人员在内的团队之间分发修补程序，以查看错误是否可以用它来重现。
在确定并签入修复后，不要根据单个测试人员/团队的观察来关闭这些问题：也许最重要的部分是关闭这些问题所遵循的方法。一旦检查了这些问题的修复，应通知不同位置的所有测试/验证团队以运行密集测试并识别回归错误（如果有）。只有所有（实际上大多数）报告为不可重现，关闭评估必须由高级管理人员完成。
如果无法重现，请获取日志，重现重现的确切步骤的屏幕截图。
Windows 7 中有一个不错的新功能，允许用户记录他们正在做的事情，然后发送报告——它以文档的形式出现，每个阶段都有屏幕截图。希望它在用户以开发人员不会想到的顺序与应用程序交互的情况下有所帮助。我已经看到了很多错误，这只是开发人员使用应用程序的逻辑方式与最终用户的实际操作方式不相符的情况......导致许多细微的错误。
记录是你的朋友！
通常，当我们发现无法重现的错误时会发生什么，我们要么要求客户打开更多日志记录（如果可用），要么我们发布一个在我们感兴趣的区域周围添加额外日志记录的版本。一般来说我们拥有的日志记录非常好，并且能够非常冗长，因此发布带有额外日志记录的版本并不经常发生。
您还应该考虑使用内存转储（IMO 也属于日志记录的范畴）。生成小型转储非常快，通常可以在生产服务器上完成，即使在负载下（只要生成的转储数量很少）。
我的看法：能够重现问题很好，因为它为您提供了一个可以更自由地调试、实验和玩耍的环境，但是 -重现错误对于调试它绝不是必不可少的！如果错误仅发生在其他系统上，那么您仍然需要以相同的方式诊断和调试问题，只是这次您需要更聪明地了解如何执行此操作。
公认的答案是最好的通用方法。在高层次上，值得权衡修复错误的重要性与您可以添加的功能或增强功能的重要性，以使用户受益。一个“不可重现”的错误是否需要两天时间才能修复？是否可以在那个时候添加一个功能，让用户获得比修复错误更多的好处？也许用户会更喜欢该功能。作为一名开发人员，我有时会关注我能看到的缺陷，然后要求用户提供反馈，但他们实际上都没有提到我能看到的错误，但该软件缺少他们真正想要的功能！
有时，在调试的同时尝试重现错误的简单持久性可能是最有效的方法。要使这种策略起作用，错误需要是“间歇性的”，而不是完全“不可重现的”。如果您甚至可以在 10 次中重复一个错误，并且您知道它最有可能发生的位置，您可以在这些点放置断点，然后顽固地尝试重复该错误并查看到底发生了什么。我经历过这比登录一两个案例更有效（尽管一般来说，登录是我的第一个选择）。