原创：张少华

背景

随着自动化测试用例的增长，模块持续集成中的验证环节时间也随之增长。如果使用单台机器，可能需要几个小时的时间才能完成一次所有用例的运行。这里我们能想到的最直接的方法，就是增加机器资源，并行运行测试用例。我们首先使用的方法是，在jenkins中将运行时间长的模块的功能测试job，拆分为多个可并行执行的job。但即使我们封装了许多jenkins相关的操作方法，可以使用脚本快速生成一系列job，但是依然存在以下问题：

增减机器成本太高，需调整整个jenkins的任务。

并行job运行时间不固定，瓶颈为最慢的job运行的时间。

稳定性问题，并行执行机器任何一台出现问题，都会影响整体任务。

建设目标

为了解决上面的问题，当时我们期望的测试系统有以下要求：

稳定性高，比如某个机器出现问题不会影响整体任务：稳定是重中之重。

分布式执行，同一job的多台机器可并行执行，同时，多个模块之间也可以并行执行测试任务：充分利用机器资源，提升自动化测试效率。

配置方便，机器资源池维护简单：可以节省维护的人力，将时间用于更有意义的事情上。

结果报告清晰，排查问题方便：错误case日志、环境等信息及时保存。

我们并没有使用一些开源的分布式框架，因为我们的需求相对来说比较简单，而且有一些定制化的需求，同时希望之后测试同学们可以在此之上做二次开发，所以最终我们决定自己实现这一系统。

具体实现

总体设计

整个系统主要分为三个角色模块：客户端、控制中心（Master）及worker端，其中client端在。

对于一个Jenkins job触发的分布式任务，主要步骤有：

Jenkins job调用客户端发送请求到控制中心，传递job相关信息，请求创建任务。

控制中心（Master）根据请求信息创建任务，筛选case创建task列表（每一个case对应一个task，可分布式执行），分配worker。

Jenkins客户端请求控制中心查询任务状态接口，打印当前状态。

Worker端请求控制中心获取可执行的命令，做出相应的拉取代码、准备环境、执行单个case task、清理环境等命令。

所有task执行完后，jenkins客户端获取任务结果，退出任务。

详细的交互过程如下如所示：

如何实现并行执行？

由于我们的case在单台机器上不能并行执行，所以我们所说的并行是指多台机器同时执行case；在创建任务的时候，会筛选出所需执行的case，每个case将会对应创建一个task并加入task队列；worker请求命令时，会从task队列中挑选合适的task进行分配（case的运行时间长的优先级高，避免出现最后等待case运行结束时间长的情况发生）。

控制中心（Master）

控制中心包括server和后台数据两部分，后台数据库存储job信息、case信息、worker信息（资源池）、result信息、配置信息等。Server提供接口供客户端及worker端访问，分步执行的控制逻辑都在控制中心实现。

由于控制中心没有页面，所以控制中心提供了一系列接口供其他模块使用：

客户端

客户端，即jenkins job中运行的脚本，每一个jenkins job对应着一个分布式的任务。

首先需要创建任务，请求/job/create接口的时候，我们会把从jenkins job的环境变量中获取的一些信息发送给Master，如jenkins job的名称，BUILD_NUM，以及最为重要的模块信息及代码仓库、分支信息。

然后，会使用/job/status循环查询任务的状态，实时打印在控制台输出里。

最后，根据任务运行状况返回结果。

worker端

worker端，即实际case运行所在的机器，每个worker都是独立的，互不影响。通过控制中心接口不停询问自己应该执行什么操作。

首先在worker端我们添加了一个系统服务，守护进程持续执行中。

然后，worker在空闲状态的时候，会根据接口/worker_get_command循环请求控制中心，如果有命令的话，就会去执行，执行完后，将执行产生的结果、日志文件上传到日志平台；同时调用/result_update接口，把命令的运行结果传递到控制中心。

收益与问题

系统上线后，完美取代了我们之前手动jenkins分组执行自动化测试的方法，首先从服务的健壮性性及正确性来说，很少会出现因为测试环境或是工具出问题而影响整个测试任务的情况，让开发和测试同学将精力聚焦于case反映出的业务代码问题上；其次，配置简单，大大节省了维护时间；最后，由于worker资源池扩充方便，大大发挥了并行的作用，使整个测试任务效率有了很大的提升。

当然，还是存在着进一步优化的空间，比如现在的机器资源是在创建任务时分配好的，可以优化为在整个任务过程中动态调整，充分利用机器资源等。