如何写好一个BUG报告？

为什么是好的Bug报告？

如果您的错误报告是有效的，那么它得到修复的机会就会更高。因此，修复bug取决于您如何有效地报告它。报告错误只是一种技能，我将解释如何实现这一技能。

“编写问题报告(bug报告)的目的是修复bug”-由CemKaner编写。如果测试人员没有正确报告错误，程序员很可能会拒绝此错误，称其为不可复制的。

这会伤害测试员的道德，有时也会伤害自我。(我建议不要保持任何自我。自我就像“我正确地报告了错误”、“我可以复制它”、“为什么他/她拒绝了这个错误？”、“这不是我的错”等等)。

一个好的软件缺陷报告的质量是什么？
任何人都可以写错误报告。但并不是每个人都能写出有效的bug报告。

您应该能够区分一般的bug报告和好的bug报告。如何区分好的和坏的错误报告？非常简单，应用以下特性和技术报告错误。

特点和技术包括：

1)有明确规定的虫号：

始终为每个bug报告分配一个唯一的编号。这反过来将帮助您识别错误记录。如果您正在使用任何自动错误报告工具，则每次报告错误时都会自动生成此唯一编号。

请注意您报告的每个bug的数量和简要描述。

2)可重复性：

如果您的错误是不可复制的，那么它将永远不会被修复。

您应该清楚地提到重现bug的步骤。不要假设或跳过任何复制步骤。一步描述的bug很容易复制和修复。

3)具体：

不要写关于这个问题的文章。

具体点，切中要害。试着用最少的词来概括这个问题，但要用一种有效的方法。不要将多个问题结合在一起，即使它们看起来是相似的。为每个问题写不同的报告。

有效的Bug报告
错误报告是软件测试的一个重要方面。一份有效的bug报告与开发团队进行了良好的沟通，避免了混乱或错误沟通。

一个好的bug报告应该是简明扼要没有遗漏关键点。任何不明确的情况都会导致误解，也会减缓开发过程。缺陷写入和报告是测试生命周期中最重要但却被忽略的领域之一。

好的写作对于错误的归档是非常重要的。测试人员应该记住的最重要的一点是不要用威严的语气在报告里。这破坏了士气，造成了一种不健康的工作关系。用暗示的语气。

别以为开发人员犯了一个错误，因此您可以使用严厉的话。在报告之前，同样重要的是检查是否报告了相同的bug。

重复的错误是测试周期中的一个负担。检查所有已知bug的清单。有时，开发人员可能已经知道了这个问题，并在以后的版本中忽略了这个问题。也可以使用Bugzilla这样的工具自动搜索重复的bug。但是，最好手动搜索任何重复的bug。

错误报告必须通信的导入信息是“怎么做？”和“在哪里？”报告应该清楚地回答测试是如何进行的，缺陷发生在哪里。读者应该很容易地复制错误，并找到错误所在。

记住编写错误报告的目的就是让开发人员可视化这个问题。他/她应该清楚地理解错误报告中的缺陷。请记住提供开发人员正在寻找的所有相关信息。

另外，请记住，bug报告将保留下来供以后使用，并且应该用所需的信息很好地编写。使用有意义的句子和简单的单词来描述你的虫子。不要使用令人费解的语句来浪费审阅者的时间。

将每个bug报告为一个单独的问题。在单个错误报告中出现多个问题时，除非所有问题都得到解决，否则无法关闭它。

所以最好是把问题分成不同的错误。这确保了每个bug都可以单独处理。一个写得很好的bug报告可以帮助开发人员在他们的终端复制bug。这也有助于他们诊断问题。

怎么报告臭虫？
使用以下简单的Bug报告模板：

这是一个简单的错误报告格式。根据您正在使用的bug报告工具，它可能会有所不同。如果您正在手动编写bug报告，那么需要特别提到一些字段，比如Bug编号，应该手动分配。

记者： 你的名字和电子邮件地址。

产品：你在哪种产品里发现了这个漏洞。

版本： 产品版本(如果有的话)。

构成部分：这些是产品的主要子模块。

平台：提到你发现这个错误的硬件平台。各种平台如“PC”、“MAC”、“HP”、“Sun”等。

操作系统： 提到所有你发现错误的操作系统。操作系统，如Windows，Linux，Unix，SunOS，MacOS。提到不同的操作系统版本，如Windows NT，Windows 2000，WindowsXP等，如果适用的话。

优先事项：什么时候应该修复bug？优先级通常从P1设置为P5。P1为“以最高优先级修复错误”，P5为“时间允许时的修正”。

严重程度：
这描述了bug的影响。
严重程度类型：

阻滞剂：没有进一步的测试工作可以做。
关键：应用程序崩溃，数据丢失。
专业：主要功能丧失。
未成年人：轻微的功能丧失。
琐碎的：一些UI增强。
增强：请求新特性或现有功能中的某些增强。
现状：

当您将错误记录到任何bug跟踪系统中时，默认情况下，bug状态将是‘New’。
后来，这个bug经历了不同的阶段，比如修复、验证、重新打开、不会修复等等。

分配给：

如果您知道哪个开发人员负责bug发生的特定模块，那么您可以指定该开发人员的电子邮件地址。否则保持空白，因为这样会将错误分配给模块所有者，如果不是，Manager将错误分配给开发人员。可能在CC列表中添加经理的电子邮件地址。

URL：

错误发生的页面URL。

摘要：

一个简要的错误摘要，大部分是在60个字或以下。确保你的总结反映了问题所在。

描述：

对错误的详细描述。

对Description字段使用以下字段：

复制步骤：显然，请提到重现bug的步骤。
预期结果：应用程序在上述步骤上的行为方式。
实际结果：运行上述步骤的实际结果是什么，即错误行为。
这些是bug报告中的重要步骤。您还可以添加“报告类型”作为另一个字段来描述错误类型。

报告类型包括：

1)编码错误
2)设计误差
3)新建议
4)文件问题
5)硬件问题

Bug报告中的重要特征
以下是bug报告中的重要特性：

1)Bug编号/id：

bug编号或标识号(如swb 001)使错误报告和引用bug变得更加容易。开发人员可以很容易地检查某个特定的bug是否已经修复。它使整个测试和再测试过程更加顺畅和简单。

2)Bug标题：

bug标题比bug报告的任何其他部分都更频繁地被读取。它应该能说出bug的全部内容。

bug标题应该具有足够的暗示性，使读者能够理解它。一个清晰的bug标题可以让读者更容易理解，并且读者可以知道错误是先前报告的还是已经修复的。

3)优先事项：

根据bug的严重程度，可以为其设置优先级。一个bug可以是一个积木，批评，主要，小，琐碎，或一个建议。可以给出从P1到P5的bug优先级，以便首先查看重要的错误。

4)平台/环境：
操作系统和浏览器配置对于明确的错误报告是必要的。这是最好的方式来沟通的错误如何可以被复制。

如果没有确切的平台或环境，应用程序的行为可能会有所不同，测试端的错误可能不会在开发人员端复制。因此，最好清楚地提到检测bug的环境。

(5)说明：
bug描述有助于开发人员理解bug。它描述了遇到的问题。糟糕的描述会造成混乱，也会浪费开发人员和测试人员的时间。

有必要在描述中清楚地说明效果。使用完整的句子总是有帮助的。一个很好的做法是分开描述每个问题，而不是把它们完全分解。不要使用“我认为”或“我相信”这样的术语。

6)复制步骤：
一个好的bug报告应该清楚地提到复制的步骤。这些步骤应该包括导致错误的操作。不要做一般的陈述。在接下来的步骤中要明确。

下面是一个很好的书面程序的例子

步骤：

选择产品Abc 01。
单击“添加到购物车”。
单击“移除”将产品从购物车中移除。
7)预期和实际结果：
一个错误描述是不完整的，没有预期的和实际的结果。有必要概述测试的结果和用户应该期望的结果。读者应该知道测试的正确结果是什么。很明显，提到在测试期间发生了什么以及结果是什么。

8)截图：
一幅画胜过千言万语。以失败实例的截图为例，配上适当的标题，突出显示缺陷。用浅红色高亮显示意外错误消息。这提请注意所需的领域。

写一份好的Bug报告的一些奖励小窍门
下面给出了一些更多关于编写好的bug报告的提示：

1)立即报告问题：

如果在测试过程中发现任何错误，则不必等待稍后编写详细错误报告。相反，请立即编写错误报告。这将确保一个良好的和可重复的错误报告。如果稍后决定编写bug报告，那么很有可能错过报告中的重要步骤。

(2)在编写bug报告之前复制该错误三次：

你的窃听器应该是可复制的。确保您的步骤足够健壮，可以在没有任何歧义的情况下重现bug。如果您的bug不是每次都可以复制，那么您仍然可以提交一个bug，其中提到了bug的周期性。

3)在其他类似模块上测试相同的bug：

有时，开发人员对不同的相似模块使用相同的代码。因此，一个模块中的bug也更有可能发生在其他类似模块中。您甚至可以尝试找到您发现的更严重版本的bug。

4)编写一个很好的bug摘要：

bug摘要将帮助开发人员快速分析bug的性质。质量不佳的报告会不必要地增加开发和测试时间。与错误报告摘要进行良好的沟通。请记住，bug摘要被用作在bug目录中搜索bug的参考。

5)点击提交按钮前阅读错误报告：

阅读错误报告中使用的所有句子、单词和步骤。看看是否有任何句子会造成歧义，从而导致误解。为了有一个清晰的错误报告，应该避免误导性的词语或句子。

6)不要使用辱骂性语言：

很好，你做了一个很好的工作，发现了一个bug，但不要用这个信用来批评开发人员或×××任何个人。

结语
毫无疑问，你的错误报告应该是一份高质量的文件.

专注于编写好的bug报告，并花一些时间在这个任务上，因为这是测试人员、开发人员和管理人员之间的主要交流点。管理者应该让他们的团队意识到，编写一个好的bug报告是任何测试人员的首要责任。

您为编写一个好的bug报告所做的努力不仅可以节省公司的资源，而且还可以在您和开发人员之间建立良好的关系。