一个测试人员在报告中报告他所发现的每件事是非常重要的。软件测试人员在团队中充当着催化剂的角色。一方面软件测试人员组成了这个团队，另一方面也可以破坏这个应用。通过了解业务和应用的过程，清晰地理解应用中大大小小的问题是很重要的。所以一个强大的Bug报告应该做为软件开发周期中强有力的证据，来证明所有阶段的bug状态都已更新。你报告一个Bug的唯一目标就是跟踪此Bug保证它被修复。

1.清晰地描述Bug：描述Bug时要用简短的陈述句并能准确指出问题所在。描述中可能需要提供一些步骤来重现这个 Bug，同时这个简短Bug描述必须能够准确地表达出问题的本质所在。例如，假如针对一个来自服务器的错误，Bug描述要对当完成什么操作时，这个服务器错误就会发生做详尽的说明。

2.不要放过你判断：虽然你满怀信心地确信你发现的Bug的真实性，但你没写到Bug报告中，这好像代表你正放过这个发现的Bug。很可能会发生一起论战，这将反映出你作为测试人员的优越感。你主要的目标应该是让你的Bug报告令人信服，以支持你发现的Bug，唯一的目的是让Bug 最终关毕。在Bug报告中试着使用外交的表达方式，而不要使用官方的表述来赞成这个Bug，这样你的报告反而会令人不愉快。最好的方法是使用建议的方式。愉快的方式总能被采用。

3．重现的步骤：如何利用对条件设置的解释以重现并获得Bug的精确点，这必须要在Bug报告中讲述清楚。例如，对于一个绘图软件，测试人员在找Bug之前，需要和开发人员就他已经做了什么进行交流。细节必须详细说明，像按什么顺序，点击了哪个按钮。对于按照提示输入命令而运行的程序，在测试Bug之前，应该详细地说明输入命令的详细信息。

4.使用简洁的语言：人们不喜欢读包含复杂的专业术语和绕口的大段的段落。一个好的Bug报告要包含短的但是表达清晰的语子。它应该只包含与Bug有关的论述。不必要把Bug报告做的过于复杂和写太多事实而篇幅过于长。避免解说过多对重现Bug没有任何帮助的细节。大家都普遍知道的事，就不必写在Bug报告中了。

5.引用相关的例子：大部分情况下，要重现一个特殊的Bug，必须输入一些特殊的数据。但是不要做模糊的表述，像提供一个联系表中无效的人名并保存，应该说在名字域中输入像035bbb@$%这样无效的输入并点击保存。为了使Bug能快速得到处理，测试人员必须努力提供所有相关的、关键的信息来帮助开发人员。

6.提供参考信息：以防一个特殊的Bug与说明文档或其他的关于工程的文档相冲突，Bug报告必须得供充分的关于这种特殊情况的参考信息或与文档中相冲突条款的数目。

7.为Bug分配优先级和严重等级??没有为Bug设置严重级别和优先级别的Bug报告是不完整的。

Bug严重级别：指的是这个Bug破坏系统的危险程度。Bug严重级别说明了这个Bug的破坏程度。严重级别是与Bug紧密联系、永恒不变的一个特性。

8.通过抓屏截图来解释??正如谚语说的“一图胜千言”。当我们发现一个错误，最好对这个错误进行抓屏截图。如果错误是可见的，抓屏将帮助开发者准确地理解这个问题。这个阶段开发者应该首先集中集力清晰理解这个问题，而不用试着去解决这个问题。

 

这样的抓屏应该做为证剧附在Bug报告中。这样测试人员就可以很好地更清晰地和开发人员交流解释这个Bug。

9.时刻准备着向开发人员展示你发现的Bug：Bug报告中最有趣的部分是，软件测试人员需要时刻准备着向开发人员展示他发现的Bug，同时需要说服开发者，报告中的Bug都是真实存在的且需要解决的，因为它们将影响应用的性能。在这个过程中，软件测试工程师一定要为下面的几种情况做好准备：

 

（1）开发者通常会说某个特定Bug不能重现。报告这个Bug的最好方法是向开发者展示它。可以请开发者看看在你计算机上运行的情景，加载应用，为这个问题提供真实的证明。这样他们可以真实地看到并了解你是如何操作应用的，如何和应用交互的，软件对提供的输入有怎样的反应。应该避免在最短的时间内一腔热情地报告大量的不能重现的Bug。

（2）有时软件测试人员会在特定的环境中发现偶尔才会发生的缺陷。当压力达到最大极限，处于测试中的应用处于崩溃状态时才会出现这种缺陷。当软件测试人员向开发者展示同样情景以证明这种缺陷时，这时应用程序又运行正常了，这让测试人员很觉尴尬。因些一个好的测试人员要有耐心，同时要保留测试数据和抓屏等信息，为证明自己的观点建立一个可防御的机制。

（3）如果测试人员提供给开发人员一个包含各种操作和输入数据等的表，当开发人员按表中的说明在他的系统上运行时，并没有发现任何错误。这说明测试人员没有提供足够的信息。开发者所用的系统和测试人员的系统有可能在配置上会有所不同，这个会导致一些错误并不能在开发者的计算机系统上出现。测试人员也可能没有完全理解程序的需求，测试人员和开发人员看的是同样的界面，但却有着不同的看法。对于同一个测试结果，测试人员认为它是错误的但开发人员却认为它是正确的，这种情况也可能会发生。所以为了避免这种情况，最好从你认为的需求是什么，你真正看到了什么,发生了什么来支持你的观点。