#1 楼
我将采用与统计不同的方法（尽管我认为其他答复更直接地回答了您的实际问题）。每当我作为质量保证或支持角色遇到“仅在某些情况下才会发生的问题”时，这是一项调查活动，目的是缩小事件不定期发生或在什么情况下发生的范围。某些（但不是全部）调查点可能是：
特定帐户或数据。
主机/环境中的差异导致应用程序或服务正在运行。
不同版本的应用程序或服务在不同的主机上运行
特定的日期，日期，时间或时区。
特定的用户及其访问应用程序的特定方式（物理设备，浏览器，网络连接）
这种情况使得报告问题的人的复制步骤和其他详细信息对于解决他们的问题非常有价值。如果您的实验是基于错误的假设，则在您进行有根据的猜测时告诉客户“您的问题已解决”会朝负面方向发展。以我的经验，最好指导他们有关哪些信息将帮助解决他们的问题以及他们如何帮助您解决问题的信息。
评论
我可以添加一个让我工作的公司陷入困境的真正默默无闻的公司吗？ “已登录的用户名中的字符是否为奇数或偶数”。 （这意味着开发人员没有问题，第一个测试用户遇到了问题。）
–马丁·邦纳（Martin Bonner）支持莫妮卡（Monica）
19年5月28日在17:12
那绝对是有趣的。达到如此细微的差异总是一个很好的挑战。
–雪莉
19年5月28日在18:09
早在世纪之交之前，当某个特定国家/地区的某个特定国家/地区的转接呼叫（通过该国家/地区发起但在其他国家/地区终止）进行转接时，我们遇到的问题是通话次数增加一倍。那是完全确定性的，但要追根溯源。 （根本原因是一个错误的数据库驱动程序以20个批为单位获取行）
– JollyJoker
19年5月29日在7:38
这么多除了硬件故障（确实存在错误的RAM）之外，大多数问题都是确定性的。甚至竞争条件也只是A的奇特名称，有时出现在B之前。如果您的行为举止怪异，则意味着您已充分确定了发生这种情况的条件。
– Matthieu M.
19年5月29日在11:22
只是另一个轶事例子-我们遇到了一个问题，一旦客户报告有时发生并且我们无法复制。我们设法将一位出色的质量检查人员缩小到...网络延迟。她玩过Chrome中的网络限制选项（位于开发工具下），发现问题几乎完全是在某些网络速度之间发生的。在快速的网络上，您将看不到问题，在速度非常慢的网络上也将看不到问题。它发生在狭窄的范围内。它仍然是不规则的，但她发现大约80％的时间出现了最佳速度。
– VLAZ
19年5月30日在11:22
#2 楼
您必须在非固定版本和假定的固定版本上执行相同的测试次数相等。您必须证明，在未修复的版本上，测试每隔N次随机失败一次。每次都通过相同的测试，或者至少失败的次数更少，是固定版本。
您必须证明1和2之间的唯一区别是“修复”本身，而不是任何外部或环境因素。
如果仅在新的固定版本上执行测试，很可能是该错误是由不相关的环境因素导致的，而现在您的测试中根本不存在该错误。
评论
+1表示验证旧版本仍然失败的原理。由于某些外部变化（例如网络速度），随机bug随机消失几天的方式太容易了。
– jpa
19年5月29日在6:53
在不太严格的平台（例如Javascript）上，这确实令人讨厌。根据计算机处理脚本的速度，可能会发生覆盖函数的竞争状态，并且代码可以根据网络延迟和特定脚本的加载时间随机调用其他函数。
–尼尔森
19年5月29日在8:58
#3 楼
我想这个答案可以帮助您您需要首先确定要以什么概率“发现”问题。
这是一个很好的例子，说明了为什么理论知识是
简化版本：
p是失败的概率，在我们的例子中是1 / N，然后成功为1-p
，进行N次成功尝试的概率为（1-p）^ N
，因此进行N次成功尝试的概率为1-（1-p ）^ N
提取N并在假设N足够大的情况下进行简化，从而得出：
-log（1-p）⋅N
评论
我将用“信心”代替“概率”。您想要多自信？请注意，要确定100％的可信度，您将需要执行无数次测试，因为当x变为1时-log（1-x）变为无穷大。
– dzieciou
19年5月28日在18:20
所有这些都是基于假设测试执行是独立的。例如，该错误不会累积，而是由于n次执行的累积而显示出来。
– dzieciou
19年5月28日在18:21
这实际上是一个正确的观点，@ Makyen，我编辑了答案
–Rsf
19年5月29日在8:07
通过定义x可以大大改善此答案，x恰好出现在最后一个项目符号中。
–格雷戈·托马斯（Gregor Thomas）
19年5月31日在1:54
#4 楼
我同意其他回答“深入了解”的问题时，请回答标题中的实际数学问题：如果问题完全随机发生且概率为
p，则至少出现的可能性为在n试用版中有一次是1-(1-p)^n。将其设置为x（您对问题已得到解决的信心）并解决n，就会为您n = log(1-x)/log(1-p)
因此，例如，如果您的问题发生了1 4次中，有95％要确定它已被修复（这意味着您会错误地将其标识为20次中的1次！！），然后
p = 0.25
x = 0.95
n = log(0.05)/log(0.75) ≈ 10.4
，因此您需要进行11次试验
我的答案与@ emrys57的区别在于，我的假设是您知道概率，而他们的假设是您知道结果的某些初始顺序。大概他们都应该以足够大的初始序列给出相同的答案。
#5 楼
已经观察到一个问题，有时在测试中会产生错误。我们实际上并不知道在任何给定的测试运行中都会产生错误的可能性，因为我们只能对损坏的系统进行有限数量的测试。如果1表示一次测试通过，而0表示一次测试失败，则我们可能会从多个测试中获得一系列结果，如下所示：12项测试中有6项失败。这使我们对损坏的系统进行测试失败概率的猜测Pf。我们假设这种可能性不会随时间变化。但是，由于我们不能进行很多测试，因此Pf的实际值存在很大不确定性。
在进行这些测试之后，我们进行了维修。我们希望这可以解决问题，但我们不确定。我们对修复后的系统进行更多测试。如果已解决问题，则修复后测得的Pf值应为0。如果尚未修复系统，则该值应与修复前的Pf值相同，而Pf不变。
如果我们在修复后进行了一些测试，但一项测试失败了，我们会立即知道修复失败。问题是，如果维修后没有任何测试失败，那是否意味着维修成功了？测试合格）
包括维修后：c个（测试合格）
a + b初始结果的排列方式为
011001010011
如果Pf不变，但最后C个结果都是1，我们需要在前a + b-c结果中排列b-c。排列这些第一个a + b-c结果的不同方式的数目是一个。
如果更改并未真正修复系统，但实际上保持其状态不变，则我们观察到的结果将是零和随机生成的随机集合，具体取决于单个实验返回零或一的概率Pf结果。鉴于此，我们将观察到由零和b组成的模式，而最后c个结果均为“ 1”的机会是
Ntot = (a + b)! /(b! * a!)
或
Nsuc = (a + b - c)! / ( (b - c)! * a! )
或
Cran = Nsuc/Ntot
维修是对系统进行维修后观察到c测试通过的机会。总共有a次失败，b次通过，但实际上我们什么都没改变，我们看到偶然发生的修复之后的一系列通过。
例如，上面的模式是修复之前的，还有6种（通过）修复后，克兰略小于5％。要使99％的修复成功，您需要在修复后进行11次通过。
有一个电子表格可以复制以进行此计算。我希望我一切都好，自从我上次解决这个问题已有15年了。那时，我花了15年的时间才找到答案。
#6 楼
令B表示“破碎”，F表示“固定”，E_k表示“在k次试验中观察到的错误”。您是说P（E_1 | B）= 1 / N;假设已损坏，则在单个观察结果中看到错误的概率为1 / N。现在，它本身可能会存在一些不确定性，因为测量它的唯一方法可能是查看失败的频率并进行经验估算。但是，如果我们按照给定的条件进行贝叶斯定律，则如果我们的先验概率为P（B），则后验概率为P（〜E_k | B）P（B）/ P（〜E_k）。对于P（〜E_k | B），我们有P（〜E_k | B）= P（〜E_1 | B）^ k =（1-P（E_1 | B））^ k = （1-1 / N）^ k =（（N-1）/ N）^ k。对于大N和k，我们可以将其近似为e ^（-k / N）。
对于P（〜E_k），我们有P（〜E_k）= P（〜E_k | B） P（B）+ P（〜E_k | F）P（F）。 P（〜E_k | F）= 1（如果已解决问题，我们将保证不会出现任何错误）。 P（F）只是1-P（B）。
全力以赴，我们有
P（B |〜E_k）〜= e ^（-k / N）P（B）/（e ^（- k / N）P（B）+ 1-P（B））
通过设置X = e ^（-k / N），Y = P（B）可以更容易阅读。然后我们有
XY /（XY + 1-Y）
或
1-（Y-1）/（XY + 1- Y）
评论
@谁投票决定关闭-您会说这主要是基于意见的吗？或可以用数学和概率回答？这当然不是基于观点的，而是与统计分析有关的。尽管在与数学相关的SE中可能会（也曾经）问过这个问题，但这在这里非常相关，并且上下文可能会有所不同。
@JoãoFarias当然，控制所说的随机性确实很棘手。我喜欢看CHESS的示例，该示例竭尽全力模拟OS的调度算法以查找多线程错误。有时，统计方法虽然不令人满意，但从业务角度来看可能更有价值。
如何确定很少复制的问题已解决？
作为开发人员，“这将随机失败”实际上意味着“我还无法查明导致失败的情况，而且我无法花更多的时间进行调查”。同样，“我已经解决了这个随机错误”的意思是“该错误仍然会发生，但是您不会再注意到了，因为我已经添加了逻辑来捕获它并修复任何错误的数据或引起的操作”。