讲师：袁华松
时间：12月5日10:30-11:45
地点：教室二
    这一讲我们是讲软件测试自动化。

    首先为什么需要软件测试自动化？通过我这几年在微软的工作，可以感觉到一点，应该说自动测试，可以定义软件系统。从理论上来说应该是功能定义软件系统，软件系统是怎么工作的是从功能Spec来看的。但是你要是没有一套可以自动测试的测试程序存在，就没有办法验证我这个软件系统，就是修改了一点点，这个软件系统是不是和前面的软件系统一模一样，你没有办法验证，只有有一套自动系统，才能验证软件系统是不是还在原来的状态上。我觉得自动测试是非常重要的一个东西，微软一个软件系统如果没有跟着一套自动系统的话，这个软件系统基本上没有生命力，也没有办法进行更新，其他的各式各样的服务也没有办法进行。

    代码的复杂性也是不能小看的。现在测试一个代码时，所有的覆盖也是不可能的事情，每一个if…else…或switch语句就会把情况增加一倍，许多异常处理代码正常使用中不会碰到。许多与时序，死锁，资源冲突，多线程有关的错误很难捕捉到。除此之外，我们每一个版本又各自带SP与QFE，每个SP进 行组合，可以得到一个天文数字，如果没有一个自动测试系统的话，要测试整个产品，在所有不同的情况下进行工作的话，几乎是一个不可能的事情。你要是有一套自动测试系统，对未来 会有一种事半功倍的效果。

    微软内部有各种不同的测试，首先开发团队有自己的DRT或者Check－in Suites。不需要重装机器，要求速度快，对结果汇报要求简单，100％通过就行，所以不需要很强的分析的能力。与开发团队的关系近，在他们的源代码控制系统中。测试团队有测试的Lab BVT，所有的测试者都是在一起的，BVT的要求是需要重新安装机器，可以排除其他老的因素在上面的干扰。要求速度快，只运行0级测试，BVT也是在每天的构建结束以后自动运行BVT，结果汇报要求也是比较简单，一般来说需要100％，如果不是100％总是要找问题，前天的结果，大前天的结果应该都是100％。与测试团队的关系近，在测试团队的源代码控制系统中，由每日产品编译系统自动触发，全自动运行。

    还有自己常规的Lab Pass也需要重装机器，模拟最终用户的使用形式。需要使用每日编译结果，规模大，测试数多，环境要求也复杂，在这时候我们就会把整个刚才我讲的测试者引进来，一天可能需要测试不同版本，或者不同语言版等。对测试结果汇报与问题要求很高，因为这时候所有测试必须百分之百的通过，可能前天有这么一个问题，今天这个问题重新出现，是不是就可以忽略了呢？如果这个报告结果工具不能干这个事，每天必须要重新做。由测试团队根据需要产生。测试团队的个人Private Pass，由测试个人根据需要产生，不一定需要重装机器，对测试结果汇报要求很高，与测试团队的关系近，在测试团队的源代码控制系统中。

    一个具体自动化测试系统分析。微软内部有很多套自动化测试系统，比如OASys，是Office用的系统，还有Maddog，Bruce等等。这些系统演化到最后，总体结构大同小异。如果大家自主开发一套新的自动化测试系统，我估计大概十年以后结果就是这样的。以OASys系统为例，有Web服务器，是前台的Web UI。SQL Server后台服务器，有控制程序，客户机程序，客户程序就是在机器上装一个小的程序，一些结果报告与分析的程序，有文件服务器，存放每天的构建的结果，每次结果的Log file等等，除此之外所有的测试都是在机器池中进行，一系列差不多一样的机器，在一个测试里随时调用某一群或者某一些，或者某一个机器进行使用。

   具体模块的功能。

   文件服务器是存放每日的结果，存放每一个Run的logfile。比如你需要安装什么东西，需要什么样的后台背景。

   SQL Server存放有关的Setup参数，存放所有与测试有关的参数，存放所有Client机器的情况，是什么样的机器，多少内存，系统时间是什么，现在在干什么等等 ，所有机器的情况都存在这里；还存放所有Run Pass的总体结果，运行数，通过率，运行机器名等。。。。。

    Web服务器是Web前台，等于说是一个Web配置。测试团队使用后台服务器的入口，好处就是只需要IE就可以运行，零安装，易集中更新。可以查询并修改所有存放在SQL Server中的参数，可以产生、查询并触发Lab Run，可以查询Lab Run进展状况，总体结果等。 还可以查询并调整客户机的状态，所安装的OS，程序等。

    机器池是几十台一样或比较接近的轻型机器，拥有操作系统或文件系统的镜像程序，可以进行自我更新。

    控制器程序，从SQL Server中读取工作数据，产生工作脚本，并把工作按客户机参数分配给客户机运行，当运行结束时，从Client得到结果并更新SQL Server，分为机房控制器与个人控制器等。Lab controller主要用于控制Lab里的Machine Pool，Private controller主要用于控制Office里的测试团队成员个人的机器。控制器程序应具有动态分配任务的功能，控制器程序应具有Load Balance的功能，控制器程序应能根据Lab Run的优先级与机器资源最优化的分配工作。比如说你有一个自动测试，一个自动化测试每次在Run的时候并不是只有一个测试，同时进行的可能有三到四个同时进行，有的Lab Run会进展的很慢，有些优先级很高。动态分配的功能是非常重要的，根据你的Lab Run的优先级，决定给你分配多少资源进行运行，这是非常重要的系统。还需要多少时间也是一个比较重要的功能，如果你有以前的数据，比如上次Lab Run以后，就知道每一个测试需要Run多少时间，把总体时间加起来，可以看到在今天的构建上还剩下多少时间。

    客户机程序。这个程序是一个非常小，非常轻型的程序，是运行在各个小的Client上面的，几乎是零安装，就是一个小程序，非常轻巧，因为他几乎不依靠于任何模块，可在裸机上运行，在微软里所有的模块都可能是需要测试的模块，如果客户机上运行的程序需要ADO这个东西，我们就需要测试这个ADO。可以用于完成控制器交给的任务并记录全过程，非常稳定，不会死机，并能截取大部分的异常情况。可以截屏，TimeOut，所有的系统都是在Lab自动运行的，全部是一些机器，没有人的。自动化运行系统很快，等于说一天24小时不停的进行。

    结果报告与分析程序，安装于测试团队成员的主机上。查询数据库并显示所要Run的状态，通过率，还需要时间等。进行简单的运行操控，如重新运行，指定主机运行等。最主要的是自动分析运行的结果文件，比较不同之处，列出改进与恶化的Test Case。刚才我讲的每天可能有成千成万的结果需要分析，成千成万的结果可能有很大一块早就已经分析过了，不想重新看这些结果，就要进行比较。各种各样的情况都能读出来，和存入的结果进行比较，得出新的需要分析的措施，你已经看过这些措施就不用管它了。这个程序分析完错误以后，可以输入失败错误的原因。提供结果文件的链接，Bug DataBase的链接，提供进一步分析结果的工具。记录Test Case失败的原因，并可直接输入与跟踪Bug号，当结果分析完毕，可记入为基准结果，以便于未来运行结果的比较。

    我们是怎样使用这一套系统的。首先一个测试经理得到一个测试的任务，比如说Windows 2000的任务，他可以把这个任务告诉一个人，这个人应该是测试团队的成员(LRF)担任，这个人干的活每次根据这些东西产生一些Run，要知道这个Run进入什么状态，是不是很成功等等，协助整个Run能够很平和的进行。这个人测试团队也不是有很多人愿意干这个活，大家就轮流干这个事情。LRF根据需求在Web UI用模板产生相应的Run，填入OS要求，语言要求，运行优先级，应完成时间等，把这些东西都输入进去。这个Run被控制器程序得到，得到以后就根据优先级，完成时间，可用机房机器数，合乎要求的机器数，测试总量等来分配任务。机房客户机得到任务，清理自己，安装要求的程序与模块，从文件服务器拷贝测试运行程序，执行测试并拷回结果。

    LRF通过Web UI跟踪Lab Run进展，检查有无重大问题，检查运行进展能否按时完成并作及时的调整，当Lab Run接近尾声，email测试团队验证各自结果。可以说测试者本身一般不会监测Lab Run进行。测试团队成员收到email打开我们刚才讲的结果报告与分析程序，最主要是新的错误，新的错误比如说是Bug，产生一个很小的Code，重现这个错误。

    测试程序的问题，测试程序本身Code上的问题，你要修改你的测试程序等等。如果是对于客户机安装的问题，一天整个系统每台不同的机器都是一个问题，比如今天XP统统都通过了，比较简单。最后测试经理对所有的结果汇总，也是在结果报告程序进行的，大家把成果分析完以后，测试经理自动产生一张总报表，会通过这个数据决定我们这个产品怎么办，不光是在最后汇总的时候用。

    做一个很快的回顾，对于一套测试自动化系统来说，对一个成熟的测试团队来说是非常重要的东西。如果一个测试团队如果没有一个完整的测试系统来说，没有办法进行一个测试。一个新开发的测试自动化系统，尽量通用化。我们的测试系统，什么都能做，可以看他系统设计的模块，并不是为了测试什么东西而设计，可以测试任何东西，所以Office这么大一个产品，里面任何东西都是在测试系统上测试，测试系统需求非常简单。对自动化测试本身来说，是非常简单的一个东西，什么都不知道，只知道产生一个结果，运行结果拷回去就完了。还有一些控制，控制我刚才讲的动态分配资源的问题。如果你要是机器数不够，这就是自动化测试控制，但是要测试什么东西，完全是由测试人员自己决定，所有自动的脚本都是自己编的，你就是存到文件服务器上就行了。每个测试自动化系统每一板块各有侧重，不必大而全。从测试自动化系统整个来说，一开始的前期投入可能大一些，大家可以看到，你要建立整套测试自动化系统，每个系统想方设法自动化、模块化，刚开始投入非常多，长远来说是很有利的。如果手工测试的话，后台那么多不同的应用程序，有各种不同XP的情况，不同语言的情况下，如果都用手工来做几乎不可以想象。如果有测试自动化系统，只要开发一次自动化以后，所有其他的机器都是自动运行的，不用再管他了。所以他对鼓舞整个团队的士气是非常重要的。一个测试者一天的工作，对测试结果来说非常简单，只要看一下每天的新的情况就完了，其他的事情都不用管。自动化测试对后期软件维护来说也是非常重要的。自动测试系统是什么都能测试，不管干什么都可以测试，针对你产品所有的测试自动化起来，如果只有一个版本可能是不行的，微软所有的产品Office已经有十二个版本了，这么多的版本程序来说，如果没有自动测试是难以想象的。如果有自动测试就可以同步测试使用，这样就可以达到事半功倍的效果，很快可以验证，可以避免重复劳动。自动测试定义软件系统，如果一个软件系统没有自动测试的话，后期维护，下一版本的发行都是难以想象的一件事情。

目前对我们来说实现这种自动化根本根本就不 可能，虽然感觉很 爽

但是现在看来国内用测试工具的公司扔是少之甚少呀。

微软的自动化测试水平能到这个地步也应该是多年积累的结果，所以搞自动化测试还是应该早考虑、多积累呀。

中国也是有我们自己的测试工具　常州夏娃软件公司就开发了一个　
叫Ｐanorama  不过好象很难　也不是共享软件　

panorama应该是国外的产品

这个工具是一个外籍华人搞出来的。早先的版本我用过，难用的很，不过据说当时技术上还是领先的。现在嘛，听说在准备出新版本了。

我对这工具也知道一二，的确不是很好上手，建议初学者不要用他

真的吗???

要一步一步慢慢引入自动化测试, 然后一步一步慢慢建立自动化测试的流程,和方法使用的工具. 最后再一步一步的完善自动化测试的一些避端,把它充分的运用到测试的过程中.

注:自动化测试对于回归测试还是可以考虑的一种方法.