背景
普通的自动测试执行一般是单进程来执行测试用例集，例如接口测试用例集多到几百个时候，执行时间会到 10 分钟以上。在正常回归测试中，这个时间是可以接受的，但在自动发布流程中进行的自动化测试，需要很快地给出测试结果，这种情况下就不能满足，那有什么方法能加快执行效率呢？
思路的演进
当前我们使用的自动化框架是 Python + nosetests，而官方提供的是单进程的运行机制。
使用官方单进程的机制执行的自动化测试，594 个用例执行时间是 11 分钟
这个时间对于一般的回归测试来说是可以接受的，但在快速发布流程中，长时间的运行会使整个流程变得很慢，效率比较低，那怎么样来提升执行效率呢？目前我们看到是单任务模式，那多任务模式是否能够减少时间呢，下面我们尝试使用并发任务的方式来执行。
如下的结构图，一个用例集我们可以分配到多个 Runner 去执行。
再回到刚才 594 个用例，我们采用 8 个 Runner 去执行，看看执行时间可以缩短到 2分 25 秒 。
NOTE：单进程的 Python 只能占用一核的 CPU，并发数可以根据机器的核数 *2 设定。理论上来讲多少个并发数可以提升多少倍的速度，但实际情况并不是这样的，这个会基于每个用例集文件的执行时间，如果想要达到最好的效率提升，测试集需要尽量小，并且执行时长比较接近，以避免其中有个别执行时间非常长的测试集所导致的进程等待。
功能介绍
Master 是整个自动化用例集运行的中枢，主要有以下职责：
●分配测试任务并启动 Runner
●收集 Runner 的结果
●合并测试结果，并生成总报告
●上传结果文件及相关截图到日志服务器
●发出结果邮件
●发出微信报警
●提交 Bug 到 Jira 中
●失败用例的重跑
Runner 作为自动化的执行者，主要职责如下：
●以单个用例文件为一个执行单位
●同步每个用例的结果到 Master
●执行结束后同步所有用例的请求 Log 到 Master
使用情况
目前该工具用于沪江每天自动化监控任务 25850 次和 649 次的回归和巡检的运行，并且已经开始逐步被接入到发布流程中，后期将在 Devops 的自动化测试中作为运行中枢，发挥重要作用。
Master 与 Runner 之间的通信原理
这里采用了 pyzmq 中的问答模式
Master 启动 Server 来接收各 Runner 发来的消息
Runner 端调用 Client 来发送消息
发送消息采用了 5 次尝试机制及 5 秒超时，防止消息丢失，从而避免了造成 Server端收不到消息而 block 住的风险。
Master 与 Runner 的执行命令及参数传递
用例执行的命令基于 nosetests，对更多的参数及功能支持，我们采用了引入 nose plugin 的方式并起了一个好听的名字：hjRunner
hjRunner 支持的参数：
●hj-nose-parameters: 运行、上传及发送相关的命令参数(如下图所示) (参数的格式以字典的格式传递，这样易于扩展)
{ 'uploadResult' : True , 'runEnv' : 1 , 'reportCategory' : 0 , 'checkCasesDescription' : False , 'mailSend' : { 'sendMail' : False , 'showUrlInMail' : True }, 'wxAlarm' : False , 'submitBug' : True } |
●run-parameters： 在运行前需要初始化的环境变量 (参数的格式需要是字典格式)
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
