（研发管理）微软研发方法
微软研发方法(上)
团队=软件
------------------------------------------------------------------------
一个伟大的软件后面都有一个伟大的故事，一个伟大的软件后面也有一个伟大的方法。
—题记
当 Windows2000经过胎死腹中的危机，终于如凤凰涅般再生时，微软决定给整个产品组成员拍摄一张合影，
以纪念这个历史时刻的诞生。到了拍摄那一天，微软人发现，他们只有把摄像师安排在飞机上才能干好这件
事儿——因为 Windows2000产品组整整有 5000人！
“团队=软件”，微软软件开发管理理论的基础可以这样一个恒等式来表达，软件可以忠实地展现创造它的
团队的一切优点和缺点。软件业中没有两个完全相同的失败，但最常见的莫过于新版本跟不上对手的脚步，
微软开发模式的精髓之一，便是通过产品组团队中每个成员对职责的承诺来控制产品的开发过程，保证新产
品准时地、经常地被推出。
这正是软件业最大的金科玉律！
开发周期四阶段
微软的产品开发遵循一个完整的开发周期，这个产品开发周期被分为四个阶段：规划阶段、开发阶段、测试
阶段（也叫稳定化阶段）和产品发送/出品阶段（参见图 1）。
微软中国研发中心中文技术部经理李东女士告诉记者，在产品的规划阶段要做三件事：拟定基于客户数据的
目标描述、基于目标描述的规格/特性说明和基于规格说明和特性优先级制定的进度表。规划阶段中最重要
的事情是让整个产品组的成员对共同的目标形成共同的认同。一座伟大建筑的诞生往往只缘于一位伟大建筑
师的不朽贡献，但一个伟大软件的设计却需要成百上千人的智力创造。
第二个阶段是开发阶段，这个阶段也叫主要里程碑阶段。微软的任何一个产品组在这个阶段都将根据特性将
项目划分成若干个子项目，每一个子项目的完成就对应于一个里程碑。在李东的经验中，一般微软中国研发
中心会在这个阶段把产品划分成 2～3个里程碑。Milestone1（第一个里程碑，简写为 M1）内要完成的是核
心的特性和功能，或今后需被共享的部件。那些将对产品稳定性形成很大影响的功能，也应该被放到
Milestone1。Milestone2可以放比 milestone1次要一些、但也是比较重要的特性和功能。Milestone3放的
特性和功能对核心特性和功能的依赖性不大，有的甚至可能根据市场的变化重新评估和取舍。总体来说，应
根据特性和功能在结构上的重要性来决定它应当被放在 M1、M2或 M3来做。
在每一个子项目（里程碑）内，进度表应当具体到每一个开发人员，而且进度表中应当加入缓冲时间。在子
项目的执行过程中，程序经理（其角色下面详述）负责协调开发过程并更新规格说明，在开发人员编码、优
化和调试的同时，测试人员进行 Bug测试及报告，直到特性稳定化之后，里程碑才达到。开发阶段有一个微
软所有的产品组都会用到的重要里程碑：代码完成（CC：CodeComplete）。达到这个里程碑，意味着所有特
性的编码任务全部完成，特性的集成测试通过后，除解决 Bug以外，不再有新的代码进来。代码完成是明显
的界线，标志着产品可以交付测试。至此开发周期进入第三个阶段。
第三个阶段是稳定化阶段，也叫测试阶段，或叫 QA阶段。测试人员对软件做各种各样的测试，其中开发和
测试工作是始终并存进行的：测试人员发现 Bug，开发人员解 Bug，测试人员再检测这个 Bug是不是解了。
如果你是一个程序经理，这个时候去看记录 Bug的数据库，会发现一大堆 Bug急剧涌现，随着一个个 Bug被
解，Bug量逐渐递减。当 Bug量控制到某一个特定范围内就可以发 Beta版，进行外部测试。这个时期程序
经理要跟踪监督用户的反馈，开发人员及时解决用户发现的 Bug。Beta测试结束之后，再经过一段时间的测
试，就会达到零错误版本（ZBR）里程碑，零错误版本里程碑的达到，并不意味着没有 Bug或遗漏的功能，
而是标志着团队的成品达到了事先规划的品质水平，可以向发布候选（RC）里程碑进军了。值得注意的是，
作为 RC的产品，应包含出品之前所必须具备的全部文档资料。发布候选（RC）可能会经历 RC0、RC1、RC2
等（最佳情况是 RC0测试之后没有一点问题，那是最后要发布的那个产品了），但如 RC0以后又发现了
Bug，并且大家认为这个 Bug必须要解，就又出来 RC1，Windows2000就是经过 RC3之后才进入产品发送/出
品阶段的。
产品有了稳定的版本就进入最后的阶段——产品发送/出品阶段。对于研发队伍来讲，十月怀胎、孩子终于
出世的那一天就是发送投产（RTM——ReleaseToManufacture）。RTM之后到用户真正拿到这个软件产品之
前还要经过我们耳熟能详的产品发布会（LaunchEvent），当然，这部分工作已经被微软的研发机构移交给
市场和销售机构，由产品经理完成相应的产品宣传策划，把产品推向市场。
微软经典团队角色
微软的产品组典型的人员角色有几类（参见图 2）。一类是产品规划（ProductPlanner）和产品管理
（ProductManagement）。产品规划的使命是通过研究，向产品组提供诸如用户需求、市场导向、竞争对手
和产品方向的分析，确保产品满足客户的需要；产品管理的使命是确定获利市场，同客户沟通产品的价值。
这两个角色相当于对产品的规划以及产品的销售。一类是程序经理（或叫程序管理：ProgramManagement），
他负责整个产品开发过程的协调，是微软各产品组中非常重要的一个角色。
开发人员（Development）、测试人员（Testing）、可用性测试员（UsabilityTesting）之类，在微软也是
一些比较特殊的角色。此外还有：Beta测试人员（Betas），如果这个产品需要汉化的话；本地化项目管理
（LocalizationProjectManager）；用户教育（UserEducation）；最后是售后支持（ProductSupport）,等
等。
尽管微软的产品组角色定位非常清晰，但这些产品组多为横向组织，由多个部门的成员组成。比如产品管理
属于微软的销售机构，而售后支持属于售后服务机构等等。微软不同机构和部门之间的协作性极强，这是保
证微软按时完成高质量产品的重要原因之一。
在微软的产品开发周期中，每一个角色在不同的阶段有不同的侧重。在规划阶段，作用比较大的是产品规划
和程序经理。开发阶段显然是开发人员的作用比较大，测试人员则在第三个阶段“QA阶段”很重要，但是
程序经理在这两个阶段的作用都很重要。
产品规划人员对产品影响最大的作用体现在规划阶段。这个阶段的产品规划需做用户问卷调查，用各种各样
的研究手段来试图了解用户的需求，并创建目标描述。这个阶段产品管理也收集用户需求，但他主要调查的
是市场走向，他关心的是如何与客户沟通产品的价值。产品规划在整个产品开发周期中总是充当一个用户代
言人的角色。产品管理在第一阶段和最后阶段发挥作用，产品管理必须设法了解新产品的获利市场所在，并
且很好地同客户沟通产品的价值。
相比于产品规划和产品管理，程序经理与程序经理之后的角色与产品具体开发过程更直接相关。
特殊角色——程序经理
在微软的产品组中，程序经理的角色很特殊，他是惟一在产品开发周期的前三个阶段都显得非常重要的角色。
程序经理在规划阶段要贯彻和推进目标描述，书写功能/特性规格说明，创建主要的进度表。规格说明是基
于产品规划所产生的目标描述来具体定义特性的实现步骤，目标描述文档是基于大量用户的调查报告和各种
研究方法得出的用户的需求，定位产品的目标。但这只是给出了一个大方向，程序经理必须把这个大方向细
化成若干个具体的特性，这些特性不仅要满足目标功能的要求，而且又必须是程序开发人员能够理解的语言。
比如 Word某一版要支持 HTML，产品规划只定目标，但程序经理就要把这个目标细化成几个具体的特性。
在第二个阶段，程序经理要管理整个开发工作的进度，检查开发人员的实现是否与规格说明相吻合，而且要
使团队目标集中、齐心协力。如果在开发过程中有什么特性的变化，或者某些功能在设计时很好但在实际开
发中出现问题，程序经理便要负责其更新规格说明，还要与产品规划、测试人员沟通项目的进展状态，协调
开发过程中出现的问题。代码完成里程碑达到之后即开始大规模的测试，程序经理那时的作用就更大了，他
要制定和控制每个 Bug的优先级，做取舍决定，发送 Beta版并收集用户反馈，确保产品按时达到发送候选
（RC）。
一句话，程序经理的中心任务是保证软件高质量并按时出品。由于总是要在品质与进度上找到平衡点，程序
经理必须精于“引导、驱策、鼓励、要求”团队做出最好的软件和表现出最好的工作效能。
在微软不同的团队里，程序经理所做的事情也有一定的差别。有偏技术性的设计功能的程序经理，他们是团
队中的关键人物；有一种程序经理被叫做 ReleaseProgramManager，他的主要任务是控制开发流程;还有的
程序经理会做一些客户需求调查的工作，定位产品方向。无论如何，程序经理的基本素质首先是要有很好的
沟通技巧，具有设身处地为他人着想的本领；其次考虑问题周全，能处理复杂的情况；此外，程序经理要对
开发产品所使用的技术很熟悉，对用户需求的理解力也要非常好。比如在具体的开发过程中，测试人员发现
Bug越多越好，但开发人员却希望 Bug越少越好，程序经理要善于协调二者的矛盾；在产品的开发过程中通
常会出现人员突然流动的现象，或者硬件环境出了问题，或者外边竞争对手出现变化，程序经理对这些要反
应非常机敏，有能力做出对公司、产品和客户影响最小的果断的取舍和决定。
微 软 的 开 发 人 员 无 疑 是 每 一 个 产 品 组 中 非 常 重 要 的 角 色 。 一 个 头 衔 是 软 件 设 计 工 程 师
（SDE——SoftDesignEngineer）的开发人员的级别有可能比某一个经理要高很多。在微软，开发人员根据
他本身知识和能力的不同分为不同的级别，顶级的开发人员负责整个软件的结构设计，中间有负责某一功能
类的结构设计师，最底层的开发人员只完成规定的模块实现。好的结构设计对产品的稳定性、可扩充性非常
重要，特别是对一个由多人参与的项目而言更是如此。在产品组中，最厉害的开发人员是整个产品结构的设
计师。应该说，微软每一个产品中都有几个核心开发人员来控制整个产品的结构，其他开发人员则在他的领
导之下共同完成开发工作。
可用性测试的重要
所有用过微软产品的人会有一种感觉，微软产品非常易用。如何使产品做到易用？微软的办法是通过重视可
用性测试（UsabilityTesting）来实现。可用性测试的使命是通过在产品开发周期的各个阶段加入客户资料
和信息来使产品更有用、适用和易用。
在产品开发周期的第一个阶段可用性测试就要展开工作，比如，微软中国研发中心的产品组会把产品的新特
性做一个模拟的模型，找用户来试用，产品组的可用性测试人员便会在试用过程中准备录音机、摄像头，把
用户的行为摄下来，说的话录下来，按的键记录下来，研究他们对产品的反应，以便把产品设计调整到足够
好。
微软中国研发中心中文处理组有一个产品“微软拼音输入法”，其最早的帮助功能是用鼠标右键击活菜单，
这是 Windows常用的菜单风格，但是通过前期的可用性测试，李东他们发现中国用户习惯了用鼠标左键，很
少用右键，这样用户很难找到微软拼音的帮助功能。后来微软中国研发中心把“帮助”放在显示特别明显的
地方——输入法状态条上，这样，按左键就能使用帮助功能。“用户的需求可能跟你想的不一样，这就要真
正倾听用户的呼声，让用户来试用，看用户的反应，来决定修改你的产品”，李东告诉记者，微软中国研发
中心这样的例子很多。
在第二个开发阶段，当开发人员达到 M1，能看到产品的最重要的特性时，可用性测试人员要随时反馈设计
好不好，如果要有个别的改动，则在 M2中将 M1的某些功能改动加进来。可用性测试人员要理解用户的工作
领域、行为和心理，微软公司总部有很多做可用性测试的人员是心理学方面的专家。用户的感受只有通过可
用性测试人员分析、理解成对功能的描述，或者对功能的反馈，才能使产品开发人员能够理解并改进。
里程碑式的开发模式的好处
综观微软对软件开发周期过程的管理，其精髓的做法一是将大项目划分成若干个子项目的里程碑式的开发模
式；其次，通过对产品组各人员角色对职责的承诺来控制产品的开发过程，以保证产品的进度和质量。
不管是小软件还是大软件，里程碑的概念在微软所有的软件开发中都会被用到。这也是微软在软件开发上摸
索多年凝聚所得。国内软件企业的开发大多是从有一个想法就开始做，不分什么阶段，但往往因为软件功能
太多，不同的人负责不同模块，到产品的最后阶段再去集成和测试，大量原来没有预计到的问题都“冒”了
出来，这时再去“动”各个部分，时间肯定要推迟。这种模式将导致两个问题:一是质量无法控制，二是时
间无法控制。
李东认为，在微软里程碑式的开发模式下，做同样大的产品，因为按子项目来划分里程碑，每一个子项目都
经过一定的稳定化阶段，再进入到第二个子项目的时候，就是基于一个相对稳定的一部分子项目基础之上的
行为，这样就将风险或错误的累加分散和降低。以局部的质量控制来保证整体产品的进一步稳定，能使得质
量和进度得以很好的控制。而且，把一个大的项目分散到不同的阶段来完成，可以灵活地去增加或减少一些
功能，否则，把增加或减少功能集中到最后集成阶段，而且是在不稳定的环境下来做，困难可想而知。这就
是里程碑式的开发模式优秀之处所在。虽然里程碑的做法在成本上比较高——为了协调出大家对里程碑一
致的价值观，为了协调出里程碑的衡量准则，如此等等，团队必须付出大量时间和精力，承受比较大的痛苦，
但这是惟一能够确保开发成功的方式。
国内软件企业的开发模式多为“大拿领衔制”，通常公司十多个技术人员中间有一个技术“大拿”，剩下人
辅助他，把这个产品的所有代码写完，则软件就算完成了。“大拿领衔制”脱不去小作坊的味道，虽然保证
了“技术大拿”的创造性，却失去了软件研发过程应有的规范。
软 件 企 业 的 创 造 性 和 制 度 要 相 辅 相 成 。 在 微 软 的 所 有 里 程 碑 中 ， “代 码 完 成 ”里 程 碑
（codecompletemilestone），是一个重要的分界线。在代码完成之前，产品组自由发挥创造力，最需要大
量的交互和碰撞。代码完成之后，则需严格按照里程碑完成进度。进入测试阶段，微软通常把里程碑分得更
细致，比如 Beta、零错误版本、发布候选、RTM等等。每个里程碑都不是简单的摆设，而是有严格的规定，
快到里程碑的时候开发人员不能做没到里程碑时的修改，“原来一个 Bug怎么改都可以，但到里程碑附近的
时候，就要求只能改动最重要的 Bug”，微软中国研发中心副总经理徐汕开发 Windows2000时曾与副总裁吵
过架，“我们觉得中文版需要这项功能，但当时已经太晚了，大家争吵了很长时间，最后还是不能改。”为
保证软件按进度完成，靠近里程碑时需要“收敛”，而收敛惟一的方法就是少做事情。过了一个里程碑，产
品比以前的质量就要好许多。通过一个一个里程碑来收敛，这个项目不会偏离目标很远。从代码完成到 RTM
是微软软件开发周期中非常重要的过程，这个时候已经完成充分发挥智力的时期，而规范成为更重要的要素。
（注：本文只给出了微软团队工作方式的常规模式，具体的实践模式可参考微软 VisualC++事业部总监吉
姆·麦卡锡所著书《微软团队成功秘诀》。）
微软研发方法(下)Bug“指挥棒”
想真正保证软件项目如期完成，不仅取决于开发人员，更取决于测试人员。
———题记
项目经理经常犯的错误之一，是以为只要雇用软件工程师就行，其他的人都不必要，或是让软件工程师占整
个团队很高的比例。他们也许认为开发人员越多，写出来的程序也越多，这是错误的概念。项目的目的是为
了完成软件，而不是完成更多的程序代码。在开发团队中，实际有一些工作是不适宜交给软件工程师做的。
要想真正保证软件项目如期完成，不仅取决于开发人员，更取决于测试人员。软件开发好像是在赶进度，而
不是在演奏交响乐：交响乐是和谐有序而优雅的，而软件开发却更像是一堆排山倒海、蜂拥而至的工作。交
响乐任何两个音符都不能相互抵触，整体表现出来的才是一段优美的音乐。在一切都不确定的软件开发过程
中，让测试人员的“Bug指挥棒”来使大家知道什么时候该表现，知道什么时候该退后一点，正是微软将软
件开发过程带向高潮的不二法则！
测试组不是开发组的助手
似乎没有谁比微软更重视测试的力量。在微软的产品组中，测试组是与产品规划组、产品管理组、开发组和
用户教育组等并列的队伍。测试与软件成本的关系是，发现产品中存在的问题越早，开发费用越低，产品质
量越高，软件发布后维护费用越低。在微软开发周期的四个阶段中，测试的目的在于保证软件质量，满足设
计的要求和客户的需求；系统地揭示出不同类型的错误，并耗费最少时间和最小工作量；降低软件的开发成
本和维护成本。
软件开发过程中开发人员很可能因为一些偶发的小事，或某种无关的灵感而不知不觉中偏离了实际的需要，
暂时忘记了什么才是产品最该有的功能，把他们拉回原定轨道中的正是测试工程师。测试人员的职责是配合
整个项目组保证按照预定的时间表完成达到预定设计目标的产品。测试人员的工作是具有整体性、持续性的
软件开发活动中的一环，而不是偶尔拿出来点缀一下。软件产品的质量是由用于测试的资源、产品的功能和
项目的时间表来决定的，是三者的平衡。对任何的一个产品组来说，无论是主观，还是客观上，都要重视测
试工程师的存在，这是产品质量的重要保证。
罗马不是一天建成的。早期的微软开发队伍中也没有设立单独的测试组。那个时候的微软几百个人做几个项
目，通常是程序员写完程序了，自己测试一下就算完事。后来微软的项目越来越大，软件越来越复杂，写代
码和测试的工作要平行进行，渐渐产生了独立的测试组。一个重要的数字是，微软产品组中测试人员和开发
人员的比例大约是 1∶1。其实，要想真正保证软件项目如期完成，不仅取决于开发人员，更取决于测试人
员。
测试组独立于开发组之外的好处在于，程序员总是倾向于认为自己设计的代码足够好，独立的测试组可以使
测试人员在不带任何假设的情况下从不同的角度来测试软件，有利于保证软件的质量始终得到控制，并使测
试资源得到重用和不断改进。但是，测试组独立于开发组之外，并不意味着程序员写完代码就扔过“墙
壁”，等待测试工程师找到所有的 bug，当测试人员认为他的工作就是测试程序，而开发人员认为他的工作
就是写程序给测试人员测试时，如果你是项目经理，要小心了！开发人员的优越感会使测试人员感觉自己是
被歧视的少数民族，这势必会影响到软件的品质。程序人员在写完代码、改正问题后必须完成基本的测试，
比如代码的路径测试、单元测试和问题验证等。产品质量控制，存在于开发过程的每一个环节中。
有一个笑话，微软的测试人员工作时间长了，都有挑刺儿的习惯，下了班见了太太做的饭都要评价一番。对
微软来说，那些聪明、细致、认真，有耐心，追求完美的产品，对用户有负责任的态度，思维方式独立又开
放，既有足够的技术背景，但又愿意学习新的技术的测试工程师更容易得到“老板”的青睐。
软件测试的阶段性
软件开发的过程就像是一支队伍正在急行军，但跑着跑着这支队伍就会“散了架”，设立里程碑的作用就仿
佛是到了某一个“点”，大家必须要重新整理步伐，实现同步。就测试组的工作模式而言，测试的阶段划分
是与项目的进度相对应的。也就是说，测试人员应当与项目组的其他人员始终保持以相同的步伐“跑步”的
状态，与整个项目的每一个里程碑配合，完成相应的测试工作。
把大项目划分成若干子项目的里程碑式的开发模式是微软软件开发管理的精髓做法，如上一期《微软研发方
法（上）》所述，在微软的每一个产品开发周期中都有以下几个重要的里程碑：CC（Codecomplete:代码完
成）；Beta测试；RC（ReleaseCandidate：候选发布）；RTM（ReleaseToManufacture:投入生产），测试
人员和产品组的其他人员一起，共同达到每一个里程碑。一个完整的测试循环应当包括运行所有的测试用例、
Beta标准测试、bug校验和解所有的 bug、随机测试。好的测试循环能够保证对软件质量有一个全面完整的
评价，每个里程碑之前至少要有一个完整的测试循环。
在微软的产品开发周期中，在规划阶段当开发人员在做计划、编进度，进行功能实现的可行性研究，对计划
的功能进行反馈时，测试人员应当研究规格说明，编写测试计划；在第二个阶段即开发阶段，当开发人员在
编写代码、测试和调试的同时，测试人员应当开始设计测试用例，开发自动测试工具和程序，熟悉必需的环
境、工具、软件和硬件，不断地丰富测试用例，直到达到 CC（代码完成）里程碑——这个时候的软件可以
进行一次整体测试，用户界面可能不完美但能够工作，可能有很多明显的 bug。
进入开发周期的第三阶段，测试人员大显身手，展开大规模的测试，比如系统级整体测试，交互性和深层测
试。测试之后，测试人员应当对新增的功能说“不”，直至达到 Bate测试里程碑。达到这个里程碑，意味
着所有的 Beta致命问题已经被修正和关闭，所有计划的功能都已经在软件中并能工作，产品稳定，大部分
界面还可以，尽管可能只是一部分，但已经有了在线帮助和用户手册，即使是发布了也不会引起负面的影响。
Beta测试的目的是确定产品是否能在预计的各种硬件平台和操作系统中正常运行，虽然 Beta测试的反馈意
见很有参考价值，但除非存在重大问题，否则不应对功能集再做修改，所有建议和反馈都留在下一版中再考
虑纳入。Beta测试之后就要向 RC和 RTM进军。测试人员要着重测试 Beta后的变动。到达 RC，意味着软件
质量状态为没有活跃的 bug（Activebug）；没有悬而未决的事；已经稳定了一段时间，如一周内很少或没
有变动，或变动很小。如果 RC后的测试没有发现新的需要改的 bug，可以达到 RTM，随后查病毒，验证光盘，
检查内容。
需要注意的是，在整个阶段性的软件测试过程中，质量不仅仅是测试组的责任。一定要防止完全依赖测试组
来保证质量的做法，否则结果只能是质量差、进度延迟。采用 Zero-Defect策略的好处在于，可以同时保证
产品的质量、进度和功能集，尽早发现和修正产品中的 bug，始终把产品的状态和 bug数量控制在可以管理
的范围之内，程序员应该修正所有的优先级为一级（P1）的 bug才能写新的代码。
同时测试组应当开发一些好的测试管理工具，比如测试用例管理工具和 bug的管理工具等等。测试工程师应
当细化测试子区域，重视测试用例的数量和质量，对 bug状态的变化要反应迅速。要防止仅以 bug多少来评
价工程师的工作。
bug的发现和管理
在微软的测试人员看来，那些功能没有实现或与规格说明不一致的问题是 bug；不能工作（死机、没反应）
的部分是 bug；不兼容的部分是 bug；边界条件未做处理是 bug；界面、消息、提示不够准确是 bug；有时把
尚未完成的工作也作为一个 bug。微软把软件中常见的 bug类型归为以下几类：功能错误；用户界面错误；
边界值相关错误；初始化错误；计算错误；内存相关错误；硬件相关错误和文档错误。
测试工程师发现 bug之后所采取的措施，首先应当是去想法验证是不是自己的偶然失误造成 bug出现，如不
是则应立即建立每一个新的 bug记录，包括具体的再现步骤、环境、屏幕等；尽可能地分析产生 bug的原因；
设计合适的优先级和严重级别，要记住，测试人员的目标不是找出更多的 bug，而是改进产品的质量；依据
bug的优先级和严重级别分派给某一个相应的人，如程序员、项目经理和测试组的负责人等。
一般来说，bug在数据库中有三种状态：活跃（Active）、被解（Resolved）、关闭（Closed）。这三个状
态在微软通常用“红黄绿”三个颜色来代表。活跃状态指的是测试人员新建一个 bug时的状态，必须分派给
相应的设计人员、开发人员或者是用户教育人员，表明 bug的状态是等待纠正的。被解状态指的是设计人员、
开发人员或者用户教育人员修正 bug后的状态，必须重新分派给报告 bug的测试人员，表明 bug已经得到修
正，但等待校验。关闭状态指的是测试人员校验完成并关掉之后的状态，表明 bug已经得到修正，并完成了
校验，但如果同样的问题再次出现后，还可能重新激活成活跃状态，则又开始了另一轮的状态循环。活跃 bug
数量的变化趋势是，一般在代码完成前很少，代码完成后增长很快，接近 Beta测试时会下降，接近 RC时奔
向零。因此依据每天新建的 bug数量与修正的 bug数量相比较和处于活跃状态的 bug数量亦可判断产品质量
和里程碑的信号。
永远有缺憾是所有智力活动的特征。软件一定有数不清的缺点，问题不是在于判断这个产品好与不好，而是
决定修改哪一部分从而可以使产品比较能被用户接受或喜爱。微软把这个判断并修改的过程称为“急救
术”。在急诊室中医生必须非常迅速地察看患者面临的所有问题，采取最急迫必要的急救医疗措施，然后再
依优先级分别施救。微软产品组也一样，他们把 bug的严重性分为四个级别：导致死机；主要问题，导致严
重的问题，如某个小功能未实现；小问题，不太严重，如提示信息不太准确；微小的问题，如有个别错别字。
把 bug的优先级分为四个级别：尽快修正；每个里程碑结束前必须修正；如果时间允许就修正；低优先级。
微软有“bug法庭”，通常由程序经理召集，由项目经理、开发负责人、测试负责人组成，可根据产品的功
能区域分成具体的“bug急救小组（bugtriageteam）”，审查每一个 bug，选择和修改产品中最重要的错误，
决定相应解决方案，尽量使大部分的用户在大部分的时间内都能够使用愉快。当然，“bug法庭”开会的频
度取决于处于哪一个阶段。
测试组应当有一个区域专门放置记录所有bug的数据库。这个数据库应当是整个产品组的中央记录和控制区，
而且其中所有的记录都无法删除，对于每个记录只能一直添加内容。测试组应当有与项目组所有成员交流与
沟通的公用工具；与 bugmail配合，能根据 bug的当前状态及时通知 bug的当前责任人；有效地跟踪项目的
进展，为产品发布提供判断标准；能积累测试人员成果。
秘密武器：测试用例和测试计划
概括来看，微软测试的精髓做法是：系统可重用的测试用例；以问题（bug）发现和跟踪为核心的测试活动；
独立的测试人员；基于产品规划、产品设计规格的测试计划；与整个项目配合的基于里程碑的软件测试周期。
而基于产品规划、产品设计规格的测试计划和系统可重用的测试用例则是微软的“秘密武器”。
在微软，测试计划是帮助测试人员管理测试项目和发现 bug的重要工具，是纲领性文件。测试计划明确了项
目的测试任务、测试内容清单，这些内容不能只存在于测试人员的脑海里，而必须被项目经理、开发经理所
了解，测试计划必须增强测试任务和测试实施过程的沟通，具有指导性。测试计划还必须提供组织管理测试
项目的框架结构，帮助控制进度。
测试计划涉及的范围应当有产品概述、测试策略、测试的方法学、测试区域、测试的配置（软件环境、硬件
环境、网络环境）、测试周期（与项目的里程碑配合）、测试资源的规划、风险分析和案例等。测试计划不
是一成不变的。虽然测试计划在产品设计阶段就开始被撰写，但在后来的开发过程中会随着项目进度表的改
变而改变。
一个好的测试用例有以下几个特征：首先，是最有可能抓住错误的；其次，不是重复的、多余的；第三，一
组相似测试用例中最有效的；最后，不要太简单，也不要太复杂。因此，在测试人员设计测试用例时应当遵
循以下原则：在人员变化和新项目中能够重用；能够分类；测试的内容不重复；保存在测试用例的数据库中；
在项目进行过程中可不断增强。
设计测试用例时的一些通常考虑“点”是：根据产品规格测试基本功能；设计普通用户的使用方案；设计稀
有或特殊的使用方案；与系统其他组成部分的配合（如 FAX和上网可能都要用到调制解调器，测试中要考虑
对设备的共享）；考虑特殊情况（比如内存和硬件的冲突等）；设计极端情况（比如内存泄漏、破坏性测试
等）。
