目录
不知道大家有没有遇到这样一种情况，实际工作中，app自动化测试的用例可能是成百上千条的，如果放在一台机器上跑，消耗的时间非常久，那**能不能使用分布式的来跑测试用例呢？**比如有1000条测试用例，给A机器分配500个，给B机器分配500个，同时去跑，这样耗时就大大减少。刚好pytest-xdist为我们提供了一种可能
什么是pytest-xdist？
pytest-xdist是一款分布式测试插件。它在pytest的基础上做了一些独有的测试执行模式的扩展。比如你有多个CPU或者多台机器，就可以使用它们做一些并行化的测试，并且它还是跨平台的，可以指定不同的python解释器或不同的平台来执行测试
使用pip命令可以简单快速的安装pytest-xdist
pip install pytest-xdist
01、分布式测试的原理
上面有提到pytest-xdist实现分布式的方式有两种：一种是使用多CPU，一种是使用多台机器。
一般来说对于web自动化测试，使用多核CPU来做分布式比较合适，但对于app自动化测试来说，使用多台机器做分布式比较合适。这里主要介绍后者
pytest-xdist是工作方式是一个master对应多个worker，每个worker会按照master的要求来执行各自的测试集。
基本的执行流程为：
-
master在测试会话开始的时候会产生一个或多个worker。master和worker之间使用execnet及其网关进行通信。worker可以是本地的，也可以是远程的
-
worker作为pytest的执行者。在收集完一套完整的测试集后，worker将收集到的测试id发送给不承担执行任务的master
-
master接收所有节点发送来的结果，同时也会做一些可用性的检查以确保所有的worker都收集到相同的测试集。如果一切正常，它会将测试id列表转换为简单索引列表，每个索引对应着它在原始测试集列表中的位置。这种方案的可行性在于可以节约带宽，由于所有的worker都有相同的测试集列表，所以master可以指派其中一个worker只执行测试索引为3的用例
pytest-xdist有两种模式，each模式和load模式
- each模式：
master会将所有的测试任务(这里的测试任务不是测试集，类似于测试指令，也就是上面说的测试索引）发送到每个worker上，每个worker都执行一遍完整的测试集。
举个例子，假如有1000条用例，分为A和B两个worker，那么A和B同时执行1000条用例
- load模式：
master会先将25%的测试任务以轮询的方式发送给每个worker，剩下的等到worker执行完后再做分发。同样，有1000条用例，有A和B两个worker，那么先给A分发250个用例，再给B分发250条用例，剩下的500条用例等A和B执行完后再做分发，有可能此时A服务器的压力比较小，那么给A再分260条，B的压力比较大，给B再分240条。类似于负载均衡的概念
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036
02、测试项目
以百度贴吧app为例，可以写简单的4条用例来测试。第一条测试的是欢迎页的滑动功能。如果用户点了同意，后面滑屏，能够正常滑动，点击立即体验，能够正常跳转，说明用例是通过的
第二条测试的是欢迎页点击不同意，能够正常弹出提示，说明用例是通过的
第三条测试搜索，如果用户滑屏后，在主页搜索栏输入关键字，能够搜索到指定的内容，说明用例通过
最后一条测试登录，点击主页"我的"，能够进入到百度账号登录页面，说明用例通过
03、环境准备
在搭建环境上，我准备了三台虚拟机，其中一台作为master，剩下两台作为执行的worker。为了避免不必要的麻烦，三台机器都统一使用python3.8，两台worker上都使用docker安装appium1.17.0，客户端采用两台系统为v7.1.2的夜神模拟器。
具体信息如下表所示：
服务器环境
|---------|-----------|----------|---------------|
| 角色 | 系统 | python版本 | ip |
| master | Centos7.6 | v3.8.0 | 192.168.0.109 |
| worker1 | Centos7.6 | v3.8.0 | 192.168.0.126 |
| worker2 | Centos7.6 | v3.8.0 | 192.168.0.136 |
客户端环境
|---------|--------|---------------|-------|
| 测试机 | 系统 | ip | tcpip |
| 夜神模拟器-1 | v7.1.2 | 192.168.0.114 | 6666 |
| 夜神模拟器-2 | v7.1.2 | 192.168.0.106 | 6666 |
运行环境
|----------|---------|-------------|---------|
| 容器 | 版本 | 端口号 | 宿主机器 |
| appium_1 | v1.17.0 | 4725->4723 | worker1 |
| appium_2 | v1.17.0 | 4725->4723 | worker2 |
04、搭建步骤
1、在worker上创建并启动docker容器
在两台worker上执行同样的操作，可以启动一个名为appium的容器
看到这里或许会问，docker里的appium服务是怎么启动的，比较简单，代码可以通过命令行的方式启动appium服务
2、模拟器设置
通过桥接的方式，设置tcpip端口，使得远程服务器可以通过adb连接到模拟器。具体方法是点开右上角的设置，进入系统设置，属性设置，勾选开启网络桥接模式，这时候应该会装一个桥接网卡，然后可以自己设置静态IP。保存后重启就可以了
正常情况下，重启后ip应该会变成静态IP，但是夜神模拟器有个bug，ip还是随机ip，不过这一点不影响后续的操作
接下来设置tcpip端口，通过如下命令设置好后，如果看到有restarting in TCP mode port:6666说明已经设置完成
3、appium远程连接模拟器
在两台worker上分别执行远程连接命令，worker1对应模拟器1，worker2对应模拟器2。这里要主要adb connect 后面跟的是模拟器的实际ip地址加tcpip端口号6666，如果看到connected to ip:端口号，说明已经远程连接成功
4、上传代码
使用命令或工具将代码上传到master上的/opt目录下并解压
main.py是项目测试执行的入口，为了适应分布式执行，我们需要对main.py做一些修改
对最关键的几步做一个说明：
-
"-d"：
表示分布式参数
-
"--tx"后面跟着worker服务器的地址
且通过python=/opt/Python-3.8.0/bin/python3.8指定了python版本，通过chdir=/opt/pyexecnetcache指定了worker上同步测试集的目录，也就是master会将测试项目同步worker的该目录下
-
"--rsyncdir"后面跟"./"，
表示将master上当前目录下的所有文件都同步
-
"TieBa-AutoTest"：
因为同步过去的项目在pyexecnetcache目录下，实际上是/opt/pyexecnetcache/TieBa-AutoTest，如果不加该配置，就进入不到TieBa-AutoTest目录下，由于worker上的pytest执行时是找test_开头的测试用例，所以会找不到测试用例，可以将其理解为cd TieBa-AutoTest
05、分布式执行
在master上执行python3 main.py命令就可以做分布式运行，gw0和gw1分别表示worker1和worker2，[4]表示共有4条测试用例
此时去看worker的/opt目录下，已经同步到了测试项目
再去观察两台模拟器，发现已经开始同步执行了
06、测试报告
测试完成后，观察master上的执行结果信息，4条测试用例耗时不到3分钟，2条通过2条失败。
但是在master上通过allure serve生成预览报告后，发现报告是空的
两台worker上的报告预览展示正常，分别展示它们各自执行用例的报告信息
其原因是pytest-xdist对allure测试报告支持的不友好，各个worker的测试报告信息没有回传，使用pytest-html就没有这个问题。github上有人提出过这个问题。暂时留个"悬念"，下次再讲讲怎么解决这一问题
如果我的博客对你有帮助、如果你喜欢我的博客内容，请 "点赞" "评论" "收藏" 一键三连哦！