关于Bugzilla本人也在不断学习中，有经验交流请给我mail。

为什么我需要Bugzilla http://www.bugzilla.org ？

一个软件写完后，事情才刚刚开始。目前我接触到的项目都是小作坊式的开发环境，所以没有专门的测试人员，开发人员就是最开始的测试人员，客户也是某种意义上的测试人员。虽然经过开发人员的测试，软件应该没有什么大的bug了，但是bug总是永远存在的，不过它有多小。而且客户的需求也是一直在改变。

在这个条条道路通我的信息时代，客户可以用电话，发qq信息，msn信息，email，或者冲过来告诉我：我中奖了，我发现一个bug，或者我想增加、修改一个功能。在这些交流方式中，我推崇用email交流，email是异步的，而且email承载的信息量比较大，Beta http://beta.xmu.edu.cn 也说了，回email时我们一般都需要思考，不管上帝是不是在发笑，至少经过思考后，我们的答复会更周全，而不是在qq里说：我知道了。好的。

我推崇email的另一个原因是基于计算机里面的一种队列queue的概念。即时信息类似一个中断，收到这个信息你被迫停止手头的工作立刻尽快做出答复。而email你可以累计4、5封mail后一并回复，如果不是那么急的话。假设我需要完成的一系列事件都看成是一个个project时，就在今天，有一个project，负责的A客户说他希望把一个网站的首页的文字“人生如梦”改为“人生是一场梦”，对于这样的修改，最慢的修改可能需要0.1秒，但是我用cuteftp连接网站，下载index.html，用editplus打开index.html，修改，上传。总过程取决于网站速度，可能是5分钟，这样效率非常低，而且你永远不知道客户什么时候给你来这个中断，可能在你关闭editplus和cuteftp拿起咖啡的时候，客户又告诉你，他想把“人生是一场梦”改为“人生是两场梦”。人生是一场梦。

除了上面的原因，反观我以往bug追踪的过程，我手动在一个目录里维护一个todolist.txt，客户或协作人员用qq，msn，email等等告诉我，和我交流。等bug数目累计到一定程度后，我开始查找聊天记录，收集更新todolist.txt，接着开始update代码。这是石器时代的做法。

所以我需要Bugzilla。我需要一个系统，可以收集我负责的软件的bug，客户可以在上面自由添加他发现的所谓的bug，然后打个电话发给mail。。。告诉我：他添加了一个bug。我们把打电话发mail发信息这件事认为是这个bug的快捷方式。电话内容不涉及具体bug信息，电话只是一个提醒。我们直接在这个系统内讨论如何修复这个bug，或者在qq里面讨论，最终有一个人（我很乐意这么做）把内容收集了RE到这个bug下面。对于这个新的bug，我可以审核他，确认他是不是bug，或者只是用户的使用错误。对于一个进行中的bug，我可以修改他的状态，被cancel或者已经完成。

to be continued…

评论

匿名 在 2003-11-13 09:18:26 说: 关注~！