1、测试流程

　　首先说说测试流程，微软的测试流程也没什么新的东西，和大多数的测试流程一样。

　　大致是先进行测试准备，然后是Testcase的编写，然后是白盒测试（不一定每个项目都有），然后是功能测试阶段，然后是验收测试，终release。

　　如果看流程的话，和一般公司大同小异，没什么新花样。但是我觉得值得借鉴的是两点。

　　第一，微软的流程执行的非常认真。

　　这点非常值得提倡，我们都知道，测试的终质量决定于测试流程和测试人员素质，要想测试质量有保证，要么是流程很完善，要么你流程不行，但是个人能力超强。如果有一个很好的流程，算执行的人稍微差点，终的质量也不会差到哪里去。所以流程是很重要的。

　　但是，看国内的公司欠缺的是这个，要么是没有流程，要么流程是个花架子，没认真执行过。我想微软的测试人都是超级牛人，但是人家还是老老实实的忠实按照流程来走，我觉得这点非常好。（在IBM 也是这样，笔者以前在IBM作项目的时候，发现他们的文档写的特认真，流程特认真），所以说忠实的执行一个好的流程是成功的一大半。

　　第二，在整个流程中，微软非常强调测试尽早介入。

　　微软在这方面是一致提倡的，按照我们国内IT业的恶习，一般都是软件主体差不多成型了，拉几个测试人员过来点点，其实这是非常不好的。微软的测试人员在项目一开始和开发人员同步介入，在需求阶段开始介入，进行需求评审。在开发人员开始编码的时候，测试人员开始编写Test case，并开发一些测试工具，或者写一些配套的测试代码（不要奇怪，微软的测试人员都能写很好的代码）。微软的理念是：预防bug比解决bug好，所以非常提倡测试尽早介入，把一部分bug消灭在需求阶段。

　　2、自动化流程

　　说到自动化，大家可能以为我是说微软的自动化测试工具多牛，其实微软内部用到的自动化测试工具倒是不多，算有也都是内部开发的，非常实用的，他们不会去用MI的工具。

　　说微软的自动化程度高，主要是体现在流程方面，譬如说整个自动构建流程，在开发人员代码check in之后，系统自动发邮件，邮件内容是一个change list，包括代码更新list以及一个编译者添加的comment，其内容是该版本功能的变化或者修改掉的bug ID。整个测试过程中能用自动化的地方都尽可能采用自动化，尽可能减少人为失误，并且可以使人和机器并行工作。个人觉得，这点很值得我们国内的测试公司借鉴，能自动化的流程都自动化，减少一些不必要的沟通。

　　3、质量控制机制

　　说到质量控制是个大问题，需要整个团队和流程提高素质。那么微软的质量控制可以借鉴的是什么呢？是他们的机制。在微软的测试流程当中，在开发的早期，项目中所有的问题都是Dev leader和PM商量说了算（当然也要参考需求方的意见），但是到后期，具体是功能测试之后，项目的主动权都在测试这边，某个bug的要不要解决，或者项目进度控制都是测试leader说了算。这和国内的大多数软件公司是不一样的，在微软，测试人员要对终的软件质量负责任，但是也有相应的权利来约束开发人员。当然，他们也肯定有一些bug是产生争议的，这个时候的仲裁机制是PM，这个不是我们传统的PM（Project manager），而是一种具有微软特色的PM（全称是Program manager）。这样，测试人员在对一些争议bug的处理上有相当的话语权。

　　4、测试用例及管理

　　微软的测试用例倒没什么特别的，不过看过他们用例之后，还是觉得写的详细，认真，但是又不冗长拖沓，这个需要很高深的水平。另外，微软的测试用例管理用的是微软自己开发的用例管理工具。

　　另外值得说明的是，微软的每个用例都进行了分级，并且功能所在的模块都标的很清楚。

　　5、效率

　　在效率方面，微软的测试效率非常高！高的让人惊叹，我问一个在微软工作的哥们，“你们那边测试的大特点是什么”，他说“大特点是快！”，是效率很高，具体是在测试后期过程中测试和开发之间的反馈非常快，开发修改一定量的bug，提交一个新的版本。测试人员往往能在很快的时间内把测试结果反馈出来，一般是在1天之内能把用例快速run一遍，这样能减少某些后期才发现bug导致的项目delay。在国内很多项目的通病是，开发解决问题带进一个新问题，测试人员整个遍历一遍用例之后才能发现，这样来回反复消耗了大量的时间。

　　但微软是如何才能实现快速反馈呢？

　　第一，测试人员对程序的了解，微软的测试人员对程序内部结构都非常熟悉，修改某一个地方，可能引起什么问题，哪些用例需要重新测试，测试人员非常清楚，能快速的执行可能出错的地方。如果某些模块不熟悉，那么他们会和开发人员在一起沟通这次修改可能引起的问题。

　　第二，工具！还是工具，在微软的测试中，测试人员用各种工具帮助测试，提高测试效率是占到很大的比重。

　　第三，时间意识。微软的测试人员有强烈的时间意识。