汇聚万千丝和绪,记录点滴得与失.

-关注移动互联网、软件开发过程与质量、数据库 -开源轻量级项目管理软件实践者(Trac+Subversion+Testlink+Reviewboard+Hudson+...)

关于测试过程中的BUG管理

测试是软件开发过程中必不可少的一个阶段,大家的着重点可能都在测试人员如何发现BUG以及开发人员如何解决BUG,而很少去关注BUG自身的管理。在这里,想介绍一下我们在开发中如何进行BUG的流程管理,更重要的是想了解一下大家都是如何进行相关的工作,希望能与大家深入的交流。

首先,需要介绍一下BUG的管理工具,这个应该做开发和测试的朋友都接触过,如Bugzilla,BugFree等,我们没有单独使用BUG的管理工具,而是使用TRAC,利用其中的TICKET来做BUG的管理与控制。TRAC中的TICKET自身有状态的工作流定义,我们使用的0.11版本,TICKET状态如下所示:

basic-workflow.png

 

然后,我介绍一下我们如何对BUG的流程进行控制:

开发人员编码结束后,发布一个0.1的软件版本提供测试。测试人员对该版本进行测试,一但测出BUG,就在TRAC中新建一个TICKET,对BUG的情况进行描述,并指定哪位开发人员接收这个TICKET。同时,也指明该BUG是针对哪一个版本的软件。

开发人员在接收到TRAC的邮件通知后,登录上TRAC,查看属于自己的TICKET列表。如果这个TICKET属于自己的修改范围,就accept下来,如果不是,就reassign给别的开发者。接下来的工作就是修复BUG,修复完成以后,将TICKET的状态更改为resolve as “fixed”。如果BUG不需要修改,或者根本不是BUG,可以选择resolve as “wontfix”和resolve as “invalid”。开发人员在将所有BUG都处理完一遍之后,可以BUILD出一个新的软件版本0.2。

测试人员进行第二轮的测试,首先,他们需要把第一轮报的TICKET全部检查一遍,如果开发人员把BUG修复了,那么可以把TICKET的状态改为”verifed”,如果发现根本没有改完,而开发人员就把TICKET标成了已修复,那么测试人员可以把TICKET做一个reopen的操作。同时,把该TICKET的指定软件版本改为0.2。然后,继续测试,报出新的BUG。

如此循环下去,直到测试人员测不出BUG,或者剩下暂进不改的BUG,开发人员的修复工作停止。测试人员提交测试报告。报告包括每一轮测试中测出的总BUG数,已修复的BUG数等。

 

以上,就是我们现在应用的测试以及BUG的管理流程。目前还是有一些问题在困扰着我们:

1测试人员在发现BUG后,填写TICKET,首先发送给谁?(直接发送给测试人员,会带来很多沟通上的成本,如测试人员觉得这不是BUG等;还是发给一个能决定这是不是一个BUG,以及如果是BUG需不需要修改的人,如项目经理)

2、BUG本身存不存在版本这么一说?(BUG是只针对某一版本的测试软件,还是跟着软件版本一起走,比如说reopen的BUG)

3、有没有更好的测试管理流程,包括BUG的管理方式?(希望能与大家深入的交流这个问题,把这个东西彻底地搞清楚)

posted on 2010-11-10 23:35  brucenan  阅读(3535)  评论(6编辑  收藏  举报

导航