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