51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3853|回复: 0
打印 上一主题 下一主题

[原创] 精彩课程-软件测试自动化实践

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2004-10-18 15:13:37 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
精彩课程-软件测试自动化实践  


讲师:袁华松


    首先为什么需要软件测试自动化?通过我这几年在微软的工作,可以感觉到一点,应该说自动测试,可以定义软件系统。从理论上来说应该是功能定义软件系统,软件系统是怎么工作的是从功能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已经有十二个版本了,这么多的版本程序来说,如果没有自动测试是难以想象的。如果有自动测试就可以同步测试使用,这样就可以达到事半功倍的效果,很快可以验证,可以避免重复劳动。自动测试定义软件系统,如果一个软件系统没有自动测试的话,后期维护,下一版本的发行都是难以想象的一件事情。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-25 22:54 , Processed in 0.067664 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表