如何编写高质量bug报告

1.定义

Bug（缺陷）：英文单词，本意是臭虫、缺陷、损坏等意思。现在人们将在电脑系统或程序中，隐藏着的一些未被发现的缺陷或问题统称为bug（漏洞）。

2.目的

简单地说，报告bug的目的是为了开发人员或者其他人员了解程序的错误。您可以亲自示范，也可以给出能导致程序出错的、详尽的操作步骤。如果程序出错了，程序员会收集额外的信息直到找到错误的原因；如果程序没有出错，那么他们会请您继续关注这个问题，收集相关的信息。

3.报告有效Bug要注意的几个关键字

（1）Condense－精简，清晰而简短。

首先，去掉不必要的词;

其次，不要添加无关的信息。

包含相应的信息是最重要的，但是确保这些信息都是有用的。对于那些没有描述清楚如何重现或者难以理解的问题，都应该提供更多的信息。但也要避免写过多的不必要的信息。

（2）Accurate－准确，这到底是不是一个bug？

确信是一个Bug，避免因为其他原因，导致错误的Report Bug，需要考虑：是否会因为安装的某个原因导致这个问题?例如，是否安装了正确的版本而且各种先决条件也已经满足?是否登陆，安全设定，命令或者操作的顺序有错误?是否存在清除不干净，或者结果不完整，或者因为上次测试的某些更改导致?是否是网络或者环境的问题?是否理解了期望的结果?

（3）Neutralize－中性语言，用中性的语言描述事实，不带偏见，不用幽默或情绪化的语言。

客观的描述Bug，不要使用幽默的或者其他带有感情色彩的语句。在提交Bug之前，仔细阅读Bug的描述，删除或者修改可能让人产生歧义的句子。

（4）Precise－精确，这到底是什么问题？

当Bug的描述很长时，例如：“我按了回车键，然后现象A出现，接着按了后退键，现象B出现，接着输入命令‘XYZ’，现象C出现”，看到这样的说明，很难明白到底想说明什么问题，三个现象中哪一个是错误的。

不要认为你在bug报告中写的那些抽象的话别人能够理解，也不要认为看了你的描述，别人会跟你有一样的结论。你的目的不是写一份很难让别人理解的高深的文章，而是一份不被别人误解的描述。想做到这个只有清晰准确并且客观的描述你发现的问题，而不是简单说明发生了什么。

（5）Isolate－定位，这到底是个什么样的问题？

尽量缩小这个问题的范围。尝试找到最短，最简单的步骤来重现这个问题。查看是否是外部的什么特殊的原因引起的这个问题?例如，系统挂起或延时，会不会是因为网络的问题?

对于一个存在多种输入条件的项目，尝试不断的改变输入值，并查看结果，直到确定哪个值导致的错误。

（6）Generalize－归纳，还有没有其他的某些地方存在这样的问题？

Report Bug时，采用合理的步骤来确定这个问题是通常会发生还是偶然一次出现或者是在特殊条件才出现。

（7）Re-Create－重现，如何引发和重现这个bug？（环境，步骤，前提条件）

如果测试时，可以重现Bug，那么，应该准确的解释重现Bug所必需的条件。列出所有的步骤，包括精确的组合，文件名以及碰到或者重现这个问题的操作顺序。如果确认这个问题在任何文件，任何的操作顺序等条件下都会发生，那也最好能够给出一个明确的示例用来帮助开发来重现。

如果测试时，不能重现Bug，那就提供尽可能多的有效的信息。在开发没有重现或者开发没有解决之前，不要清除相应的测试数据，或者至少要备份这些数据。

（8）Impact－影响，这个缺陷对客户有何影响？对测试有什么影响？

发布产品时，需要判断未解决的影响问题。例如，在某一个窗口发现一个排版错误或者拼写错误，这类Bug对测试人员来说可能是微不足道的，但对于客户来说，这是接触产品的第一件事，所以必须在给客户实施前修改好。

（9）Debug－调试，怎么做才可以让开发更容易来修改这个bug？

开发人员会如何调试这个问题？如果需要，在Report时，提供跟踪、截图、日志等对捕获这个Bug有帮助的信息。文件的位置和访问权限设定的如何？

（10）Evidence－证据，如何证明确实存在这个bug？

提供Report的是一个Bug的证据信息，这些信息可能包括操作指导，文档，必备条件等等，还有可能是客户以前反馈过来的零碎的信息，或者是竞争对手的软件中的一些标准，又或者来源于以往版本中的结果。

4．报告软件Bug的规范

报告软件测试错误的目的是为了保证修复错误的人员可以重复报告的错误，从而有利于分析错误产生的原因，定位错误，然后修正之。因此，报告软件测试错误的基本要求是准、简洁、完整、规范。需要掌握的报告技术归纳如下：

（1）Bug 的标题

Bug标题应该简单明朗直接说明什么地方出现了什么错误。Bug的标题在很多情况下是一个有力的和项目组成员之间的沟通工具，在很多情形下，能够做决定的人都不会去仔细的看bug的描述，而只是查看bug的标题，然后就下结论。

Bug的标题必须简短而且要求描述和传达出准确的信息。因为有长度的限制，这个概要的描述一般都比较短，使用一些不会引起歧义的简写比好的语法和句子更好。因为许多使用者习惯于用关键词来搜索，所以在bug的标题中使用一些精练的关键词事很有必要的，象挂起，异常中止，拼写错误等都是比较有效的和有力的搜索关键字。如果长度允许，在bug的标题中有必要加上诸如环境，影响等5个W（why，when，who，where，what）的问题。

（2）描述 (Description)，简洁、准确，完整，揭示错误实质，记录缺陷或错误出现的位置

描述要准确反映错误的本质内容，简短明了。为了便于在软件错误管理数据库中寻找制定的测试错误，包含错误发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。

（3）明确指明错误类型：布局、翻译、功能、双字节

根据错误的现象，总结判断错误的类型。例如，即布局错误、翻译错误、功能错误、双字节错误，这是最常见的缺陷或错误类型，其他形式的缺陷或错误也从属于其中某种形式。

（4）短行之间使用自动数字序号，使用相同的字体、字号、行间距

短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。

（5）UI要加引号，可以单引号，推荐使用双引号

UI加引号，可以容易区分UI与普通文本，便于分辨、定位缺陷或错误。

（6）每一个步骤尽量只记录一个操作保证简洁、条理井然，容易重复操作步骤。

（7）确认步骤完整，准确，简短

保证快速准确的重复错误，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。

（8）根据缺陷或错误类型，选择图象捕捉的方式

为了直观的观察缺陷或错误现象，通常需要附加缺陷或错误出现的界面，以位图的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或错误本质，可以捕捉缺陷或错误产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或错误位置，通常要求附加中英文对照图。

（9）附加必要的特殊文档和个人建议和注解

如果打开某个特殊的文档而产生的缺陷或错误，则必须附加该文档，从而可以迅速再现缺陷或错误。有时，为了使缺陷或错误修正者进一步明确缺陷或错误的表现，可以附加个人的修改建议或注解。

（10）检查拼写和语法错误

在提交每条缺陷或错误之前，检查拼写和语法，确保内容正确，正确的描述错误。

（11）尽量使用业界惯用的表达术语和表达方法

使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。

（12）通用UI要统一、准确

错误报告的UI要与测试的软件UI保持一致，便于查找定位。

（13）尽量使用短语和短句，避免复杂句型句式

软件错误管理数据库的目的是便于定位错误，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。

（14）每条错误报告只包括一个错误

每条错误报告只包括一个错误，可以使错误修正者迅速定位一个错误，集中精力每次只修正一个错误。校验者每次只校验一个错误是否已经正确修正。

（15）概率性

在报告Bug时，除了在描述中说明Bug的复现步骤外，还要在Description中，添加该Bug的测试发生率。测试发生率为按照特定步骤执行多次的Bug重现率。测试发生率=ug重现次数/按照特定步骤执行的总次数。

总结：

一份bug报告中需要包括的内容有：标题、测试环境描述、详细操作步骤、软件错误描述、猜测错误原因、提供解决方案（如果可以）。

以上概括了报告测试错误的规范要求，随着软件的测试要求不同，测试者经过长期测试，积累了相应的测试经验，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习高级测试工程师的测试错误报告，结合自己以前的测试错误报告进行对比和思考，可以不断提高技巧。