作为测试最直观的产出物来说，bug不仅是测试人员与开发交互最直接的介质，也是项目后期决定版本是否可以发布的重要依据。这也就意味不仅直接经手的bug修复人员及其它测试人员需要了解这些bug,很可能项目的管理人员也需要了解。那么如何报出一个既能提供足够的信息，又不会显得太过繁冗的bug呢？
通常来说，一个bug的基本结构是：Summary; Reproduce steps; Actual result; Expected result and Other related information (Priority, Workaround, business impact etc.).
针对这个结构的不同部分，我们可以通过注意如下内容来提高bug的质量：
1. Summary –用一句话来概括这是个什么样的bug。
可不要小看这一句话哦，当项目比较紧张或者bug数目较多的情况下，开发或者PM快速了解新bug的方法可能就是直接扫一遍summary然后做简单的bug分类。所以，summary中需要直接说明以下三个要素：
a) 这个bug是在系统的什么地方出现的，可以用系统各模块的简称来标识
b) 这个bug是在做什么操作的时候发生的，也就是直接引发它的动作
c) 这个bug导致的结果是什么
当然，如果测试人员可以定位到这个bug发生的原因，并且这个原因也很容易用三五个字表达清楚，那么也是可以加到summary中的：
d) 这个bug是什么原因引起的。
另外，可根据项目中的情况在summary中加简单的标识来表达这个bug的一些特性，例如regression test中以在summary最前端加上X来表示这个bug是当前版本新引入的:
e) Summary延展：用项目组人员统一约定的标志来传达信息
2. Reproduce steps –如何重现bug
Reproduce steps是很难把控的一个地方，重现步骤写得越细致，开发人员越容易重现bug，但是反过来说，步骤写得越多，读这个bug时也就越难一眼看出重点。举一个简单的例子来说，如果有一个bug是说邮件系统在特定的浏览器上发送邮件时有信息丢失，那么我们需要从打开浏览器登录这个邮箱开始写呢还是从在邮件系统中输入要发送的信息开始写呢？
Reproduce steps中需要着重注意如下地方：
a) 这个bug的重现场景是什么？是否需要一些特殊的设置？如果有的话可以用描述性的语言直接说明，可以保持Steps的简洁明了，比如在上面的例子中，我们可以在steps的前面加一个前提条件：用户已在特定的浏览器上登录了邮箱系统。
b) 重现这个bug的参考信息。例如登录需要的用户名，密码，或者附上bug产生的数据信息（特别是在数据比较复杂的情况下，这些信息可以很有效地节省开发重现的时间，他们可以通过保留的现场直接进行调查修复）
c) 如果可以的话，把关键步骤标志出来
3. Actual result & Expected result
之所以有这个bug,是因为它的一些特性没有符合我们预期的结果。因此我们需要把实际出现的结果和我们期望的结果做为两个部分一一列出，可以让看bug的人一眼看到差异在哪里。Actual result一定是并且只是陈述当前的表现，Expected result一定是说它“应该”要怎样怎样。
4. Other related information
作为项目运行中的一个bug来说，除了bug表现，重现步骤等信息，我们还需要添加一些可以支持bug分析的信息，例如它的优先级，它对整个业务的影响，对最终用户的影响，以及是否可以有办法绕过这个问题等。这些信息可以帮助项目管理团队决定是否要在当前版本里修复这些bug,如果要修复，应该首先修复哪一些，进而降低发布的风险。
如果测试对bug发生的原因做了分析，那么我们还可以添加一些测试过程中初步分析的结果，比如是否是发送请求时数据传入错误，或者是说数据库数据生成有问题等等。此外，问题出现时后台打印的日志，出现问题的截屏贴图都可以帮助开发更好，更快地了解并修复这个bug。
本文出自糖51t的51Testing软件测试博客：http://www.51testing.com/?371125
