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、从分布式测试执行过渡到云测试服务。
