只有收集了bug数据的这些特性之后，它才真的有用！

软件测试发现的bug，可以给我们带来很多用处。比如，探索新的Bug、实现Bug再现、确定解决方案、决策测试是否终止、判断软件质量水平……

而要实现这些功用，收集Bug数据的时候就不能简单地描述下问题，有效的Bug数据需要包括下面这些核心特性：

• 优先级。设定Bug修复的优先级，可以项目团队利用有限的资源，满足用户使用的需求。优先级的设定应尽量使之保持简单。比如：优先级1=必须修正。优先级2=找机会修正。优先级3=想修正，但是不可能修正。优先级4=不可能修正。

• 严重性。严重性是指Bug的出现对软件造成的影响程度。严重性和优先级截然不同。有可能严重性高的优先级低。例如，可能有个造成浏览器瘫痪的脚本错误，这很严重；但是因为它只有在注册网页的电子邮件字段里多次大写输入“PAPAYA”时才会出现，这是低优先级的情况。

• 分配。所有的Bug都应该分配给具体的人负责解决。

• 再现。让Bug再现也许是修复Bug过程中最重要的一环。好的Bug要详细记录Bug出现的环境条件，会有简短的再现步骤帮助他人顺利地再现Bug。

• 区域。对于较大的软件项目而言，Bug应该根据它们在软件中出现的位置（区域）来进行分类。有个测试公理这样表述的：随着软件中某个部分已发现的缺陷的不断增多，其中存在更多未发现的缺陷的概率也会增大。给Bug标识出发现它的区域，很可能就会在这个区域中找出更多的Bug。

• 发现者。要给出发现这个Bug的人的姓名以及联系方式，这样修复Bug的人会知道如何以及找谁来了解Bug。

• 状态。要给每一个Bug标明它所处的状态。一个Bug只有4种状态：活动中、已修订、已解决或者关闭的。活动中是指Bug还没有修订，没有决定是否修复。已修订的意思是指程序员认为这已经修订完成。已解决是发现这个Bug的人同意Bug拖延后期或者确认Bug已修复。关闭表明Bug的生命已经结束，测试团队已经确认它的寿终就寝。

• 解决方法。负责修复Bug的人在Bug跟踪过程中就要详细地描述解决方法，以便他人对其进行确认。直到这个Bug得到解决之后，详细的解决方法也就成了一个有用的资产。

• 类型。这里所说的Bug类型有两种：缺陷型和回归型。缺陷型是常规的普通Bug。回归型是已经修订过，但是因为其他方面变化所带来的负面边际效应而又重新出现的Bug。

• 标题。所有Bug都应该有一行标题来描述Bug。

以上是参考文献中给出的一些有用的Bug特性。我们收集Bug数据，要保留哪些特性，应当根据我们的需要来确定。

这正是：

要想Bug有大用，采集注意它特性

根据需要去采集，描述必须要详细

参考文献：程序之美系列：团队之美、项目管理之美，Andrew Stellman,Jennifer Greene,Scott Berkun，机械工业出版社

---