错误报告的最佳指南？

#1 楼

作为开发人员，这是我需要解决的信息：


重现步骤。
预期的结果。
实际结果。

按此顺序。小于此值的任何内容都将导致难以重现问题或确定需求解释方式的差异。还有更多可能会使开发人员感到困惑。


其他信息

或者为什么我不喜欢您的编辑

步骤复制的步骤应该是书面的，有序的步骤清单，其中包括尽可能多的细节。在报告中包括以下内容时请务必小心：



屏幕截图：

仅在包括屏幕截图的情况下才能对错误进行解释。
请勿使用屏幕截图来证明存在错误。如果开发人员无法重现该问题，则说明步骤中缺少某些内容。与他们一起找出问题所在（无论如何，我们大多数人都不会咬）。


视频：而不是屏幕截图，因为它通常会包含未记录的步骤的详细信息，但一般来说，请谨慎使用。 br />如果您使用特定的环境/工具来重现该错误，则在
重现的步骤中应包括对该环境/工具进行设置
。

#2 楼

问题报告（错误报告）是质量检查人员使用的主要沟通方法之一。
您正在向利益相关者创建声明-“我发现了我认为的问题，这是我对问题的明确解释以及如何查看它。请仔细研究”。

了解报告的听众

重要的是要知道谁将阅读您的问题报告，并且

对于某些商店，唯一的读者就是您自己和一个或多个开发人员。如果是真的，您可以使用各自理解的各种术语和缩写。支持，产品管理，文档，管理等。使用更少的行话并添加更多详细信息可能变得更加重要。

还有一些特殊情况也必须牢记。

例如，如果离岸测试人员或开发人员必须阅读您的问题报告，则需要特别注意不要在书写中使用混乱的行话或口语。客户最终将阅读您的问题报告，您在选择语言时需要非常非常小心。 （顺便说一句，我不建议您这样做，而无需先将问题报告发送给熟练的作者进行“消毒”。）您甚至可以对错误进行两种不同的描述，一种是内部使用，

选择一个好的摘要/标题

由于单行摘要或标题通常会促使某人决定进一步阅读您的问题报告，并且通常是有关摘要报告中显示的错误的唯一信息，在此字段中进行一些思考很重要。点。
试图偷工减料，在这里只写几句话“ Program x crashed”，但显然没有用。

此外，您无需在此处包括已经包含在其他程序中的文本错误跟踪系统的字段。对于大多数系统，会在其自己的字段中跟踪严重性/优先级，产品，组件等项目。在摘要/标题中，不要浪费任何宝贵的空间。在这里，您可以使用比“摘要/标题”所允许的更多的单词，但仍然避免冗长。
包括重现您所看到的问题的步骤
并非每个bug都可以完全再现。但是，重要的是尝试找出相对较少的步骤来重现该问题，并在“问题报告”中予以注明。
这为开发人员提供了一个挣扎的机会，使您可以看到自己所看到的并进行实际修复迅速。

避免无关紧要的步骤-与重现错误无关的步骤。包括太多步骤可能会浪费时间并导致混乱。

包括实际上似乎很重要的所有步骤。

用清晰的样式编写它们，以避免猜测。

缩小步骤的时间会花费一些时间，但是通常会花费很多时间。

错误不能完全重现，请在问题报告中清楚指出。开发人员。

有时候，他们的期望是正确的，有时是错误的。无论哪种方式，都包括您期望看到的内容。

包括您实际观察到的结果

由于存在此问题报告，我们假设发生了意外情况。请注意实际发生的情况。

如果您看到错误消息，请附上该错误消息。

如果您在日志文件中发现了重要内容，请将该部分记录在日志中。

包括足够的详细搜索内容

尝试像支持人员或经理一样思考，或不熟悉此问题的新QAer。如果您看到这些相同的症状，您将搜索什么？如果您有幸拥有包含全文搜索的缺陷跟踪系统，请确保在“问题报告”的文本中包括这些重要的关键字。

如果缺陷跟踪系统具有“关键字”字段，将其放在此处。

解释对客户的影响

在此过程中，将对您的问题报告的优先级和/或严重性进行分析。

如果您说明此问题对客户的影响，则可以更好地对问题进行正确分析。如果问题使进一步测试无法进行，请确保指出该事实（在这种情况下，您也是客户）。

附上任何可能有帮助的内容

附上任何有助于澄清和/或调试问题的内容。

他们说“图片是值得一千个字”。因此，经常附上问题的图片可能会非常有帮助。如果日志文件，测试文件等有助于重现或调试问题，则也可以附加它们。 ）或包含在报告本身中（以便在搜索过程中使用）。

避免猜测

报告事实-您所看到的，所见的预期会看到的任何其他症状。但通常，除非存在足够的事实来支持您的推测，否则请避免对问题的根本原因进行推测。

猜测可能会使审稿人大吃一惊，浪费时间。如果不相关，也会使此错误报告作为搜索结果显示。

注意报告的语气

不要使用否定语气在你的写作中。请记住，您的工作是描述错误，以便可以高效地对其进行修复。批评这里的开发人员或设计师没有任何好处-您是他们的合作伙伴，你们俩站在同一侧。要客观，尊重。

避免重复-首先搜索

您不想浪费人们的时间来阅读已经被别人涵盖的问题报告。在某些商店中，编写此类错误报告可能会受到惩罚。因此，请首先使用需要的话使用将要写到报告中的关键字进行搜索。它们。

还有一些其他的方法可能会有所帮助：


写作问题报告有效不可复制的错误
问题跟踪模板

#3 楼

除了Joe的贡献之外，我只想补充一件事。

不要在同一bug报告中指出两个或多个问题。如果您遵循相同的步骤时仍感觉到另一个不同的问题，请分别提出，否则有可能被遗漏。

#4 楼

为了扩大在Phil K提到的链接。 Cem Kaner发表了一篇名为“ Bug Advocacy”的论文，您可以在以下页面上以100页的PDF阅读：http://www.kaner.com/pdfs/bugadvoc.pdf。它还构成了第二个BBST课程的基础。

Kaner概述了Bug倡导的4个要点：（直接从第10页引述）。 br />
错误报告是您的主要工作产品。这是测试小组以外的人们最注意和记住的事情。

最好的测试员不是发现最多的bug或使最多的程序员感到尴尬的人。最好的测试人员是修复最多错误的人。
程序员在时间常数和相互竞争的优先级下工作。例如，在8小时工作日以外，某些程序员更喜欢睡觉和观看《星球大战》，而不是修复错误。花费时间和精力修复错误的想法
。


我从来没有那样想过-错误报告是我们的主要工作产品。我们可以指出并说“这就是我所做的”。

我还没有读完它，我敢肯定很多东西都适用于前面提到的内容。认为记住错误和问题之间的区别很重要。 Bug是威胁产品价值的任何事物，而问题则是威胁测试价值（或项目价值，尤其是测试价值）的一切。快速软件测试教会了我们这一点。

#5 楼

这是我在错误报告中需要注意的几件事。


要重现的确切步骤。您可能可以摆脱一些语，例如在我们的APP中，您几乎总是可以按F1键转到下一个屏幕，因此您可能会看到有人说“ F1直通，直到<>”。但是您不能只说“转到此功能，此订单号”。除非解析以3结尾的订单号有问题，否则给我123的订单无济于事。告诉我“有多个待补商品的订单”，现在我可以处理。
告诉我确切的内容。如果我能复制它，那太好了。但是，如果您不知道它应该做什么，那您怎么知道它没有做呢？当分析师对应该做什么没有正式定义时，这尤其困难。我们经常听到“这个报告说XYZ，而那个报告说ABC。请解决。”嗯，我首先成为ABC吗？还是第二个是XYZ？也许他们都错了？也许他们甚至不应该报告相同的数据！因此，如果该报告无法告诉我应该怎么做，就不能指望该开发可以解决任何问题。
不要将功能请求伪装成错误。您不能提交错误报告“此屏幕没有删除按钮”。那不是错误。 “好吧，这不是一个正确的屏幕。它没有删除按钮！”好的，这不是一个完美的屏幕。为什么原始规格中没有删除按钮？现在，如果以前有一个删除按钮并且它消失了，那就是一个错误。但是开发只知道项目应该做的时候应该做的事情。您不希望随后做完任何事情并将其称为错误。
看到它的其他人（/不是重复报告）。现在，这不是报告创建者的责任，因为他有责任在发现错误后立即报告错误。但是，如果存在报告，则不要创建新报告，而要对旧报告进行评论。这有两件事：第一，它减少了需要支持和/或筛选的报告数量。其次，它表明这正在影响多个人员，并可能影响多个系统/模块。这是一个很棒的开发线索，可以帮助您确定错误所在。 “嗯，我们在Alice的行为和Bob的后续评论之间只有两个相互依赖的模块。让我们看一下。这也有助于显示报告该错误的人不是片状。这导致了...
这实际上是一个错误。我见过很多错误，只是人们不知道如何使用该系统。如果您的微波炉煮的食物太热，那不是一个错误。如果您的微波炉煮了肉而不是解冻，尽管实际上您告诉过它肉的类型和正确的大小，那是个错误。您只是想知道它需要4分钟而不是2分钟？不是错误；您在键盘上键入4而不是2？不是错误。可以让您在空的时候做饭。当您打算推定时器而不是做饭时，这很烦人，但让我们面对现实：您告诉它要做饭！（实际上，我一直这样做。是的，这很烦人。是的，可以使用更好的界面。但这是一项功能请求（请参阅＃2），而不是错误！）
这一点很重要。现在，这个问题有些不明确，因为我认为应该报告不重要的错误。 （请参阅我的非重要错误报告的史诗般的示例。）但是，与此同时，您必须愿意承认它并不重要。有些地方会拒绝那些不重要的错误。例如，某些布局偏离1像素。抱歉，这是一个内部应用程序-我们将永远不会修复它。总会有比这更好的时间花在我们身上。但是我们还是可以报告它，以便至少可以指出我们有问题，如果我们进行了图形大修，我们可能会对其进行调查。但是必须对错误进行分类。在我的公司中，该公司管理着近一百家制造工厂，其中许多工厂有副总裁的朋友和“董事会”的成员，他们会因为必须再次按下箭头的事实而感到猿猴-$＃！^这个屏幕比那个屏幕。我明白了，这很烦人。但是让我们确保我们的折扣逻辑和定价错误已首先修复，是吗？当我们最终解决所有这些问题时，我们可以使您的向下箭头更好一些。

其中一些可能是伪装的。好吧，那是因为它们是。作为没有质量检查团队的开发人员，这就是我得到的报告。如果人们将其简化为6个项目的简单清单（复制步骤，所需的正确结果，实际上不是功能要求，不是重复的报告，实际上不是正确的行为，并且已正确分类），我不会介意这些报告这么多。

同样作为开发人员，在我的组织中，我从分析师那里得到“规范”。他们应该仔细检查并定义正确的行为，以便记者不必这样做。通常，他们只是发送报告，然后将所有内容留给开发人员。因此，如果要制定准则，请确保正确定义了职责。不要让开发做所有事情，不要让分析师做所有事情，不要让质量检查团队做所有事情，不要让记者做所有事情。弄清楚应该由谁来做，并追究他们的责任。您可以使用数十种职责配置，只要您对谁在做什么方面保持一致，就可以使用大多数配置。

P.S.嘿，我公司的分析师们。希望您正在阅读！这不是宣战，而是白旗！ :-)

#6 楼

在我的公司中，有一份很好的错误报告：


描述症状，包括屏幕截图或堆栈跟踪（如有必要）
确切说明如何重现问题
指定为什么作者认为，该错误很重要，如果尚不明确的话。

某些开发人员可能更喜欢测试人员尝试尽可能缩小问题的范围。开发人员由我决定要提供多少诊断。

在我的小公司中，我们通常会理解彼此的缩写和假设。在大型公司中，可能有必要使用更正式，更明确的语言。

最后，我不建议盲目遵循任何人的错误报告做法。他们的情况与您的情况不同。听取他们的建议，然后考虑这些做法如何与您自己的情况相结合。

#7 楼

除了上面列出的项目之外，还有一些准则


测试步骤
如果可能的话，为每个步骤提供快照（如果您在远程团队中工作，请避免反复往返电子邮件通信）
预期结果与实际结果
环境详细信息-操作系统，硬件，软件，内部版本
日志文件条目/值
很高兴-初步调查/分析支持查询/假设，为开发人员提供进一步的线索以进一步检查
提供对测试环境的访问权限-URL，供开发人员在必要时检查的机器
参考BRD，FS，设计记录实现是否与设计/需求冲突的地方
很高兴-召开分类会议/问题审查会议，与开发团队一起检查一次错误，以便在他们开始研究之前快速概述问题。 F2F对话有时比电子邮件/聊天对话更好。
具有描述性，不要使用缩写，没有隐式假设。呼唤您对功能及其与实现的冲突的理解

#8 楼

标题准确且准确
问题的简要说明
实际和预期结果
复制的确切步骤（提供尽可能多的信息，例如浏览器版本等）尽可能的截屏。
不要在一个错误报告中放入多个错误。

#9 楼

1.简短有意义的标题（将给出确切的问题
声明）

2.Repro步骤

3.实际结果是什么

4.预期结果是什么

5.如果适用，请获取屏幕快照/视频以获取再现信息

6.问题的严重性是什么

7.测试环境是什么

8.什么是构建号

9.来源是什么（Test / PM / Dev / Design等） ）的错误。这意味着谁在记录此错误

10.如何找到（功能测试/性能测试/安全测试/设计审查等）。

11.分配给（Triage / Dev / PM）

12.源代码管理中的区域/迭代（将此bug保留在源代码管理中的位置）

#10 楼

错误报告应...
...清除
错误报告应具有：

准确，描述性的摘要。
内容丰富，简洁的描述。
保持中立的语调，避免抱怨或猜疑。

...可复制的
错误报告应包含：

重现此问题的最简单步骤，或...
该错误的测试夹具失败。该问题着重于事实。

预期结果和实际结果。

使用的软件，平台和操作系统的版本。

崩溃数据，包括堆栈跟踪，日志
文件，屏幕快照和其他相关信息。

...独特的
请在报告错误之前搜索重复项，并确保摘要包括在内
相关关键字，以使其他用户更容易找到重复项。

#11 楼

尽管我通常反对硬编码模板，但是错误报告是一个例外。
根据用于报告的系统，在创建新错误或添加必填字段时，我会显示一个空模板。

#12 楼

发布良好错误报告的清单：


查找重复项
检查错误报告中所有元素的准确性
以其他收件人的身份进行角色扮演（例如，测试经理），并询问错误报告对他们是否真正有用
使用错误报告列出过去的错误列表，并通过报告运行错误
检查附件，附件的大小以及与附件的相关性此错误报告的上下文
，每个人都知道错误跟踪系统，也会崩溃，因此将错误报告的副本保存在MS Word或其他编辑器中。
确保您对错误中的所有文本进行拼写检查报告–尤其是带有错误标题的信息
确保所有错误报告的语法报告都很好，并且所有阅读此错误报告的人都清楚您的用词选择

此处更多。

#13 楼

阅读Cem Kaner的Bug倡导

http://www.kaner.com/pdfs/BugAdvocacy.pdf

#14 楼

我想我以前的答案也适用于此。

我认为，最好的错误报告（假设发送错误报告的人不知道观察到的故障的原因）是包含可重复性信息的错误报告，因此开发人员可以能够重现该问题。

在几个错误跟踪站点（例如MySQL）中，我们发现有成千上万个错误报告被标记为“无法重现”或“无法重复”。因为用户不知道应该如何报告错误，或者因为用户不知道如何重现错误，所以问题是相同的：发送的报告几乎没有或完全没有有关错误发生的历史信息（例如仅包含堆栈跟踪和/或内存快照和/或事件的文本描述的报告，这些报告既肤浅又麻烦。有时，很少的信息就足够了，但很多时候却不足够，尤其是在非常特殊的条件引起的错误中，这些特殊条件导致执行通过非常特定的路径进行。

因此，总而言之（我认为），一份好的Bug报告是为开发人员提供了足够的信息来重现所观察到的问题的报告。这通常很难提供，尤其是在执行失败期间未执行任何日志记录的情况下。

在过去的几十年中，该领域进行了大量研究，但是不幸的是，没有解决所有问题的解决方案。就我而言，我相信记录和重播系统（又名故障复制系统）更有希望，因为它们会在用户执行期间自动记录非确定性的来源，并且如果/当发生故障时，它们会创建能够确定性重播的错误报告。但是，他们仍然在性能开销，日志大小和隐私方面存在问题。


关于什么是好的bug报告，您可能会发现以下有趣的研究论文：


[“是什么使bug报告很好？”，IEEE软件工程学报，T。Zimmermann，R。Premraj，N。Bettenburg，J。Sascha，A。Schroter和C. Weiss]提出：i）关于在2226位开发人员和报告者中如何使用错误报告的调查，其中466位做出了回应； ii）经验证据，证明开发人员的期望与报告者的提供不匹配； iii）CUEZILLA工具，用于测量错误报告的质量，并建议报告者如何增强报告的质量，从而更快地解决问题。可在以下位置公开获得：
http://thomas-zimmermann.com/publications/files/bettenburg-fse-2008.pdf


[“（非常大的）调试：十年的实施和经验”，在ACM SIGOPS第22届操作系统原则研讨会论文集中，K。Glerum，K.Kinshumann，S.Greenberg，G.Aul，V.Orgovan，G.Nichols，D.Grant， G. Loihle和G. Hunt]

这是Microsoft撰写的有关Windows错误报告系统十年错误报告分析的论文。您可以在以下位置找到公开的版本：http://research.microsoft.com/pubs/81176/sosp153-glerum-web.pdf


[“错误报告中的信息需求：正在改进开发人员
和用户之间的合作”，在S. Breu，R。Premraj，J。Sillito和T. Zimmermann在“ 2010 ACM计算机支持的合作工作会议上的会议记录”中，

A这篇论文分析了Mozilla和Eclipse项目的600个错误报告样本中提出的问题，并提供了一些改进错误跟踪器的建议。链接：http：//people.ucalgary.ca/~sillito/work/cscw2010.pdf



[“谁测试了我的软件？将测试作为组织的跨部门活动”，2011年软件质量杂志，M。Mantyl a，J。Iivonen和J. Itkonen]

检查不仅由专业测试人员而且由多个利益相关者在不同的工业案例公司中进行的测试活动。链接：http://lib.tkk.fi/Diss/2011/isbn9789526043395/article6.pdf


[“工业软件开发中缺陷报告的调查复制”，2011年国际研讨会经验软件工程与测量，Eero I. Laukkanen，Mika V. Mantyla]

对六个工业软件开发组织进行了有关缺陷报告信息的调查（142个开发人员中有44个完成了调查） ，从三个角度来看：关于信息的质量，有用性和自动化的可能性。链接：
https://courses.cs.ut.ee/MTAT.03.159/2015_spring/uploads/Main/SWT_bugrep2.pdf

#15 楼

规范：软件版本，数据库版本等。
描述：预期的行为与所达到的行为。
复制：遇到错误所需的确切输入。
路由：解决此问题或进一步解决问题的“地址”。

#16 楼

BBST Bug倡导课程使用RIMGEA首字母缩写词，可帮助您编写和销售有效的错误报告。

我在此博客系列中解释了RIMGEA首字母缩写词。能够列出每次都会重现该错误的一组步骤。

M表示最大化-找到一种方法来使故障以最壮观的方式发生。

G表示Generalize-寻找一种将故障从极端情况变为一般问题的方法。

E表示Externalize-寻找对用户的后果。问问自己，谁会关心这种失败以及为什么？

您越有经验，就越不需要参考这些步骤。它们将显示在您的错误报告中。

#17 楼

当您说出准则时，我立即想到了我们所需的信息模板


环境
URL
参数
问题/缺陷/错误（不论您叫什么）
描述是否需要更多详细信息
复制步骤
实际结果
预期结果
与问题相关的要求/接受标准
是否有解决方法？
问题的影响

我读到的大多数答案都非常清楚，是关于问题的报告，而不是关于人民的报告，我完全同意这一点。它应该是关于事实的。


如果不解决此问题，严重性是什么？
解决方法是否可以使我们的客户/客户在我们修复该问题之前需要使用它，还是需要立即对其进行修复？

答案不是很长，但我认为将信息保持在必要的信息上是关键。

#18 楼

希望下面的答案对您有所帮助：


QA测试服务提供的错误报告应该准确，以便开发人员可以立即理解该问题。因此，缺陷
描述应包含以下信息：

a）摘要：摘要应简短且具有描述性。它应该以这样的方式创建，使得错误库搜索可以有效地指向错误
。

b）先决条件：再现的先决条件/要求应当提供
bug。

c）重现步骤：分步描述以重现缺陷。

d）实际结果：实际发生了什么。它
不应太详细，但应清楚地描述
缺陷。可以将其扩展为2-3个句子以描述
观察结果。 br /> f）正常工作：如果有任何解决办法可用于缺陷
，或者相同的功能在应用程序中的任何地方都能正常工作。
纠正了后端的问题。

g）屏幕截图或视频：附加/上传屏幕截图或视频，以再现并理解缺陷。

h）环境：操作系统，浏览器，测试应用程序的版本详细信息，其中发生缺陷的地方

以下是示例错误报告：

摘要：电视是从遥控器上按下“电源”按钮后无法开机。

先决条件：1）确保电视和遥控器均可用。

步骤复制：1）打开电视。 2）握住遥控器。 3）从遥控器上按
“电源（绿色）”按钮。 4）观察行为。

实际结果：电源屏幕闪烁一段时间并显示黑屏
。

预期结果：单击遥控器上的“电源”按钮后，电视应该启动并显示主屏幕。

工作原理：单击“电源”按钮后电视正在启动
/>（来自电视）（边框面板上电视屏幕下方的按钮）。 com / qna / 2325 /您能给我样本的错误报告是您写的吗？

#19 楼

已经有了一些不错的答案，所以只需添加一个小答案即可：这将减少至少50％的编码器试图勒死您的一个队友的机会。