文：泽木 本文原创，转载请注明作者及出处
背景
普通的自动测试执行一般是单进程来执行测试用例集，例如接口测试用例集多到几百个时候，执行时间会到 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：在运行前需要初始化的环境变量 (参数的格式需要是字典格式)
Master 支持的参数
- hj-nose-parameters：运行、上传及发送相关的命令参数传递给各 Runner
- run-parameters：在运行前需要初始化的环境变量并传递给各 Runner
- tests：指定执行的用例运行目录或文件，多个以”,”隔开
- local-runners: 并发数量 相对于 nose 插件多了指定的测试集和并发数量
Runner 如何收集用例结果并同步给 Master
在 nose 的插件中有用例成功、失败或错误的方法，通过重写这些方法收集结果并同步给 Master。收集的信息有：
- 用例名
- 用例的文件相对路径名
- 结果
- 详细步骤的 Log
- Exception 的消息
收集到的信息通过 Client 的 sendData 方法同步到 Master上
所有用例运行完之后，会进入 report 方法，这里会把所有请求的 Log 及结束的信息发送给 Master
Master 并发执行
1.生成 nosetests 命令
首先在执行的 nosetests 命令中加入 hj-nose-parameters 和 run-parameters 的参数，然后设置好并发数，Master 会根据当前并发数的设置启动多个进程的任务，并以用例文件为单位，给每个任务分配一个用例文件
2.用例集在多任务中的分配机制：
当收到任务执行完成以后，当前的 Runner 会收集结果数据，接着起动新的任务并执行（任务列表中还未执行到的任务）
测试执行结果归档、邮件报告及微信报警输出功能详解
- 用例的结果日志会归档到 DB 中，最终可以通过 QAClub 平台页面来查看历史执行的结果 测试的 HTML 结果文件通过 ftp 上传到 Log Server，在 QAClub 平台以及执行结果邮件中可 以通过邮件发送测试执行结果
- 如果有执行失败的测试用例，可以通过 微信-沪江人-运维监控报警 的方式通知到相关人员(相关人员列表可以通过 QAClub 平台页面来设置)
- 如果有执行失败的测试用例，可以自动在 Jira 中提交 Bug 并 assign 给 QAClub中配置的人员
总结
hjRunner 是一款基于 nose 框架的二次开发的插件，目前除了支持多并发任务，提高提供执行效率，还有这可扩展的优点，在日后的工作中会扩展出更多使大家工作更轻松更便捷更高效的功能，欢迎大家提出宝贵的意见及想法。
来源：本文转自沪江技术。
还不过瘾？还想了解更多 DevOps 精彩玩法？还有更多企业如何落地 DevOps 的？
4月21-22日，GOPS 全球运维大会 2022 · 深圳站，BATJ、金融、通信领域 DevOps 议题来袭~，关注 GOPS，运维转型不背锅~
近期好文：
新鲜出炉！DevOps 能力成熟度模型持续交付第十七批及系统和工具第四批评估结果公布
“DevOps时代”公众号诚邀广大技术人员投稿，
投稿邮箱：jiachen@greatops.net，或添加联系人微信：greatops1118.
点个“在看”，少个“bug”
