微软研发方法

微软研发方法团队=软件 一个伟大的软件后面都有一个伟大的故事，一个伟大的软件后面也有一个伟大的方法。 题记 当Windows 2000经过胎死腹中的危机，终于如凤凰涅般再生时，微软决定给整个产品组成员拍摄一张合影，以纪念这个历史时刻的诞生。到了拍摄那一天，微软人发现，他们只有把摄像师安排在飞机上才能干好这件事儿因为Windows 2000产品组整整有5000人！ “团队=软件”，微软软件开发管理理论的基础可以这样一个恒等式来表达，软件可以忠实地展现创造它的团队的一切优点和缺点。软件业中没有两个完全相同的失败，但最常见的莫过于新版本跟不上对手的脚步，微软开发模式的精髓之一，便是通过产品组团队中每个成员对职责的承诺来控制产品的开发过程，保证新产品准时地、经常地被推出。 这正是软件业最大的金科玉律！ 开发周期四阶段 微软的产品开发遵循一个完整的开发周期，这个产品开发周期被分为四个阶段：规划阶段、开发阶段、测试阶段（也叫稳定化阶段）和产品发送/出品阶段（参见图1）。 微软中国研发中心中文技术部经理李东女士告诉记者，在产品的规划阶段要做三件事：拟定基于客户数据的目标描述、基于目标描述的规格/特性说明和基于规格说明和特性优先级制定的进度表。规划阶段中最重要的事情是让整个产品组的成员对共同的目标形成共同的认同。一座伟大建筑的诞生往往只缘于一位伟大建筑师的不朽贡献，但一个伟大软件的设计却需要成百上千人的智力创造。 第二个阶段是开发阶段，这个阶段也叫主要里程碑阶段。微软的任何一个产品组在这个阶段都将根据特性将项目划分成若干个子项目，每一个子项目的完成就对应于一个里程碑。在李东的经验中，一般微软中国研发中心会在这个阶段把产品划分成23个里程碑。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之后才进入产品发送/出品阶段的。 产品有了稳定的版本就进入最后的阶段产品发送/出品阶段。对于研发队伍来讲，十月怀胎、孩子终于出世的那一天就是发送投产（RTMRelease 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越少越好，程序经理要善于协调二者的矛盾；在产品的开发过程中通常会出现人员突然流动的现象，或者硬件环境出了问题，或者外边竞争对手出现变化，程序经理对这些要反应非常机敏，有能力做出对公司、产品和客户影响最小的果断的取舍和决定。 微软的开发人员无疑是每一个产品组中非常重要的角色。一个头衔是软件设计工程师（SDESoft Design Engineer）的开发人员的级别有可能比某一个经理要高很多。在微软，开发人员根据他本身知识和能力的不同分为不同的级别，顶级的开发人员负责整个软件的结构设计，中间有负责某一功能类的结构设计师，最底层的开发人员只完成规定的模块实现。好的结构设计对产品的稳定性、可扩充性非常重要，特别是对一个由多人参与的项目而言更是如此。在产品组中，最厉害的开发人员是整个产品结构的设计师。应该说，微软每一个产品中都有几个核心开发人员来控制整个产品的结构，其他开发人员则在他的领导之下共同完成开发工作。 可用性测试的重要 所有用过微软产品的人会有一种感觉，微软产品非常易用。如何使产品做到易用？微软的办法是通过重视可用性测试（Usability Testing）来实现。可用性测试的使命是通过在产品开发周期的各个阶段加入客户资料和信息来使产品更有用、适用和易用。 在产品开发周期的第一个阶段可用性测试就要展开工作，比如，微软中国研发中心的产品组会把产品的新特性做一个模拟的模型，找用户来试用，产品组的可用性测试人员便会在试用过程中准备录音机、摄像头，把用户的行为摄下来，说的话录下来，按的键记录下来，研究他们对产品的反应，以便把产品设计调整到足够好。 微软中国研发中心中文处理组有一个产品 “微软拼音输入法”，其最早的帮助功能是用鼠标右键击活菜单，这是Windows常用的菜单风格，但是通过前期的可用性测试，李东他们发现中国用户习惯了用鼠标左键，很少用右键，这样用户很难找到微软拼音的帮助功能。后来微软中国研发中心把“帮助”放在显示特别明显的地方输入法状态条上，这样，按左键就能使用帮助功能。“用户的需求可能跟你想的不一样，这就要真正倾听用户的呼声，让用户来试用，看用户的反应，来决定修改你的产品”，李东告诉记者，微软中国研发中心这样的例子很多。 在第二个开发阶段，当开发人员达到M1，能看到产品的最重要的特性时，可用性测试人员要随时反馈设计好不好，如果要有个别的改动，则在M2中将M1的某些功能改动加进来。可用性测试人员要理解用户的工作领域、行为和心理，微软公司总部有很多做可用性测试的人员是心理学方面的专家。用户的感受只有通过可用性测试人员分析、理解成对功能的描述，或者对功能的反馈，才能使产品开发人员能够理解并改进。 里程碑式的开发模式的好处 综观微软对软件开发周期过程的管理，其精髓的做法一是将大项目划分成若干个子项目的里程碑式的开发模式；其次，通过对产品组各人员角色对职责的承诺来控制产品的开发过程，以保证产品的进度和质量。 不管是小软件还是大软件，里程碑的概念在微软所有的软件开发中都会被用到。这也是微软在软件开发上摸索多年凝聚所得。国内软件企业的开发大多是从有一个想法就开始做，不分什么阶段，但往往因为软件功能太多，不同的人负责不同模块，到产品的最后阶段再去集成和测试，大量原来没有预计到的问题都“冒”了出来，这时再去“动”各个部分，时间肯定要推迟。这种模式将导致两个问题:一是质量无法控制，二是时间无法控制。 李东认为，在微软里程碑式的开发模式下，做同样大的产品，因为按子项目来划分里程碑，每一个子项目都经过一定的稳定化阶段，再进入到第二个子项目的时候，就是基于一个相对稳定的一部分子项目基础之上的行为，这样就将风险或错误的累加分散和降低。以局部的质量控制来保证整体产品的进一步稳定，能使得质量和进度得以很好的控制。而且，把一个大的项目分散到不同的阶段来完成，可以灵活地去增加或减少一些功能，否则，把增加或减少功能集中到最后集成阶段，而且是在不稳定的环境下来做，困难可想而知。这就是里程碑式的开发模式优秀之处所在。虽然里程碑的做法在成本上比较高为了协调出大家对里程碑一致的价值观，为了协调出里程碑的衡量准则，如此等等，团队必须付出大量时间和精力，承受比较大的痛苦，但这是惟一能够确保开发成功的方式。 国内软件企业的开发模式多为“大拿领衔制”，通常公司十多个技术人员中间有一个技术“大拿”，剩下人辅助他，把这个产品的所有代码写完，则软件就算完成了。“大拿领衔制”脱不去小作坊的味道，虽然保证了“技术大拿”的创造性，却失去了软件研发过程应有的规范。 软件企业的创造性和制度要相辅相成。在微软的所有里程碑中，“代码完成”里程碑（code complete milestone），是一个重要的分界线。在代码完成之前，产品组自由发挥创造力，最需要大量的交互和碰撞。代码完成之后，则需严格按照里程碑完成进度。进入测试阶段，微软通常把里程碑分得更细致，比如Beta、零错误版本、发布候选、RTM等等。每个里程碑都不是简单的摆设，而是有严格的规定，快到里程碑的时候开发人员不能做没到里程碑时的修改，“原来一个Bug怎么改都可以，但到里程碑附近的时候，就要求只能改动最重要的Bug”，微软中国研发中心副总经理徐汕开发Windows 2000时曾与副总裁吵过架，“我们觉得中文版需要这项功能，但当时已经太晚了，大家争吵了很长时间，最后还是不能改。”为保证软件按进度完成，靠近里程碑时需要“收敛”，而收敛惟一的方法就是少做事情。过了一个里程碑，产品比以前的质量就要好许多。通过一个一个里程碑来收敛，这个项目不会偏离目标很远。从代码完成到RTM是微软软件开发周期中非常重要的过程，这个时候已经完成充分发挥智力的时期，而规范成为更重要的要素。（注：本文只给出了微软团队工作方式的常规模式，具体的实践模式可参考微软Visual C+事业部总监吉姆麦卡锡所著书微软团队成功秘诀。） 微软研发方法(下)Bug“指挥棒” 想真正保证软件项目如期完成，不仅取决于开发人员，更取决于测试人员。 题记 项目经理经常犯的错误之一，是以为只要雇用软件工程师就行，其他的人都不必要，或是让软件工程师占整个团队很高的比例。他们也许认为开发人员越多，写出来的程序也越多，这是错误的概念。项目的目的是为了完成软件，而不是完成更多的程序代码。在开发团队中，实际有一些工作是不适宜交给软件工程师做的。 要想真正保证软件项目如期完成，不仅取决于开发人员，更取决于测试人员。软件开发好像是在赶进度，而不是在演奏交响乐：交响乐是和谐有序而优雅的，而软件开发却更像是一堆排山倒海、蜂拥而至的工作。交响乐任何两个音符都不能相互抵触，整体表现出来的才是一段优美的音乐。在一切都不确定的软件开发过程中，让测试人员的“Bug指挥棒”来使大家知道什么时候该表现，知道什么时候该退后一点，正是微软将软件开发过程带向高潮的不二法则！ 测试组不是开发组的助手 似乎没有谁比微软更重视测试的力量。在微软的产品组中，测试组是与产品规划组、产品管理组、开发组和用户教育组等并列的队伍。测试与软件成本的关系是，发现产品中存在的问题越早，开发费用越低，产品质量越高，软件发布后维护费用越低。在微软开发周期的四个阶段中，测试的目的在于保证软件质量，满足设计的要求和客户的需求；系统地揭示出不同类型的错误，并耗费最少时间和最小工作量；降低软件的开发成本和维护成本。 软件开发过程中开发人员很可能因为一些偶发的小事，或某种无关的灵感而不知不觉中偏离了实际的需要，暂时忘记了什么才是产品最该有的功能，把他们拉回原定轨道中的正是测试工程师。测试人员的职责是配合整个项目组保证按照预定的时间表完成达到预定设计目标的产品。测试人员的工作是具有整体性、持续性的软件开发活动中的一环，而不是偶尔拿出来点缀一下。软件产品的质量是由用于测试的资源、产品的功能和项目的时间表来决定的，是三者的平衡。对任何的一个产品组来说，无论是主观，还是客观上，都要重视测试工程师的存在，这是产品质量的重要保证。 罗马不是一天建成的。早期的微软开发队伍中也没有设立单独的测试组。那个时候的微软几百个人做几个项目，通常是程序员写完程序了，自己测试一下就算完事。后来微软的项目越来越大，软件越来越复杂，写代码和测试的工作要平行进行，渐渐产生了独立的测试组。一个重要的数字是，微软产品组中测试人员和开发人员的比例大约是11。其实，要想真正保证软件项目如期完成，不仅取决于开发人员，更取决于测试人员。 测试组独立于开发组之外的好处在于，程序员总是倾向于认为自己设计的代码足够好，独立的测试组可以使测试人员在不带任何假设的情况下从不同的角度来测试软件，有利于保证软件的质量始终得到控制，并使测试资源得到重用和不断改进。但是，测试组独立于开发组之外，并不意味着程序员写完代码就扔过“墙壁”，等待测试工程师找到所有的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的优先级分为四个级别：尽快修正；每