完整的Bug报告的内容有哪些？

1。

描述（Description），简洁、准确，完整，揭示错误实质，记录缺陷或错误出现的位置描述要准确反映错误的本质内容，简短明了。为了便于在软件错误管理数据库中寻找制定的测试错误，包含错误发生时的用户界面（UI）是个良好的习惯。

例如记录对话框的标题、菜单、按钮等控件的名称。 2。

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

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

4。UI要加引号，可以单引号，推荐使用双引号UI加引号，可以容易区分UI与普通文本，便于分辨、定位缺陷或错误。

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

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

7。根据缺陷或错误类型，选择图象捕捉的方式为了直观的观察缺陷或错误现象，通常需要附加缺陷或错误出现的界面，以位图的形式作为附件附着在记录的“附件”部分。

为了节省空间，又能真实反映缺陷或错误本质，可以捕捉缺陷或错误产生时的全屏幕，活动窗口和局部区域。 为了迅速定位、修正缺陷或错误位置，通常要求附加中英文对照图。

8。附加必要的特殊文档和个人建议和注解如果打开某个特殊的文档而产生的缺陷或错误，则必须附加该文档，从而可以迅速再现缺陷或错误。

有时，为了使缺陷或错误修正者进一步明确缺陷或错误的表现，可以附加个人的修改建议或注解。 9。

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

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

通用UI要统一、准确错误报告的UI要与测试的软件UI保持一致，便于查找定位。 12。

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

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

如何写一个强大的bug测试报告

在报告中说“不好用”；所报告内容毫无意义；在报告中用户没有提供足够的信息；在报告中提供了错误信息；所报告的问题是由于用户的过失而产生的；所报告的问题是由于其他程序的错误而产生的；所报告的问题是由于网络错误而产生的；简单地说，报告bug的目的是为了让程序员看到程序的错误。

您可以亲自示范，也可以给出能导致程序出错的、详尽的操作步骤。如果程序出错了，程序员会收集额外的信息直到找到错误的原因；如果程序没有出错，那么他们会请您继续关注这个问题，收集相关的信息。

当您报告bug的时候（既然您已经这么做了），一定是希望bug得到及时修正。所以此时针对程序员的任何过激或亵渎的言语（甚至谩骂）都是与事无补的——因为这可能是程序员的错误，也有可能是您的错误，也许您有权对他们发火，但是如果您能多提供一些有用的信息（而不是激愤之词）或许bug会被更快的修正。

除此以外，请记住：如果是，作者提供给我们已经是出于好心，所以要是太多的人对他们无礼，他们可能就要“收起”这份好心了。“程序不好用”程序员不是弱智：如果程序一点都不好用，他们不可能不知道。

他们不知道一定是因为程序在他们看来工作得很正常。所以，或者是您作过一些与他们不同的操作，或者是您的环境与他们不同。

他们需要信息，报告bug也是为了提供信息。信息总是越多越好。

本文中提到的都是一些指导方针，没有哪一条是必须恪守的准则。不同的程序员会喜欢不同形式的bug报告。

如果程序附带了一套报告bug的准则，一定要读。如果它与本文中提到的规则相抵触，那么请以它为准。

如果您不是报告bug，而是寻求帮助，您应该说明您曾经到哪里找过答案，（例如：我看了第四章和第五章的第二节，但我找不到解决的办法。）这会使程序员了解用户喜欢到哪里去找答案，从而使程序员把帮助文档做得更容易使用。

“演示给我看”这些可能还不够。也许他们觉得还需要更多的信息，会请您重复刚才的操作。

他们可能在这期间需要与您交流一下，以便在他们需要的时候让bug重新出现。他们可能会改变一些操作，看看这个错误的产生是个别问题还是相关的一类问题。

如果您不走运，他们可能需要坐下来，拿出一堆开发工具，花上几个小时来好好地研究一下。但是最重要的是在程序出错的时候让程序员在电脑旁。

一旦他们看到了问题，他们通常会找到原因并开始试着修改。如果您必须报告bug，而此时程序员又不在您身边，那么您就要想办法让bug重现在他们面前。

当他们亲眼看到错误时，就能够进行处理了。“哪儿出错了？在我看来一切正常哦！”如果您给了程序员一长串输入和指令，他们执行以后没有出现错误，那是因为您没有给他们足够的信息，可能错误不是在每台计算机上都出现，您的系统可能和他们的在某些地方不一样。

有时候程序的行为可能和您预想的不一样，这也许是误会，但是您会认为程序出错了，程序员却认为这是对的。特殊情况下，如果有错误消息号，一定要把这些号码告诉程序员。

不要以为您看不出任何意义，它就没有意义。错误消息号包含了能被程序员读懂的各种信息，并且很有可能包含重要的线索。

给错误消息编号是因为用语言描述计算机错误常常令人费解。用这种方式告诉您错误的所在是一个最好的办法。

如果您使用UNIX系统，程序可能会产生一个内核输出（coredump）。内核输出是特别有用的线索来源，别扔了它们。

另一方面，大多数程序员不喜欢收到含有大量内核输出文件的EMAIL，所以在发之前最好先问一下。还有一点要注意：内核输出文件记录了完整的程序状态，也就是说任何秘密（可能当时程序正在处理一些私人信息或秘密数据）都可能包含在内核输出文件里。

如何有效的写BUG报告

测试向开发反馈软件存在的问题，一般是以bug表的形式进行，不可否认，每一位开发人员手头都有很多代码，所以开发人员希望收到错误信息定位明确的bug表，而不是诸如“软件不好用”这样的无用信息。

同样，作为测试人员，我们的工作也是尽量的定位问题，向技术支持方向靠拢。 一份拙劣的bug报告也许是： 在报告中说“不好用”； 所报告内容毫无意义； 在报告中用户没有提供足够的信息； 在报告中提供了错误信息； 所报告的问题是由于用户的过失而产生的； 所报告的问题是由于其他程序的错误而产生的； 所报告的问题是由于网络错误而产生的； 所报告的问题是由于相应的环境没有配置好而产生的。

报告Bug的目的是为了让开发人员看到程序的错误，当然您可以亲自给开发人员示范，当面交流，也可以在bug中给出导致程序出错的、详尽的操作步骤。这里我建议尽量用bug管理工具提出，这样做回归测试的时候，就能够有迹可循有据可依，同时也能够规范bug管理的过程。

在一个bug表中，我们希望能够包含尽量完整的信息： 1、提供测试环境及版本信息，最好包括软硬件，也许您遇到的问题并不是软件本身的问题，而是测试环境配置的问题，是开发人员在自测的时候用的环境与您使用的环境不同导致的，所以，请给他们提供详尽的信息，帮助他们定位问题所在。 2、提供能让问题重现的详尽的操作步骤，最好附上操作截图，让开发人员知道问题是怎么产生的，您的操作与他们的操作有什么不一样。