项目中,测试最开始一段时间, Bug 总是不断的蹦出来, Bug 指缺陷或故障,区别在于项目发布之前发现的叫缺陷,项目发布之后发现的叫故障,通常故障会对用户造成伤害,团队里也制订了相应的惩罚机制。这次不妨从 Bug 的角度来说说项目,下图是我们使用过的一份 Bug 级别定义,一般来说对一个 Bug 的描述有以下几个关键点。
缺陷级别(Severity ) :即上图中的5 级别定义,一般大于等于III 级的Bug 被认为是严重的问题。
所属产品、项目 :有的人需要同时处理很多产品、项目,这个属性可以用来筛选。
Bug 名称 :一个短句,此Bug 的简单说明。
Bug 描述 :写成如下形式,“执行某操作,期望出现什么情况,实际出现什么情况”,还可以添加截图、文档等附件。
其实其他属性还有很多,不过我觉得非必须,经常不填,也就不说了。
我们的测试过程使用了Mercury Interactive 公司的Quality Center 来管理,它是一个基于 Web 且支持测试管理的所有必要方面的应用程序,更小的团队,用Excel 来管理Bug 也未尝不可。作为PD ,也是会经常提Bug 的,PD 做测试的时候主要是模拟用户的身份使用产品,而测试人员会更多的按照TC 执行。当发现一个Bug 以后,我们会提交给相应的开发工程师,如果认为是需求问题也会提交给对应的PD ,这时候Bug 的状态为Open ,之后的状态改变,可以用下图表示。
![Bug状态流转图(图中defer拼错了) Bug状态流转图(图中defer拼错了)](http://farm3.static.flickr.com/2596/4039067907_06812d4ba8_o.jpg)
Bug状态流转图(图中defer拼错了)
收到Open 的Bug ,确认并修复,状态变为Fixed ;否认,也许提出者理解错了,也许不打算修改,状态改为Rejected ;或者认为不是自己的问题,可以把Bug 转交(Assign to )给别人。
测试验证状态为Fixed 的Bug ,没问题了就Closed ,否则可以Reopened 。看到Rejected 的Bug ,发现是自己理解错了,就可以Closed ,仍然认为是Bug 的可以Reopened 。对于Deferred 的Bug ,意味着本项目中暂不修正,可能是因为技术做不到,时间不允许,性价比太低等,必须慎之又慎,通常由能负责的人,比如是测试经理、项目经理最终同意才Deferred 。
整个过程中,Bug 的每次状态改变都可以添加注释说明,我们更鼓励有争议叫上当事人面对面的交流,而不是在系统里不停的纠缠。
到了项目发布之时,我们要求所有Bug 的状态必须是Closed 或者Deferred ,当然对I 、II 级的Bug ,有时候并没有这么严格。
使用Quality Center 比Excel 的好处,在于每个Bug 重要的状态转换点,系统都会有邮件通知到相关人员,防止遗漏;项目中每个人在系统里的角色不同,权限不同,防止误操作,甚至一些恶意行为,比如开发人员就不能把Bug 状态改为Closed ;所有操作都有记录,谁在何时做了什么,便于追溯。这些都有效的防止了人为因素导致的问题。
PS:很久都不发带图片的文章,是因为picasa,我终于打算放弃,转投flickr了。。。