[轉]微软软件测试的可借鉴之处
来源：希赛网
做测试很久了，一直为一些问题所困扰，也一直对微软有一种顶礼膜拜的向往，终于有一天，近距离的接触了微软的测试，感觉不是以前想象中那么遥不可及，却又难以企及。于是把个人觉得微软值得借鉴的地方整理了一下，希望能对大家有所帮助。
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。在国内很多项目的通病是，开发解决问题带进一个新问题，测试人员整个遍历一遍用例之后才能发现，这样来回反复就消耗了大量的时间。
但微软是如何才能实现快速反馈呢?
第一， 测试人员对程序的了解，微软的测试人员对程序内部结构都非常熟悉，修改某一个地方，可能引起什么问题，哪些用例需要重新测试，测试人员非常清楚，能快速的执行最可能出错的地方。如果某些模块不熟悉，那么他们会和开发人员在一起沟通这次修改可能引起的问题。
第二， 工具!还是工具，在微软的测试中，测试人员用各种工具帮助测试，提高测试效率是占到很大的比重。
第三， 时间意识。微软的测试人员有强烈的时间意识。
6. 测试工具
测试工具能很大程度上提高测试效率，这个作为测试人员都很清楚。当然测试工具在微软的测试中也应用非常广泛，但是请注意，微软并不是像我们国内的公司一样使用的都是LR或QTP这类的录制回放工具，反而这种工具倒是用的不多，就跟微软不屑CMM一样，可能是不想屈尊自己IT老大的身份吧。
但是微软的测试工具最大的特点是实用。他们用的测试工具都是确实能提高效率，确实能办事情的工具，都不是类似WR和QTP的很大很系统的工具，而是比较小的，很灵活，实用的小工具(譬如：Fiddler、Drip、httpwatch、IE DevToolBar、PaintNotNet、procexp etc.)。甚至有一些测试工具是测试人员在开发人员协助下根据项目需要临时开发的，不过大多数工具都是微软内部已经共享出来的，在微软内部各种各样的小工具特别多。
总体给我的感觉是，不是为了用测试工具而用，而是根据实际的需要，确实能提高效率而用到，在用的过程中确实也很大的提高了效率。
7. 测试人员的专业素质
微软测试给我印象最深刻的还有他们测试人员的专业水准，在测试过程中，测试人员在一些技术上并不逊色于开发人员，在一些bug的处理上，能提出很多合理的很有建设性的建议。
8. 微软的白盒测试
微软的白盒测试怎么执行呢?让我略微有点吃惊的是，微软的一半测试人员基本不做白盒测试，除非有些不能做黑盒的模块，另外也不是所有的产品都作白盒测试。
微软的白盒测试一般还是由专门的白盒测试人员来做，但是开发人员要对测试人员的白盒测试代码进行Review，另外微软对开发人员的代码，效率也都有一套详细的考核机制，所以开发人员对自己的代码也是非常负责任的，都进行很认真的进行测试。
9. 意识(时间，质量)
另外微软的测试还有很好的一点就是意识，时间和质量的意识都是非常强。在控制时间成本上，意识非常强，这点非常值得我们国内同仁学习，另外，风险管理的机制和意识都是非常好。在微软，项目组的每个成员都被明确告知，如果这个项目每delay一天，就会损失多少个million的美元，所以整个项目组都有比较好的时间意识。
另外，在微软，项目组人员的质量意识都是比较强的。怎么样更好服务用户，让用户体验更好，怎么样更好的改进，这种意识比较强。
10. 微软的培训
在微软内部，员工外训的机会比较少，大多都是内部互训，各人培训自己的强项，有比较好的互相分享的习惯。另外微软的内部有非常丰富的各种培训文档。以后我会上传上去和大家分享。
11. 测试数据记录
微软的测试数据记录是非常全的，也都是系统自动的，每天都是由系统自动统计当天的bug情况，然后发送一个report到每个项目组成员的邮箱里。最后到测试总结的时候，这些测试数据将变得非常有用。
编后感：
在深入了解微软的测试之前，对微软这个IT业界巨无霸的测试感觉是顶礼膜拜，高不可攀，总觉得可能很神秘，用很牛的技术或者很高深的手段。深入了解之后，发现微软的测试也是和我们做一样的事情，只不过人家做的更认真，更细，更实用，更有效率。再回过头来看时，微软的测试给我留下印象最多的是，流程，效率，意识，工具，素质!也就是这几项，成为我们国内IT企业亟需跨越的。
做测试很久了，一直为一些问题所困扰，也一直对微软有一种顶礼膜拜的向往，终于有一天，近距离的接触了微软的测试，感觉不是以前想象中那么遥不可及，却又难以企及。于是把个人觉得微软值得借鉴的地方整理了一下，希望能对大家有所帮助。
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。在国内很多项目的通病是，开发解决问题带进一个新问题，测试人员整个遍历一遍用例之后才能发现，这样来回反复就消耗了大量的时间。
但微软是如何才能实现快速反馈呢?
第一， 测试人员对程序的了解，微软的测试人员对程序内部结构都非常熟悉，修改某一个地方，可能引起什么问题，哪些用例需要重新测试，测试人员非常清楚，能快速的执行最可能出错的地方。如果某些模块不熟悉，那么他们会和开发人员在一起沟通这次修改可能引起的问题。
第二， 工具!还是工具，在微软的测试中，测试人员用各种工具帮助测试，提高测试效率是占到很大的比重。
第三， 时间意识。微软的测试人员有强烈的时间意识。
6. 测试工具
测试工具能很大程度上提高测试效率，这个作为测试人员都很清楚。当然测试工具在微软的测试中也应用非常广泛，但是请注意，微软并不是像我们国内的公司一样使用的都是LR或QTP这类的录制回放工具，反而这种工具倒是用的不多，就跟微软不屑CMM一样，可能是不想屈尊自己IT老大的身份吧。
但是微软的测试工具最大的特点是实用。他们用的测试工具都是确实能提高效率，确实能办事情的工具，都不是类似WR和QTP的很大很系统的工具，而是比较小的，很灵活，实用的小工具(譬如：Fiddler、Drip、httpwatch、IE DevToolBar、PaintNotNet、procexp etc.)。甚至有一些测试工具是测试人员在开发人员协助下根据项目需要临时开发的，不过大多数工具都是微软内部已经共享出来的，在微软内部各种各样的小工具特别多。
总体给我的感觉是，不是为了用测试工具而用，而是根据实际的需要，确实能提高效率而用到，在用的过程中确实也很大的提高了效率。
7. 测试人员的专业素质
微软测试给我印象最深刻的还有他们测试人员的专业水准，在测试过程中，测试人员在一些技术上并不逊色于开发人员，在一些bug的处理上，能提出很多合理的很有建设性的建议。
8. 微软的白盒测试
微软的白盒测试怎么执行呢?让我略微有点吃惊的是，微软的一半测试人员基本不做白盒测试，除非有些不能做黑盒的模块，另外也不是所有的产品都作白盒测试。
微软的白盒测试一般还是由专门的白盒测试人员来做，但是开发人员要对测试人员的白盒测试代码进行Review，另外微软对开发人员的代码，效率也都有一套详细的考核机制，所以开发人员对自己的代码也是非常负责任的，都进行很认真的进行测试。
9. 意识(时间，质量)
另外微软的测试还有很好的一点就是意识，时间和质量的意识都是非常强。在控制时间成本上，意识非常强，这点非常值得我们国内同仁学习，另外，风险管理的机制和意识都是非常好。在微软，项目组的每个成员都被明确告知，如果这个项目每delay一天，就会损失多少个million的美元，所以整个项目组都有比较好的时间意识。
另外，在微软，项目组人员的质量意识都是比较强的。怎么样更好服务用户，让用户体验更好，怎么样更好的改进，这种意识比较强。
10. 微软的培训
在微软内部，员工外训的机会比较少，大多都是内部互训，各人培训自己的强项，有比较好的互相分享的习惯。另外微软的内部有非常丰富的各种培训文档。以后我会上传上去和大家分享。
11. 测试数据记录
微软的测试数据记录是非常全的，也都是系统自动的，每天都是由系统自动统计当天的bug情况，然后发送一个report到每个项目组成员的邮箱里。最后到测试总结的时候，这些测试数据将变得非常有用。
编后感：
在深入了解微软的测试之前，对微软这个IT业界巨无霸的测试感觉是顶礼膜拜，高不可攀，总觉得可能很神秘，用很牛的技术或者很高深的手段。深入了解之后，发现微软的测试也是和我们做一样的事情，只不过人家做的更认真，更细，更实用，更有效率。再回过头来看时，微软的测试给我留下印象最多的是，流程，效率，意识，工具，素质!也就是这几项，成为我们国内IT企业亟需跨越的。
