微软研发方法

微软研发方法

------------------------------------------------------------------------一个伟大的软件后面都有一个伟大的故事，一个伟大的软件后面也有一个伟大的方法。

—题记

当Windows 2000通过胎死腹中的危机，终于如凤凰涅般再生时，微软决定给整个产品组成员拍照一张合影，以纪念那个历史时刻的产生。到了拍照那一天，微软人发觉，他们只有把摄像师安排在飞机上才能干好这件事儿——因为Windows 2000产品组整整有5000人！

“团队=软件”，微软软件开发治理理论的基础能够如此一个恒等式来表达，软件能够忠实地展现制造它的团队的一切优点和缺点。软件业中没有两个完全相同的失败，但最常见的莫过于新版本跟不上对手的脚步，微软开发模式的精髓之一，便是通过产品组团队中每个成员对职责的承诺来操纵产品的开发过程，保证新产品准时地、经常地被推出。

这正是软件业最大的金科玉律！

开发周期四时期

微软的产品开发遵循一个完整的开发周期，那个产品开发周期被分为四个时期：规划时期、开发时期、测试时期（也叫稳固化时期）和产品发送/出品时期（参见图1）。

微软中国研发中心中文技术部经理李东女士告诉记者，在产品的规划时期要做三件事：拟定基于客户数据的目标描述、基于目标描述的规格/特性说明和基于规格说明和特性优先级制定的进度表。规划时期中最重要的情况是让整个产品组的成员对共同的目标形成共同的认同。一座伟大建筑的产生往往只缘于一位伟大建筑师的不朽奉献，但一个伟大软件的设计却需要成百上千人的智力制造。

第二个时期是开发时期，那个时期也叫要紧里程碑时期。微软的任何一个产品组在那个时期都将依照特性将项目划分成若干个子项目，每一个子项目的完成就对应于一个里程碑。在李东的体会中，一样微软中国研发中心会在那个时期把产品划分成2～3个里程碑。Milestone1（第一个里程碑，简写为M1）内要完成的是核心的特性和功能，或今后需被共享的部件。那些将对产品稳固性形成专门大阻碍的功能，也应该被放到Milestone1。Milestone2能够放比milestone1次要一些、但也是比较重要的特性和功能。Milestone3放的特性和功能对核心特性和功能的依靠性不大，有的甚至可能依照市场的变化重新评估和取舍。总体来说，应依照特性和功能在结构上的重要性来决定它应当被放在M1、M2或M3来做。

在每一个子项目（里程碑）内，进度表应当具体到每一个开发人员，而且进度表中应当加入缓冲时刻。在子项目的执行过程中，程序经理（其角色下面详述）负责和谐开发过程并更新规格说明，在开发人员编码、优化和调试的同时，测试人员进行Bug测试及报告，直到特性稳固化之后，里程碑才达到。开发时期有一个微软所有的产品组都会用到的重要里程碑：代码完成（CC：Code Complete）。达到那个里程碑，意味着所有特性的编码任务全部完成，特性的集成测试通过后，除解决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，Windows 2000确实是通过RC3之后才进入产品发送/出品时期的。

产品有了稳固的版本就进入最后的时期——产品发送/出品时期。关于研发队伍来讲，十月怀胎、小孩终于出世的那一天确实是发送投产（RTM——Release To Manufacture）。RTM之后到用户真正拿到那个软件产品之前还要通过我们耳熟能详的产品公布会（Launch Event），因此，这部分工作差不多被微软的研发机构移交给市场和销售机构，由产品经理完成相应的产品宣传策划，把产品推向市场。

微软经典团队角色

微软的产品组典型的人员角色有几类（参见图2）。一类是产品规划（Product Planner）和产品治理（Product Management）。产品规划的使命是通过研究，向产品组提供诸如用户需求、市场导向、竞争对手和产品方向的分析，确保产品满足客户的需要；产品治理的使命是确定获利市场，同客户沟通产品的价值。这两个角色相当于对产品的规划以及产品的销售。一类是程序经理（或叫程序治理：Program Management），他负责整个产品开发过程的和谐，是微软各产品组中专门重要的一个角色。

开发人员（Development）、测试人员（Testing）、可用性测试员（Usability Testing）之类，在微软也是一些比较专门的角色。此外还有：Beta测试人员（Betas），假如那个产品需要汉化的话；本地化项目治理（Localization Project Manager）；用户教育（User Education）；最后是售后支持（Product Support）,等等。

尽管微软的产品组角色定位专门清晰，但这些产品组多为横向组织，由多个部门的成员组成。比如产品治理属于微软的销售机构，而售后支持属于售后服务机构等等。微软不同机构和部门之间的协作性极强，这是保证微软按时完成高质量产品的重要缘故之一。

在微软的产品开发周期中，每一个角色在不同的时期有不同的侧重。在规划时期，作用比较大的是产品规划和程序经理。开发时期明显是开发人员的作用比较大，测试人员则在第三个时期“QA时期”专门重要，然而程序经理在这两个时期的作用都专门重要。

产品规划人员对产品阻碍最大的作用表达在规划时期。那个时期的产品规划需做用户问卷调查，用各种各样的研究手段来试图了解用户的需求，并创建目标描述。那个时期产品治理也收集用户需求，但他要紧调查的是市场走向，他关怀的是如何与客户沟通产品的价值。产品规划在整个产品开发周期中总是充当一个用户代言人的角色。产品治理在第一时期和最后时期发挥作用，产品治理必须设法了解新产品的获利市场所在，同时专门好地同客户沟通产品的价值。

相比于产品规划和产品治理，程序经理与程序经理之后的角色与产品具体开发过程更直截了当相关。

专门角色——程序经理

在微软的产品组中，程序经理的角色专门专门，他是惟一在产品开发周期的前三个时期都显得专门重要的角色。

程序经理在规划时期要贯彻和推进目标描述，书写功能/特性规格说明，创建要紧的进度表。规格说明是基于产品规划所产生的目标描述来具体定义特性的实现步骤，目标描述文档是基于大量用户的调查报告和各种研究方法得出的用户的需求，定位产品的目标。但这只是给出了一个大方向，程序经理必须把那个大方向细化成若干个具体的特性，这些特性不仅要满足目标功能的要求，而且又必须是程序开发人员能够明白得的语言。比如Word某一版要支持HTML，产品规划只定目标，但程序经理就要把那个目标细化成几个具体的特性。

在第二个时期，程序经理要治理整个开发工作的进度，检查开发人员的实现是否与规格说明相吻合，而且要使团队目标集中、齐心协力。假如在开发过程中有什么特性的变化，或者某些功能在设计时专门好但在实际开发中显现问题，程序经理便要负责其更新规格说明，还要与产品规划、测试人员沟通项目的进展状态，和谐开发过程中显现的问题。代码完成里程碑达到之后即开始大规模的测试，程序经理那时的作用就更大了，他要制定和操纵每个Bug的优先级，做取舍决定，发送Beta版并收集用户反馈，确保产品按时达到发送候选（RC）。

一句话，程序经理的中心任务是保证软件高质量并按时出品。由于总是要在品质与进度上找到平稳点，程序经理必须精于“引导、驱策、鼓舞、要求”团队做出最好的软件和表现出最好的工作效能。

在微软不同的团队里，程序经理所做的情况也有一定的差别。有偏技术性的设计功能的程序经理，他们是团队中的关键人物；有一种程序经理被叫做Release Program Manager，他的要紧任务是操纵开发流程;还有的程序经理会做一些客户需求调查的工作，定位产品方向。不管如何，程序经理的差不多素养第一是要有专门好的沟通技巧，具有设身处地为他人着想的本领；其次考虑问题周全，能处理复杂的情形；此外，程序经理要对开发产品所使用的技术专门熟悉，对用户需求的明白得力也要专门好。比如在具体的开发过程中，测试人员发觉Bug越多越好，但开发人员却期望Bug越少越好，程序经理要善于和谐二者的矛盾；在产品的开发过程中通常会显现人员突然流淌的现象，或者硬件环境出了问题，或者外边竞争对手显现变化，程序经理对这些要反应专门机敏，有能力做出对公司、产品和客户阻碍最小的果断的取舍和决定。

微软的开发人员无疑是每一个产品组中专门重要的角色。一个头衔是软件设计工程师（SDE——Soft Design Engineer）的开发人员的级别有可能比某一个经理要高专门多。在微软，开发人员依照他本身知识和能力的不同分为不同的级别，顶级的开发人员负责整个软件的结构设计，中间有负责某一功能类的结构设计师，最底层的开发人员只完成规定的模块实现。好的结构设计对产品的稳固性、可扩充性专门重要，专门是对一个由多人参与的项目而言更是如此。在产品组中，最厉害的开发人员是整个产品结构的设计师。应该说，微软每一个产品中都有几个核心开发人员来操纵整个产品的结构，其他开发人员则在他的领导之下共同完成开发工作。

可用性测试的重要

所有用过微软产品的人会有一种感受，微软产品专门易用。如何使产品做到易用？微软的方法是通过重视可用性测试（Usability Testing）来实现。可用性测试的使命是通过在产品开发周期的各个时期加入客户资料和信息来使产品更有用、适用和易用。

在产品开发周期的第一个时期可用性测试就要展开工作，比如，微软中国研发中心的产品组会把产品的新特性做一个模拟的模型，找用户来试用，产品组的可用性测试人员便会在试用过程中预备录音机、摄像头，把用户的行为摄下来，说的话录下来，按的键记录下来，研究他们对产品的反应，以便把产品设计调整到足够好。

微软中国研发中心中文处理组有一个产品“微软拼音输入法”，其最早的关心功能是用鼠标右键击活菜单，这是Windows常用的菜单风格，然而通过前期的可用性测试，李东他们发觉中国用户适应了用鼠标左键，专门少用右键，如此用户专门难找到微软拼音的关心功能。后来微软中国研发中心把“关心”放在显示专门明显的地点——输入法状态条上，如此，按左键就能使用关心功能。“用户的需求可能跟你想的不一样，这就要真正倾听用户的呼声，让用户来试用，看用户的反应，来决定修改你的产品”，李东告诉记者，微软中国研发中心如此的例子专门多。

在第二个开发时期，当开发人员达到M1，能看到产品的最重要的特性时，可用性测试人员要随时反馈设计好不行，假如要有个别的改动，则在M2中将M1的某些功能改动加进来。可用性测试人员要明白得用户的工作领域、行为和心理，微软公司总部有专门多做可用性测试的人员是心理学方面的专家。用户的感受只有通过可用性测试人员分析、明白得成对功能的描述，或者对功能的反馈，才能使产品开发人员能够明白得并改进。

里程碑式的开发模式的好处

综观微软对软件开发周期过程的治理，其精髓的做法一是将大项目划分成若干个子项目的里程碑式的开发模式；其次，通过对产品组各人员角色对职责的承诺来操纵产品的开发过程，以保证产品的进度和质量。

不管是小软件依旧大软件，里程碑的概念在微软所有的软件开发中都会被用到。这也是微软在软件开发上摸索多年凝聚所得。国内软件企业的开发大多是从有一个方法就开始做，不分什么时期，但往往因为软件功能太多，不同的人负责不同模块，到产品的最后时期再去集成和测试，大量原先没有估量到的问题都“冒”了出来，这时再去“动”各个部分，时刻确信要推迟。这种模式将导致两个问题:一是质量无法操纵，二是时刻无法操纵。

李东认为，在微软里程碑式的开发模式下，做同样大的产品，因为按子项目来划分里程碑，每一个子项目都通过一定的稳固化时期，再进入到第二个子项目的时候，确实是基于一个相对稳固的一部分子项目基础之上的行为，如此就将风险或错误的累加分散和降低。以局部的质量操纵来保证整体产品的进一步稳固，能使得质量和进度得以专门好的操纵。而且，把一个大的项目分散到不同的时期来完成，能够灵活地去增加或减少一些功能，否则，把增加或减少功能集中到最后集成时期，而且是在不稳固的环境下来做，困难可想而知。这确实是里程碑式的开发模式优秀之处所在。尽管里程碑的做法在成本上比较高——为了和谐出大伙儿对里程碑一致的价值观，为了和谐出里程碑的衡量准则，如此等等，团队必须付出大量时刻和精力，承担比较大的痛楚，但这是惟一能够确保开发成功的方式。

国内软件企业的开发模式多为“大拿领衔制”，通常公司十多个技术人员中间有一个技术“大拿”，剩下人辅助他，把那个产品的所有代码写完，则软件就算完成了。“大拿领衔制”脱不去小作坊的味道，尽管保证了“技术大拿”的制造性，却失去了软件研发过程应有的规范。

软件企业的制造性和制度要相辅相成。在微软的所有里程碑中，“代码完成”里程碑（code complete milestone），是一个重要的分界线。在代码完成之前，产品组自由发挥制造力，最需要大量的交互和碰撞。代码完成之后，则需严格按照里程碑完成进度。进入测试时期，微软通常把里程碑分得更细致，比如Beta、零错误版本、公布候选、RTM等等。每个里程碑都不是简单的摆设，而是有严格的规定，快到里程碑的时候开发人员不能做没到里程碑时的修改，“原先一个Bug如何改都能够，但到里程碑邻近的时候，就要求只能改动最重要的Bug”，微软中国研发中心副总经理徐汕开发Windows 2000时曾与副总裁吵过架，“我们觉得中文版需要这项功能，但当时差不多太晚了，大伙儿争吵了专门长时刻，最后依旧不能改。”为保证软件按进度完成，靠近里程碑时需要“收敛”，而收敛惟一的方法确实是少做情况。过了一个里程碑，产品比往常的质量就要好许多。通过一个一个里程碑来收敛，那个项目可不能偏离目标专门远。从代码完成到RTM是微软软件开发周期中专门重要的过程，那个时候差不多完成充分发挥智力的时期，而规范成为更重要的要素。（注：本文只给出了微软团队工作方式的常规模式，具体的实践模式可参考微软Visual C++事业部总监吉姆·麦卡锡所著书《微软团队成功要领》。）

微软研发方法(下)Bug“指挥棒”

想真正保证软件项目如期完成，不仅取决于开发人员，更取决于测试人员。

———题记

项目经理经常犯的错误之一，是以为只要雇用软件工程师就行，其他的人都不必要，或是让软件工程师占整个团队专门高的比例。他们也许认为开发人员越多，写出来的程序也越多，这是错误的概念。项目的目的是为了完成软件，而不是完成更多的程序代码。在开发团队中，实际有一些工作是不适宜交给软件工程师做的。

要想真正保证软件项目如期完成，不仅取决于开发人员，更取决于测试人员。软件开发看起来是在赶进度，而不是在演奏交响乐：交响乐是和谐有序而文雅的，而软件开发却更像是一堆移山倒海、蜂拥而至的工作。交响乐任何两个音符都不能相互抵触，整体表现出来的才是一段优美的音乐。在一切都不确定的软件开发过程中，让测试人员的“Bug指挥棒”来使大伙儿明白什么时候该表现，明白什么时候该退后一点，正是微软将软件开发过程带向高潮的不二法则！

测试组不是开发组的助手

看起来没有谁比微软更重视测试的力量。在微软的产品组中，测试组是与产品规划组、产品治理组、开发

组和用户教育组等并列的队伍。测试与软件成本的关系是，发觉产品中存在的问题越早，开发费用越低，产品质量越高，软件公布后爱护费用越低。在微软开发周期的四个时期中，测试的目的在于保证软件质量，满足设计的要求和客户的需求；系统地揭示出不同类型的错误，并耗费最少时刻和最小工作量；降低软件的开发成本和爱护成本。

软件开发过程中开发人员专门可能因为一些偶发的小事，或某种无关的灵感而不知不觉中偏离了实际的需要，临时不记得了什么才是产品最该有的功能，把他们拉回原定轨道中的正是测试工程师。测试人员的职责是配合整个项目组保证按照预定的时刻表完成达到预定设计目标的产品。测试人员的工作是具有整体性、连续性的软件开发活动中的一环，而不是偶然拿出来点缀一下。软件产品的质量是由用于测试的资源、产品的功能和项目的时刻表来决定的，是三者的平稳。对任何的一个产品组来说，不管是主观，依旧客观上，都要重视测试工程师的存在，这是产品质量的重要保证。

罗马不是一天建成的。早期的微软开发队伍中也没有设立单独的测试组。那个时候的微软几百个人做几个项目，通常是程序员写完程序了，自己测试一下就算完事。后来微软的项目越来越大，软件越来越复杂，写代码和测试的工作要平行进行，慢慢产生了独立的测试组。一个重要的数字是，微软产品组中测试人员和开发人员的比例大约是1∶1。事实上，要想真正保证软件项目如期完成，不仅取决于开发人员，更取决于测试人员。

测试组独立于开发组之外的好处在于，程序员总是倾向于认为自己设计的代码足够好，独立的测试组能够使测试人员在不带任何假设的情形下从不同的角度来测试软件，有利于保证软件的质量始终得到操纵，并使测试资源得到重用和不断改进。然而，测试组独立于开发组之外，并不意味着程序员写完代码就扔过“墙壁”，等待测试工程师找到所有的bug，当测试人员认为他的工作确实是测试程序，而开发人员认为他的工作确实是写程序给测试人员测试时，假如你是项目经理，要小心了！开发人员的优越感会使测试人员感受自己是被鄙视的少数民族，这势必会阻碍到软件的品质。程序人员在写完代码、改正问题后必须完成差不多的测试，比如代码的路径测试、单元测试和问题验证等。产品质量操纵，存在于开发过程的每一个环节中。

有一个见笑，微软的测试人职员作时刻长了，都有挑刺儿的适应，下了班见了太太做的饭都要评判一番。对微软来说，那些聪慧、细致、认真，有耐心，追求完美的产品，对用户有负责任的态度，思维方式独立又开放，既有足够的技术背景，但又情愿学习新的技术的测试工程师更容易得到“老总”的青睐。

软件测试的时期性

软件开发的过程就像是一支队伍正在急行军，但跑着跑着这支队伍就会“散了架”，设立里程碑的作用就看起来是到了某一个“点”，大伙儿必须要重新整理步伐，实现同步。就测试组的工作模式而言，测试的时期划分是与项目的进度相对应的。也确实是说，测试人员应当与项目组的其他人员始终保持以相同的步伐“跑步”的状态，与整个项目的每一个里程碑配合，完成相应的测试工作。

把大项目划分成若干子项目的里程碑式的开发模式是微软软件开发治理的精髓做法，如上一期《微软研发方法（上）》所述，在微软的每一个产品开发周期中都有以下几个重要的里程碑：CC（Code complete:代码完成）；Beta测试；RC（Release Candidate：候选公布）；RTM（Release To Manufacture:投入生产），测试人员和产品组的其他人员一起，共同达到每一个里程碑。一个完整的测试循环应当包括运行所有的测试用例、Beta标准测试、bug校验和解所有的bug、随机测试。好的测试循环能够保证对软件质量有一个全面完整的评判，每个里程碑之前至少要有一个完整的测试循环。

在微软的产品开发周期中，在规划时期当开发人员在做打算、编进度，进行功能实现的可行性研究，对打算的功能进行反馈时，测试人员应当研究规格说明，编写测试打算；在第二个时期即开发时期，当开发人员在编写代码、测试和调试的同时，测试人员应当开始设计测试用例，开发自动测试工具和程序，熟悉必需的环境、工具、软件和硬件，不断地丰富测试用例，直到达到CC（代码完成）里程碑——那个时候的软件能够进行一次整体测试，用户界面可能不完美但能够工作，可能有专门多明显的bug。

进入开发周期的第三时期，测试人员大显身手，展开大规模的测试，比如系统级整体测试，交互性和深层测试。测试之后，测试人员应当对新增的功能说“不”，直至达到Bate测试里程碑。达到那个里程碑，意味着所有的Beta致命问题差不多被修正和关闭，所有打算的功能都差不多在软件中并能工作，产品稳固，大部分界面还能够，尽管可能只是一部分，但差不多有了在线关心和用户手册，即使是公布了也可不能引起负面的阻碍。

Beta测试的目的是确定产品是否能在估量的各种硬件平台和操作系统中正常运行，尽管Beta测试的反馈意见专门有参考价值，但除非存在重大问题，否则不应对功能集再做修改，所有建议和反馈都留在下一版中再考虑纳入。Beta测试之后就要向RC和RTM进军。测试人员要着重测试Beta后的变动。到达RC，意味着软件质量状态为没有活跃的bug（Active bug）；没有悬而未决的事；差不多稳固了一段时刻，如一周内专门少或没有变动，或变动专门小。假如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急救小组（bug triage team）”，审查每一个bug，选择和修改产品中最重要的错误，决定相应解决方案，尽量使大部分的用户在大部分的时刻内都能够使用愉快。因此，“bug 法庭”开会的频度取决于处于哪一个时期。

测试组应当有一个区域专门放置记录所有bug的数据库。那个数据库应当是整个产品组的中央记录和操纵区，而且其中所有的记录都无法删除，关于每个记录只能一直添加内容。测试组应当有与项目组所有成员交流与沟通的公用工具；与bug mail配合，能依照bug的当前状态及时通知bug的当前责任人；有效地跟踪项目的进展，为产品公布提供判定标准；能积存测试人员成果。

隐秘武器：测试用例和测试打算

概括来看，微软测试的精髓做法是：系统可重用的测试用例；以问题（bug）发觉和跟踪为核心的测试活动；独立的测试人员；基于产品规划、产品设计规格的测试打算；与整个项目配合的基于里程碑的软件测试周期。而基于产品规划、产品设计规格的测试打算和系统可重用的测试用例则是微软的“隐秘武器”。

在微软，测试打确实是关心测试人员治理测试项目和发觉bug的重要工具，是纲领性文件。测试打算明确了项目的测试任务、测试内容清单，这些内容不能只存在于测试人员的脑海里，而必须被项目经理、开发经理所了解，测试打算必须增强测试任务和测试实施过程的沟通，具有指导性。测试打算还必须提供组织治理测试项目的框架结构，关心操纵进度。

测试打算涉及的范畴应当有产品概述、测试策略、测试的方法学、测试区域、测试的配置（软件环境、硬件环境、网络环境）、测试周期（与项目的里程碑配合）、测试资源的规划、风险分析和案例等。测试打算不是一成不变的。尽管测试打算在产品设计时期就开始被撰写，但在后来的开发过程中会随着项目进度表的改变而改变。

一个好的测试用例有以下几个特点：第一，是最有可能抓住错误的；其次，不是重复的、余外的；第三，一组相似测试用例中最有效的；最后，不要太简单，也不要太复杂。因此，在测试人员设计测试用例时应当遵循以下原则：在人员变化和新项目中能够重用；能够分类；测试的内容不重复；储存在测试用例的数据库中；在项目进行过程中可不断增强。

设计测试用例时的一些通常考虑“点”是：依照产品规格测试差不多功能；设计一般用户的使用方案；设计稀有或专门的使用方案；与系统其他组成部分的配合（如FAX和上网可能都要用到调制解调器，测试中要考虑对设备的共享）；考虑专门情形（比如内存和硬件的冲突等）；设计极端情形（比如内存泄漏、破坏性测试等）。