恒美微站
首页
关于我们
建站服务
主题模板
案例展示
资讯中心
联系我们
Appium+Python移动自动化测试入门:环境搭建与第一个脚本实战
首页
资讯中心
/
Appium+Python移动自动化测试入门:环境搭建与第一个脚本实战
Appium+Python移动自动化测试入门:环境搭建与第一个脚本实战
发布时间:2026/8/8 7:40:55
1. 从零到一为什么选择AppiumPython作为移动自动化起点如果你正在看这篇文章大概率是刚接触移动端自动化测试或者是从其他测试领域比如Web端转过来面对五花八门的工具和框架有点无从下手。我刚开始的时候也一样被各种名词搞得晕头转向UIAutomator、XCUITest、Espresso、Calabash... 每个看起来都很强大但学习成本和维护难度也让人望而却步。直到我系统性地用上了Appium配合Python才感觉真正找到了一个能快速上手、又能支撑复杂项目的“瑞士军刀”。简单来说Appium是一个开源的、跨平台的移动端自动化测试框架。它的“跨平台”是真正的核心优势你用同一套API就能写测试脚本来测试Android和iOS应用甚至是混合应用Hybrid App或移动端网页。这背后是基于WebDriver协议Appium把自己伪装成一个WebDriver服务器接收来自客户端的指令比如“点击”、“输入文本”然后把这些指令“翻译”成对应平台原生测试框架能听懂的语言去执行。对于Android它底层调用的是UIAutomator2或Espresso对于iOS则是XCUITest。这意味着你不需要去深入学习每个平台的原生框架Appium帮你做了这层抽象和封装。那么为什么搭配Python呢从我多年的实战经验来看Python在自动化测试领域的生态和易用性是无与伦比的。它的语法简洁学习曲线平缓特别适合测试这种需要快速实现、频繁修改的场景。大量的第三方库比如requests做接口测试、pytest组织测试用例、allure生成漂亮报告都能无缝集成进来构建一个完整的测试流水线。更重要的是Appium-Python-Client这个库非常成熟和稳定它提供了对WebDriver协议完整的Python绑定让你能用非常Pythonic的方式去编写测试逻辑代码可读性极高。很多人一开始会纠结于环境配置觉得Appium环境复杂容易出错。确实相比一些纯客户端的工具Appium需要Node.js环境、Appium Server、以及各平台的开发工具包Android SDK, Xcode。但我想说的是这是一次性的投入一旦配好后续的收益是巨大的。这篇文章我就带你彻底走通这条路从环境搭建、原理理解到写出第一个能真正启动应用的脚本并解释清楚每一个步骤背后的“为什么”让你知其然更知其所以然避开我当年踩过的那些坑。2. 环境搭建构建稳定可靠的自动化基础环境配置是拦路虎但也是最重要的地基。一个混乱的环境会导致后续各种灵异问题。我们这里的目标是搭建一个支持Android自动化测试的环境iOS环境需要在macOS上进行原理类似。2.1 核心组件安装与验证首先你需要安装几个核心的、全局性的软件。1. Node.js与npmAppium Server本身是一个Node.js应用所以我们需要先安装Node.js。请前往Node.js官网下载LTS长期支持版本进行安装。安装完成后打开命令行Windows的CMD或PowerShellmacOS/Linux的Terminal执行以下命令验证node -v npm -v这两条命令应该能分别输出Node.js和npmNode.js的包管理器的版本号。npm会在安装Node.js时自动附带。注意有些教程会推荐用cnpm淘宝镜像来加速后续安装Appium的过程。对于新手我强烈建议直接使用官方npm。cnpm的镜像同步有时会有延迟或问题可能导致安装的包版本不对或依赖关系错误引发一些难以排查的诡异问题。网络问题可以通过科学合理使用网络代理解决但这不是本文讨论范畴。2. Appium Server的安装有了npm我们可以用以下命令安装Appium Servernpm install -g appium这个-g参数代表全局安装这样你才能在任意路径下启动Appium服务。安装过程可能会稍长因为它会下载不少依赖。安装完成后你可以通过命令appium -v来查看版本。但更重要的验证方式是启动它appium如果看到类似[Appium] Welcome to Appium v2.x.x和[Appium] Appium REST http interface listener started on 0.0.0.0:4723的输出说明Server已经成功启动并在本机的4723端口监听。这是Appium的默认端口。3. Appium Doctor你的环境诊断医生环境依赖没装全是新手最常见的问题。Appium官方提供了一个强大的工具叫appium-doctor它可以检查你的环境是否满足Appium运行的所有条件。npm install -g appium-doctor安装后运行appium-doctor它会一项项检查比如JDK、ANDROID_HOME环境变量等。所有项目前面出现绿色的✔才表示你的环境是OK的。如果有红色的✖它会明确告诉你缺少什么按照提示去安装配置即可。在开始写代码前务必让appium-doctor全部通过这能节省你后面无数小时的调试时间。4. Python与Appium Client确保你安装了Python推荐3.7及以上版本。然后在命令行中用pip安装Appium的Python客户端库pip install Appium-Python-Client这个库是我们编写测试脚本时直接导入和使用的。2.2 Android测试环境专项配置因为我们要测试Android应用所以需要配置Android开发环境。1. 安装Android SDK不建议直接下载完整的Android Studio因为它太庞大了。你可以只安装Android SDK命令行工具。谷歌提供了下载链接。下载后解压到一个你喜欢的路径例如C:\Android\。2. 配置关键环境变量这是至关重要的一步很多启动失败都源于此。ANDROID_HOME这个变量要指向你的Android SDK根目录。例如C:\Android\。将SDK中的platform-tools和tools或tools/bin目录添加到系统的PATH环境变量中。%ANDROID_HOME%\platform-tools包含adb命令%ANDROID_HOME%\tools包含sdkmanager等命令配置完成后重新打开命令行输入adb version如果能看到版本信息说明adbAndroid调试桥配置成功。输入sdkmanager --list如果能列出可安装的包说明SDK工具也配置好了。3. 安装必要的SDK包通过sdkmanager安装一个Android系统镜像用于模拟器和对应的平台工具。例如安装一个常用的API级别sdkmanager platform-tools platforms;android-30 system-images;android-30;google_apis;x86_64这里的android-30可以根据需要替换但建议选择你的测试应用所支持的主流版本。4. 准备测试设备真机或模拟器真机用USB线连接手机打开手机的“开发者选项”和“USB调试”模式。在命令行输入adb devices应该能看到你的设备序列号后面跟着device字样表示已授权连接。模拟器如果你没有真机可以使用Android SDK自带的模拟器。首先用sdkmanager安装一个系统镜像如上一步然后通过Android Studio的AVD Manager图形界面创建一个虚拟设备或者使用命令行工具avdmanager创建。创建后启动它。无论用哪种方式确保adb devices命令能列出你的设备并且状态是device。这是Appium能够控制设备的大前提。3. 核心概念解析Desired Capabilities与驱动会话环境就绪后在写第一行代码之前我们必须理解两个最核心的概念Desired Capabilities和Driver Session。这是Appium脚本的“灵魂”。3.1 Desired Capabilities告诉Appium你的测试意图你可以把Desired Capabilities想象成一份“测试任务说明书”或者一份“合同”。在你启动测试之前你需要通过一个字典Python中的形式明确地告诉Appium Server我想要测试哪个平台Android/iOS的哪个应用在哪个设备上测试以及其他一些重要的设置。为什么需要这个因为Appium支持太多平台和场景了它必须根据你的明确指示来初始化正确的底层驱动和上下文。如果没有这个Appium根本不知道你要做什么。一份最基本的用于启动Android应用的能力集如下所示desired_caps { ‘platformName‘: ‘Android‘, # 平台必填 ‘platformVersion‘: ‘10‘, # 安卓系统版本尽量准确非必填但推荐 ‘deviceName‘: ‘Android Emulator‘,# 设备名任意字符串用于日志标识非真机名 ‘appPackage‘: ‘com.example.myapp‘, # 要启动的App包名必填 ‘appActivity‘: ‘.MainActivity‘, # 要启动的App主Activity必填 ‘automationName‘: ‘UiAutomator2‘, # 自动化引擎Android推荐UiAutomator2 ‘noReset‘: True, # 是否在会话开始前重置应用状态如清除数据 ‘newCommandTimeout‘: 600, # 命令超时时间秒 }这里有几个关键点需要深入理解deviceName新手最大的误解之一。这个字段并不是你手机的型号如“小米12”而是一个任意字符串仅仅用于在Appium日志中标识这个会话。对于模拟器常用“Android Emulator”对于真机可以写“MyPhone”。真正识别设备的是adb提供的设备序列号Appium会自动使用adb devices列表中的第一个设备或者你可以通过udid能力来指定具体设备。appPackage和appActivity这是启动一个Android应用的关键。appPackage是应用的唯一标识符包名appActivity是你要启动的那个界面的入口。如何获取它们有几个方法问开发。如果你有APK文件可以使用aapt工具在SDK的build-tools目录下解析aapt dump badging your_app.apk | findstr package和aapt dump badging your_app.apk | findstr launchable-activity。在已安装应用的设备上打开你要启动的那个界面然后在命令行输入adb shell dumpsys window | findstr mCurrentFocusWindows或adb shell dumpsys window | grep mCurrentFocusmacOS/Linux。输出结果中/后面的部分就是当前的appPackage和appActivity。automationName指定底层自动化引擎。对于AndroidUiAutomator2是当前官方推荐且最稳定的选择它基于Google的UIAutomator2框架。老旧的UiAutomator1已被弃用。noReset这个参数非常实用。如果设为FalseAppium会在测试开始前卸载重装应用如果指定了app能力或清除其数据确保从一个干净的状态开始。如果设为True则会保留应用的数据和状态直接从当前状态开始。在调试脚本时设为True可以避免反复登录提高效率。3.2 Driver会话建立与设备的通信桥梁Desired Capabilities定义好了之后我们需要通过它来建立一个与Appium Server进而与手机设备的通信会话。这个会话在代码中体现为一个Driver对象通常是webdriver.Remote。这个过程可以分解为你的Python脚本客户端将desired_caps这个字典通过HTTP请求发送到正在运行的Appium Server默认地址是http://localhost:4723。Appium Server接收到请求解析这些能力然后根据platformName,automationName等去调用对应的底层驱动如UiAutomator2。底层驱动通过adb与Android设备通信完成应用的启动、界面初始化等操作。如果一切顺利Appium Server会返回一个成功的响应并在你的Python代码中创建一个driver对象。这个driver对象就是后续所有自动化操作找元素、点击、滑动的入口。这个driver对象是WebDriver协议标准的一部分因此如果你有Selenium Web自动化经验会发现很多API是相似的如find_element,click,send_keys这大大降低了学习成本。4. 第一个脚本实战启动应用并验证理论说得再多不如动手跑一遍。我们来编写一个完整的、可以运行的脚本启动设备上的“设置”应用因为它每个Android设备都有。4.1 脚本编写与逐行解读创建一个新的Python文件比如first_start.py。# 导入必要的库 from appium import webdriver from appium.webdriver.common.appiumby import AppiumBy import time # 1. 定义Desired Capabilities desired_caps { ‘platformName‘: ‘Android‘, ‘platformVersion‘: ‘10‘, # 请根据你的模拟器/真机系统版本修改 ‘deviceName‘: ‘Android Emulator‘, ‘automationName‘: ‘UiAutomator2‘, ‘appPackage‘: ‘com.android.settings‘, # 系统设置的应用包名 ‘appActivity‘: ‘.Settings‘, # 系统设置的主Activity ‘noReset‘: True, # 不清除数据直接打开 ‘newCommandTimeout‘: 30, # 30秒内无新命令则超时 } # 2. 初始化驱动建立会话 # 注意Appium Server必须已经在运行命令行执行了appium driver webdriver.Remote(‘http://localhost:4723‘, desired_caps) # 3. 添加一个简单的等待让我们能看到应用启动 time.sleep(3) # 可选4. 进行一个简单的界面元素查找验证应用确实启动成功 # 这里尝试查找“设置”界面中通常存在的“搜索设置”框 try: # 使用ACCESSIBILITY_ID定位方式通常对应元素的content-desc或text属性 search_box driver.find_element(AppiumBy.ACCESSIBILITY_ID, “搜索设置”) print(“成功找到搜索框应用启动验证通过”) except Exception as e: print(f“未找到特定元素但应用可能已启动。错误信息{e}”) # 也可以尝试其他定位方式比如通过CLASS_NAME找列表 # items driver.find_elements(AppiumBy.CLASS_NAME, “android.widget.TextView”) # print(f“当前界面找到 {len(items)} 个文本元素”) # 5. 关闭会话 driver.quit() print(“测试会话结束。”)逐行解读与注意事项导入库webdriver是核心AppiumBy提供了Appium增强的定位方式比标准Selenium的By更友好。定义desired_caps这是脚本的核心。请务必将platformVersion改成你设备实际的Android版本。appPackage和appActivity这里用的是系统设置的通用性高。初始化驱动webdriver.Remote()是建立连接的关键。第一个参数是Appium Server的地址第二个参数就是我们定义的能力字典。执行这行代码前必须确保在另一个命令行窗口中已经运行了appium命令并且服务器已启动。等待time.sleep(3)是一个简单的强制等待目的是让应用有足够时间启动并加载界面方便我们观察。在实际项目中应该使用更智能的“显式等待”WebDriverWait后面会提到。元素查找与验证这里使用try-except块来尝试定位一个元素。AppiumBy.ACCESSIBILITY_ID是定位元素的首选方式之一它对应Android元素的content-desc属性或iOS的accessibility identifier通常由开发设置稳定性较好。如果找到说明应用成功启动并进入了我们预期的界面。如果没找到可能是界面结构不同脚本会打印错误并继续。这是一个基本的健壮性处理。关闭会话driver.quit()非常重要它会告诉Appium Server结束本次测试会话释放设备连接。如果不调用设备可能会一直被占用导致后续测试失败。4.2 执行脚本与结果分析确保你的设备模拟器或真机已连接且adb devices可看到。在一个命令行终端启动Appium Serverappium。在另一个终端或直接用IDE运行你的Python脚本python first_start.py。预期成功现象Appium Server终端会刷出一大堆日志显示它正在初始化会话、启动应用。你的手机或模拟器屏幕会自动亮起并打开“设置”应用。你的Python脚本控制台会打印出“成功找到搜索框...”或类似的成功信息最后打印“测试会话结束。”。常见失败排查WebDriverException: Cannot connect to the Service at localhost:4723原因Appium Server没有启动。解决检查是否在另一个终端执行了appium命令并成功启动。WebDriverException: An unknown server-side error occurred while processing the command. Original error: Could not find a connected Android device.原因Appium找不到设备。解决执行adb devices确认设备列表不为空且状态是device。如果是unauthorized检查手机是否弹出了“允许USB调试”的授权框。WebDriverException: An unknown server-side error occurred while processing the command. Original error: Cannot start the ‘com.android.settings‘ application.原因appPackage或appActivity名称错误或者该应用未安装。解决使用前面介绍的adb shell dumpsys window命令在设备上手动打开“设置”应用获取正确的包名和Activity名。脚本执行后Appium日志正常但手机没反应原因可能platformVersion填错了或者automationName不匹配。解决仔细核对设备系统版本。对于较新的Android版本5.0以上automationName务必使用UiAutomator2。当你的脚本成功运行看到手机上的应用自动打开时恭喜你你已经跨出了Appium自动化最关键的第一步。这不仅仅是启动了一个应用更是建立了一套从你的代码到真实移动设备的自动化控制链路。接下来所有复杂的操作都是基于这个已建立的会话来进行的。5. 从启动到稳定进阶配置与最佳实践成功启动应用只是第一步。要让自动化脚本真正可靠、可维护我们需要考虑更多。5.1 使用显式等待替代强制等待在上面的例子中我们用了time.sleep(3)。这是一个“强制等待”无论界面是否加载完成它都会死等3秒。这会导致两个问题如果网络或设备慢3秒可能不够脚本会失败如果设备快又会白白浪费时间降低测试效率。正确的做法是使用“显式等待”。它告诉驱动程序在接下来的最多X秒内每隔一段时间检查某个条件是否成立比如某个元素是否出现一旦成立就立即继续执行如果超时则抛出异常。from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from appium.webdriver.common.appiumby import AppiumBy # ... 初始化driver之后 ... # 设置显式等待最多等待10秒 wait WebDriverWait(driver, 10) # 等待直到“搜索设置”这个元素出现在页面上 search_box wait.until( EC.presence_of_element_located((AppiumBy.ACCESSIBILITY_ID, “搜索设置”)) ) print(“元素已加载完成”) # 现在可以安全地与元素交互了 search_box.click()显式等待是编写稳定自动化脚本的基石务必掌握。5.2 关键Capabilities的深入应用udid当你有多个设备连接时需要用这个参数指定具体的设备。通过adb devices获取设备的序列号然后设置‘udid‘: ‘你的设备序列号‘。app如果你测试的应用尚未安装在设备上你可以通过这个能力直接指定APK文件的路径可以是本地路径或一个URLAppium会自动安装它。例如‘app‘: ‘C:/path/to/your/app.apk‘。注意如果同时指定了app和appPackage/appActivityAppium会优先安装或使用app指定的应用。fullReset与noReset这是一对相关的设置。noResetFalse(默认)会话结束后不会重置应用状态。noResetTrue会话结束后不会重置应用状态会话开始前也不会清除数据。fullResetTrue会话开始前会卸载重装应用如果app指定了或者清除应用所有数据会话结束后也会卸载应用。这个设置比较暴力通常用于需要绝对干净环境的测试。autoGrantPermissions设置为True时Appium会在启动应用时自动授予所有运行时权限弹窗。这在测试初期非常有用可以避免脚本被权限弹窗阻塞。5.3 编写可维护的脚本结构不要把所有的能力配置和操作都写在一个文件里。好的实践是配置文件将desired_caps放在一个单独的配置文件如config.py或config.yaml中方便针对不同设备、不同环境测试/生产进行切换。Page Object模式这是UI自动化测试的核心设计模式。将每个应用页面封装成一个类页面上的元素定位符和基本操作点击、输入作为这个类的方法。这样你的测试用例脚本就会变得非常清晰只包含业务逻辑而元素定位的细节被隐藏起来。当UI发生变化时你只需要修改对应的Page Object类而不需要修改大量测试用例。日志与报告使用Python的logging模块记录脚本运行的关键步骤和错误信息。集成pytest测试框架和allure报告工具可以生成非常专业和直观的测试报告。启动应用是Appium自动化的敲门砖它串联起了环境、协议、客户端与服务端的通信。把这个过程理解透彻后续的元素定位、手势操作、断言验证都是在此基础上叠加的技能。我建议你在第一个脚本成功后不要急于往下学更复杂的操作而是多尝试修改不同的Desired Capabilities参数观察Appium日志和手机行为的变化同时用appium-doctor确保环境始终健康。这个扎实的起步能让你在后续更复杂的自动化之旅中走得更稳、更远。