最近父母来美国访问，大部分时间都陪他们到处游玩，因此也没有写任何新的文章出来，今天还是老声常谈。从写测试文章以来就陷于自动化测试话题的漩涡中，虽然我觉得这个话题对我来说已经没有任何讨论的意义，可是还是怕很多反对自动化的文章对大家产生误导作用。以前的文章我主要是从技术的角度来讨论，而且从这个角度我认为我已经基本表达了所有我对自动化测试的理解，那么今天我就从业内实际的产品测试的范例来谈自动化测试的重要性。

　　众所周知，微软的WindowsVista投入了6000工程师，花费了5年的时间来进行开发，不夸张的说，这是人类历史上规模最大的一次软件产品的开发。因此，对于Windows的测试流程是非常值得拿来进行研究的。今天我也想从我自己了解的一些情况来简单的谈一谈。

　　首先，微软没有专门的手工测试人员，基本全部是自动化测试人员。微软的一个测试人员的测试用例大概是其他公司3，4个人的数量。我们知道测试量不能仅仅用测试用例的数量来衡量，还有一个测试周期的问题。而Windows的测试周期是一天，甚至有的时候不到一天。其他公司的测试周期一般至少要一个星期。那么微软一个测试人员一天的时间要完成其他公司3，4个人一个星期的测试任务，听起来是不现实的。那么他们是怎样完成的呢？下面我从纵向和横向来分析。

　　纵向来看，由于Windows开发团队的规模宏大，使得他们的组织一定要分层，分级的。最高层的build就是在市面上发布的build，而每一个部门都会有自己单独的build。平时的开发和bugfix都是在自己的build中来进行的，经过测试人员的signoff才能传送到上一级的build。而一般来说，都是分3或4级的。也就是说，每一级的build你都需要进行测试，而每一级一般每天都会出一个新的build。那么最多每天你需要测试4个build，大家想想，如果不采用自动化，只是纯手工的方式，如何能够完成呢？而实际上，Windows聘用了大量的外包人员，他们专门安装每天出的新build，并且运行测试人员的自动化测试程序，然后把测试报告发布出去。而测试人员得到报告以后，要分析任何的测试错误，进行相应的处理。一般来说，错误分三种，测试环境的问题，测试程序的问题，产品的问题。测试环境的问题要外包人员来负责，测试程序的问题要报测试的bug，自己解决。产品的问题，当然就要报产品的bug由开发人员来解决了。这种模式就使得测试人员能够把测试的开发和运行分离开来，使得测试人员能够专注于测试的开发工作，也就是说测试人员大部分的时候是在coding中。这也是为什么微软的测试人员title是SDET(softwaredevelopmentengineerintest),也就是说微软的测试人员本质上就是开发人员。

　　横向来看，Windows的测试根据时间的长短和重要性分成很多种。以上所说的是测试每天的build，在自己部门的build往上一级传送之前的测试又是一种，还有一种是要测试一个build使得质量可以使得微软的员工进行内部的使用，还有就是每个milestone的测试，以及release之前的beta,rc阶段的各种测试。因此，测试用例的优先级在这里就显得十分的重要。由于各种原因，往往不能100%的进行测试用例的自动化，因此手工测试还是必不可少的。如果我们把测试用例按照优先级分为P0-P3。那么一般来说，P0和P1的testcase是一定要实现自动化的。那么对于P2和P3的手工测试，就只在非常重要的测试阶段来进行。在每天的测试，和不太重要的测试阶段，也没有要求保证全部的测试用例要通过。这样的安排，就使得SDET能够尽量少的去执行手工测试，从而能够专注自动化测试的开发和对产品进行更加深入的测试，以及安全测试等等。一般来讲，需要进行手工测试的情况的发生周期要大于一个月，而因为SDET平时尽量的能自动化更多的测试（包括P2和P3），手工测试往往需要2天的时间就能完成。

　　从以上纵向和横向的分析来看，Windows的测试任务是十分浩大的，纯手工测试也是无法想像的。可是，由于微软大量的采用自动化测试技术和人才，使得不可能变为可能，实在是做了一个自动化测试软件工程的典范，值得任何公司和个人去思考。