1. 单机串行跑Appium的瓶颈到底卡在哪如果你已经用pytestAppium写过一阵子UI自动化大概率经历过这个场景本地一条用例跑完切到下一台设备再跑一遍整个回归套件跑完要四十多分钟。设备越多等待越久因为默认情况下pytest是单进程串行执行的一台设备跑完才轮到下一台。这个模式在用例量少的时候还能忍一旦用例上百条、设备上到三五台时间成本就变得非常刺眼。我在实际项目里做过一次统计一套包含120条用例的Appium回归套件单设备串行跑完平均耗时38分钟。如果手上有4台真机理论上并行跑可以把时间压到10分钟左右但直接开4个终端手动跑又会遇到端口冲突、Appium Server互相抢占、日志混在一起分不清是哪台设备的问题。这就是多设备并发要解决的核心痛点——不是能不能跑而是怎么让多台设备同时跑且互不干扰。这里要先厘清一个概念多设备并发不等于多线程。很多人一上来就说用多线程跑Appium但真正落地时有两条路可以走。一条是用Python的threading或concurrent.futures在单个进程内开多个线程每个线程绑定一台设备和一个Appium Server端口另一条是用pytest-xdist做进程级并行每个worker进程负责一台设备。两者各有适用场景后面会详细对比。这篇文章面向的是已经能跑通单设备Appiumpytest、想进一步做多设备并发的同学。如果你还没搭好基础环境建议先把单设备的用例跑通再来看并发否则排查问题时变量太多会很痛苦。接下来我会从架构设计、端口分配、设备管理、用例隔离、踩坑排查几个维度把多设备并发这件事拆开讲透。2. 多设备并发的两种架构路线线程池 vs 进程池2.1 线程池方案轻量但要注意GIL和资源竞争线程池方案的核心思路是在一个Python进程里启动N个线程每个线程独立创建自己的webdriver.Remote连接指向不同端口的Appium Server。代码结构大概是这样import threading from appium import webdriver devices [ {udid: device1_udid, port: 4723, systemPort: 8200}, {udid: device2_udid, port: 4725, systemPort: 8201}, {udid: device3_udid, port: 4727, systemPort: 8202}, ] def run_device(device): caps { platformName: Android, udid: device[udid], systemPort: device[systemPort], appPackage: com.example.app, appActivity: .MainActivity, noReset: True, } driver webdriver.Remote(fhttp://127.0.0.1:{device[port]}/wd/hub, caps) try: # 执行测试逻辑 pass finally: driver.quit() threads [threading.Thread(targetrun_device, args(d,)) for d in devices] for t in threads: t.start() for t in threads: t.join()这个方案的好处是启动快、内存占用小、调试直观。但问题也很明显Python有GIL虽然Appium的通信是IO密集型网络请求等待占大头GIL在IO等待时会释放所以线程池跑Appium实际上是可行的。但如果你在用例里做了大量CPU计算比如图像比对、复杂断言GIL就会成为瓶颈。另一个坑是共享资源竞争。比如多个线程同时写同一个日志文件、同时操作同一个全局变量、同时读写同一个测试数据文件都会出问题。我踩过一次坑三个线程同时往一个Excel结果文件里写数据最后文件内容错乱行都对不上。后来改成每个线程写独立的临时文件最后合并才解决。2.2 进程池方案pytest-xdist的隔离优势pytest-xdist是pytest生态里做并行测试的标准方案它通过-n参数指定worker进程数每个worker是一个独立的Python进程天然隔离内存空间和全局状态。pytest -n 3 --distloadfile--distloadfile表示按文件粒度分配用例同一个文件里的用例会分到同一个worker避免同一台设备的用例被拆散。这个参数在多设备场景下很关键因为你需要保证一台设备对应一个worker而不是用例随机飘。进程池的优势是隔离彻底一个worker崩了不影响其他worker日志天然分开全局变量不共享。代价是启动开销大一些每个进程都要重新import模块、初始化driver内存占用也更高。另外进程间通信比线程间麻烦如果你需要汇总所有设备的结果得通过文件或消息队列来传递。2.3 怎么选看你的用例特征维度线程池进程池xdist隔离性弱共享内存强独立进程启动速度快慢内存占用低高调试难度低中适合场景用例轻、IO密集用例重、需要强隔离结果汇总直接共享变量需文件/队列我的建议是如果你的用例主要是UI操作和等待CPU计算少线程池够用且更轻如果你需要跑大量用例、要求稳定性高、不想处理共享状态直接上xdist。下面两节分别展开讲实操。3. 线程池落地的关键端口、设备与driver的绑定关系3.1 Appium Server端口规划不能随便拍脑袋每台设备需要一个独立的Appium Server实例每个实例监听不同端口。默认4723被占用后下一个用4725、4727这样隔开是因为Appium还会用到一些相邻端口做内部通信连续端口容易冲突。我一般按奇数递增分配BASE_PORT 4723 devices [] for i, udid in enumerate(udid_list): devices.append({ udid: udid, port: BASE_PORT i * 2, systemPort: 8200 i, })systemPort是Android设备上UiAutomator2的通信端口也必须每台设备不同否则会报port already in use。这个参数很多人第一次做并发时会漏掉导致第二台设备启动时直接失败。启动Appium Server可以用命令行也可以用Python的subprocessimport subprocess def start_appium(port): cmd fappium -p {port} --log-level error return subprocess.Popen(cmd, shellTrue, stdoutsubprocess.DEVNULL, stderrsubprocess.DEVNULL)注意启动Appium Server后要留几秒等它初始化完成直接连会报连接拒绝。我一般用time.sleep(3)或者轮询端口是否可连。3.2 设备发现与动态分配硬编码设备列表在设备固定的场景下没问题但如果你的设备池是动态的比如CI环境里设备可能增减就需要用adb devices动态获取import subprocess def get_connected_devices(): result subprocess.run([adb, devices], capture_outputTrue, textTrue) lines result.stdout.strip().split(\n)[1:] return [line.split(\t)[0] for line in lines if \tdevice in line]拿到设备列表后按数量启动对应数量的Appium Server和线程。这里有个细节设备状态要确认是device而不是offline或unauthorized否则连上去也是白连。3.3 driver生命周期管理每个线程里的driver必须在该线程内创建和销毁不能跨线程共享。我见过有人为了省事在主线程创建好driver传给子线程用结果各种诡异报错。Appium的driver不是线程安全的必须一线程一driver。def run_device(device): driver None try: driver webdriver.Remote( fhttp://127.0.0.1:{device[port]}/wd/hub, build_caps(device) ) execute_test_cases(driver) except Exception as e: log_error(device[udid], e) finally: if driver: driver.quit()finally里quit很重要否则Appium Server会残留session下次连接可能失败。4. pytest-xdist多设备并发的工程化配置4.1 conftest.py里按worker分配设备xdist给每个worker分配一个唯一ID可以通过worker_id这个fixture拿到。利用它来给每个worker绑定不同设备# conftest.py import pytest DEVICES [ {udid: udid1, port: 4723, systemPort: 8200}, {udid: udid2, port: 4725, systemPort: 8201}, {udid: udid3, port: 4727, systemPort: 8202}, ] pytest.fixture(scopesession) def device(request, worker_id): if worker_id master: # 不用-n时默认用第一台 return DEVICES[0] index int(worker_id.replace(gw, )) return DEVICES[index % len(DEVICES)] pytest.fixture(scopesession) def driver(device): d webdriver.Remote( fhttp://127.0.0.1:{device[port]}/wd/hub, build_caps(device) ) yield d d.quit()scopesession让driver在整个worker生命周期内复用避免每条用例都重启App能省大量时间。但要注意用例之间的状态清理否则会互相污染。4.2 用例文件粒度与设备绑定策略--distloadfile保证同一个文件的用例分到同一个worker这样driver的session级复用才有意义。如果你的用例文件很多每个文件用例少可以考虑--distloadscope按模块分配。启动命令pytest -n 3 --distloadfile -v --alluredir./results-n 3对应3台设备。设备数和worker数必须一致多了会有的worker拿不到设备少了浪费设备。4.3 结果汇总与Allure报告合并xdist跑完后每个worker会生成自己的Allure结果文件需要合并allure generate ./results -o ./report --clean如果每个worker写到不同目录先合并目录再生成。我一般让所有worker写同一个--alluredirAllure的结果文件是按UUID命名的不会冲突。提示xdist并行时print输出会混在一起建议用logging并带上worker_id前缀方便排查。5. 并发跑起来之后才会遇到的坑5.1 端口冲突的三种表现和排查方法端口冲突是多设备并发最常见的坑表现有三种Appium Server启动失败、driver连接超时、用例跑到一半突然断连。排查步骤lsof -i :4723看端口是否被占用adb devices确认设备在线检查systemPort是否重复看Appium日志里有没有UiAutomator2 server cannot be initialized我有一次折腾了两小时最后发现是两台设备的systemPort都设成了8200第二台启动时UiAutomator2服务起不来driver连接一直超时。这个参数一定要确保唯一。5.2 设备性能差异导致的超时误判不同设备的响应速度差异很大老设备点一个按钮要等3秒新设备1秒就响应了。如果你用统一的implicitly_wait老设备上很容易超时。我的做法是按设备性能分组或者用显式等待配合较长的超时from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC WebDriverWait(driver, 15).until( EC.element_to_be_clickable((By.ID, submit_btn)) )15秒的超时对新设备没影响元素出现就继续对老设备给了足够余量。5.3 日志混乱与结果错位并发跑的时候如果不做日志隔离三个线程的输出交织在一起根本没法看。解决方案是每个线程/worker写独立日志文件import logging def setup_logger(udid): logger logging.getLogger(udid) handler logging.FileHandler(flogs/{udid}.log) logger.addHandler(handler) return logger结果文件同理每个设备写独立的JSON或CSV最后合并。我踩过的坑是三个线程同时写一个文件最后行数对不上排查了半天才发现是并发写导致的。5.4 Appium Server残留进程清理跑完一轮后如果driver没正常quitAppium Server会残留session下次跑可能报session not created。建议在测试开始前和结束后都做一次清理pkill -f appium -p adb shell am force-stop com.example.app或者在Python里用subprocess调用清理命令。这个习惯能省掉很多莫名其妙的失败。6. 从能跑到跑得稳并发测试的稳定性优化6.1 重试机制不是所有失败都是真失败UI自动化天然不稳定网络抖动、设备卡顿、App偶发ANR都会导致用例失败。在并发场景下这种不稳定会被放大。加一层重试能显著提升通过率pytest.mark.flaky(reruns2, reruns_delay3) def test_login(driver): ...pytest-rerunfailures插件支持用例级重试。但要注意重试会拉长整体时间reruns不要设太大2次足够。另外重试的用例要确保是幂等的否则可能因为状态残留导致重试也失败。6.2 资源隔离数据、账号、文件都要分开多设备并发时如果多台设备用同一个测试账号登录服务端可能会踢掉前一个session导致用例失败。测试数据也一样多台设备同时操作同一条数据会互相干扰。我的做法是每台设备分配独立的测试账号和数据前缀。比如设备1用test_user_1设备2用test_user_2数据里带上设备标识。这样即使并发跑也不会互相影响。6.3 并发度不是越高越好设备越多并发度越高但稳定性会下降。我实测下来4台设备并发是比较稳的甜点区再往上Appium Server的资源占用、ADB的通信压力、机器的CPU和内存都会成为瓶颈。如果你的机器配置一般2-3台并发可能比4台更快因为减少了资源竞争导致的超时重试。判断并发度是否合适看两个指标整体耗时是否随设备数线性下降、失败率是否明显上升。如果加到第5台设备后耗时没怎么降、失败率反而涨了说明到瓶颈了。6.4 CI环境下的并发注意事项在CI里跑多设备并发有几个额外要注意的点。一是CI机器的USB端口数量有限设备多了要接USB Hub但Hub供电不足会导致设备掉线。二是CI环境的ADB版本要和本地一致版本不匹配会出现设备识别问题。三是并发跑的时候CI机器的负载会很高建议给CI机器留足够的CPU和内存余量否则Appium Server自己都会卡。我在CI上跑4设备并发时把CI机器的配置从4核8G升到8核16G失败率从15%降到了3%以下。这个投入是值得的。7. 一些实际项目里攒下来的经验多设备并发这件事工具和代码只是基础真正决定成败的是细节管理。我做了几个项目下来最大的体会是并发测试的稳定性问题八成来自资源隔离没做好。端口、设备、账号、数据、日志、结果文件每一样都要确保独立任何一处共享都可能成为并发失败的根源。另一个体会是不要一上来就追求高并发。先把2台设备跑稳再逐步加到3台、4台每加一台观察一轮稳定性。直接上4台然后天天排查随机失败效率反而低。还有一点关于线程池和xdist的选择如果你的团队对pytest生态熟悉直接上xdist工程化程度高维护成本低。如果只是临时跑个并发、用例不多线程池写起来更快。没有绝对优劣看场景。最后说个容易被忽略的点Appium Server的版本要和driver版本匹配。并发场景下版本不匹配的问题会被放大因为多台设备同时连接版本兼容性问题更容易暴露。建议固定版本不要频繁升级升级前先在单设备上验证。