集群式自动化测试框架（平台）设计与实现

【 用逻辑脚本和指令控制各个服务器、服务器上的程序和脚本7*24小时自动、并行、有序地工作，无人值守，本地资源代码一“丢”，报告和邮件会及时自动来找你汇报，接受检查。应用如自动化测试、自动部署维护等。】

工程主页：http://code.google.com/p/ecstool-platform/

本文全文：http://ecstool-platform.googlecode.com/files/%E9%9B%86%E7%BE%A4%E5%BC%8F%E8%87%AA%E5%8A%A8%E5%8C%96%E6%B5%8B%E8%AF%95%E6%A1%86%E6%9E%B6%28%E5%B9%B3%E5%8F%B0%29%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%AE%9E%E7%8E%B0V1.1.doc

摘要：
（1）以windows为中控，既支持Windows又支持Linux，底层基于TCP/IP socket和SSH。既能作为服务器接受N个客户端的连接，又能作为客户端继续连接N个服务器（线程池、异步通信、数据包队列，N>100） 
（2）支持公网、私网及复合网络（在家访问公司内网？VPN？通信数据安全加密？--支持） 
（3）仅在工作机可以操作集群中任意IP节点（包括纵向、横向扩展跨越多个中控机集群，类似自定义路由路经） 
（4）通过中控机控制（只需添加一个定时任务、无需每台添加）；定制自动化脚本控制逻辑（同步并发式工作调度：同时向千台服务器文件分发、启停控制与检查、命令分发、……） 
（5）动态插件dll扩展和常用工具exe集成，继承基类编写dll可调用系统API，命令组合实现各种功能或实现自定义功能； 
（6）全部操作基于命令引擎接口，并可不断扩展：dos、shell、文件上传下载、连接、断开、WinAPI、执行脚本、定时任务、邮件服务、查看文本、…… 
（7）入围2012阿里云开发者大赛50强43号作品。功能近似STAF，增强安全和性能，支持Windows、Linux平台；支持公网、私网复合网络；本地及远程命令引擎；文件批量发送下载；自动化脚本任务定制；动态插件扩展；工具平台集成；可作为自动化框架应用于服务器群的自动化管理维护和测试等。 

集群式自动化测试框架（平台）设计与实现

目录

一、 背景概述

1. 现有特点 

2. 分析挖掘 

3. 突破启发 

二、 框架设计概述

三、 完成效果

（一）内容 

（二）简要说明 

（三）模块操作说明 

四、 命令执行引擎帮助手册 ExecCommand(string)

（一）命令格式 

（二）分类举例 

五、 应用于全自动化测试体系的应用实现实例（基于SVN跨平台敏捷项目）

1．期望实现效果 

2. 全局变量和公共函数 

3. 版本检查和编译实现函数 

4. 启动执行测试函数 

5. 测试完成发送邮件和结果链接函数 

6. 逻辑流程串联 

7. 测试结果效果 

六、 其他简单例子

1. 修改远程Windows和Linux服务器配置文件 

2. 操作远程Windows服务器的计算器 

 

 

一、背景概述

1. 现有特点

A公司的网络环境是一个比较典型的国内互联网企业结构，如图所示：

 

2. 分析挖掘

假设该公司的项目产品及其服务器集群有如下基本特点

3.  突破启发

要满足这些特点和要求，要是能设计开发出这么一个产品就好了：能将所有服务器通过自定义方式连接起来（即作为一个或几个集群），只在某一个节点就能够方便地对集群中每一个节点作尽可能多的操作。功能有点类似STAF，并增强其安全和性能，支持Windows、Linux平台；支持公网、私网复合网络；本地及远程命令引擎；文件批量发送下载；自动化脚本任务定制；动态插件扩展；工具平台集成；可作为自动化框架应用于服务器群的自动化管理维护和自动化测试等。参照下图所示：

二.  设计概述

（1） 网络共享通信少不了，考虑到易用性，Windows平台网络通信方面做成STAF模式：对等式（对用户而言不论客户机还是服务机就一个安装包，显式不区分Client与Server，当然内部Client与Server实现模块均集成）。考虑到是多服务机，也可能是多客户机，即多对多，需要较好的处理性能（当然性能要求也不是特别严格，不需要支持海量在线），那么Client与Server均采用异步通信模式、线程池处理包队列。

 

（2） 既然对象是针对服务器，肯定少不了Linux，所以Windows、Linux平台均需要支持。Windows采用网络编程，Linux通过SSH协议通信，这样成本比较小、容易实现。Linux操作一样采用线程池处理包队列。

 

（3） Linux Shell命令是Linux服务器操作的主要方式，通过SSH通道都能实现，Windows的Dos命令同样得实现支持，这样命令式操作服务器就没问题了。可是需要调用执行shell脚本文件、bat脚本文件或者其他程序、其他脚本呢？还有文件操作、文件传输？如果要实现一些复杂的批量任务，比如自动更新服务器程序、自动安装部署、服务器管理维护等，这些统统都是需要实现的基本功能，每个基本功能都实现命令式调用接口，形成一个内部命令执行引擎。

 

（4） 接上一点，单机既然能够实现一些复杂的批量任务了，那么这单机的逐个任务的一些先后顺序和逻辑条件，谁来控制？还有是多服务器，各个服务机（Windows和Linux）之间若存在相关先后顺序和逻辑条件，谁来控制？那么就必须支持动态语言了，嵌入一种或几种脚本解析器，使用脚本语言来控制这些逻辑是比较明智的，而且能达到不同程度的自动化效果。（自动化程度取决于框架功能和脚本的结合，脚本实现不了的特定功能需要不断丰富并开放接口给脚本内调用。）

 

（5） 安全方面：STAF都有信任等级区分，所以并不是所有机器安装有程序就能互连操作，还是需要自定义一个校验值（token），校验错误的连接不上，校验正确方可互连操作。请求方（客户机）加密存储，被请求方（服务机）明文配置（便于查看）。除了文件流，网络通信包均加密传输，即使被抓包工具截获也无法获取信息。Windows可以自设token，Linux的登录用户名和密码就视作为token。

 

（6） 平台化扩展考虑（设计模式应用）：Eclipse和Staf都能提供API支持插件或服务开发，那么仿照此功能，能够开放一些API作为二次插件开发，就可以不断累积集成一个平台，集思广益实现各种各样的内部功能。一些常用单机程序（Windows）扔进目录，可在界面中显示和点击实现外部调用，也算一个桌面工具条式平台。

 

（7） 网络支持：局域网、ADSL拨号网络、公网等网络进行网络通信和文件传输时需区别对待，区分局域网IP（私网）、对外公网IP、网络出口IP等，局域网内不通过公网直接通信效率更高，ADSL家庭办公就只能通过出口IP和公网IP连接了（延伸VPN等原理）。对用户而言，通过什么网络路径连接都是没有区别的，能够并存，除了速度外操作没有差异。

 

（8） 基本的美观性易用性考虑，Windows、Linux服务器操作界面一样，各种操作对用户而言差异化最小。