我在QA上工作时遇到了这个问题，当我问起这个问题时，我发现我的同事在进行测试时似乎并不担心这种行为。他们似乎很高兴通过测试！
这让我很讨厌。我应该报告什么？我的本能是使测试失败，并深入探讨该问题。但是，由于这可能是优先事项，因此产品负责人可能只是想先完成其他事情。但是记录一个小错误有什么问题呢？我对这种情况应该有什么反应？
#1 楼
一个只占50％的时间的错误仍然是一个错误。我仍然将其报告/记录为常规错误，但带有“间歇性”标签-让两个开发人员都知道
这样，该问题将由管理人员优先处理，提到的人员可能会提出一些使该错误可再现的想法100 ％ 的时间。您还可以通过记录下观察到的事实来使此“ IRKING”部分消失。不是-尽可能多地记录-屏幕截图，日志，堆栈跟踪，当前的理论和思想。考虑一下从一个测试执行到另一个测试执行的事情-测试顺序，不同的前后条件，网络延迟，用户访问控制等。
评论
另外，缓存。 Cronjobs。超时时间。日期更改。二手标记（就像只在工作的开始和结束发生在不同分钟内才出现的错误，因此，如果您从：59开始，您会看到它，但从：07开始，您就不会看到）。更多缓存。缓存失败。你应该怪缓存吗？
–通配符
17年6月30日在20:03
@Wildcard，无法发送超过500英里的电子邮件。
–马克
17年6月30日在23:02
@Mark读起来很有趣-以前从未遇到过这个故事。感谢张贴的链接！
– alecxe♦
17-6-30在23:32
不只是“还是个bug”。在其他条件相同的情况下，仅在X％的时间发生的错误是始终发生的错误的100 / X倍。
–R .. GitHub停止帮助ICE
17年7月2日在0:08
作为前开发人员，您能否仅给我们一个错误报告，该报告仅在50％的时间内可以在工作队列中显示？我认为那会更合适。
–corsiKa♦
17年7月4日在3:26
#2 楼
尝试获取一个可靠失败的测试用例，但归根结底，这仍然是一个错误。确保声明例如"hey, this only fails ~1/2 the time". （请注意，如果是不礼貌的话，可以解决此问题的一种方法是编写一个运行该测试的新测试用例，例如100次。）
我曾经报告过发生在
~1-in-100k times on ~1/10设备上的硬件错误...（而且我在9986 / 10k迭代中找到了它，但这仅仅是因为我忘了在离开周末之前停止了它...）根本原因是这些"if the stars line up"错误之一-在1个时钟周期窗口中进行写操作将使输出处于三态，只要该输出保持其值足够长的时间，一切都将正常。评论
最好将其框架为“嘿，这只经过大约1/2的时间”，因为这听起来比其他方法更令人担忧。
–雷电
17年7月1日在14:56
英特尔浮点错误是另一个示例。只是发生了一些价值，但修复花费了3.5亿美元，因为它永远都不会失败。
–user207421
17年7月3日在1:48
编写一个运行45％失败测试的测试20次。新测试失败。
–kaay
17年7月5日在6:31
#3 楼
不能按需复制（但已知存在）的错误比易于复制的错误更为重要。它们可能通过几种非常重要的场景发生：例如它们可能发生在实验室中可能不存在的条件下，但是很可能在客户端使用软件时出现；当您的bug可以如实地复制时，也许您可以暂时将其归档并稍后再处理。但是，如果您有一个“无法始终复制但肯定存在的错误”，则需要弄清楚并立即修复它，因为现在导致它出现的奇怪条件可能变得更加神秘，而且很少出现。 />
Therac-25是此类漏洞最著名的案例之一。我会让您自己阅读大量的Wikipedia文章，但本质上，这是一台放射治疗机，它具有与“竞赛条件”相关的错误。到发现它的时候，意识到这确实是一个错误而不是“人为错误”，许多患者因意外的大量辐射过量而死亡。所以是的，错误甚至可以杀死，甚至更难以“复制”错误。
PS。显然，这确实取决于产品的用途以及错误可能如何受到干扰（尽管这很难预测，琐碎的错误最终会触发精彩的级联而成为热门）。我没有在这里过分夸张。但是您从来没有说过该软件的真正含义，所以我选择将“高风险软件”假设作为重要性的基准。
评论
这是真的。如果您确切地知道什么是不良行为以及在什么情况下发生，您的系统仍然是可预测的。如果您不知道为什么会发生某些事情，那么整个系统将变得不可预测，并且逻辑上无法进行推理，因为您不知道哪个假设是错误的。从谎言中可以证明任何事情。
–通配符
17年6月30日在20:10
在Therac-25事故调查中更严格的处理（双关语意味）（在IEEE计算机中发布）。它很长（四页长），但是很有趣，任何与功能安全有关的人员都应该阅读。
– Peter Mortensen
17年7月1日在13:58
#4 楼
正确的反应不仅仅是“测试失败”并完成（或通过测试并完成）。您应该进行“尽职调查”，以调查是否可以始终触发该错误。如果您找到一致的触发器，请报告该事件。
如果找不到根本原因并持续触发它，请将其报告为间歇性错误，并让管理层决定该问题是否如此晦涩，无关紧要以至于无需修复，或者更多应该花费资源来挖掘根本原因。
质量保证不是为了确保质量，而是协助管理人员提供有关应用程序状态的信息，以便在分配资源时做出明智的决定。
记录一个琐碎的bug（不会被修复）没有任何商业价值，因此只是浪费时间：您（作为测试人员）和将这些bug进行分类并决定忽略它的人。 （稍后将讨论一些我认为“琐碎”的示例）。
如有疑问，请将错误输入跟踪器。
与产品负责人讨论该错误是否是微不足道的（应忽略），或者是否应报告和修复。 （亲自）交流便宜；不要通过bug跟踪器进行沟通。
在我们公司中，我们有“产品负责人”-负责对各自领域做出决定的人，他们是分类小组的成员。因此，这是为了让他们更加警惕，避免进入错误跟踪程序，而无论如何在错误分类期间都会拒绝它们，以避免浪费时间。
跟踪甚至应该忽略的错误也可能是有意义的-因此记录了忽略它们的决定，并且不再尝试输入它们。但是您的错误跟踪系统可能不是正确的输入错误的地方（可能会有太多开销）-也许是一些较轻的资源，例如已知故障的Wiki页面（因此其他测试人员可能会了解什么是故障以及什么是诚实的错误）需要报告）。但是对于大多数情况，这样的已知故障的正式列表也太笨拙了-可以通过与其他更高级的测试人员进行交流来了解。
过程并不能代替交流。
一个琐碎的bug确实是琐碎的：例如，有时在窗口大小更改时，在只有一小部分用户使用的浏览器中，页面无法正确重绘，并且可以通过刷新页面来解决，并且没有任何后果，并且您不能强迫其持续发生。
常见的间歇性错误的另一个示例是回溯，该回溯仅发生一次或很少，也就是说某些对象没有正确实例化，发生在其他一些中断/服务中断时与数据提供者合作，其代码已经好几个星期没有变化了。你能证明它与破坏有关吗？不太可能。是找出根源的好时机吗？不太可能。因此，您不必将其输入到bug跟踪器中。
有时候，我们会进行多次这样的追溯，将它们输入到bug跟踪器中将没有任何商业意义。如果数量众多且持续出现，情况就不一样了-值得跟踪和修复。
很少有评论员坚持认为每个错误都值得报告。让我不同意。也许我们不同意什么是错误。
我在质量检查部门工作了几年，发现了很多问题，因此我们决定不将其输入错误跟踪器，也不要浪费时间进行调查，因为我们要炸的鱼更大。如果您有时间和资源潜入发现的每个兔子洞中，我会感到嫉妒，但我们没有。
当然，我们确实在多年前就输入了错误，但仍未解决。有些在几年后就关闭了，因为自从报告以来，系统的某些部分发生了很大的变化，从那以后我们就没有注意到它。
但是同样可以肯定的是，我们不会将在日志中找到的每一个单向追踪都输入到bug跟踪器中，并花费大量时间进行调查。
评论
“记录琐碎的错误（不会修复）没有商业价值” –作为开发人员，完全不同意。几乎所有真正的重大问题都是“琐碎”问题的集合，尽管并非所有琐碎问题都会成为重大问题的一部分。如果未跟踪，则与跟踪问题/识别出潜在原因相比，解决主要问题将要困难得多，无论如何，您都需要这样做才能识别出这是一个微不足道的错误。管理层绝对应该确定它不值得修复，但是值得跟踪。
– Ph子
17年6月30日在9:44
因此，与其提倡记录错误，以便在所有相关人员都准备就绪且可以进行分类时在分类会议期间进行讨论/优先排序，您提倡到办公室去打扰许多人，单独谈论一些潜在的琐碎问题。 '必须向每个用户n次解释它，并尝试整理每个人的意见并充当中间人吗？而且您认为这是更有效的“交流”。否。记录错误（详细信息），继续。让分类小组在分类会议期间做出决定，这就是他们的工作。
–freedomn -m
17年6月30日在11:52
很抱歉，这个答案的上半部分很棒，但是下半部分是错误的...间歇性错误仍然是一个错误，需要报告。对一个人来说似乎微不足道的事情，可能对另一个人来说却是最便宜的。我同意沟通至关重要，但必须记录所有问题，否则您将失去可视性，这最终会增加周期时间并降低整体质量
– Taegost
17年6月30日在12:58
@ freedomn-m-不打断很多人。在我们的组织中，我们有“客户代表”负责就它们各自的领域做出决策，并且他们是分类小组的一部分。因此，这并不是打断他们，而是让他们抬起头来。如果他们会在分类中说错误是微不足道的，不值得修复，那么为什么要浪费时间呢？
– Peter M.-代表莫妮卡（Monica）
17年6月30日在14:55
@Phoshi-我添加了一个不值得跟踪的错误（回溯）示例。我是前开发人员，现在在QA中从事自动回归测试的工作，而我的日常工作的一部分是分析回溯，检测可操作的并忽略琐碎的事情。
– Peter M.-代表莫妮卡（Monica）
17年6月30日在15:11
#5 楼
50％是极高的比率。 1,000,000个客户中有500,000个会遇到此错误。作为开发人员，我需要修复此问题，并且很幸运，它很容易复制。用错误报告显然报告“ 20次中有9次”。
评论
那不是50％的意思。测试失败50％的时间，但是测试可能是百万分之一的用户使用的测试代码。
–达沃
17年6月30日在9:51
@Davor，当然，这取决于人的观点，可能会使事情变得更糟，而不是不那么值得关注。
– Tasos Papastylianou
17年6月30日在17:27
@Davor或所有用户每天使用两次的代码，在这种情况下，他们每天都会遇到它。
–user207421
17年7月3日在1:47
@EJP-完全是。测试失败50％的时间并不能告诉我们在生产中多久遇到一次此错误。它可能会在每次登录时登录，但可能永远不会登录。
–达沃
17年7月3日在11:11
#6 楼
应该报告存在错误，应该将测试视为失败。其中一个细节是失败的频率。
测试失败的45％时间对我来说绝对是失败。对于百分比没有严格的规定，但是当测试在90％以上的合格范围内-通常超过95％，例如19次通过20次运行，我可能会认为测试通过了。但是，我将创建或更新另一个故障单以跟踪那些偶发故障。 50％距此还有很长的路要走，因此我肯定会认为失败。失败。然后，您可以随时间进行报告。
评论
每次测试应给出相同的结果。如果他们不这样做，那么东西就会坏掉。不好
–索比昂·拉文·安德森（ThorbjørnRavn Andersen）
17年6月30日在4:32
一百万次运行中失败的测试或从未发生过的错误，可能是由于从未发生过的异常情况或未发生的依赖项或配置问题引起的。因此，对于这些用户不会自动“糟糕”。
–迈克尔·杜兰特（Michael Durrant）
17年6月30日在10:25
您必须先完全了解它失败的原因以及解决方法，然后才能知道。百万分之一的故障可能是很少触发的竞赛情况。
–索比昂·拉文·安德森（ThorbjørnRavn Andersen）
17年6月30日在12:25
@ThorbjørnRavnAndersen确实如此，但在分配错误修复优先级时，应考虑失败的可能性。 （好吧，这和错误的严重性。如果您的百万分之一的错误清除了数据库，那听起来还是很重要的。）
– Llewellyn
17年7月1日在21:20
@hiergiltdiestfu是的，在这些情况下，即使99.99％也可能不够用，因为万分之一的死亡是不可接受的。有些产品应具有99.9999999％
–迈克尔·杜兰特（Michael Durrant）
17年7月3日，11：38
#7 楼
在我看来，间歇性可复制的错误与每次发生的错误一样重要。它们有时是由于竞态条件造成的，当软件从测试环境迁移到生产环境时，这种恶性习惯会更频繁地发生。产生大量昂贵的支持电话。这些将需要从某人的预算中支付，尽管可能不需要从当前开发工作所支付的预算中支付。我在成熟（10年以上）的商业系统上同时进行支持和开发。 ，而花费在支持电话上的员工时间大约有一半用于解决我们尚未弄清楚如何复制的间歇性错误。知道如何复制这些错误可以使我的公司省钱。
评论
“重要”->“更重要”。您的其余答案证实了这一点。
–通配符
17年6月30日在23:32
#8 楼
很大程度上取决于您的管理层对跟踪短期内可能无法解决的问题的感觉。这可能不是bug分类的头等大事，但是他们是否想建立一个特定组件似乎表现出不稳定行为的信息？可能。追踪更严重的错误时，具有可复制的行为会很有帮助。例如，如果某个特定的代码签入在长时间运行的测试用例中导致某个特定的行为发生了变化，那么我将尝试做的一件事就是转储代码前后版本的中间活动日志和数据结构值，然后将它们进行比较，以了解行为的差异。对数据结构进行微小的更改可能会变得微不足道，而这种更改最终会在几分钟后触发不良行为。但是，如果中间行为存在很多不确定的差异，即使它们最终无关紧要，也几乎不可能看到重要行为在哪里发散。这是一个可以更改处理顺序的代码示例。我们在C ++代码中做的很多事情是使用STL集跟踪以前是否看到过对象。所以我们可能会有一个
std::set<foo *> bar;包含指向我们已经看到的foo对象的指针。现在，有时程序员想遍历该集合中的项目。您不需要做的是从bar.begin()迭代到bar.end()，因为您可能会遍历其他一些STL容器。原因是该集合中的项目将按指针值排序，以便在代码的另一轮运行中将项目分配到内存中的其他位置，可能会以不同的顺序进行迭代。从算法上讲，这可能并不重要-遍历所有项目的任何一种方式。但是，如果您希望中间结果保持一致，则要么需要按照其他条件对地图进行排序，要么需要保留用于迭代的并行指针列表或可见指针向量。有时，这样排序的微小差异可能会对代码产生巨大的宏影响，并导致间歇性错误。#9 楼
我在过去的项目中不得不面对相同的问题。
我们已经使用了快照，或者如果更难然后捕获视频，则开发人员可以轻松地检查复制步骤。
特定操作系统相关的问题，那么我们已经检查了该操作系统。
用于视频捕获的插件已使用以下插件：详细信息/ screencastify-screen-vide / mmeijimgabbpbgpdklnllpncmdofkcpn？hl = zh-CN
https://chrome.google.com/webstore/detail/loom-video-recorder-scree/liecbddmkiiihnedobmlmillhodjkdmb
#10 楼
间歇性错误的确很糟糕，如果客户遇到它们（根据我自己的经验），可能会破坏一家公司。将错误记录为跟踪器中的间歇性错误。它对公司有帮助，因为可能需要一段时间才能发现某人指出潜在问题的趋势。进一步（不同）的测试可能会突出显示其他有趣的代码行为，从而有助于确定第一个错误的原因。
但是，重要的是要检查问题是否出自您的测试。尝试重新编写代码，重新考虑代码的所有可能输入。
如果您确定同事仍然不感兴趣或取笑，请询问他们是否间歇性错误可能是由未初始化的变量引起的。我并不是说这是造成您的错误的原因，但它至少应该使您的同事谈论该问题，而不是忽略测试结果。
#11 楼
作为开发人员，我想立即深入浅出很重要。能够做到50％的时间以前从未注意到过，比罕见的不可预测的异常要好得多。在下一个版本中，它可能会再次隐藏起来。#12 楼
不要寻找方法来解释测试用例的措词以适应观察到的结果。关键在于产品及其是否适合客户使用；您的测试用例列表只是为此目的的一种手段。创建该测试用例的原因是，希望您的客户采取任何必要的措施，并且软件应每次都做出适当的响应。如果通过了，就告诉开发人员，只要知道存在，软件的那部分就没有问题。您的同事应该“只通过它”的态度，应该在其他领域寻求机会。为什么只有50％的时间会发生这种情况，这意味着它受您的一个因素的影响尚未确定（测试用例的作者也未预料到）。我看到这样的问题取决于测试数据的某些特定问题，例如字符串中的字符数或是否存在特定字符，甚至此数据库记录ID是否高于该字符。记录每次操作的详细信息，以便开发人员可以在分配固定的情况下追溯您的步骤。
#13 楼
首先，我将介绍其他情况，并留出一些时间以便稍后再访问。在重新访问时，我将以系统的方式（例如去皮洋葱）调查该情况。
根据我的经验，我将采取一些不必要的步骤，以便我将采取核心步骤以原始形式重现此问题。一旦将其简化为核心形式，我将与错误分享我的发现。
在这种情况下，即使您在投入大量时间后仍无法找到确切的步骤，但是如果您系统地进行操作，至少可以大大提高您对SUT的了解，这将在测试过程中以一种或多种方式帮助您。
#14 楼
当错误仅在50％的情况下发生时，应该报告什么？
我在质量保证工作中遇到这种情况，当我问到这个问题时，我发现我的同事在展示时测试时，似乎不太担心这种行为。他们似乎很高兴通过测试！
经常发生的错误使程序无法使用或烦人，或者有一半的时间丢失了工作，这显然是不可接受的；但是，您可能会更担心更大的问题，您的同事。
错误始终是一个错误，在计算机程序中，它是不可取的。就像看到飞虫在窗户上又在外面飞一样，当它在外面时不再是虫子并且无法再次发生？ -只有在关闭窗口的情况下才有可能。
我应该报告什么？我的本能是使测试失败，并深入探讨该问题。
如果发生如此频繁的错误，则应尝试确定何时发生和何时不发生。记录效果的严重性。这是一个小麻烦还是会导致数据损坏，这很难引起注意-优先级是确定首先出现的问题以及应专门用于修复它的资源（人员和设备）的原因。
但是，因为这可能是优先事项，也许产品负责人只是想先完成其他事情。
是的，这取决于它的作用，发生的频率以及必须完成的其他工作；但是最终，如果它永远无法修复并且破坏了程序，那当然也是一个重要因素。将表面上的次要问题留给最后只是为了发现，如果没有解决该特定问题，程序就无法发布。我应该对这种情况做出什么样的反应？
如果您看到它，则应报告您所看到的。即使只有一次。如果这是一个小问题，并且您可以清楚地看到是这种情况，那么您仍然需要对其进行记录，请相信该问题是小问题，以证明不花大量时间在该问题上。
通常情况是不可复制的或被其他人看不到，但是对于某些人来说，问题已经很明显了。可能是由于不同的硬件产生了千差万别的结果，也可能是人们对构成问题的看法。
您不希望成为发布之日说的那个人：“ Fffft，我几周前看到了这个错误，但是不用理会”。最好说：“我看到并记录了下来，但由于...而将其分配为较低的优先级。”
没有一点怀孕的感觉。如果应该是新的，请稍加使用。当有人为正确买单时，这有点不对劲。如果达到时间或金钱限制，您可以拥有可以向客户展示的文档（可能是屏幕截图），如果客户在该产品上签字，就可以覆盖，如果他们希望它得到修复，则您知道要解决的问题（或尝试复制和修改）声明其不可复制或固定）。
评论
这种行为表明代码对外部条件（也称为竞争条件）敏感。由于您所描述的确切原因，此类错误是最难识别和修复的，应予以认真对待，因为它们可能导致系统无法以生产方式对客户生产失败。您会很幸运地看到它出现的频率很高。我建议您与产品负责人交谈，并强调“并非每次都发生”不是一件好事，而是一件坏事。只需确保这是软件问题，而不是不稳定的测试。
作为开发人员，我会惊异地看到有50％的时间发生错误。这是一个错误。
这实际上取决于要测试的内容。如果这是不可控制的，例如测量一个函数运行需要多少毫秒，并且测试环境与生产环境不同，则它可能是可忽略的（或已删除）。还有其他任何东西，这是一个错误，并且可能是一个不好的错误。
我有一个错误，该错误在大约10％的时间内失败，并且放入任何跟踪或调试代码进行了修复（令人讨厌！）可能需要执行100次重复才能从统计角度确定该错误是否消失了。必须在计算机中构建自定义硬件以对其进行调试。揭示了一整套被忽略的种族状况，并且没有在其他地方出现。任何失败，请调查。错误来自您未完全了解系统的工作原理。如果您不了解系统的工作方式，那么您将在灾难性的麻烦中构建，以备后用。