开头语：

　　做测试很久了，一直为一些问题所困扰，也一直对微软有一种顶礼膜拜的向往，终于有一天，近距离的接触了微软的测试，感觉不是以前想象中那么遥不可及，却又难以企及。于是把个人觉得微软值得借鉴的地方整理了一下，希望能对大家有所帮助。

　　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。在国内很多项目的通病是，开发解决问题带进一个新问题，测试人员整个遍历一遍用例之后才能发现，这样来回反复就消耗了大量的时间。

评论