微软的开发流程和bug管理

孟岩：刘振飞，你好。我知道你以前是方正出版印刷系统的核心开发人员，后来来到微软的Office开发组。我认识你的时候你还在微软工作，状态似乎不错。为什么后来又离开微软了呢？ 

刘振飞：93年到96年，我在北大计算机研究所读研。96年毕业后，我留在所里继续从事方正核心产品世纪RIP --- PSPNT的研发、维护、升级（还有外围软件开发比如新女娲补字NewNW、PDF流程系统等）。PSPNT是国内比较大的、成功的软件产品，我一直为曾参与研发过这个产品而自豪。

工作中，我模模糊糊地觉得应该有一个清晰的、可控的流程，而不是依靠几个开发“高手”来支撑一个项目。方正人的个人素质非常优秀，集中在一起应该做得更为出色。我在方正的时候最多也就带过10来人的队伍，但即使这么小的团队，已经让我精疲力竭、疲于应付了。我发现面临一个无法解决的难题：如何有效地控制软件研发流程以保证产品质量和进度。我意识到做好一个软件，只靠技术好是很不够的，必须要有一套好的研发流程和配套的支持工具。你也知道国内软件企业的项目经理都是“全才”：需求、设计、编码、测试、维护乃至产品发布都要精通，事必躬亲，但实践中你又不可能样样都精通，所以结果只有一个：四处救火，累得半死但永远看不到尽头。

当时就觉得这么干有问题，但究竟问题出在哪里、如何有效改进都不知道。我最纳闷的是：这么10来号人的研发管理就这么费劲，人家微软上千人、分布全球的Windows、Office研发队伍是怎么有效管理的？我当时深入研究了一些软件工程方面的理论，比如花了一段时间仔细阅读了原版的Rational Unified Process（RUP），觉得很兴奋，RUP里面的研发理论很完备，和几个同事聊天觉得应该按照RUP的去做，但是理论归理论，具体到实际产品开发该如何做，还是一筹莫展。

恰好那时候读了微软（中国）公司前总经理吴士宏的畅销书《逆风飞飏》，提到了微软的企业管理、内部的数字神经系统及相关叙述，非常感兴趣，想去那里看看。刚好有个机会，得到了微软（中国）研发中心Office组的一个PM（Program Manager）职位。在微软的4年中，我先后经历过Office XP、Office 2003的研发，中间还夹着做过Project 2002。微软所有产品的研发都遵循同样的研发模式、使用同样的研发工具来进行管理，只不过产品大小不一、人员配置有点区别罢了。经历这几个大产品的研发流程，加上在方正的体验的对比总结，我觉得自己比较深入的理解了微软做研发的“套路”。

    我是C++程序员出身，当PM后就没怎么写过代码，总还想写写。刚好几个朋友开的公司要做网站、短信、声讯，还要对报纸做数据支持，他们需要一个懂研发管理的人去带技术部。我觉得已经熟悉了微软的研发流程，这刚好是一个检验自己所学所思的机会，所以就离开微软去做这家小公司的技术总监了（而且满足我另外的愿望：我对Windows之外的世界充满好奇，比如每天去新浪网看新闻，他们网站是如何做出来的、用到什么样的技术？Linux、开源软件到底怎么回事？）

    不过我一直认为微软是一家伟大的公司，很喜欢其工作氛围。特别的，微软的软件研发流程我认为是最先进的，值得大家去学习。 

孟岩：那请你介绍一下你所体会的微软研发管理的妙处。

刘振飞：从我理解的角度，微软的研发管理可以从以下几个方面描述：

（1）研发人员分工明确。主要的三个角色： PM (Program Manager)、 Dev (Developer)、Tester三者分工明确、接口清晰，PM来定义需求、书写出来每个功能特性 (Feature)的设计文档(Spec)，Dev写代码来实现这个Spec，Tester来测试 Dev做出来的东西是否符合 PM定义的 Spec，三个角色之间并无必然的上下级关系，只是分工合作完成某个功能(Feature)。我将之形容为“三权分立”，三者之间有效合作并制衡。国内企业好像还没有PM这个角色，而测试人员又往往成为开发人员的附庸，一个 Bug是否要被解决全由开发人员说了算，这很糟糕，就像政治上一个权力没有被有效的制衡一样，一定会产生各种问题。

（2）研发工具很配套。PM将写好的需求设计文档(Spec)保存到 SharePoint文档库中，所有相关的人都可以随时查看；Dev用Source Depot （功能类似CVS的微软内部源代码管理工具）来保存源程序；Tester把发现的Bug记录到Raid中以有效跟踪这个问题的处理流程。

（3）分阶段的研发流程。和任何软件公司一样，微软的研发无非也分为规划、开发、测试、发布等几个阶段。但是微软的研发流程不走形式，可以统一产品组所有员工的思想，并且能够有效地控制住进度。做完一个版本后，还会让所有员工匿名投票，找出这次研发过程中出现的各种问题以便在下个版本中解决 (此过程称为 Postmortem，挺吓人的一个词)。

    可以这么比喻，微软这套研发模式让其中的每个人都成了一架高速运转的机器上的各种零件，少数零件坏了不要紧，可以随时更换。当然微软有许许多多技术高手，但我认为更重要是其研发模式保证了软件产品的高品质、可持续发展。 

孟岩：提到微软的研发管理，你说过一句话，我印象很深。你说微软的研发管理中，它的bug管理系统是居于核心地位的。你这么说，有什么道理吗？ 

刘振飞：前面说过，微软所有产品的研发都遵循同样的研发模式、使用同样的研发工具来进行管理。在所有的工具中，我最佩服的就是其Bug管理系统Raid（现在叫Product Studio）。可以说，遍布全球的微软研发人员能够保持统一的思维模式、做事及语言习惯，与整个研发流程的配套工具密不可分，其中最重要的就是通过Raid把整个产品的研发有机的联系起来。阅读每个 Bug，你可以详细的看到大家讨论解决该问题的完整思路。

我曾读过微软Project 2002产品的Architect写的一个备忘录，其中提到： 如果Raid是别家的产品，需要微软每年付出一笔巨大的费用，Bill Gates会支付这笔钱吗？“He wouldn’t be happy, but you bet he would. Microsoft depends on Raid to get the job done.”当时我“心有戚戚焉”，立即给这哥儿们发Email表示赞同之意J他回信说希望Project能够做的像Raid一样成功，但可惜他要离开微软自己开公司了。

在微软上班，我每天第一件事是打开 Outlook来处理有关自己的重要邮件，第二件事就是打开Raid来看看有关自己的Bug情况，赶快处理。我一直纳闷，微软为什么不把这个Bug管理系统作为软件来出售，那可是任何一家软件企业都需要的啊！

表面上看Raid其实是一个简单的工具，那么它的重要性体现在什么地方呢？

l         Raid从一开始就支持多用户

l         一个团队中的所有人都可以创建、指派Bug，或者改变Bug状态

l         用户可以非常自由的去定制Raid

l         基于SQL，很多有用的报告可以被生成出来

l         管理层需要所有Bug都在Raid中被有效的跟踪处理

Raid的价值在于它密切跟踪当前产品的实际Bug状态，使项目组中的成员非常有效的协调他们的工作。大家都很聪明，如果一个工具是容易理解的、而且管理层提供其使用指南（比如Bug怎么被指派和解决），那么简单的工具也能提供巨大的价值。 

孟岩：能否请你简要地介绍一下微软的bug管理体制？

刘振飞：在整个产品的研发过程中，特别是在测试产品、修复Bug的中后期，团队中所有人都生活在Raid中：

-          测试人员（Tester）只要发现问题就立即新建一个Bug予以跟踪并指派给相关的开发小组长（Dev Lead）

-          开发小组长会判断这个Bug属于某个特定的开发人员（Dev）并指派给他处理

-          开发人员会根据Bug的详细描述信息找到问题所在，修改程序解决这个Bug并把Bug返回给当初的测试人员；或者有争议的时候，把Bug指派给这个Feature的定义者PM，要求一个澄清说明

-          测试人员在看到某个Bug被解决后，就去验证这个Bug是否真的不存在了，根据最初的发现步骤去证实问题真的解决了就关闭这个Bug；若还能重现，或者不同意开发人员的解法，可以激活这个Bug，返还给当初的开发人员做进一步调查处理

-          当测试人员和开发人员无法达成一致意见的时候，由对应的PM出面做协调，判断这个Bug的严重程度、对用户可能的影响，根据产品的进度和项目资源做出评估，是否真的需要修理掉这个问题

-          管理团队利用Raid来跟踪整个进度：单个人的工作、小组的进度，整个产品研发进度

研发队伍中的所有人都通过Raid来商议、沟通某个Bug是否符合当前解决Bug的“门槛”，决定是否需要真正修理掉这个Bug、如何修理、可能的副作用、如何测试其解决方案等等。每个人可以在Raid中看到某个Bug的全部历史档案，比如几年前发现的一个Bug一直推迟到这一版才解决，前几年大家是如何讨论的，可能的处理思路是什么，都被完整地记录下来了。

    每月、每周甚至每天，参与这个产品研发的人都收到一封当前Bug状态的Email：每个人都上有多少Bug，Dev、PM、Tester头上Bug数最多的前5名都是谁，哪个子产品、子模块中的问题还是处于上升阶段，整个Bug的趋势怎么样等等。这是最详尽的产品状况“内参”，暴露在团队中每个成员的面前，一览无遗。只要你的名字被列在Email中，你就非常紧张，因为你脑袋上的Bug比较多、影响整个产品的质量。这些该死的Bug等待着你去快速处理，尽快把自己从排行榜上去掉。每解掉一个Bug，或者把Bug转给另外的人去处理，就会舒一口气，因为头上又少了一个；某一天你头上的Bug数降为0了，心里就会非常高兴J

    我觉得微软的Bug处理过程，非常类似于“击鼓传花”的游戏。鼓点响起，你的任务就是尽快把自己手中的“花”（Bug）传给下一个人，不要让它在自己手里耽误很长时间。从表面上看，在微软工作从不打卡、上班时间也很自由、上午很晚到办公室也没人管你，但是有Email跟着、有Bug催着，你永远不可能偷懒。没有人盯着你，只是事情如影随形，而且所有和你相关的事情都是公开的，相关的人都知道，就像处于非常开放的舆论监督之中，除了把事情办漂亮你还能有别的选择吗？

    最后要强调两点：

（1）上Bug不仅仅是测试人员的事情，团队中的每个人发现问题时都上个Bug来跟踪；

（2）  Raid中不仅仅是跟踪软件功能方面的Bug，其他各种问题如需求文档（Spec）的改动、界面上的错别字、帮助文档的遣词造句问题、某项任务指派等等都可以通过一个Bug来跟踪。

我至今对刚进微软时老板的一句话印象深刻：Everything should be tracked in Raid！ 

孟岩：就你了解到的情况，国内的公司在这方面怎么样？

刘振飞：在微软这几年，我也一直和国内软件公司的朋友们保持接触。很遗憾的是，国内的一些软件企业，特别是不少中小企业，其软件研发还是处于作坊式的状态，只不过作坊规模有大中小之分罢了。有意思的是，走在国内IT最前沿做各类网站的企业，根据我的了解，也在走软件企业最初几个“大虾”（牛人）搞定一切的阶段。我不是说个人技术好不重要，而是需要更进一步，把研发管理真正搞起来，做出规模效应，从而有效的保证质量、控制进度、把对某个人的依赖尽量降低，并使产品可持续发展。

    你知道国内不少软件企业在做ISO9001或CMM认证，花费不菲。少数企业纯粹是为了认证而认证，对付着拿到证书就达到目的了；更多的企业确实是想利用这个认证的过程，把自己的研发流程规范化。但似乎能从这些认证中享受到真正的研发管理提升的并不是很多，甚至开发人员现在需要花费大量的时间去书写一些例行公事的、没有任何实际价值的格式化文档，苦不堪言。

我觉得软件研发管理必须结合自己企业的实际情况，不要生搬硬套书本上的理论，只要人员分工、配置合理，能够控制质量，什么方法都可以采用。黑猫白猫，能抓耗子的就是好猫。千万不要走形式、走过场。 

孟岩：其实国内公司在研发方面与微软的差距非常大，也存在于很多方面。为什么你独独看中bug管理？为什么你认为中国中小型企业的软件开发管理规范化，应当从bug管理入手呢？

刘振飞：从微软的研发管理来看主要是需求、开发、测试这三大块，毫无疑问国内公司在开发这个环节一直都很重视，不过需求和测试较弱一点。大家现在都已经认识到充分理解业务需求的重要性，如果没有很好的对项目或产品用户需求的真正把握，后面所有的工作都将是白费工夫、事倍功半，这一块缺乏的是如何有效地将用户的需求转成一份份详细的、后面开放测试人员可以理解的文档。

    但是测试这一块大家还是不够重视，对测试人员的素质要求也不是很高、人员比例也较低，测试人员往往依附于开发人员的直接管理，人微言轻。而在微软，测试人员和开发人员的比例很多时候是1比1的，有时候会更高。测试人员和开发、需求人员一样有自己单独的行政管理路线，比如我就注意到有非常资深的测试人员可以做VP，专门管理某个产品的测试工作。这在国内企业来说，几乎就是不可能的。

    通过前面的介绍，无论人员的配置和工具的提供，你可以看出微软是非常重视测试的。所以我觉得如果我们学习微软先进的研发理念，可以从测试入手，打造必要的测试管理系统，通过这样的系统，把需求、开发、测试三个环节融合在一起，让团队中所有的人都遵循同样的研发思路：需求人员真正理解用户的业务需要，认真研究后形成需求文档作为产品一个个功能的“合同”；开发人员写出设计文档，然后动手写代码；测试人员理解需求文档，然后测试做出来的功能是否符合最初的设想。整个过程碰到的任何问题都要通过Bug系统来记录、跟踪，相关人员通过Bug管理来商谈、沟通相应的解决方案。

    这样通过Bug管理，逐步统一研发人员的思维、做事模式，让整个团队可以有效地运转起来，并不断优化自己项目的软件研发流程，提高产品质量，从而使产品可持续发展。 

孟岩：看来你对于bug管理可真是重视。听说你在离开微软后，开发了一个开源项目BugFree，号称是要全面模拟微软的bug管理机制。能介绍一下大致的情况吗？

刘振飞：今年四月我加盟朋友的公司开始做网站，发觉自己已经习惯了微软的研发模式，于是建议这几个朋友先做一个“数字神经系统”，其目的是让一切可以数字化、文档化的信息被记录下来，为公司的进一步发展和决策提供基础信息支持。

    BugFree 就是其中有关软件研发的Bug管理系统部分。我太了解Bug管理对软件研发的重要性、也对微软的Bug系统有了深入掌握，所以需要有一个类似微软的Bug系统才好开展工作。虽然网上有免费的Bug管理系统（如Mantis、Bugzilla），但是我看后觉得都不好使，和我在微软用的差别太大，上海科泰世纪公司的 Bug管理系统倒也很像微软的，但是要花钱买。琢磨着反正我也这一块非常熟悉了，何不做一个出来自己用？于是决定借鉴微软的研发流程和Bug管理工具自己开发一个，以便对我们开发新网站、声讯软件、客户端软件和公司事务管理中出现的问题进行有效的跟踪处理。

“数字神经系统”中的BugFree是用开放源代码的PHP+MySQL写成、基于浏览器方式运行的。我以前没有任何Linux+Apache+MySQL+PHP的开发经验，但我很幸运的招聘到几名优秀的Web程序员，可以在短短的两个月时间内搭建起这样的系统。其中BugFree是由我的同事王春生开发的，他用了不到一个月的时间就把代码写完，让我很是惊讶，从而认识到基于Linux的Web开发魅力。之后我们测试一个多月，就可以在实际工作中使用并不断完善。现在BugFree已经成了我们日常工作最重要的工具，每个员工也都习惯用Bug来记录跟踪事情，不仅仅是代码中的缺陷可以上Bug，新的需求、设计变化等都可以用这个Bug管理系统有效的管理起来。其实Bug 不仅仅可以用来记录软件中的缺陷，也可以用来跟踪公司的日常事务。比如在公司的网上报销系统还没有建立之前，我们就用 BugFree来处理报销的事情。甚至，一个同事给我上了这样的Bug：你的桌面太乱了，请整理一下J

命名BugFree 有两层意思：一是希望软件中的缺陷越来越少直到没有，Free嘛；二是表示它是免费且开放源代码的，大家可以自由使用传播。也算为中国的软件业做点小小的贡献，特别的，希望能对国内中小企业的研发流程改进、Bug的有效管理提供参考和帮助。

和微软内部的Raid比较起来，BugFree有如下特点：

（1）Raid是Windows客户端软件，BugFree是基于浏览器的。基于此，Raid 有很强大的编辑展示功能，而BugFree简单、方便、易用；

（2）Raid可以进行极其复杂的组合查询，BugFree的查询功能相对弱一些，但我觉得对中小企业已经够用了；

（3）一个Bug从创建到关闭这个“生命周期”的处理过程，BugFree 全面借鉴Raid的处理流程，处理方法甚至一些词汇都和Raid一样 (所以我现在用BugFree处理Bug的感觉和在微软时候基本一样)；

（4）BugFree 还有一个独创的功能：当一个Bug被指派给你的时候，系统会自动给你发一封邮件，告诉你有个Bug需要你处理，这样结合 Email，BugFree被完美使用起来，成为我们现在网站开发、运行、维护必备的工具。我们还增加了两个Bug统计功能：一是每天早上8点钟每个同事都会收到一封Email，告诉他/她头上还有多少 Bug等待处理；二是每周一中午给所有人发一封邮件，告知上周Bug的处理情况和到目前为止所有Bug的统计数据；

（5）BugFree程序规模很小，一个中等水平的PHP程序员就可以在1~2周内看懂所有的代码，然后就可以根据自己的需要做相应的定制了；

（6）最最重要是，BugFree 是免费并且开发源代码的。你可以体验到微软的Bug管理精髓，按自己需要自由地增加功能、修改代码而不用担心版权问题J

 不过坦率的讲，BugFree 仅仅是个工具而已，重要的是掌握其中蕴含的软件研发的流程思想，才能用好这个工具。如果你以前没有用过 Bug管理系统，那么一开始的时候也许你会觉得这个工具是在浪费时间，因为一个测试人员需要费神把发现 Bug的详细步骤记录下来，有时还要贴一张示意图，这一切都不如当面说来得直接。

但是使用一段时间，你会发现 BugFree很有用，它忠实的记录着每个问题的处理过程，不断提醒你存在的问题，永远不会丢失和忘记。如果你参与过较大软件项目或产品的研发，就会理解它对软件可持续发展是至关重要的。而且研发的规模越大，BugFree 的作用就会越大。

感兴趣的朋友，可以到http://www.okooo.com/OpenSource来体验、下载最新版的BugFree。

孟岩：好的，我们下期结合BugFree来具体看看一个软件开发项目的bug管理应该怎么做。

　

—发表在《程序员》杂志2005年第2期38~42页的原文—

孟岩：刘振飞，你好。上一期文章里，我们谈到了Bug管理的理念和经验。按照我的体会，Bug的控制是一个管理与技术相结合的课题。做好Bug的管理，一方面需要有完善的管理体系和制度，另一方面更需要有一个坚实的基础平台来支撑。确切地说，就是要有一个比较完善适用的软件，充当Bug管理的中枢神经。显然你是很看重这个软件系统的。我想问你一个问题，如果没有这样的软件系统，而是单方面强化管理，比如制定完善的流程和制度来管理Bug，你看这样可行吗？ 

刘振飞：从我的经验来讲，只靠制度而没有良好的Bug管理软件，根本无法确保Bug管理的有效性，因为仅靠这些规章制度很可能流于形式、走过场。正如源代码管理一样，如果没有类似CVS或VSS的工具，很难想象一个较大项目中的源代码仅仅靠公司的源代码管理制度和大家的自觉性，就可以让多个程序员之间的不同版本源程序保持同步、不冲突。光有制度是不行的，必须有配套工具来保证这些制度落到实处！

       还有，做好 Bug 的管理，应该是从高层领导到中间管理层再到基层人员，都从内心认同其重要性，然后根据自己公司的实际情况制定相关的管理体系和制度，切实执行并逐步形成自己的风格。要实用、不要随波逐流。不能今天一个ISO、明天一个CMM、后天又来个6西格码。工具是思想的载体，再好的管理思想还是要通过工具来实现。购买也好、自己开发也好，必须有个 Bug 管理工具作为基础支撑平台。 

孟岩：一个企业如果有意建立自己的“Bug管理神经系统”，大致可以有三种选择，一是购买成熟的商业产品，二是选择类似BugFree那样的开源软件，三是自己开发符合本公司现有架构的Bug管理软件。对于某些公司来说，最后一种模式应该是很有吸引力的。你主持了BugFree的开发，能否告诉我们，开发一个Bug管理系统难不难？ 

刘振飞：应该说不难，想自己开发一个Bug管理系统的朋友，你首先要明确本公司真正的需求是什么，再就是根据你的需求做出来后一定要在实际产品研发中真正应用起来，根据大家的反馈不断去完善。

       像我们开发BugFree，从开始动手写代码到真正能够在公司里使用，前后也就两个月时间。为什么能够这么快做出来呢？最重要的原因是我把BugFree的需求真正掌握了。我在微软天天使用Raid、时时刻刻和Bug管理打交道。我是站在微软这个巨人的肩上去深刻理解其20多年研发所总结出来的经验，所以四年下来，不让我熟悉Bug管理都难J当我决定做 BugFree 的时候，脑子里很清楚为什么要做、做成什么模样、应该怎么做、做出来后大家怎么用，每个环节都考虑清楚了。这样真正实现的时候就很快了。

       当然仅仅做出来是不够的，还要在实际工作真正使用起来，并根据大家的实践去不断完善这个系统。之所以敢于把 BugFree 开源出来展示给更多的朋友，是因为经过我们近20人的团队10个多月的实际应用，大家一致觉得它是个难得的好工具、是日常工作的好帮手，大家工作都离不开了。

       不过，现在有不少成熟的Bug管理软件可以买的到，也有很多开源软件让你自由挑选。BugFree 是免费并且开发源代码的，你可以体验到微软的Bug管理精髓，按自己的需要自由地增加功能、修改代码而不用担心版权问题，为什么不试一试？实在不满意再动手自己造也不迟J  

孟岩：那么去买一个成熟的商业产品如何？有什么比较好的选择吗？我听说科泰世纪公司在陈榕的领导下也开发了一个类似微软内部使用的Bug管理系统，你了解吗？还有开源社区里很流行的Bugzilla！，你怎么看？ 

刘振飞：成熟的Bug管理商业产品应该有不少，比如，IBM提供的Rational ClearQuest、微软将在VS.NET 2005（Whidbey）中集成的Bug管理系统、上海微创提供的BMS、科泰世纪《和欣软件工程管理工具》套装软件中的Bug管理系统等等，都应该不错。开源社区中，你可以选择Bugzilla！、Mantis等Bug管理系统。

       老实讲，除了微软相关的Bug管理系统之外，其它的我都不熟悉。不过我认为不同的Bug管理系统之间功能上应该不会差别太大，因为大家都是从软件实践中总结出来的经验结晶，不会说某家有特别独到、别家根本想不到的地方。差别之处主要在于价格、安装配置、易用性、可定制、能修改源程序等方面。

       在我决定做 BugFree 之前，曾经考察过上面提到的开源社区Bug管理系统，但是简单研究之后，觉得和我在微软用的Raid差别太大、不习惯；陈榕在微软工作时间更长，他们做的系统也是借鉴微软、最接近我的使用习惯，但是得花钱购买（尽管比起其它商业化Bug管理系统而言，价格不算贵），而且不能根据我自己的要求随便更改，所以干脆自己做一个算了。不管怎么样，我觉得多样性是一件好事，给了大家更多的选择机会。每家公司、项目、人员的状况都不一样，都可以根据自己的具体情况挑选自己喜爱的Bug管理系统。

       顺便说一句，通过我自己做BugFree开源的经历，觉得自由软件的真正魅力不在于其零价格，而是其源代码的完全开放，你可以根据自己的具体情况自由的去修改、去定制，完整的控制整个系统。

孟岩：如果有这么一家公司，它接受不了整套的Bug管理制度，打算自己开发一个Bug管理系统，以适应自己企业的需求，让你给参谋参谋，你觉得一个良好可用的Bug管理系统，需要有哪些基本功能？ 

刘振飞：我觉得一个Bug管理系统需要具备以下外部特征：

1．可以完备的记录、跟踪Bug 的一生：从出生（创建新的Bug）、不断成长（记录相关人员寻找产生Bug的原因的讨论过程）、发育成熟（找到了一个处理办法）到最后死亡（关闭），同时也要允许Bug的复活（问题重现），继续其生长过程。

2．方便的查询功能，快速找到你关心的 Bug。比如：

a). 最近N个指派给我的 Bug

b). 最近N个由我创建的 Bug

c). 各种自定义条件的查询

3．提供各种Bug统计信息。比如每个人头上有多少个Bug、到目前为止Bug总数的统计、最近一周Bug曲线图等等，视具体需要可以有很多种统计。

4．方便的项目和模块管理，可以有很多项目、每个项目有多个模块，要能够很方便的增加、删除、修改。

5．简单的用户管理。作为一个可独立使用的系统，需要能够增加、删除用户。当然最好的是直接使用公司已有的管理系统中的用户认证。比如在微软，只要你登录公司内部网（域）后，你就可以直接使用Raid了，它直接集成了公司的用户认证，不需要单独一套用户认证系统，那样对使用者就很不方便，管理起来也会比较混乱。 

孟岩：你结合BugFree具体谈谈，这些功能是如何协同的？开发者、测试工程师和PM在整个开发过程中，是如何围绕这个系统运转的？ 

刘振飞：先从基础设施说起。首先BugFree有一个独立且简单的用户管理，可以方便的增删用户：

然后是简单的项目/模块管理，管理员可以方便的增加新的项目、新的模块，或者更改已有项目/模块的显示名字：

因为仅仅有管理员才可以进入后台管理，所以这两个后台功能做的比较简单。 

这样定义了项目/模块和用户后，BugFree的用户就可以进行Bug的跟踪处理了。举个虚拟的场景，林燕锋、你、我三个人在一家公司做网站，他是测试工程师（Tester）、你是开发工程师（Developer）、我是需求定义者（PM），我们三个负责公司网站的新闻频道：

[1]. 林燕锋发现新闻频道的后台管理中“编辑”功能打开速度非常的缓慢，无法忍受。于是他新建一个Bug说明这个问题，然后指派给我；

[2]. 我看到这个Bug后，赶快到新闻频道的后台试用一下，果然很慢。于是我把这个Bug指派给你，加上我的注释：“孟岩，这项功能使用很频繁，速度太慢直接影响了我们信息编辑的工作效率。请你研究一下这部分代码，看如何调整程序，以加快打开速度。”

[3]. 你看到这个Bug后，作为这部分功能的实现者，去认真地研究了当时的代码，经过调试，发现是数据库查询方式的问题，采用不同的方式之后，新闻编辑功能的速度大大提高了，于是你解掉（Fixed）这个Bug，并把你发现的问题原因和解决方法做了描述：“不好意思，以前的查询方法有点笨，现在已经修改了数据库查询方式，加快了浏览速度，具体改动请参见附件EditNews.php。”因为问题被解决，这个Bug会被自动指派给创建者林燕锋头上。

[4]. 林燕锋看到这个Bug被Fixed了，赶快去验证了一下，发现问题真的消失了，于是他关闭这个Bug，并加上注释：“太好了，刚才用了一下，速度确实快了很多。我代表信息编辑感谢你老兄的工作啊！:-)”

       你看这样做，BugFree就非常完整地记录了Bug的一生：如何发现（创建Bug）、不断讨论（编辑Bug）、找到原因（解决Bug）到最后关闭它。这样开发工程师、测试工程师和PM在整个开发过程中，都被一个个情况各异的Bug们牵着鼻子，密切配合，不断发现问题、研究可能的原因、找到处理办法、验证解决方法是否真的凑效。BugFree 让所有项目/产品的研发参与者围着它转，忠实的记录了所有被发现问题的讨论处理过程，即使时间过了很久、我们三个都离开了这家公司，但当时我们处理的思路被保留下来了，后面接手的同事可以完整无误的看到全部的讨论过程，就像有台录像机把这个过程录下来一样。 

孟岩：从内部来看，BugFree的架构是怎么样的？ 

刘振飞：BugFree 是用 PHP+MySQL 写成的。首先我们定义了七个相关数据表：

-          BugProject: 项目表

-          BugModule: 项目中的模块表

-          BugInfo:      Bug基本信息表

-          BugHistory: Bug处理过程的历史记录表

-          BugFile:        Bug相关附件表

-          BugQuery:   Bug查询条件表

-          BugUser:      Bug的简单用户表

程序代码也是按照前面介绍的Bug管理功能展开的，基本上一个功能对应一个PHP文件，比如：

● Bug的处理过程

-          AddBug.php:             加入一个新Bug

-          EditBugForm.php:    编辑一个Bug的信息

-          ResolveBug.php:       解决一个Bug

-          ActivateBug.php:      激活一个Bug

-          CloseBug.php:           关闭一个Bug

●     Bug的查询

-          QueryBug.php:          查询符合条件的Bug

-          SaveQuery.php:        保存用户定义的查询条件

-          DelQuery.php:           删除一个用户定义的查询条件

●     Bug的统计自动通知

-          NoticeBug.php:         发信通知每个用户的Bug情况

-          StatBug.php:             发信给所有人告知当前Bug统计情况

BugFree 中使用Smarty技术把PHP代码和HTML隔离开，每个涉及到界面的.php文件，都有一个对应的在Template目录下的.tpl文件，这样代码结构就非常清晰，很容易看懂、维护和添加新的功能。

主要目录结构如下：

\                   -     根目录下主要存放上述Bug一生处理流程、查询等功能文件

Admin\        -     后台管理对应的文件

BugFile\       -     存放Bug中的附件

Compile\     -     存放Smarty编译后的文件

Document\ -     BugFree 的各种说明文档

Image\        -     BugFree 中用到的各种图片

Include\      -      公用文件

JS\               -     用到的JavaScript文件

Shell\           -      存放需要定时执行的文件

Template\   -     所有界面模板文件（.tpl）

    除去ADO、Smarty等第三方文件，BugFree 自身也就是由30多个PHP文件组成。更详细的说明请参看Document\FileList.txt (代码文件结构)。 

所以你看，BugFree 的架构其实非常简单，代码量也不大。想探个究竟的朋友，只要明白了表的结构，然后按图索骥，根据功能逐个查看对应的代码文件就可以了。PHP 程序的复杂度要远小于C/C++，很直观。我觉得一个中等水平的 PHP程序员就可以在1~2周内看懂所有的代码，然后就可以根据需要做相应的定制了。BugFree 仅仅是个小工具而已，没有什么神秘的。 

孟岩：看来BugFree的设计考虑是相当细致的。不过很多人都抱怨这个用PHP编写的软件不容易配置，尤其是在Windows环境下。你能否简单地给大家介绍一下BugFree的配置和部署方法？ 

刘振飞：上一期文章发表后陆续收到一些网友的Email，反映的主要问题是 BugFree 在 Windows平台上的安装问题，而Linux平台上似乎很少人抱怨。这从一个侧面说明在Linux上大家已经习惯自己动手配置、有问题自己能找到解决办法J

坦率的讲，因为时间、精力、资源有限，目前我们对 BugFree的安装配置这一块的测试做的很不够，所以还要请网友谅解。我也是通过这个软件，觉得做好开源项目真的很不容易，需要付出巨大的努力，因而很佩服那些为开源社区贡献优秀软件的人们。

       从反馈的情况来看，我想主要的原因有三个：

[1]. 运行环境的版本问题，比如PHP、MySQL的版本

[2]. 程序路径问题

[3]. PHP 的配置参数

    目前经过我们实际测试的工作环境有：

        ●  PHP 4.3.8和MySQL 4.0.17　(基于RedHat 9 + Apache 1.3.x)

        ●  EasyPHP 1.7 (我自己在Windows上测试过)

其他环境，如IIS、Apache2、PHP5等，还没有测试过。在Window上使用BugFree需要改动PHP.ini中的下述参数：

        allow_call_time_pass_reference = On

        error_reporting = E_ALL & ~E_NOTICE

        register_globals = On

    根据大家的意见，我特别写了一份文档“在 Windows 平台上安装 BugFree 的详细步骤”，公布在http://www.okooo.com/OpenSource，供大家参考。

若有朋友成功尝试过其他版本的运行环境，欢迎你把详细步骤整理出来发送给我，这样我可以共享给所有网友。这就是开源的好处：和感兴趣的热心朋友们一起不断完善 BugFree。 

孟岩：我记得BugFree 1.0开发出来以后，你特别兴奋，跟我说这个系统已经达到了微软内部系统的水准。不过马上你就开始做2.0版。2.0有什么大的改进吗？是你的1.0版还不够完善，还是说你对于Bug管理有了新的认识？

刘振飞：前面提过，BugFree 仅仅是个小小的Bug管理工具而已，所以第一版发布后我觉得从1.0计数有点不好意思，那么庞大的Apache才到2.0了嘛。所以我决定 BugFree 的版本从0.1计数，慢慢往上加J

       BugFree 0.1版是在2004-10-11正式公开的。在我们内部使用过程中，逐步累积了不少新的功能需求一直没有来得及添加，而且 Ver 0.1主要有两个不足：

[1]. 最初的代码是10个月前写的，有很多不规范之处。而且PHP代码和HTML代码混在一起，很难阅读和维护；

[2]. 原先的界面看起来不是很美观，感觉有点局促。所以我和负责编程的朋友王春生认真讨论后，决定重新书写 BugFree 的代码，解决已知的若干小Bug，并增加了很多新功能。王春生写了程序，同时在我们内部不断测试使用。终于我可以按计划在2004-12-15公布出来了这个全新的版本 0.2 版。

Ver 0.2的主要的改动有：

n         用Smarty技术把HTML和PHP代码分开，代码很清晰，易于维护

n         多语言支持，目前你可以选择英文界面。增加一个新语言也很容易，就是增加一个对应的文件包含所有的字符串而已（由此BugFree可以走出国门了J）

n         系统配置很灵活，可以根据使用情况自己定义

n         全新的界面，显示空间更大，更加大气

n         增加BugFree的简单用户管理

n         符合你自定义查询条件的Bug改动时，会自动给你发信

n         Bug信息中增加了两个字段：操作系统、抄送。“抄送”的功能表示这个Bug有变化时，也会发送给这些人

n         增强BugFree的查询功能

n         增加Bug的多任务分派功能，新建一个Bug时可以同时指派给多个人，这对事务跟踪和数据校对类问题非常有用

n         可以添加多个附件

n         改变Severity的显示方式

n         有快捷键支持

n         用Pear中标准的树状列表TreeMenu

n         使用ADO访问数据库

目前这个0.2版的代码质量和用户界面都有了很大改进，但其中的Bug管理思想和0.1版相比没有任何变化，只不过代码更清晰、界面更漂亮、使用起来更方便了。

　

                  —发表在《程序员》杂志2005年第3期46~49页的原文—

孟岩：刘振飞，你好。在这个系列的前面两篇文章里，我们先是探讨了Bug管理的理念和意义，然后又从软件系统的构建角度更进一步探讨了Bug管理技术层面的问题。这次我想我们应该来探讨Bug管理中“人”的问题了。当然，所谓人的问题，就是管理制度的问题。有了先进的理念、坚实的软硬件基础，还需要有相应的管理制度与之相配套，否则Bug管理就只是一个摆设。你认为一个软件开发团队应当制定严格的Bug管理制度吗？没有一个相配套的管理制度，会有怎样的后果？ 

刘振飞：我们在第一篇文章中讨论过，微软的软件研发可以总结为以下两点：

（1）．需求（PM）、开发（Dev）、测试（Test）三权分立，分工明确、各司其职

（2）．每个产品的每个版本遵循同样的模式：流程＋工具＋人，并不断反馈（以改进流程、升级工具并提高团队/员工的能力）

       回到你这个问题，Bug管理制度其实就是定义Bug处理流程，有了好用的工具之后，我们需要这样的流程去明确指导如何对Bug进行管理。但是一个软件开发团队应当制定严格的Bug管理制度吗？坦率的讲，不需要。严格的制度在软件行业就意味着教条、负担和不切实际，让一帮聪明的大脑陷入无边无际的条条框框不能自拔，明知道是包袱还要去背、是火坑还要去跳，直到有一天终于受不了，最终结果不外乎三个：过劳累到、对付一天是一天或者干脆辞职换个工作。因此我觉得应该用“Bug管理指导原则（guidance）”来替换“Bug管理规章制度（rules & regulations）”这个词。

所以我认为Bug管理就是去制定适合自己团队实际情况的Bug处理流程和指导原则，制定者（管理层）应该起到真正指导的作用，他们要非常清楚下面这些问题的答案：

l         我们需要测试什么：哪些软件（网站）、哪些模块

l         测试人员的分工：什么人负责什么模块

l         测试工具和环境：巧妇难为无米之炊。你不能安排一个测试人员去测某个模块，而没有给他提供必要的软硬件环境

l         测试的进度安排：干这一行加班是不可避免的，但是需要有度，人不是机器，长期的劳累谁都扛不住。如果时间很紧，那只能去抓重点，要有所不为

l         发现一个问题时，如何用Bug管理工具去创建一个Bug：标题如何写、严重程度、详细重现步骤、错误状况、期望结果、现场附件、这个Bug去分配给谁

l         当一个Bug被处理掉时，测试人员应该如何验证并关闭

l         当一个Bug的解决方法有争议时，谁来仲裁

l         定期的Bug提醒，比如当前每个人的Bug情况

l         Bug状态报告：Bug数目的变化趋势及我们应该采取的行动

l         阶段性的总结反馈：哪些地方我们做的好，哪些做的不好，为什么、如何改进

l         … …

    没有这样配套的Bug处理流程和指导原则，再好的工具都将会是一个摆设、甚至是添乱的工具。就像一个乐队有非常出色的各种乐器，但乐队指挥是个外行（就像成龙电影《双龙会》一个镜头），那么演奏出来的一定会是混乱的乐章。 

孟岩：根据你的了解，国内中小型软件开发企业中Bug管理制度方面有什么缺陷？主要的问题是什么？

刘振飞：我想目前中小软件企业的Bug管理主要存在的问题是：

1.     不重视测试，认为测试人员无关大局，随便测测就行了。当然这种情况正在逐步好转，因为大家都开始意识到了测试重要性；

2.     有些企业，认识到测试的重要性后，却走向极端 --- 制定了极其严格的规章制度：无数琐碎、难用的测试工单、非常严密的一级级权力控制，在Bug管理系统中谁能看到什么信息、谁可以解决、谁可以关闭等等，非常严格。一个需要灵活变化的工作变成了工业制造车间流水线的一个工种，让测试人员陷入制度的泥潭，不能把主要精力投入测试工作本身；

3.     管理层自身没有制订明确的Bug处理流程及相关指导原则，让测试人员在黑暗中摸索，走到哪儿算哪儿，不能给他们以切实有效的指导和帮助；

4.     管理层把软件的质量保证责任一股脑推到测试人员身上，任何问题都去指责下面的测试人员，殊不知测试仅仅是研发的一个环节，前面需求、开发两个环节如果没有好好做，测试将会极其被动，比如：没有需求文档，怎么测试？这是一个系统工程；

5.     错误的考核标准：管理层用Bug个数去衡量测试人员的工作成绩，谁发现的Bug多谁的工作就做的好。这是一个十分危险的倾向，将直接导致测试人员去重视Bug个数这个数字本身、而不是产品的真正质量。

遗憾的是，即使在微软内部，各个地方研发中心也有这个倾向，比如经常出现大陆、台湾、韩国、日本四个地方某个软件的测试人员虎视眈眈的在半夜盯着某个版本的问世，一旦下载到最新的Build，马上安装测试，把表面上的Bug赶快“抢”到、记录进Raid/Product Studio中，然后心满意足的打车回去，很高兴比另外三个对手多上了几个Bug。我记得微软内部有个专门的培训曾认真的研讨过这个问题：不能用Bug数目来衡量Tester的工作。但是微软太大了，当某地方或部门不能找到更合适的标准的时候，Bug数目本身就是最快捷的答案了。

这是我现在经常思考的问题之一。 

孟岩：能否请你比较系统地阐述一下微软的Bug管理制度？ 

刘振飞：其实前两篇文章已经陆续谈过微软的Bug管理指导原则了，这里系统的总结一下：

u       管理层要求所有的Bug都要通过Raid（Product Studio）来跟踪处理。这个看起来很简单的Bug管理工具是每个员工和其他同事有效协作的重要保证

u       每个产品都细分模块（Area，SubArea），每个模块都有明确的需求定义者（PM）、开发工程师（Dev）和测试工程师（Tester）这三个角色。一个问题出现了，一定会落实到某个人的头上去跟踪处理，绝不能出现“无主”的Bug

u       PM负责书写的Spec是这个功能特征（Feature）的“合同”，以此Spec来指导开发和测试。当Dev和Tester就某个Bug发生争执的时候，PM负责给出一个明确的说明

u       测试不仅仅是Tester的事情，尽管那是他们的专职工作。研发团队中的所有人每发现产品的问题时候，都有义务把这个问题告知负责这个模块的测试人员去记录跟踪这个Bug，或者干脆自己新建一个Bug来跟踪

u       你可以创建一个Bug指派给自己，以跟踪某件事的处理。比如开发人员把源代码中的某处问题用Bug记录下来，以后抽出时间来进行处理

u       团队中的所有人都可以创建、指派和更改Bug的状态

u       当你创建一个Bug的时候，描述一定要足够详细，让下面处理Bug的人和其他关心这个Bug的同事能够通过Bug描述准确的重现这个问题，而不是猜测某些步骤或者跑过来当面问你

u       通常一个Bug的处理过程是这样的：

1.    Tester发现一个问题，到Raid中创建一个Bug，描述这个Bug的详细信息，比如重现步骤（Repro Step）、错误结果（Result）、期望的改动（Expect）、运行版本等；然后把这个Bug指派给负责该模块的Dev Lead

2.     Dev Lead判断后把这个Bug指派给某个特定的Dev

3.     Dev处理掉这个Bug并返还给原Tester，或者请求PM给出一个澄清说明

u       管理层通过Raid来跟踪整体进度，以及每个员工、团队在其中的贡献

u       有专人定期给相关同事发出Bug的状态报告

u       每个人都可以方便的自助查询Bug的分布处理情况。Bug管理系统对所有的团队成员都是毫无保留的敞开大门（除了你不能删除Bug，另外所有的操作都被忠实的纪录下来）

u       随着时间的推移，管理层要逐步给出明确的Bug解决指导方针：哪些Bug是可以不理睬的（Won’t Fix），哪些是可以推迟到下个版本处理（Postponed）。比如在最终Build到来前的几周，也许非常严重的Bug，像数据丢失、程序崩溃之类的也都要推迟到下个版本再解决了。

u       当一线员工出现争执、无法达成一致意见的时候（尽管这种情况不多见），管理层要快速给出处理意见等等。

孟岩：在微软，如果违反了这些制度，会有什么后果？ 

刘振飞：哈，这个问题有意思。我还真没有仔细考虑过，如果一个研发人员在微软违反了这些“Bug管理制度”，会有什么结果？他一定不会因此被开除J，不过他肯定会努力学习和适应这些Bug处理原则，他的直接上司也会指导他如何做才是正确的。

    让我们换个角度去考虑这个问题。Bug管理是研发管理的有机组成部分，而研发管理是微软企业管理极其重要的部分，只有好的企业管理才能把业务做好，业务做好了，公司就有好的利润，这样公司发展了员工也跟着赚钱了。微软可以很奢侈的在众多求职者中招聘到合适的员工，这个员工进来后不可能对微软近30年研发总结出来的“Bug管理制度”发生抵触情绪、甚至有意去违反破坏这些处理原则，他所能够做的只能是快速去体会、理解、适应这些流程和指导原则。

    我曾听到这样一个故事：国内某大型软件企业研发老总访问微软，询问如何进行研发管理，微软一位研发高层答曰：很简单啊，定期看看Email发来的Bug报告和曲线图，然后通过Email告诉各软件负责人，下一步应该注意哪些问题就可以了。我们国企老总很愕然，百思不得其解。如果没有相关的软件研发流程和指导原则、配套工具以及熟悉这些的员工，管理层无论如何达不到这样的“轻松自在”--- 用Email进行研发管理。

    有时候想，我们需要“拿来主义”。与其羡慕Bill Gates的钱袋、痛骂微软帝国的“霸权”，还不如好好研究学习人家的研发管理和企业管理：如何把几万个聪明的脑壳有效的管理起来？如何让分布全球的几千名研发人员每隔上18个月生产出新版本的Office和Windows？为什么我们上百人、几十人甚至几个人的软件企业就管理不好？ 

孟岩：在整个Bug管理的系统中，测试人员是非常关键的一个角色。以前测试人员在团队里的形象好像是灰色的，这两年各公司都开始重视测试工作和专业测试人员的培养。你觉得测试人员在Bug管理体系中处在一个怎样的位置上？测试人员与开发人员之间的关系如何？ 

刘振飞：测试人员在整个软件研发管理体系中都是一个十分重要的、无法替换与省略的角色。经过多年产品研发的体会，我现在无法想象一个软件企业没有或者不重视测试和测试人员。就像没有经过质检人员检验过的流水线生产出来的电视机，能出厂吗？会有人买吗？

    测试人员和开发人员是对立统一的关系。说对立，是因为测试人员需要专门挑出开发人员做出来的功能模块的毛病、发现其考虑不周的地方；说统一，这两个角色需要努力协同工作，把负责的模块做好。只有每一个模块问题减少了，整个产品才能提高质量；好质量才有好价钱；公司赚到钱了大家才能有好收入。所以开发和测试是同一战壕里的战友，只有共同努力才行。 

孟岩：现在很多开发工程方法提倡“全员测试”，很有点类似日本企业里流行的“全员质量管理”。特别是单元测试已经将功能性测试变成开发人员的一项职责，这是否与Bug管理体系有冲突？全员测试是否会导致责任的不清晰？你觉得单元测试与Bug管理是否矛盾？能否协同工作？ 

刘振飞：一点也不矛盾。开发人员把一个功能模块送去测试的时候，应该已经把最基本、最常用的功能逻辑测试通过，否则测试人员发现这些基本问题后，很快还得退回去给开发人员，这样双方都费时费神。

    我所理解的“全员测试”就是每个人当发现问题的时候，不能说“这是测试/研发人员的事情”而置之不理，而应该把这个问题记录到Bug管理工具中，或者告诉相关的测试人员去跟踪。产品是公司的产品，是大家共同的饭碗。当然测试人员的专职工作就是去分模块测试，而且测试得有计划、有条理、有总结归纳；别的同事可能不是那么系统化而已。

    在Office 2003（Office 11）发布后启动的下一版Office 12研发伊始，微软Office组的管理层就根据大家的反馈，启动了一项叫做“Engineering Excellence”的活动，全面总结上一版研发流程中经验教训，提出了十多条大的、具体的过程改进办法全面执行，其中有一条叫做“Feature Crews”，就是加强测试：在把源代码check in到代码库之前，就开始测试一个功能特征（Feature）。该Feature对应的PM、Dev、Tester紧密合作在本地Build上，当一个Feature进入总产品代码库的时候应该经过认真测试、非常稳定可靠，就是说把测试工作大大往前（开发阶段）提了。当然Office组有专人立即设计、开发相关的支撑工具去保证“Feature Crews”这个新方法能够顺利执行。当我第一次看到这份“Engineering Excellence”活动说明时，真是佩服得五体投地！！很多像这样具有优秀管理、执行能力的各个小组织，组成了微软公司优秀的大团队。  

孟岩：这样吧，假设你领到一个团队进行软件开发，以BugFree为基础进行Bug管理，能否简单地介绍一下你打算制定怎样的Bug管理协作制度？比如，有哪几个角色，角色之间如何协作，那些规定需要作为硬性要求保证执行，如何保证等等。 

刘振飞：我现在还真是正在带领着一个团队去这么干（北京金环天朗通信技术发展有限公司 http://www.newsky.cn/）。我所计划的Bug管理指导原则是：

ü         产品（WAP、彩e或彩信杂志、网站等）中碰到的所有问题都要用BugFree来跟踪处理

ü         有一个专职的测试小组

ü         团队中每个同事发现一个问题时，都有义务去告知相关的人员或者直接创建一个Bug

ü         需求、开发、测试三个角色的定位要非常明确。特别的，提出需求的人要把需求认真考虑好、细化成文档，然后才能提交正式开发、测试

ü         发现一个Bug时，测试人员提交给某个开发小组长，他来负责指派给具体的开发人员；产生争议的时候由需求定义者来出面说明；“矛盾”很大时我来协调和仲裁。Bug的处理过程都要用BugFree记录下来：

ü         每天系统自动通知头上有Bug的人自己还有几个问题。我会检查这些Bug，看到不合适的地方就去添加我的意见

ü         每周系统自动通知所有人前一阶段Bug的整体情况；同时测试小组要汇总上周的Bug测试情况，告诉团队中所有同事哪些模块容易出问题、主要有哪些类型的问题

上面这些我能够作为“硬性要求”的，只能是前两条：

Ø         任何人再向开发人员反映问题的时候，开发人员会告诉他们：创建一个Bug来跟踪

Ø         刚刚成了一个测试小组

    其余的只能融化在日常工作中，管理层不断在很多细节上要求、甚至亲自示范（比如我会使用不同的产品，发现问题上Bug），去教会大家测什么、如何测、发现问题怎么办、Bug解决后怎么办。

因为整个研发团队刚招聘了不少新人，由于历史的原因以前也没有重视测试工作，大家这方面的经验相对而言比较少，所以目前我最重要的工作是给大家不断灌输这些意识，手把手去教他们如何创建一个Bug、解决一个Bug时应该怎么描述、提供哪些信息等等。坦率的讲，这个过程会非常辛苦劳累。去年我在的公司比较小，一切我都可以从零开始设计规划。但现在不同，因为公司业务有很多、人员也有了一定规模、以前的程序有很多，而且基于这个行业自身的特点，新的需求很多、变化非常频繁，所以在这种情况下如何把研发流程理顺、Bug管理到位，对我也是很大的挑战。我会根据对业务的深入理解去不断调整、细化上面提到这些“制度”。 

孟岩：BugFree在设计上为此作了什么特别的考虑？ 

刘振飞：我想主要有这么几点：

（1）     BugFree是基于Web的Bug管理系统，我们研发人员很容易上手使用、简单方便

（2）     一个Bug从创建到关闭这个“生命周期”的处理过程，BugFree 全面借鉴微软内部工具Raid的处理流程，处理方法甚至一些词汇都和Raid一样，代表着“先进的生产力”J

（3）     当一个Bug被指派给你的时候，系统会自动给你发一封邮件，提示有个Bug需要你处理，这样结合 Email，不断提醒研发队伍Bug的存在和进展。我们还增加了两个Bug统计功能：一是每天定时（比如早上8点钟）每个同事都会收到一封Email，告诉他/她头上还有多少 Bug等待处理；二是每周一中午给所有人发一封邮件，告知上周Bug的处理情况和到目前为止所有Bug的统计数据

（4）     很方便的去自定义查询条件，以后轻轻点击一个按钮随时查看你关心的Bug

（5）    BugFree是用开源的PHP+MySQL写成的，规模很小、代码也很规范，所以需要的时候很容易定制或扩充功能。

孟岩：非常感谢你，刘振飞。我们通过这三期访谈，已经较全面地谈到了Bug管理的方方面面。从前两次的反应来看，很多读者都对这个话题非常感兴趣，你能否用三句话总结一下你的主要观点？ 

刘振飞：

1．  测试是软件产品研发的重要一环，需要IT企业的高度重视，就像重视开发一样。

2．  选择一个得心应手的Bug管理工具，比如使用最接近微软内部Bug管理系统的开源软件BugFree ，是免费的！J

3．  明确Bug管理的流程和指导原则，并把这些意识逐步灌输到每个研发人员头脑中；同时根据企业的具体情况不断去完善测试流程和方法。 

也真诚感谢你做这次访谈，通过这么多有启发性、很有条理的问题，我算是有机会把这么多年的软件研发经验、特别是Bug管理的体会系统的总结一下，给自己留下一份很有意义的记录。同时借这个机会，也感谢给我Email探讨Bug管理实践以及BugFree系统的读者朋友表示感谢，如果这三篇访谈能对大家的实际测试管理工作有所帮助、BugFree能够被真正使用起来，那我就非常自豪和快乐了。

另外，我也会根据自己的使用经验和网友们的反馈，逐步完善BugFree，让它成为一个长期的、有生命力的开源项目。 

孟岩：最后一个题外话。我知道你现在从事研发管理工作，招聘过不少技术人员，对那些未走出校门的大学生和刚刚踏入社会的大学生们，有什么意见和建议？ 

刘振飞：春节后我刚刚完成我们部门今年的第一轮招聘，一共收到了1000多封简历、面谈过近100人，最后录取了9名新同事。去年也曾招聘过一些新人；一方面是很多大学生工作不好找、另一方面是很多企业招到一个合适的人也很费劲。在招聘过程中，真是什么情况都碰到过。

作为一名有几年工作经验的老毕业生，我想对年轻的学弟学妹们提几点建议以共勉：

1.     争取做一个善良的人、多站在别人的角度上去考虑问题。

2.     要树立为自己努力工作的心态，你不仅仅是为老板打工。如果对工作不满，赶快换一个，千万不要耗着；我们比上一代人幸运、可以有更多的选择工作机会，所以不要浪费自己的青春年华。

3.     珍惜在学校读书的四年宝贵时光，打好专业基础（比如计算机专业的起码应该把离散数学、数据结构认真搞明白）、提高基本素质（比如诚信、沟通表达及团队协作能力）。

4.     如果你想朝技术方面发展，多去钻研钻研那些优秀的开源软件，学习别人的智慧；

5.     摆脱那种非常纯的技术情结，要逐步明白在市场经济的企业中，业务、管理最重要，技术是一种“后勤支持”，没有我们想象的那么重要。

6.     不断学习来提高综合素质。技术之外的书籍：哲学、历史、经济、文学等都需要好好读一读。古人云，“世事练达即文章，处处留心皆学问”。比如我看电影和话剧的时候，觉得这两样和软件研发非常相似，剧本就是需求、演员就是开发人员、彩排类似测试，导演呢就像一个项目经理，一个票房很高的电影就像很受欢迎的软件产品一样。

7.     身体是革命的本钱。毛主席他老人家的这句话千真万确，健康的身体是扛住工作和生活压力的重要保证。

8.     想办法去慢慢培养自己金钱和管理意识，碰到合适的机会也可以尝试自己创业，即使失败了也可以学到很多书本之外的知识。难道陈天桥生下来就注定要当中国大富豪吗？王侯将相，宁有种乎？