别让你发现的缺陷跑掉
（建议使用火狐浏览器，IE可能会有乱码）
假定只有一个开发人员，比如你；假定只有一个用户，比如老赵。现在来看看你们之间关于Bug方面的交互。每当你给老赵程序的一个新版本，老赵就开始玩它。由于经常出现问题，他会经常来打扰你。于是你厌烦了，跟他约法三章，“每天下午四点，我们讨论你发现的Bug！”
第一天，老赵发现了2个Bug。下午四点，向你汇报。哈，这两个都是小问题！老赵说的时候，你就顺手改好了！
第二天，老赵发现了10个Bug。下午四点，向你汇报，汇报了7个。因为他没全记住。你一边听，一边翻白眼，因为好像有几个解决起来有点困难…… 等明天上午，好好想想。
第三天，上午，你在改Bug。改好了3个。因为你忘了3个。还有1个，老赵说不清楚，让他重新演示一下，可这次又没出现异常情况。你把改好后的程序的最新版本给老赵，老赵欣然接受，但是一炷香的功夫，他就嚷嚷起来了。
其实只要对此做一点改进，就能基本解决问题了：老赵把10个Bug写在纸上。在下午四点，你们一起过一遍这张纸上的内容，然后你把这张纸放在电脑旁边直到Bug都被解决。这张纸，就是最简单的Bug跟踪系统。
Bug跟踪系统，学名叫缺陷跟踪系统(Defect Tracking System)。据此推算，Bug的学名叫缺陷（Defect）。本书自此处开始，改称呼它为缺陷。
通常使用的缺陷跟踪系统，当然比上面那个复杂得多，因为实际情况常常复杂得多。不只一个开发人员，可能是一大帮；不只一个用户，可能来自五湖四海；恐怕不是用户直接找开发人员，而是有客服人员、产品经理等等在其中，坚守岗位；另外，缺陷不光是被用户发现，事实上，相当多的缺陷是被测试团队发现。
有些开发团队使用MS Excel等电子表格来处理缺陷跟踪，这比用小纸条前进了不少。但是，通常仍然是不够方便的。比如，由于不能两个人同时修改一个MS Excel文件，所以经常需要相互等待，甚至发生修改丢失的情况。再比如，如果缺陷数量多了，用一个表格来浏览，也会很不方便。对于某一个程序员来讲，可能没几个缺陷是归自己解决的，可是却要为此，在成百上千个缺陷条目里找自己的名字。
基本的建议是，安装并使用缺陷跟踪软件。在这样的软件里，每一个缺陷是一个条目。缺陷被发现的时候，就被录入到这样的软件里。之后，软件帮助我们跟踪它，跟踪一个缺陷的整个生命周期，直到确认这个缺陷已经被消灭。
[Bugzilla] 这是开源世界当前最为流行的缺陷跟踪软件，准确地讲，是变更请求管理软件。类似的开源软件还有Mantis和Trac。
[BugFree] 这是中国人自己的变更请求管理软件，开源，用户广泛。
[ClearQuest] IBM Rational公司出品。功能强大的商用变更请求管理系统。它能够跟ClearCase很好的集成：能够将ClearCase中的活动（即任务单元），与一条变更请求记录（比如缺陷记录）关联起来。更多的功能，我们随后介绍。类似的商用软件还有Telelogic Change等。
其实老赵在把小纸条交给你之前，自己偷偷复印了一张。这只老狐狸。
变更请求管理将在下一章中讲述。在这里只要知道，对缺陷的管理，属于变更请求管理，因为修复缺陷的请求，是变更请求中的一类。
注明：上文出自《未雨绸缪——理解软件配置管理》原稿，如果对此书感兴趣可以访问互动网获取该书目录等详细信息，如果兴趣实在难以磨灭，欢迎购买。好书，定价才45元。
相关推荐：
