软件测试过程中的BUG管理

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

创新互联是一家以网络技术公司，为中小企业提供网站维护、成都网站设计、做网站、网站备案、服务器租用、域名申请、软件开发、小程序开发等企业互联网相关业务，是一家有着丰富的互联网运营推广经验的科技公司，有着多年的网站建站经验，致力于帮助中小企业在互联网让打出自已的品牌和口碑，让企业在互联网上打开一个面向全国乃至全球的业务窗口：建站电话联系：18980820575

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

然后，我介绍一下我们如何对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的管理方式？（希望能与大家深入的交流这个问题，把这个东西彻底地搞清楚）

原文链接：http://www.cnblogs.com/brucenan/archive/2010/11/10/1874450.html

【编辑推荐】

1. 由一个Bug引出的自动扩张WPF树型表格列宽问题
2. FirePHP：像Firebug那样调试你的PHP代码
3. WCF Bug解决方案详解
4. 写给测试人员：不是所有的bug都需要修复
5. 为Web程序员解毒：9个IE常见Bug的解决方案
    

本文题目：软件测试过程中的BUG管理
URL网址：http://www.mswzjz.com/qtweb/news1/194151.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联