Python + Appium 实现网易严选 APP 自动化测试全流程指南

最近我按“Python Appium 驱动网易严选 APP 全流程测试”这个方向完整跑了一遍先给结论3 天确实能把一条链路搭出来但不是靠 2026 或某个新特性而是靠把环境、定位、场景串联、设备并行、报告和排查全部理顺。这套方案最值得练的地方是它面对的是网易严选这个真实商业 APP不是 Demo 项目控件、页面跳转、弹窗、登录态和异步加载都很真实。你如果准备从零开始学 APP 自动化或打算在企业内部用 Python 做安卓端的回归测试这篇文章可以直接当落地参考。先说清楚我指的 3 天是什么。不是让你 3 天变成自动化测试专家而是在 3 天里完成这几件事第一天把 Appium 环境跑通能启动网易严选并定位元素第二天把首页、搜索、详情、加购、购物车、结算页这条主链路串起来第三天把脚本改造成配置驱动加入日志、截图、失败重试、报告和多设备并行。能做到这个程度企业里普通项目的自动化冒烟和常规回归就够用了。下面按实际踩坑顺序拆。1. 先把“3 天做什么”定清楚这套方案的真实边界1.1 为什么选网易严选练手市面上的自动化教程大多数用系统自带的 Calculator 或某个开源 Demo跑通很容易但一换到真实 APP 就到处失败。网易严选的好处是界面层级真实、控件数量多、页面跳转路径清晰而且包含搜索列表、商品详情、购物车、结算页这类电商核心场景非常适合练 APP UI 自动化。网易严选不是简单的静态页面。首页有弹窗运营位列表存在加载更多详情页需要滚动价格数字会异步刷新登录需要处理验证码。这些才是自动化测试真正会遇到的日常问题。如果你能在这类 APP 上稳定跑通再去测自己公司的应用思路会顺畅很多。需要注意一点网易严选是线上正式应用。正常学习可以装到自己的模拟器或测试机上跑但不要用你的真实账号反复做下单和支付操作也不要编写绕过风控或批量注册之类的脚本。自动化测试的落脚点是验证流程不是去刷业务数据。1.2 UI 自动化适合哪些场景不适合哪些场景很多人第一反应是“APP 自动化可以代替手工测试”这个理解需要纠正。适合 UI 自动化的场景有这么几类冒烟回归核心用例每次发版后跑一遍比手工点半天节省时间。多机型兼容脚本在不同设备上执行收集元素层级、布局和页面响应差异。长链路验证从首页搜索到结算页的流程人工操作容易漏步骤脚本可以按固定顺序执行。版本迭代后的控件回归重点看资源 ID、文案、页面结构有没有改坏。不适合的场景也要提前知道需要大量人工判断视觉效果比如配色、间距、模糊效果UI 自动化很难替代。临时需求不断变化的页面每天改版的页面维护脚本成本会高于手工测试。强验证码和强风控环境短信验证码、滑块验证每次不一样脚本不能稳定跑必须先解决测试账号和数据的问题。性能压测UI 自动化只适合验证功能流程不适合测量真实并发性能。我建议把网易严选项目定位成“端到端主流程冒烟”不要一上来追求覆盖所有按钮和异常分支。覆盖范围过大的结果往往是维护脚本占据了所有精力。1.3 3 天的具体产出物3 天能完成的不是“测试全部功能”而是建好一套可扩展的骨架。第一天产出Appium Server 能启动Appium Inspector 能连接设备Python 能调用 Appium 打开网易严选首页脚本能输出日志并正常退出。第二天产出实现一条至少包含搜索、查看商品详情、加入购物车、进入结算页的用例并且能把通过、失败原因写清楚。第三天产出用例拆分为 Page Object支撑多设备并发增加截图和失败重试生成 HTML 报告把新增测试项的成本降下来。这个拆法比较符合真实项目节奏。很多教程只教第二步忽略第一步和第三步所以读者看完还是不知道怎么在企业里落地。2. 环境准备先解决 Python、Appium、安卓设备和网易严选的连通性2.1 基础软件清单在跑网易严选之前确认机器上已经装齐了这些。缺任何一个后面都可能出现“脚本看起来没问题但就是启动不了”的情况。软件作用建议Python编写测试脚本3.8 以上即可优先 3.10 到 3.12Appium Server提供自动化服务2.x 比较主流老教程常用 1.22.3Appium Inspector查看页面元素网页元素调试工具建议单独安装Appium-Python-ClientPython 调用 Appiumpip 安装JDKAndroid 自动化依赖根据 Android SDK 要求配置Android SDK连接安卓设备配好 ANDROID_HOME 和 platform-toolsadb识别设备和安装应用SDK 自带模拟器或真机运行网易严选 APP网易严选建议用 Android 7 以上系统网上很多教程会直接写“下载 Appium Desktop 1.22.3”那是早期版本。如果你只是想学习用老版本也能跑如果打算长期维护我更建议用 Appium 2.x并把 Appium Inspector 单独安装。这里不要纠结“最新版一定最好”关键是版本组合要能互相兼容。2.2 环境变量检查装完之后先不要急着写测试。把下面几个命令在命令行里跑一遍python --version pip --version java -version adb version appium --version这四个命令只要有任何一个报“不是内部命令”或“command not found”就先处理环境变量不要直接写 Python 脚本。Windows 上常见问题是 Python 安装后没有勾选 Add Python to PATH导致命令行无法执行 python。macOS 和 Linux 上常见问题是使用系统自带 Python后续安装依赖会出现权限问题。我建议在开始阶段就创建一个独立虚拟环境避免和系统 Python 环境混在一起python -m venv appium_env source appium_env/bin/activateWindows 上执行appium_env\Scripts\activate。虚拟环境激活后再安装 Appium-Python-Client、pytest 和 allure-pytestpip install Appium-Python-Client pytest pytest-xdist allure-pytest这里解释一下为什么不用全局安装。Python 项目经常遇到依赖冲突今天装 Appium 客户端明天可能装 requests、yaml、openpyxl。如果全部塞进系统环境一旦某个依赖版本升级之前能跑的脚本可能突然不能运行。虚拟环境可以把项目依赖隔离起来出问题后直接删除重建不会影响其他项目。2.3 启动顺序先连设备再启动 Server最后启动脚本很多人第一次跑网易严选失败不是代码问题而是启动顺序不对。正确的启动顺序是启动模拟器或连接真机并开启 USB 调试。执行adb devices确认设备已经显示为 device。启动 Appium Server或者启动 Appium Desktop 里的服务。让 Appium Inspector 连接设备并打开网易严选。确认能看见网易严选页面后再运行 Python 脚本。如果跳过第 2 步直接启动 Appium服务端可能一直拿不到设备列表脚本会卡在创建会话阶段。2.4 拿到网易严选的包名和初始页面网易严选的包名在教程里经常被直接写出来但 APP 不同版本可能不一样。不要盲信截图自己用 adb 拿最靠谱。先在模拟器或真机上打开网易严选然后执行adb shell pm list packages | grep -i netease执行结果里通常能看到包含 netease 的包名。如果只装了网易严选结果一般是com.netease.yanxuan之类。拿到包名后再执行下面的命令看当前页面adb shell dumpsys window | grep -E mCurrentFocus|mFocusedApp通过这个命令能拿到当前 Activity。后续在 Appium 的 capabilities 里appPackage 和 appActivity 就可以填这里看到的实际值。不要直接复制别人代码里的 Activity不同版本可能差异很大。2.5 如果环境装不上或网络慢国内下载 Appium 或 Android SDK 时容易遇到下载慢的问题。普通做法是切换镜像源比如 Android SDK 使用国内镜像npm 和 pip 也可以配置国内源。判断环境是否成功的标准很简单Appium Server 能正常启动adb 能识别设备Python 能 import appium 库。能做到这三点环境这一关就算过了不需要反复纠结“我装的是不是最新版”。3. 元素定位别一上来写代码先用 Appium Inspector 看控件3.1 先看页面结构再操作Appium 自动化最忌讳的就是“凭肉眼猜测控件 ID”。网易严选首页的搜索框、底部 Tab、商品卡片都是真实 UI 控件但它们的 resource-id、class、text 必须先通过 Inspector 看一遍。在 Appium Inspector 里连接设备并打开网易严选后能看到类似 XML 的控件树。点击任意控件右侧会显示它的属性包括resource-idclasstextcontent-descboundsenabledclickable这些属性才是脚本定位的依据。比如你要点击搜索框先在页面树里找到搜索框控件看它是否 clickabletext 是什么。如果没有 resource-id再用文本或 class 组合定位。3.2 为什么不要只看 text 或 XPath只看 text 的问题很明显网易严选的文本经常变搜索框提示文案可能从“搜索商品”改成“搜索严选好物”一旦文案更新脚本就会失效。只看绝对 XPath 的问题更严重。APP 页面结构经常变化XPath 里的/android.view.ViewGroup[2]/android.widget.FrameLayout[3]/...只要层级里多一个节点整条路径就废了。而且 Appium 执行 XPath 定位速度比 resource-id 慢页面越复杂越明显。更合理的定位优先级是优先级定位方式原因高resource-id最稳定版本升级时不容易变高content-desc适用于图片按钮和纯图标控件中text 文本适用于按钮、标题但文案变动会影响中androidx.test.uiautomator 选择器支持组合属性例如同时匹配 text 和 class低XPath最后选择优先用短路径或包含属性3.3 定位的实操顺序打开网易严选首页后我会先按这个顺序做一次元素盘点搜索框通常带 text 提示或可在顶部区域点击。底部 Tab首页、分类、购物车、个人中心等一般有固定文案。首页商品卡片可能是整个卡片可点击图片不一定有 resource-id要借助卡片区域或 text。搜索结果的商品标题看商品标题完整文本或者部分文本。加购按钮确认按钮可点击并且点击后有“已加入购物车”之类的反馈。购物车商品项确认名称、价格、数量等元素存在。点击元素前先问三个问题这个控件一定可见吗是否被弹窗遮挡是不是需要滚动后才能显示这三个问题解决不了写在脚本里的点击大概率会超时。4. 写全流程测试从最小的“能跑”用例到搜索、加购、结算链路4.1 最小示例先启动网易严选不要第一天就写几十个方法。先从最小示例开始确认 driver 能打开网易严选。from appium import webdriver caps { platformName: Android, appium:deviceName: emulator-5554, appium:udid: emulator-5554, appium:appPackage: com.netease.yanxuan, appium:appActivity: activity路径请用dumpsys拿到的值填写, appium:noReset: True, appium:automationName: UiAutomator2, appium:newCommandTimeout: 120, } driver webdriver.Remote(http://127.0.0.1:4723, caps) print(driver.current_package) print(driver.current_activity) driver.quit()这段代码只要能把当前包名打印出来就说明 Appium 和 Python 的链路已经通了。这里要说明上面 caps 里的 appActivity 不是让你直接照抄而是要先用 2.4 里的 dumpsys 命令拿到实际值。appPackage 也可能因为不同版本有差异务必以你本机为准。4.2 搜索商品并点击第一个结果启动网易严选后下一步是完成搜索。假设你已经通过 Inspector 确认首页搜索入口的控件可以用文本或 resource-id 识别下面是一个简化示例from appium import webdriver from appium.webdriver.common.appiumby import AppiumBy from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC # 搜索按钮的定位信息要根据实际页面调整 search_entry (AppiumBy.ID, com.netease.yanxuan:id/v_search_bar) driver.find_element(*search_entry).click() input_box (AppiumBy.ID, 输入框实际ID) wait WebDriverWait(driver, 10) wait.until(EC.visibility_of_element_located(input_box)).send_keys(保温杯) # 执行搜索通常点击键盘搜索键或页面上的搜索按钮 driver.press_keycode(4) # 示例不一定适用这里不能保证v_search_bar就是网易严选当前版本的 ID实际执行前必须用 Inspector 刷新一遍。真实项目里我一般会先打开 APP找到搜索框把它的属性记录到 Page Object 里再写点击逻辑。搜索之后页面上会展示商品列表。点击第一个商品时不要直接写(AppiumBy.XPATH, //android.widget.FrameLayout[1])因为第一个 FrameLayout 不一定是商品。更稳妥的方式是查找商品标题文本或者查一个固定的“全部商品”区域里的子节点再取第一个可点击的商品卡片。4.3 商品详情、加购、查看购物车从结果列表进入详情后需要确认商品名称、价格、购买按钮都加载出来。有些商品详情页会异步加载所以加购前必须等待“加入购物车”按钮可见并可点击add_cart_btn (AppiumBy.XPATH, //*[text加入购物车]) wait WebDriverWait(driver, 10) cart_btn wait.until(EC.element_to_be_clickable(add_cart_btn)) cart_btn.click()加购后可能会出现“已加入购物车”的弹窗也可能会自动跳转到购物车。这个行为取决于版本和配置。脚本不要假设固定结果应该根据实际页面反馈做断言。加购成功的一个可靠标志是购物车徽标数字变化或页面上出现“去购物车”按钮。这个判断点最好在第一次写脚本时就记录成一条断言后面回归时能及时发现加购行为被改坏。购物车页面要注意商品名称、数量、价格三个元素是否都在同一屏。如果购物车商品比较多可能还要滑动列表才能看到目标商品。先做一个简单的断言购物车页面至少出现一个商品标题并且该标题和刚才搜索的商品名称相关。4.4 结算页的边界处理自动化测试练习到“购物车”就可以算主流程但如果要做“全流程”还需要进入结算页。点击购物车里的“去结算”按钮会进入确认订单页面。此时页面上有收货地址、商品清单、支付方式等模块。测试脚本应该在确认订单页停留并断言关键元素出现例如“提交订单”按钮可见。除非你有企业内部的测试账号和沙箱支付环境否则不要继续执行真实支付。真实支付会涉及资金操作不适合在公开的自动化脚本里反复跑。正确做法是进入提交订单页后断言页面加载成功。把最后一步支付操作留成手工验证。如果后续需要完整全链路使用公司提供的测试白名单账号或沙箱订单网关。这样的处理方法既符合工程规范也不会让自己或团队为自动化脚本付出额外资金成本。5. 从“能跑”到“稳定跑”等待、弹窗、截图和处理日志5.1 不要用固定 sleep 代替等待初级脚本最常见的问题是time.sleep(5) driver.find_element(...)固定等待不是完全不能用但作为主策略会让脚本变得很慢、很不稳。网易严选首页在不同网络环境下加载时间可能从 2 秒到 8 秒如果固定等 5 秒网络快的时候浪费时间网络慢的时候照样超时。更好的方式是优先使用显式等待from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC wait WebDriverWait(driver, 10) loc (AppiumBy.ID, 实际控件ID) wait.until(EC.visibility_of_element_located(loc)).click()显式等待的好处是“轮询直到条件满足”不是傻等固定时间。我用WebDriverWait时一般先给 10 秒如果页面加载稳定了再适当降到 5 秒。不要一上来就把超时设到 60 秒长时间超时会掩盖页面正常变慢的问题。5.2 处理 APP 启动弹窗和运营浮层真实 APP 自动化最烦人的是弹窗。网易严选首页可能出现新手引导、活动弹窗、推送授权弹窗。弹窗的位置和内容随着运营配置变化所以不能写死一个关闭按钮。我在脚本里通常建一个close_optional_popups方法专门处理这些“可跳过但不一定出现”的元素。这个方法捕获取消按钮、关闭按钮或空白遮罩区域如果元素不存在就跳过from appium.webdriver.common.appiumby import AppiumBy def close_popups_if_visible(driver): possible_close_selectors [ (AppiumBy.ID, 弹窗关闭按钮ID), (AppiumBy.XPATH, //*[text关闭]), ] for selector in possible_close_selectors: try: elements driver.find_elements(*selector) if elements: elements[0].click() return True except Exception: continue return False注意不要在所有页面都调用这个方法只在首页或特定入口前后调用。弹窗回归逻辑如果写得太激进反而可能把正常页面里的按钮当成弹窗关闭按钮点掉。5.3 失败时先截图再保留页面源码脚本失败最怕只有一句报错没有现场信息。真正跑的时候截图和页面源码非常关键。我建议在 pytest 的每个用例失败钩子里自动做两件事保存当前界面截图。保存driver.page_source到 XML 文件。这样排查用例失败时先看截图再看页面源码定位是谁挡了路、哪个控件属性变了。import datetime def attach_failure_info(driver, case_name): ts datetime.datetime.now().strftime(%Y%m%d_%H%M%S) driver.save_screenshot(foutput/{case_name}_{ts}.png) with open(foutput/{case_name}_{ts}.xml, w, encodingutf-8) as f: f.write(driver.page_source)页面源码看起来啰嗦但它包含完整的控件层级。如果发现某个按钮不见了在 XML 里搜索关键字比一次次重新跑脚本效率高很多。5.4 用 pytest 管理用例和测试数据建议把测试用例按流程拆成一个 pytest 模块。比如import pytest def test_home_page_load(): pass def test_search_and_enter_detail(driver_fixture): pass def test_add_to_cart(driver_fixture): pass def test_checkout_page_visible(driver_fixture): pass这些用例之间不要强依赖前一个用例的状态。如果test_search跑完test_add_to_cart跑的时候应用被意外重启了脚本不要直接失败而应该在 fixture 里重新进入状态。用例能做到相对独立后面做并发和执行选择时才不会一团乱。6. 把脚本改造成“企业级”骨架配置、报告、多设备、CI6.1 先把设备能力配置化脚本里直接写死包名、设备名、udid短期能跑换一台设备就要改代码。企业里多套环境一定不会只在一台模拟器上跑所以要把 capabilities 抽出来。可以用 YAML 或 JSON 文件保存设备配置。不同环境用不同配置文件。下面是一个简化示例android_local: platformName: Android udid: emulator-5554 appPackage: com.netease.yanxuan appActivity: 来自dumpsys的Activity noReset: true automationName: UiAutomator2Python 启动 driver 时读取这个配置文件再把配置转给 Appium。这样模拟器、真机、CI 环境可以各自维护一套配置核心代码不用改。6.2 多设备并行不等于直接开线程很多人以为多设备并行就是用 Python 的多线程跑测试用例这个理解还需要完善。Appium 的会话和具体设备绑定。同一台模拟器上如果同时启动多个会话就会互相争抢界面焦点点击可能点到别的页面。因此一台设备同一时间只能跑一个会话。多设备对应多个 Appium Server 实例或在不同端口启动同一 Server 管理的会话。测试数据、截图目录、报告文件都要按 udid 分开。简单实现是每个设备启动一个独立进程设置独立端口。设备 A 用 4723设备 B 用 4724测试脚本把 udid、端口、输出目录作为外部参数传入。6.3 失败重试一定要有边界用例失败后自动重跑看起来很美好但一定要控制重试次数和重试范围。如果脚本在首页加载时就失败了整个用例重跑三遍只会把日志弄得更复杂。我通常只对两类情况做重试网络抖动导致的元素加载超时。弹窗运营位短暂出现导致的点击无效。重试前先记录第一次失败原因再清理现场。比如回到首页或重启应用再执行同一条用例。如果重试两次仍然失败不再继续直接把失败结果写入报告。不要把所有断言失败都自动重试。断言失败说明业务逻辑可能真的不对自动重试只会掩盖问题。6.4 报告和日志怎么接测试报告使用 Allure 是现在比较常见的做法。在 pytest 中加上 allure 装饰器后可以记录用例步骤、链接、附件。import allure allure.story(搜索流程) allure.title(搜索商品并进入详情) def test_search_flow(driver_fixture): with allure.step(输入关键词): pass with allure.step(点击搜索结果): pass执行测试时加上pytest -s test_yanxuan_flow.py --alluredirallure-results执行完后生成报告allure generate allure-results -o allure-report --cleanAllure 报告能看到用例执行时间、失败步骤、截图和源码比命令行输出直观得多。企业里如果还要接 CI通常会用 GitLab CI、Jenkins 或类似平台定时执行这些命令再把报告上传到内部页面。6.5 多设备并行时的资源冲突多设备并行会遇到资源冲突最常见的是测试账号冲突。如果两台设备同时用同一个网易严选账号登录后登录的设备会把前一台设备踢下线。所以做并行测试时要准备多个账号或者在用例里清理登录态并分别使用不同账号。截图目录也要按设备命名。比如output/emulator-5554/和output/emulator-5556/不然多台设备同时失败时后写入的截图会覆盖前面的截图。7. 高频报错和排查顺序按这个顺序找问题最快7.1 排查顺序是固定的遇到 Appium 脚本跑不起来时不要一上来改代码。先按顺序检查看报错来自 Appium Server 还是来自 Python 客户端。确认设备在线adb devices。确认 Appium Server 是否监听了预期端口。确认 capabilities 里 appPackage 和 appActivity 是否正确。确认网易严选是否真的启动到了预期页面。确认控件是否存在用 Appium Inspector 刷新页面看一次。确认等待逻辑页面是新加载完成还是你给的时间不够。确认权限和资源Windows 防火墙、端口占用、磁盘空间。这套顺序适合 80% 的初学问题。很多人卡住的点不是代码逻辑而是设备没连上或 appActivity 写错了。7.2 常见报错汇总现象大概率原因先检查什么创建会话失败设备 not foundudid 写错或设备未连接adb devices提示 activity 不存在appActivity 写错或 APP 不是从启动页开始dumpsys 查当前页面启动后秒退APP 版本与安卓版本不兼容或 noReset 导致数据异常手动打开 APP看能否正常进入首页元素找不到 NoSuchElement控件 ID 变了或页面还没加载完Inspector 刷新看控件树点击了但无反应控件被弹窗遮挡或 not clickable查看截图点击前先关闭弹窗输入框 send_keys 后没有文字输入框没有聚焦或输入法弹窗遮挡先 click 再 send_keys超时时间很长异步接口慢或 XPath 定位太耗时改用 resource-id增加显式等待两台设备串号用例没有绑定独立 udid 和输出目录检查多设备并发时传给 driver 的参数7.3 不要忽略日志里的原生错误Appium 日志里会输出页面加载时的原生异常这比 Python 报错信息更有用。比如页面里有 JavaScript 崩溃、网络请求超时、原生控件不可见Appium 日志会留下痕迹。遇到“看起来 APP 启动了但脚本找不到元素”的情况先不急着加 sleep。打开 Appium Server 的日志看页面加载过程中有没有网络报错或页面异常。很多问题可能是测试机连接的网络不稳定不是脚本问题。8. AI 驱动和自动化的关系不要本末倒置8.1 AI 定位是好补丁但不是第一课现在很多讨论提到“AI 驱动 APP 端自动化”。如果把 AI 理解成“自动帮我写所有定位器”目前还不现实。AI 可以通过自然语言生成一部分代码也可以辅助解析页面结构但这些都依赖稳定的基础能力。如果 Appium 会话都建不起来元素等待策略混乱点击前不知道弹窗在哪里那么 AI 生成再多的代码也跑不稳定。自动化项目要先把基础设施做好再考虑用大模型辅助生成用例和选择器。把它当成提效工具而不是替代基本功的方案。8.2 真正的提升来自三层能力第一层是能力会用 Appium 完成启动、定位、点击、输入、断言。第二层是稳定性能处理等待、弹窗、失败重试、日志截图。第三层是工程化能配置化、多设备并行、接 CI、生成报告。这三层正好对应 3 天的拆法。别人说“3天学会”如果只学会第一层那是表面能力如果能做到第三层才算真正能到企业项目里做贡献。8.3 最后保留一点经验我个人建议先不要盲目追求同时跑几十台设备。先把一条用例在同一台设备上连续跑 5 次如果每次通过再加入第二条、第三条。如果连续跑 10 次出现偶发失败优先处理偶发原因而不是扩充用例数量。自动化测试最怕的是“用例通过率不稳定”用例一大堆但每次跑都有不同失败点最后就只能天天清理垃圾结果。网易严选这个项目很适合用来暴露这些问题。页面真实、控件真实、网络真实、版本也在更新。你能让它稳定跑通再换到其他 APP 时就不会被“看起来能跑实际上到处踩坑”的状态困住。3 天的目标不是跑满所有功能而是把一条主流程做成一个能长期维护的自动化骨架。这个骨架一旦建好后面加用例、加设备、接 CI 就只是重复劳动而不是每次都从环境配置开始推倒重来。