由于错误报告质量较差而难以验证

#1 楼

首先，我想说的是，通常只需照顾例外就足够了。也许这是一个被遗忘的特殊情况（排序一个列表，但是忘记它可能是空的）。当然，当您可以信任开发人员以确保修复程序正确时，您会更加了解。

然后回答您的问题：




在每个错误中都有相应步骤非常好。最好有一个测试用例在修复该错误之前重现该错误。就是说，我还编写了错误报告，这些报告没有确切的步骤，但确实尽力解释了这种情况。有时，即使我什至不知道破坏系统的确切原因，我也必须提交错误。当然，在这些情况下，我可以帮助开发人员解决他们可能遇到的任何问题。

也许开发人员也不知道如何准确地重现它，但是会对损坏的部分进行代码审查并找到一些问题。完全有可能知道某个问题，而又不知道如何使系统完全运行到确切的状态。

如果问题显然出在沟通中，而不是重现问题的困难，那么我只能建议所有人，为什么写一个好的错误报告很重要。指出可能有很多人在不同的时间阅读案例（开发人员修复错误，测试人员测试修复，为客户提供技术支持，其他报告错误的人，产品所有者和其他股东试图了解产品的状态， ...）。

我认为仅仅拒绝这些错误并没有取得成功。这听起来很自大，只会妨碍与记者的讨论。将错误保持开放状态，但要问清楚要重现的问题或步骤，但仍准备好在未得到这些问题的情况下解决该问题。如果明显存在问题，即使指出该问题的人无法告诉他们确切的解决方法，也应予以解决。他们无论如何都已经看到了。也许他们甚至对产品不太了解，也不了解导致问题的原因，或者太忙而无法解决问题。这样做不好，但是不同的人有不同的优先级，并且对于某些人来说，错误报告的位置可能并不靠前。

总的来说，我认为我们经常所需要的信息少于我们想要的。以在这样的条件下也能工作而感到自豪，但不断推动人们改善流程。

#2 楼

我喜欢将“错误”视为三部分：



失败。系统产生的结果与我们想要产生的结果之间观察到的差异。

故障。在某些情况下会导致故障的系统错误。

条件。故障导致故障的条件。

在这三部分中，一个测试人员（和其他人员）首先遇到的是故障。在OP的情况下，您会看到NullPointerException。

有时故障的性质会提供足够的信息以识别故障。在OP的情况下可能就是这种情况。因此，开发人员修复了错误……据我们所知。

OP场景中（通常在缺陷报告中）缺少的是导致失败的条件。 />
要确定情况，通常必须进行一些调查。有人可能是测试人员，开发人员或团队。想法是隔离涉及的变量。我使用的技术的简要概述：


头脑风暴，您可以想到的所有可能涉及的变量。


测试动作和输入，以识别可能受动作和输入影响的变量（前提条件，动作，输入，事件序列）。

从故障（甚至是故障，如果发生故障，请向后退）您知道）来识别可能导致该故障的变量。

从每个变量向前和向后进行工作，以识别可能涉及的其他变量。


分类变量。我喜欢使用思维导图将它们聚类。您可以使用鱼骨图。或者，您可以在变量之间建立某种因果关系图。
通过选择最可能的类别或变量并进行试验以查看其对故障是否有影响，从而确定相关条件。如果它似乎没有效果，请转到下一个变量。

此调查可能会很昂贵。它可能需要对系统内部有详细了解的人员。可能需要当前正在优先处理其他活动的人员。

但是不仅包含故障而且包括条件的缺陷报告更有助于发现故障，更有助于重现故障，并且对测试和重新测试更有帮助。

#3 楼

错误编写者可能没有收集正确的信息，因为他们不了解要包含的内容和时间。对于那些认为编写错误报告很容易但是却不了解好的错误报告的元素的人来说，常见的错误。

碰巧我写了一篇有关如何编写好的错误报告的文章。在本文中，我尝试从BBST Bug Advocacy类中提取良好的bug报告的元素。阅读。您也可以查看来自Bug Advocacy的源信息，以获取更多信息。

那么，如何解决问题：

您可以与团队成员（程序员，其他测试人员）一起查看现有的错误报告，以期了解他们的各种要素报告以及如何改进它们。标题和摘要如何编写？简短，简洁和准确？向他们展示不良和良好报告的示例。看看他们是否必须找出方法来改进自己的报告（如果他们必须重写它们）。您甚至可以开始修复发现质量较低的错误报告。这将使整个团队集中精力确保报告的质量，无论他们是否编写报告，都是高质量的。

现在，如果客户直接报告问题，则可能需要设置一些基本规则并/或模板，以确保它们包含有价值的信息。示例在这里效果很好。他们总是有机会不予理attention，在这种情况下，您可以回覆以获取更多信息。如果其他人（内部人员）为您的客户记录了错误，则将其与程序员一起接受培训。

我喜欢这样看：提交错误报告的原因是为了获取错误已修复。如果您没有足够的简洁信息来识别问题，则没有理由打开错误报告-您将无法对其进行任何处理。

#4 楼

有关其他人提出的建议的几点想法：




复制问题：在任何可能的情况下，我都会尝试复制任何客户报告的问题，因为可能还会涉及其他问题客户没有报告-特别是如果错误报告本身仅包含堆栈转储。可能只有在使用特定配置时才会发生这种情况，或者这是客户执行的一系列操作所浮出水面的其他一些不稳定的可见端点。

指导错误工具有帮助：如果有可能，有一个针对客户报告的错误的模板，它包含以下内容（我的措辞很粗略，但您明白了）会有所帮助：


问题在系统中的哪里发生？ （几行空格，因此很明显可以预期得到答案）

您期望发生什么？ （再次添加几行空间）

实际发生了什么（请尽可能具体）？

每次都会发生这种情况吗？ （也就是说，是否可以重现该问题）

请描述您为重现该问题所采取的步骤：（以及下面的许多空白）




如有必要，请更新错误报告：可能由于客户报告的问题，最初的信息还不够。客户往往会忘记他们的配置不是Universe中唯一的配置，因此，除非您拥有准确的客户配置数据库，否则其他人可能需要添加此信息。谁进行更新都没有关系，只要进行了更新，以便在两个月后需要重新测试该问题时，测试人员所需的所有信息就可以在错误报告中找到。

记录测试步骤和测试配置：这应该很明显，但是仍然值得重复。在测试生涯的早期，我曾多次向客户报告一个错误，因为实际上存在多个具有相同症状的错误，每个错误所显示的配置略有不同。在第一步中，开发人员修复了该问题，我验证了最明显的体现。下一遍，我们获得了有关客户配置的更多信息，其中增加了第一次迭代中不存在的条件。因此，该问题已得到解决和验证-但是还涉及其他条件和配置，当被询问时，这些条件和配置都是由客户一个接一个地发出的，“哦，是的，我们在做X”。如果我知道确切地记录我为设置，复制和验证所做的工作，那么来回的希望就不会那么多了（在发现该错误之后，我才学会了。我学到了男孩子）。当然，如果有的话，我可能不会偶然发现所有相互关联的错误，那么谁知道呢？

#5 楼

作为测试人员，我总是喜欢以高效的方式报告错误，以便通过提供尽可能多的信息来减少在开发人员处进行错误修复的成本（时间和精力）。
我想对于改进bug报告过程的几点要说的要点：

报告新的BUG时，我们应该尝试提及以下内容：

1。简短描述：
每个错误都必须有一个简短描述，其中应尽可能以最短的方式包含有关该问题的尽可能多的信息。

2.Severity：Term本身表明它是对问题的度量。发现的错误对整个系统或系统操作的影响。错误的严重性必须提及。

3.优先级：先修复此错误有多重要？
报告新错误时必须标记优先级。

4。子系统：
如果我们提到当前错误所属的子系统（模块/子模块），则在修复或评估已开发/开发模块的过程中有助于检查错误。

5 。描述：
描述也是错误报告中非常重要的部分。
在描述部分中，我们应该在各个方面提供尽可能多的与BUG相关的信息。以下是一些内容：


报告者：帮助开发人员找回该人，以防他在修复它时可能无法重现该人。
报告日期
测试服务器信息（如果有的话）
经过测试的版本/版本

以上提到的三种方法都可以在根本原因分析中帮助您解决错误。通过直接单击链接作为参考的页面链接可以看到错误。

6。附件：
附件基本上包括屏幕快照，以及再现错误时所需的任何其他文件。

拍摄屏幕快照时，我们应重点注意以下内容：
-不应在屏幕截图中包含不必要的部分，但请注意包括所有必要的内容。
-实际问题所在的区域应标记为红色
-应在其中提供一些消息屏幕上显示了有关该错误的画面

7。重现步骤：
这是报告错误时最重要的步骤
在这里，我们应该逐步编写确切的步骤，然后在质量检查结束时重现错误。
这必须包括：
当前/实际行为以及预期行为（按照我的看法，这并不总是强制性的，但是在报告错误时是强制性的）。

8。错误日志：
即使我们包含了错误消息，该消息在重现在UI上获得的错误时也会得到，但是并没有给出有关错误的完整而详细的想法。因此，我们应该提供带有错误的错误日志。
错误日志是开发人员本身包含在代码中的代码的一部分，因此应在应用程序发生任何崩溃或某些故障时捕获。
错误日志提供了一个关于发生故障的原因有很多想法，查看此日志开发人员可以轻松地找出问题所在的区域。

有可能有时候我们没有上面提到的所有信息，但我们可以尝试提供尽可能多的信息。

这不仅非常重要，不仅可以降低修复成本，而且在验证修复程序时也如您在上述情况中所述。报告错误的人在修复错误后并不一定会验证错误，因此，在报告错误时提供详细信息是一种很好的做法。

关于第二个问题：“如果开发人员和测试人员无法从客户那里收集信息以重现该错误，那么他们应该修补该错误（如上例所示）还是将错误报告拒绝为“无法重现”？”

如果错误是由客户自己报告的，则不能总是期望他们会提供逐步的操作来由开发人员或测试人员重现该错误，在这种情况下，测试人员应该尝试以所有可能的方式重现该错误。无法复制，则可以要求客户提供更多信息以复制该错误。但是无论如何，在一次尝试从客户那里收集更多信息之前，我不建议您拒绝一个错误。