企业官网建设流程全解析

最近我按“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 基础软件清单

在跑网易严选之前，确认机器上已经装齐了这些。缺任何一个，后面都可能出现“脚本看起来没问题，但就是启动不了”的情况。

网上很多教程会直接写“下载 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/activate

Windows 上执行appium_env\Scripts\activate。

虚拟环境激活后，再安装 Appium-Python-Client、pytest 和 allure-pytest：

pip install Appium-Python-Client pytest pytest-xdist allure-pytest

这里解释一下为什么不用全局安装。Python 项目经常遇到依赖冲突，今天装 Appium 客户端，明天可能装 requests、yaml、openpyxl。如果全部塞进系统环境，一旦某个依赖版本升级，之前能跑的脚本可能突然不能运行。虚拟环境可以把项目依赖隔离起来，出问题后直接删除重建，不会影响其他项目。

2.3 启动顺序：先连设备，再启动 Server，最后启动脚本

很多人第一次跑网易严选失败，不是代码问题，而是启动顺序不对。

正确的启动顺序是：

1. 启动模拟器或连接真机并开启 USB 调试。
2. 执行adb devices，确认设备已经显示为 device。
3. 启动 Appium Server，或者启动 Appium Desktop 里的服务。
4. 让 Appium Inspector 连接设备并打开网易严选。
5. 确认能看见网易严选页面后，再运行 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-id
• class
• text
• content-desc
• bounds
• enabled
• clickable

这些属性才是脚本定位的依据。比如你要点击搜索框，先在页面树里找到搜索框控件，看它是否 clickable，text 是什么。如果没有 resource-id，再用文本或 class 组合定位。

3.2 为什么不要只看 text 或 XPath

只看 text 的问题很明显：网易严选的文本经常变，搜索框提示文案可能从“搜索商品”改成“搜索严选好物”，一旦文案更新，脚本就会失效。

只看绝对 XPath 的问题更严重。APP 页面结构经常变化，XPath 里的/android.view.ViewGroup[2]/android.widget.FrameLayout[3]/...只要层级里多一个节点，整条路径就废了。而且 Appium 执行 XPath 定位速度比 resource-id 慢，页面越复杂越明显。

更合理的定位优先级是：

3.3 定位的实操顺序

打开网易严选首页后，我会先按这个顺序做一次元素盘点：

1. 搜索框：通常带 text 提示或可在顶部区域点击。
2. 底部 Tab：首页、分类、购物车、个人中心等，一般有固定文案。
3. 首页商品卡片：可能是整个卡片可点击，图片不一定有 resource-id，要借助卡片区域或 text。
4. 搜索结果的商品标题：看商品标题完整文本或者部分文本。
5. 加购按钮：确认按钮可点击，并且点击后有“已加入购物车”之类的反馈。
6. 购物车商品项：确认名称、价格、数量等元素存在。

点击元素前先问三个问题：这个控件一定可见吗？是否被弹窗遮挡？是不是需要滚动后才能显示？这三个问题解决不了，写在脚本里的点击大概率会超时。

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(f"output/{case_name}_{ts}.png") with open(f"output/{case_name}_{ts}.xml", "w", encoding="utf-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. 把脚本改造成“企业级”骨架：配置、报告、多设备、CI

6.1 先把设备能力配置化

脚本里直接写死包名、设备名、udid，短期能跑，换一台设备就要改代码。企业里多套环境一定不会只在一台模拟器上跑，所以要把 capabilities 抽出来。

可以用 YAML 或 JSON 文件保存设备配置。不同环境用不同配置文件。下面是一个简化示例：

android_local: platformName: Android udid: emulator-5554 appPackage: com.netease.yanxuan appActivity: "来自dumpsys的Activity" noReset: true automationName: UiAutomator2

Python 启动 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 --alluredir=allure-results

执行完后生成报告：

allure generate allure-results -o allure-report --clean

Allure 报告能看到用例执行时间、失败步骤、截图和源码，比命令行输出直观得多。企业里如果还要接 CI，通常会用 GitLab CI、Jenkins 或类似平台定时执行这些命令，再把报告上传到内部页面。

6.5 多设备并行时的资源冲突

多设备并行会遇到资源冲突，最常见的是测试账号冲突。如果两台设备同时用同一个网易严选账号登录，后登录的设备会把前一台设备踢下线。所以做并行测试时要准备多个账号，或者在用例里清理登录态并分别使用不同账号。

截图目录也要按设备命名。比如output/emulator-5554/和output/emulator-5556/，不然多台设备同时失败时，后写入的截图会覆盖前面的截图。

7. 高频报错和排查顺序：按这个顺序找问题，最快

7.1 排查顺序是固定的

遇到 Appium 脚本跑不起来时，不要一上来改代码。先按顺序检查：

1. 看报错来自 Appium Server 还是来自 Python 客户端。
2. 确认设备在线：adb devices。
3. 确认 Appium Server 是否监听了预期端口。
4. 确认 capabilities 里 appPackage 和 appActivity 是否正确。
5. 确认网易严选是否真的启动到了预期页面。
6. 确认控件是否存在：用 Appium Inspector 刷新页面看一次。
7. 确认等待逻辑：页面是新加载完成，还是你给的时间不够。
8. 确认权限和资源：Windows 防火墙、端口占用、磁盘空间。

这套顺序适合 80% 的初学问题。很多人卡住的点不是代码逻辑，而是设备没连上，或 appActivity 写错了。

7.2 常见报错汇总

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 就只是重复劳动，而不是每次都从环境配置开始推倒重来。