为什么是好的Bug报告?
如果您的错误报告是有效的,那么它得到修复的机会就会更高。因此,修复bug取决于您如何有效地报告它。报告错误只是一种技能,我将解释如何实现这一技能。
“编写问题报告(bug报告)的目的是修复bug”-由CemKaner编写。如果测试人员没有正确报告错误,程序员很可能会拒绝此错误,称其为不可复制的。
这会伤害测试员的道德,有时也会伤害自我。(我建议不要保持任何自我。自我就像“我正确地报告了错误”、“我可以复制它”、“为什么他/她拒绝了这个错误?”、“这不是我的错”等等)。
一个好的软件缺陷报告的质量是什么?
任何人都可以写错误报告。但并不是每个人都能写出有效的bug报告。
您应该能够区分一般的bug报告和好的bug报告。如何区分好的和坏的错误报告?非常简单,应用以下特性和技术报告错误。
特点和技术包括:
始终为每个bug报告分配一个唯一的编号。这反过来将帮助您识别错误记录。如果您正在使用任何自动错误报告工具,则每次报告错误时都会自动生成此唯一编号。
请注意您报告的每个bug的数量和简要描述。
如果您的错误是不可复制的,那么它将永远不会被修复。
您应该清楚地提到重现bug的步骤。不要假设或跳过任何复制步骤。一步描述的bug很容易复制和修复。
不要写关于这个问题的文章。
具体点,切中要害。试着用最少的词来概括这个问题,但要用一种有效的方法。不要将多个问题结合在一起,即使它们看起来是相似的。为每个问题写不同的报告。
有效的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报告中的重要特性:
bug编号或标识号(如swb 001)使错误报告和引用bug变得更加容易。开发人员可以很容易地检查某个特定的bug是否已经修复。它使整个测试和再测试过程更加顺畅和简单。
bug标题比bug报告的任何其他部分都更频繁地被读取。它应该能说出bug的全部内容。
bug标题应该具有足够的暗示性,使读者能够理解它。一个清晰的bug标题可以让读者更容易理解,并且读者可以知道错误是先前报告的还是已经修复的。
根据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报告所做的努力不仅可以节省公司的资源,而且还可以在您和开发人员之间建立良好的关系。