处理'不可重复'错误的任何好策略？

通常,您将获得或提交"不可重现"缺陷的错误报告.它们可以在您的计算机或软件项目中重现,但不能在供应商的系统上重现.或者用户提供重现步骤,但您无法在本地查看缺陷.当然,这种情况有很多变化,所以为了简化,我想我正在努力学习的是:

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

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

验证用于产生错误的步骤

报告错误的人或者重现错误的人通常会做错事并且不会以同样的状态结束,即使他们认为错误也是如此.尝试与报告方一起完成.我有一个用户INSIST,管理员权限没有正确显示.我尝试重现错误,但无法.当我们一起走过时,事实证明他是在这种情况下以普通用户身份登录的.

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

我发现了许多"不可复制的"错误,后来才发现它们在Mac OS上可以重现(10.4)运行X版Safari.这不仅适用于浏览器和渲染,它可以应用于任何东西; 当前正在运行的其他应用程序,无论用户是否为RDP或本地,管理员或用户等...确保您的环境尽可能接近他们的环境,然后再将其称为不可复制的.

收集截图和日志

一旦你确认用户正在正确地做所有事情并且仍然遇到错误,并且你正在做他们正在做的事情,并且你没有得到错误,那么现在是时候看看你能做些什么了.屏幕截图和日志至关重要.你想确切地知道它的样子,以及当时正在发生的事情.

日志可能包含您可以在系统上重现的一些信息,并且一旦您可以重现确切的方案,您就可以从隐藏中哄骗错误.

屏幕截图也有帮助,因为您可能会发现"X片段已正确加载,但它不应该因为它依赖于Y",这可能会给您一个提示.即使用户可以描述正在做的事情,屏幕截图也可以提供更多帮助.

收集用户的逐步说明

责备用户是非常普遍的,不要相信他们所说的任何东西(因为他们称之为'用户控制'是'东西'),但即使他们可能不知道他们所看到的名字,他们仍然能够描述他们看到的一些行为.这包括一些可能在真正的错误发生之前几分钟发生的小错误,或者某些通常很快的事情可能会缓慢.所有这些都可以成为线索,帮助您缩小导致机器错误的方面,而不是您的机器.

尝试替代方法以产生错误

如果所有其他方法都失败了,请尝试查看导致问题的代码部分,并可能重构或使用变通方法.如果您可以创建一个场景,从那里开始,已经有一半的信息(希望在UAT中)请用户尝试这种方法,并查看错误是否仍然存在.您最好创建替代但类似的方法,将错误转化为不同的光,以便您可以更好地检查它.

简短回答:对可疑错误代码进行详细的代码审查,目的是修复任何理论错误,并添加代码以监控和记录任何未来的错误.

答案很长: 从嵌入式系统世界中给出一个真实的例子:我们制造包含定制电子产品的工业设备,并在其上运行嵌入式软件.

一位客户报告说,单个站点上的许多设备以随机间隔出现相同的故障.他们的症状在每种情况下都是相同的,但他们无法找出明显的原因.

显然,我们的第一步是尝试在我们实验室的同一设备中重现故障,但我们无法做到这一点.

因此,我们在部门内部传播了可疑的错误代码,以尽可能多地获取想法和建议.然后,我们举行了一些代码审查会议来讨论这些想法,并确定一个理论:(a)解释了在现场观察到的最可能的故障原因; (b)解释了为什么我们无法复制它; (c)导致我们可以对代码进行改进,以防止将来发生错误.

除了(理论上)错误修复之外,我们还添加了监视和日志记录代码,因此如果再次发生错误,我们可以从相关设备中提取有用的数据.

据我所知,这个改进的软件随后在现场部署,似乎已经成功.

错误报告,日志文件和严厉要求"如果再次发生这种情况立即与我联系".

如果它发生在一个上下文中而不发生在另一个上下文中,我们会尝试枚举两者之间的差异,并消除它们.

有时这是有效的(例如其他硬件,双核与超线程,笔记本电脑磁盘与工作站磁盘......).

有时却没有.如果可能,我们可以开始远程调试.如果这没有帮助,我们可以试着抓住客户的系统.

但是,当然,我们不会在第一时间写出太多错误:)

解决了"无菌"和"怪异"

对于这种情况,我们有两个封闭的错误类别.

无菌 - 无法繁殖.

怪异 - 它承认有一个问题,但它只是间歇性出现,不太容易理解,并且给每个人一个微弱的小怪案例.