摘要: 1 相关说明 1.1 背景简介 随着一个产品的自动化工作不断深入，自动化的case积累数量持续增长，绝大部分毫无依赖关系的case由于串行运行，测试执行时间达到小时界别，且不易于优化。另外，ci运行时所需机器 ...
2.3 分布式运行逻辑 这里的逻辑主要是两块，一部分是本地部分，一部分是分布式节点机器部分。我们将分布式测试执行过程封装到一个hadoop job里。 本地部分： 1、获取计算资源。这里的计算资源指可用的tasktracker的槽位数，这个槽位是case切分的分母。 2、根据计算资源生成case列表。有了槽位数，最简单的切分算法就是：每节点case数=总case数/槽位数。 3、业务层自定义操作。例如业务层测试执行时需要的程序或者配置获取，依赖的大数据推送到hdfs等。 4、配置hadoop的job。包括input，output，执行job所需的文件或者tar包等。这里的input就是case列表。 5、执行测试执行job。这个实际是个hadoop job。 6、发送报告。汇总每个节点的运行结果，并发出报告。 每个tasktracker的map任务输入是切分后的case列表，通过这种方式将整个测试执行部分分发到每个tasktracker上。 节点部分： 1、准备case列表。从map的input获取。 2、根据case列表下载case。，这里类似于本地单机版的case获取，来源仍然是SVN或者CASE库。 3、安装lib库。同本地单机版。 4、安装测试环境。同本地单机版。 5、执行case。同本地单机版。 6、推送报告。 这里hadoop还会根据每个map任务的返回值，来进行重试运行的调度。 从以上的描述可以看到，在hadoop集群节点机器上(tasktracker)，测试执行的逻辑和单机版基本无差别，所以整个改造的过程也是比较简单的 2.4 分布式测试集群架构设计 整个分布式测试执行依托于一个公共的计算集群，这个计算集群由两部分组成，一部分是hadoop相关的，包括hadoop的总控，子节点的tasktracker服务。另外一部分就是公共环境，包括测试框架，公共工具例如valgrind等。前者通过jobtracker来管理，后者通过统一运维系统来管理，其功能基本就是公共环境的安装和维护。 3 收益 经过我们的实际项目实践，这部分的收益主要体现在如下两点： 1、测试执行时间大幅优化。15台机器的情况，所有原测试执行时间要1-2小时的模块，优化到10分钟以内。 2、机器资源的节省。通过公共集群的维护，保证所有机器cpu满负荷运作，避免了以往单机测试执行的cpu浪费。 4 准入原则及发展方向 4.1 分布式改造的准入原则 并不是所有的测试执行都可以分布式化，在我们的实际操作过程中，总结出以下几点准入原则，供参考： 1、空白机器可运行。通过一个总控脚本就可以做到依赖环境准备，lib库安装，测试case执行等。 2、测试框架允许case并行。 3、业务层case对外部不存在固定依赖，例如依赖于某个写死的目录。 4、业务层case依赖的server端口，最好是随机的。 5、不允许业务层去操作公共环境。 4.2 后续可能的技术方向 1、case按照执行时间切分。按照时间切分来替代按照case数切分。 2、从分布式测试执行过渡到云测试服务。 |
