软件测试发现的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有大用,采集注意它特性
根据需要去采集,描述必须要详细
参考文献:程序之美系列:团队之美、项目管理之美,Andrew Stellman,Jennifer Greene,Scott Berkun,机械工业出版社
联系客服