目标:自动化测试框架(一键QA)
解决方案:
1. 框架的可配置
框架本身需要一个可配置文件。这个文件可以以任何形式存在,如key-value的键-属性,或者是xmlfile,都可以。配置文件仅包含必须配置的属性,比如服务器ip,工作目录,需要跑哪类测试等,不需要太大,已简单易配为主。每次跑测试者只需要配置好这个文件,其他的都不用care,让自动化框架搞定一切。
2. 需要一台机器做总控
这台机器我们称为client,是测试的大本营。也是我们的工作目录。
3. 我们需要测试的程序所运行的机器
就是server。
4. client到server的ssh无验证连接
这一步非常重要,因为要通过client去控制,监测server上发生的一些事情,只能通过ssh后跟命令去做。所以必须去除client和server之间的密码验证。
5. 自动部署。
在做了第四步之后,我们需要在开始时,将框架本身里,需要在server上跑的各个组件scp到各台server的对应工作目录里。server的ip以及工作目录都由框架的属性文件指定。
6. 一个由脚本实现的,简单的用于收发自己命令的客户端服务器程序。
我们可以称之为哨兵。哨兵位于各个server上,另外我们需要一个教官。教官位于我们的客户端上。
哨兵和教官之间通过我们自己定义的协议进行通信,哨兵负责控制记忆检测server,教官负责接收client上的命令,再将命令转发给哨兵。
这套机制可以说是整个自动化测试框架的核心。对于远程server上发生的一切,如果client仅仅通过ssh命令进行控制,那达到的功能会是有限的,而且实现起来不方便也很丑陋。添加功能也很方便,通过增加哨兵的协议和更多函数功能就可以了。
7. 一个稳定的lib库
所有的测试用例都需要公用的一套库,必须稳定,库的内容包括一些封装过的,我们需要测试的应用程序所支持的所有功能,它们的发送/接收函数,server的控制函数(启动,关闭,重启,格式化,等等)对于远程server的操作,监控,则可以通过向教官发送指定命令实现。
8. 测试用例
所有的testcase是核心,testcase应该做到即插即用,即需要增加新的test时,只要将新case加到文件夹里,testcase跟框架唯一的耦合处就是它们使用了lib,testcase中不允许使用任何的硬编码,一切参数通过外部传入。testcase应该做到,可以由自动化框架调用,也可以让人来手工跑。
9. 一个环境配置确认脚本
这个脚本查看本地和远端的软/硬件情况。比如对方的网卡设置是否正确,mount的设备是否正确,可执行文件是否在正确位置,版本是否是我们需要的等等。遇到任何问题,及时返回错误,报告情况并中断整个框架执行直到有人来将环境配置正确。