自动化测试的思考和总结之平台利器篇
2,533 Views『作者：RickyZhu 转载务必注明出处和作者』
Tag:automation
上周休了一周的假, 在医院照顾老爸
这周继续自动化测试的思考系列,今天谈谈平台建设.
自动化测试一般来说,随着产品的不同,都会有不同的测试架构和测试平台,稳定和合适的平台对于一个产品的自动化测试来说,相对来说相当重要,有了合适的载体和工具,自动化测试就能很好的扩容和执行.
一般来说,自动化测试的平台包含以下一些方面:
测试管理部分–管理不同产品,不同版本的测试用例
测试执行部分–执行测试用例
测试维护部分–测试用例的维护,版本控制等
测试资源部分–测试资源特别是实验室资源的管理
测试调度部分–测试的调度,控制和执行中心
一 般来说,这几个部分可以集成于一个平台本身,也可是独立的子系统,通过接口有机的结合起来,其实市场上也有很多商用的产品,比如Mercury的QC (Quality Center, Test Director的后续版本)就覆盖了其中的测试管理,测试执行等, Rational的Test Manager覆盖了另外一些部分等等.
因为这些商业工具相对来说,价格比较昂贵,而且对具体产品的适应能力等方面的考虑,不一定适合所有的公司,因此我们自己开发了自己的相应的系统.
测 试执行平台:我们的测试执行平台其实覆盖了测试执行部分,测试维护部分和测试调度部分,是一个很强大的平台,从最初的1.0版本,到现在的2.1.1版 本,基本可以支持我们公司的绝大多数的产品,另外测试管理的部分也有一些涉及,但是相对来说比较薄弱,特别是版本管理部分,目前是通过和测试管理工具的接 口来实现的,我们正在改进这些薄弱的环节.
测试资源平台:我们也有一个自己开发的资源管理平台,可以预定实验室的各项资源,并用于测试,目前我们在测试执行平台预留了资源的相关接口.这部分跟具体的产品联系比较密切.
总体来说,下面这个图能详细说明这些部分之间的一个关系和接口.
下图是我们自己的测试执行平台的架构:
其中
ATS: automated testing system
LRMS: lab resource management system
TMS: test management system
(转载请注明出处)
重要的不再技术，而是理念
三层结构-》产品无关的一个自动化测试架构
其实分为两个部分，第一是web，也就是用户层，GUI
第二个是后台的引擎，自动化执行引擎
第一个是java写的，第二个是tcl写的
支持后台程序，主要是通讯程序的自动化，这部分是最重要的一块
支持web，主要是集成进来了QTP和WR，并提供了一个独立的QTP框架，web和java的界面都支持
支持性能测试，集成进来了LR，提供了独立了LR架构，满足不同产品的性能测试
先说后台程序，用tcl封装了不同的原子操作，比如数据库基本操作，字符操作，时间操作，文件操作等等，用户写case直接用这些API即可
这些API，都在web页面可见，并支持拖拽，拼装成 test case
这些test case，都是以自定义的格式保存在oracle数据库中
需要执行的时候，就是通过执行引擎吊起来，自动化的进行执行，并提供日志和报表
并从LR，QTP，WR的执行结果取回需要的数据，统一占线在web gui的界面
其实后台执行执行，是有一个复杂的状态机来完成的
case执行中途出错，暂停，恢复，告警，启动，停止，完成等很多状态，全部都是通过状态机来控制
对qtp的封装分三层
basic API, service API and business API
三层的结构分工明确，而且保证了界面变化之后，代码维护量最小
读前辈的文章,非常过瘾啊!这些都是精品文章,不知何时我也能写出这等文章.呵呵…
支持一下!!!