其中一些错误似乎是
我跟踪出现的错误，无法在特定站点的实时环境中复制或仅在特定站点上复制（假设同一应用程序正在不同站点（客户端）上运行）。跨运行相同应用程序（不同实例）的各个站点，查找前端用户可见的错误或引发的大量相同类型的错误，并将这些错误作为错误放入开发队列。我一直在从开发中获得案例，因为它们无法修复，因为它们无法复制，并且因为我没有提供足够的细节。
所以我的问题是，如果您知道错误总是被抛出，但似乎修复和重现该问题所需的精力太高。那你该怎么办？
我的建议之一是使调试问题和获取更多信息变得更加容易。然后，当我们了解更多信息时，便可以尝试解决该问题。
#1 楼
我将报告该问题，但要清楚地描述我无法复制。作为测试人员，我不是要决定在重现此问题上付出了多少努力。我认为我们应该发挥信号作用。风险
如果报告包含估计的风险，真实的用户确实有问题并且可能卡住并且可能无法使用，那很好某些功能，这会降低用户体验。
调试
从代码的角度来看，一个问题可能很容易理解，即使无法再现也是如此。如果开发人员对此也感到困难，则可以添加额外的日志记录。现在，再次监视该问题，并查看是否可以使用其他信息解决该问题。重复直到修复。问题。这样，任何研究都不会丢失，并且可以在以后的阶段中重复使用。
评论
由于按期付款，我几乎要对此投票。总体而言，很棒的建议。 CYA也适用于此。
– Paul Muir
2015年1月19日，17：17
@PaulDonny Lol，那是个玩笑。我从答案中删除了“也向我报告的每个问题付款；-)”。我实际上没有因缺陷而得到报酬。
– Niels van Reijmersdal
15年1月19日在17:24
#2 楼
应该报告该问题，并在报告中加注说明您无法一致地（或根本无法）重现该问题，并且将在有更多可用信息时更新该报告。您的下一步应该包括以下策略的一些组合：如果可以增加日志记录的级别，请这样做并保留日志记录，直到再次出现该错误为止。有时，您可以将其发送给对该错误问题最多的客户，并在错误再次发生时让他们发送日志。日志中记录的事件序列可能足以使开发人员确定正在发生的事情（您可能无法验证这些事件，而不得不依靠客户报告该问题不再发生）。
如果您可以获取屏幕录像或键盘记录，执行此操作。
如果有错误的堆栈转储，则将其附加到以前记录的内容中。
如果它是Web应用程序，并且可以提取Web服务器日志，请这样做。浏览服务器日志可能很痛苦，但是它也可以为您提供重要信息。如果服务器日志中没有足够的信息，请查看是否可以提高日志记录级别，直到问题再次出现并可以捕获该信息。
您可能需要捕获多个来源的日志以跟踪问题。最近我遇到一个案例，问题是用户最终会在原始作业完成之前重试该作业，并在此过程中破坏了该作业使用的数据。要对其进行跟踪，我需要来自多个服务的日志和时间戳，以便重新创建实际发生的事情。
对于Web应用程序，您可能还需要捕获客户端信息字符串并在虚拟机中尽可能紧密地重新创建用户环境。
一旦您制定出或多或少可靠的方式进行复制（如果可以），请使用该信息更新报告。您可能需要间歇性地尝试复制数周或数月。
即使问题报告以不可再现的状态存在了几个月，它仍然可以提醒您该问题的存在，这意味着如果它开始更频繁地发生，则可以重新确定问题的优先级。
评论
这是彻底的，并且似乎是一个好的做法。但是，我认为并非所有错误都值得在此级别上努力（如果您认为用户看不到的应用程序错误不太重要）。以我为例，我正在查看Web应用程序的错误日志，最终使用时看不到某些错误，但是它们仍然会堵塞日志，并且最好予以纠正。我意识到，询问如何处理这些情况似乎很重要，我实质上是在暗示它们并不总是值得进行彻底的调查。
– Vincent巴西
2015年1月12日13:12
@VincentBrazil如果它们阻塞了日志，那么也许应该从登录周期中删除它们。我记得有一段时间我们停止查看日志文件，因为这要花很多时间。最终忽略完整日志可能会更糟，然后在这些问题上花费一些时间。
– Niels van Reijmersdal
2015年1月12日13:35
@VincentBrazil-如果您确定这些错误对应用程序没有影响，那么可以，您可以选择不记录它们。有一些错误属于此类：您只需要监视一段时间以确保没有影响（有时隐藏的错误会使应用程序进入不稳定状态，从而在其他地方导致明显的错误）。
–凯特·保罗（Kate Paulk）
15年1月13日在11:47
#3 楼
无论如何都要提高它并提供尽可能多的细节（时间，日期，错误日志，测试证据等）。如果它影响到进一步的事情，如果项目经理或利益相关者询问为什么没有做某事，这将掩盖您的后脑。我已经经历过几次，而没有可复制的，所以开发人员只是说“如果您不能复制它，我将无法修复”。我们的工作是根据要求提出缺陷-如果开发人员后退并决定不跟进，这不是您的问题：)
#4 楼
报告错误。开发人员可能出于某种原因或其他原因不愿或无法解决该问题，但是如果未报告，则开发人员将无法解决该问题。提供尽可能多的详细信息尽你所能。我记得几个月前看到的一个错误，该错误仅是由于用户在公司VPN以外的生产环境中以特定帐户运行Internet Explorer。如果这四个变量中的任何一个发生了更改，该错误都不会出现。开发人员很难重现该错误，因为自然地，他们的机器都在VPN上，因此即使尝试使用不同的浏览器，不同的帐户以及测试/分期/生产，该错误也不会出现。如果您过于冗长，可能会叹息或烦恼，但是如果您给的不足，开发人员将积极抱怨，并且不会进行任何错误修正。
#5 楼
在全球范围内，您要确定风险并采取适当的措施（可能不采取任何措施）。因此，您真的想知道错误的后果是什么，以及错误发生的频率和/或可能性。如果它很少见并导致一些较小的UI异常，则不值得追求。如果每次在目标网页上都发生这种情况，或者您正在失去客户金钱，那么至少您将需要添加其他诊断代码，并且可能想探索其他方法来快速确定并修复导致此问题的原因。更常见的是，风险介于两者之间，因此应对风险的程度是一个判断。我从“全球”这个词开始，因为实际上，做所有事情的能力和责任通常由开发团队，测试团队和可能的许多其他涉众组成。因此，除了技术答案外，还可能存在一些官僚主义的问题解决方法。牢记全球目标，希望您或团队中的某人在该领域具有技能。
#6 楼
除了其他建议外，您还可以尝试“会话重播”工具。您可以查看在后端记录错误时用户执行的确切操作。这对开发人员有很大的影响。当他们看到此消息后，便立即认为出了问题，并将其关闭。我不知道该类别中是否有任何Opensource工具，但我们使用的是Splunk中的工具。我的上一个项目使用了Adobe的类似工具。
#7 楼
如果发现问题，即使不容易重现也必须报告。因为它可能会带来更大的问题，并且可能很容易解决，所以您必须与开发人员讨论，并且如果它发生一次或不经常发生，我建议在Google chrome浏览器上使用Screencastify之类的录像机。 br />评论
并非所有错误都是由测试仪生成的，因此无法记录。开发人员推迟了无法轻松复制或解决的问题，这意味着您最终陷入僵局，测试人员报告了问题，而开发人员则表示无法解决。这不是有效利用任何人的时间。
– Vincent巴西
2015年1月12日在10:15
#8 楼
第一步，我建议您对源代码进行分析，以确定哪些是应用程序不确定性的根源（即，有可能使应用程序执行方式不同的任何事物）。通常有两种类型（每种都有很多子类型）：-input；
-内存交织
您可以在此处找到有关非确定性来源的更多详细信息。
产生误入歧途的可能性：如果您的应用程序仅具有第一种类型的源（输入），实现确定性重放可能并不那么困难：使用面向方面的编程，程序工具或其他日志记录工具记录所有类型的输入。一旦引起错误，就可以使用日志确定性地重现该错误。
（非常）难以解决的可能性：如果内存交错对问题有直接影响（例如，多个线程访问同样的资源，同步性很差或没有同步），日志记录不是您的朋友。这是因为记录线程访问的不确定性会导致严重的性能下降（您可能最终不得不重新引导系统）和非常大的日志（太大）。在这种情况下，建议您花一些时间研究应用程序中线程同步的实现。否则，您还可以在这里查看该领域的最新研究进展（据我所知，这是最新的），它们提供了C ++和Java实现。
希望有帮助。
评论
听起来像当您开始使用window.onerror在实时网站中跟踪所有JS错误时发生的情况
是的我们是。您还有其他建议吗？
仅供参考，很多错误源于浏览器插件/扩展，间歇性连接问题（即脚本未加载）以及应用程序中的实际错误。