文档介绍：一个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 –如何重现bugReproduce steps是很难把控的一个地方,重现步骤写得越细致,开发人员越容易重现bug,但是反过来说,步骤写得越多,读这个bug时也就越难一眼看出重点。举一个简单的例子来说,如果有一个bug是说邮件系统在特定的浏览器上发送邮件时有信息丢失,那么我们需要从打开浏览器登录这个邮箱开始写呢还是从在邮件系统中输入要发送的信息开始写呢?
Reproduce steps中需要着重注意如下地方:
a)        这个bug的重现场景是什么?是否需要一些特殊的设置?如果有的话可以用描述性的语言直接说明,可以保持Steps的简洁明了,比如在上面的例子中,我们可以在steps的前面加一个前提条件:用户已在特定的浏览器上登录了邮箱系统。
b)        重现这个bug的参考信息。例如登录需要的用户名,密码,或者附上bug产生的数据信息(特别是在数据比较复杂的情况下,这些信息可以很有效地节省开发重现的时间,他们可以通过保留的现场直接进行调查修复)
c)        如果可以的话,把关键步骤标志出来
3.      Ac