基于ZStack设计一个较为简单的自动化测试系统

本文首发于泊浮目的专栏： https://segmentfault.com/blog...

背景

在笔者目前的项目中，大部分业务跑在基于kvm的vm上。鉴于对项目质量的追求及尽量节省人力资源的目的，着手调研高测试覆盖率的解决方案。

因为项目基于ZStack，因此架构与其较为类似，但在vm上添加了相应的agent，经过其来控制vm中的操做系统与软件。

众所周知，ZStack管理节点部分有一套较为完善的自动化测试框架，能够知足大多数场景。而Utility并不是如此，只能经过黑盒测试来保证其质量，且许多测试场景须要start up一个真实的ZStack的环境，测试成本较高。

若是一部分测试能够设计在agent端，也就说是agent端的测试能够自举。这样就能够少设计一部分黑盒测试实例，下降潜在成本。

从业务看测试

从vm agent的业务逻辑来看，大多数业务都是修改DB配置、读DB配置，start, stop DB等。而为了case之间不受到影响，咱们在跑完测试以后，须要重置当前的测试环境。

方案选择

Docker

放弃。其无状态的特性简直完美契合上述需求。可是docker里只能跑单进程，对于oracle相关的业务，可能没法知足。且部分版本oracle对Docker的镜像支持上可能有问题。

在docker中能够经过一些hack的手段去作到在一个容器中起多进程，好比systemd或supervisord。可是笔者对docker并非很是的了解，因此没有继续研究下去。

Pouch

放弃。阿里自研的富容器技术，能够完美解决docker里单进程的问题——其实本质上也是在容器镜像起来时运行了一个init进程指定为1号进程，而不是像docker里在命令行中指定的进程。

在实践过程当中发现有各类莫名其妙的报错，且相关文档不齐全。

VM By ZStack

目前的方案。经过ZStack来管理环境vm的生命周期，经过快照机制来还原环境。缺点也很是的明显，仅仅一个case生命周期就须要1min+，生命周期大体以下：

• 使用vm跑测试
• 中止vm
• 恢复快照
• 启动vm

让人感到舒服的是，ZStack提供了一套Java SDK，能够直接经过SDK完成上述操做。

基于ZStack的自动化测试

对接ZStack根本没有什么困难之处。更多的是要从成本这个点去考虑整个测试系统的设计。

这里的成本则又能够分为两种成本：

• 物理资源成本：产品线上目前可以投入进测试的host较少，故在资源稀缺的状况下，得尽可能用较少的vm去完成这件事。
• 时间成本：一个开发人员跑测试的时间越短越好，而不是花大量时间去等待测试环境准备、清理等。举个列子，若是我搭建一个mysql 主备库，须要两台vm，若是串行去完成生命周期相关的操做，那么就是2min+；若是并行的去作，即是1min+。同理，若是这些测试可以尽可能并行的去跑，则能够省下更多的时间。

角色

角色示意图以下：

TestCase

一个测试实例，含有测试代码。同时它会向ResourcePool申请所需的vm。

TestGroup

根据当前的策略组织TestCase去并行的跑这些Case。在这里能够控制并发粒度，最后将会提交给Junit的跑测试。

JUnitCore.runClasses(new ParallelComputer(true, true)
                    , testGroup.toArray(arrayTestGroup));

ResourcePool

资源池的概念其实有点像云。好比组内有4个开发，那么4个开发几乎是不可能同时跑测试的，同时有2个开发在跑测试也是小几率事件。与其每一个人都申请几台测试vm放在那边（一天可能就跑一、2小时的测试），还不如你们都共享一个池内的vm，避免资源的浪费。就像公有云卖你1core512m，你去架个网站，可是它料到你用不了这么多，因此它就会超分超卖。

这个类会根据配置文件或者网络请求存入相应测试用的vm，并记录这些vm是否被使用，为了防止其余开发者一块儿跑测试的时候共用同一台vm，会给使用中的vm打上一个user tag，避免冲撞。另外，SessionId等常量也是从这里刷新而来。

小结

经过本文，向你们介绍了一下笔者目前在项目中设计的一个基于ZStack的自动化测试系统。基于各方各面的成本限制，故此设计的较为简单。若是后续有些较大的改动或显著的改进，笔者还会与你们继续分享。若是你们对于这方面的自动化测试有较好的实践或者建议，也欢迎在留言中一块儿交流学习。**