前端5月30日 20:38
Appium 的核心特性是什么？为什么适合跨平台移动自动化？Appium 是基于 W3C WebDriver 协议的移动端自动化框架，核心价值是用同一套测试思路覆盖 Android、iOS、移动 Web 和混合应用。它不是自己去“点屏幕”，而是由客户端把命令发给 Appium Server，再交给 UiAutomator2、XCUITest 等平台驱动执行。适合黑盒回归、跨平台主流程验证和 CI 冒烟测试，但不适合替代单元测试或追求极限执行速度的白盒 UI 测试。
## 追问
### Appium 和 Espresso、XCUITest 怎么取舍？
只测 Android 且能接触源码时，Espresso 通常更快更稳；只测 iOS 时，XCUITest 的系统集成更直接。Appium 的优势是跨平台和黑盒测试。
### Appium 为什么不需要重新编译 App？
它通过系统自动化框架驱动已安装应用，不要求在业务代码里埋测试 SDK。边界是安全控件、系统弹窗或 WebView 调试开关可能仍要测试包配合。
### 元素定位最容易踩什么坑？
最常见的是依赖 XPath 全路径，页面层级变化就全挂。更稳的是让客户端补 accessibility id 或 resource-id。
### 混合应用测试要注意什么？
进入 WebView 前要确认调试已开启，并等待 context 出现后再切换。切回原生时也要显式切到 NATIVE_APP。
### CI 里跑 Appium 有哪些边界？
CI 适合跑登录、下单、关键链路等少量稳定用例。设备占用、模拟器启动和网络抖动都会放大失败率。
## 写段命令
```bash
npm i -g appium
appium driver install uiautomator2
appium driver install xcuitest
appium --base-path /wd/hub
```标签
Appium
Appium 是一个开源的、跨平台的自动化测试工具，用于原生、移动Web和混合应用程序的自动化测试。它支持 iOS、Android 和 Windows 应用的自动化，允许使用诸如 Java、Python、JavaScript (Node.js)、Ruby、C# 等多种编程语言来编写测试脚本。
前端5月30日 20:13
Appium 测试运行慢时如何定位和优化？Appium 测试慢，通常是定位、等待、会话创建、设备资源和网络链路叠在一起变慢。优化前先量化：哪一步耗时最长，是启动应用、找元素、切 WebView、执行手势，还是每条命令都慢。没有数据就调参数，很容易把稳定性也一起调没。
## 追问
### 元素定位为什么会拖慢 Appium？
每次定位都要跨进程和设备通信，复杂 XPath 还会遍历 UI 树。优先用 id、accessibility id，其次平台特定选择器。
### 隐式等待和显式等待怎么取舍？
隐式等待影响几乎每次查找，定位失败尤其拖时间；显式等待只等关键条件，更容易控制成本。少用固定 sleep。
### 会话复用一定更快吗？
会话复用能省安装、启动和授权时间，但会带来脏数据、登录态残留和用例污染。冒烟可用 noReset，首次启动类用例要干净环境。
### 并行为什么有时更慢？
瓶颈可能在 Appium Server、设备 CPU、USB、模拟器资源和后端环境。Android 并行要给每台设备独立 udid 和 systemPort。
### 性能监控看什么？
先看 Appium 命令耗时，再看应用 CPU、内存、网络和日志。所有命令都慢查网络和设备负载，只有定位慢就查选择器。
## 写段配置
```javascript
const capabilities = {
automationName: 'UiAutomator2',
noReset: true,
disableWindowAnimation: true,
newCommandTimeout: 60
};
```前端5月30日 20:13
Appium 元素找不到或启动失败时如何排查？Appium 排查不要一上来就改脚本，先把链路拆开：Server 是否可连、设备是否在线、应用是否成功安装和启动、元素是否真的在当前上下文里。很多“找不到元素”不是定位写错，而是页面没加载、弹窗挡住、WebView 没切上下文，或测试连到另一台设备。
## 追问
### Appium Server 连不上先看什么？
先确认端口和服务状态，检查 Appium 版本、4723 是否监听、URL 是否还在用旧的 `/wd/hub`，以及防火墙或代理。
### 设备连接失败怎么区分？
先脱离 Appium，用 `adb devices` 或 Xcode 设备列表验证设备是否在线。多设备时必须显式写 udid。
### 元素找不到为什么不能只换 XPath？
XPath 复杂且慢，层级变化就失效。先用 Appium Inspector 确认元素是否存在，再优先用 id、accessibility id 或平台选择器。
### 应用安装或启动失败卡在哪里？
安装失败查路径、包损坏、设备空间和签名冲突；启动失败看 appPackage、appActivity、权限弹窗和 logcat 崩溃日志。
### 点击滑动失败怎么判断？
先看元素是否可见、可点击、是否被浮层遮挡，再考虑坐标点击。滑动建议用屏幕比例而非固定像素。
## 写段命令
```bash
lsof -i :4723
appium --log-level debug -p 4723
adb devices
```前端5月30日 20:13
Appium 如何测试混合应用并稳定切换 WebView？Appium 测混合应用，关键是先分清当前操作发生在原生视图还是 WebView。原生导航栏、权限弹窗、底部 Tab 通常留在 NATIVE_APP；H5 页面里的按钮、输入框、DOM 文案要切到 WEBVIEW 后再用 CSS、XPath 或 WebDriver 定位。难点不在 API，而在 WebView 什么时候出现、Chromedriver 是否匹配、页面是否加载完成。
## 追问
### 什么时候需要切换到 WebView？
只有目标元素属于 H5 DOM 时才切换。原生控件不要硬切 WebView 找，系统弹窗、原生返回按钮、底部导航栏通常仍在 NATIVE_APP。
### WebView 上下文找不到怎么排查？
先确认 Android 应用开启 WebView 调试，再检查页面是否加载完成。iOS 还要确认 Web Inspector、证书和真机调试权限。
### Chromedriver 版本不匹配会怎样？
可能能看到上下文，但切换后查 DOM 或执行 JS 报 session 错误。要配置 chromedriverExecutableDir 或自动下载策略。
### 定位元素优先用什么？
WebView 内优先稳定 CSS 或 data-testid，原生侧优先 accessibility id 或 resource-id。不要依赖易变层级 XPath。
### 切换后为什么还要等待？
上下文切换只说明进入执行环境，不代表页面元素可交互。要显式等待目标元素可见或可点击。
## 写段代码
```javascript
const contexts = await driver.getContexts();
const webview = contexts.find(c => c.includes('WEBVIEW'));
if (webview) await driver.context(webview);
```前端5月30日 20:13
Appium 如何进行数据驱动测试才稳定？Appium 做数据驱动测试，核心是把测试步骤和测试数据拆开：脚本负责打开页面、输入、点击、断言，账号、密码、预期文案、设备差异、边界值放到 JSON、CSV、Excel、数据库或接口里。这样新增场景时通常只改数据，不改自动化逻辑，回归覆盖会稳定很多。
## 追问
### 数据源选 JSON、CSV 还是 Excel？
JSON 适合层级结构，CSV 适合简单二维数据，Excel 对测试同学友好但 CI 里容易遇到空值类型、日期格式问题。
### 最容易踩什么坑？
测试数据之间互相污染，比如同一手机号被多条用例注册。另一个坑是只换输入不换断言，跑很多数据却没有真正覆盖业务规则。
### 一条数据失败后要不要继续？
回归场景建议继续跑，并记录 caseId、设备、输入数据、截图和关键日志。冒烟测试可以关键链路失败就中止。
### 动态生成数据好不好？
手机号、订单号适合动态生成；空密码、特殊字符等边界值最好显式写在文件里。动态数据还要有清理逻辑。
### 和 Page Object 怎么配合？
Page Object 管页面操作，数据驱动管输入和预期。用例层读取数据后调用页面方法，断言也要带 caseId。
## 写段代码
```javascript
for (const tc of require('./login-cases.json').testCases) {
it(`${tc.id} ${tc.description}`, async () => {
await loginPage.login(tc.username, tc.password);
expect(await loginPage.resultText()).toBe(tc.expected);
});
}
```前端5月27日 21:22
Appium 的 Desired Capabilities 是什么？Appium 的 Desired Capabilities 是一组键值对，用于告诉 Appium Server 如何配置自动化测试会话——包括在哪个平台、哪台设备、启动哪个应用、使用哪个自动化引擎。客户端以 JSON 格式发送这些参数，服务端据此创建对应的测试环境并返回 session ID。
## 核心参数有哪些？
必须掌握的几个关键参数：
- **platformName**：目标平台，值为 Android / iOS / Windows，必填
- **deviceName**：设备名称，真机或模拟器均可，必填
- **automationName**：自动化引擎，Android 用 UiAutomator2，iOS 用 XCUITest
- **app**：待测应用的路径或远程 URL（.apk / .ipa）
```json
{
"platformName": "Android",
"deviceName": "Pixel 5",
"automationName": "UiAutomator2",
"app": "/path/to/app.apk"
}
```
## Android 和 iOS 有什么区别？
这是面试高频追问。两者差异主要体现在应用标识和引擎配置上：
**Android 专属**：用 `appPackage` 指定包名，用 `appActivity` 指定启动 Activity。例如 `appPackage: "com.example.app"`、`appActivity: ".MainActivity"`。
**iOS 专属**：用 `bundleId` 标识应用，真机测试需要配置 `xcodeOrgId` 和 `xcodeSigningId` 完成签名，模拟器则设置 `udid: "auto"` 即可。
引擎选择也不同——Android 默认 UiAutomator2，iOS 默认 XCUITest，选错引擎会直接导致会话创建失败。
## noReset 和 fullReset 有什么区别？
- **noReset: true** — 会话结束后保留应用数据，下次启动不重装，适合调试阶段复用状态
- **fullReset: true** — 每次会话前卸载应用并重装，确保干净环境，适合持续集成场景
两者互斥，不能同时为 true。面试中常追问"你项目中用的哪个，为什么"，回答时要结合实际场景。
## 常见踩坑点
1. **appActivity 前缀漏写点号** — 应写 `.MainActivity` 而非 `MainActivity`，否则 Appium 报找不到 Activity
2. **automationName 与平台不匹配** — iOS 用了 UiAutomator2 会直接报错，务必对齐平台
3. **真机 udid 填错** — 可通过 `adb devices`（Android）或 Xcode 设备列表（iOS）确认
## 追问：如何在多平台项目中管理 Capabilities？
将 Android 和 iOS 配置拆分为独立文件，运行时通过环境变量切换：
```javascript
const caps = process.env.PLATFORM === 'ios'
? require('./ios.config')
: require('./android.config');
```
这样既避免配置混乱，又便于 CI 流水线按平台并行执行。前端5月27日 21:18
Appium 如何进行移动 Web 测试？Appium 支持对移动浏览器中的 Web 应用进行自动化测试，核心思路是通过设置 `browserName` 能力让 Appium 驱动移动端 Chrome 或 Safari，然后用标准 WebDriver 协议操作页面元素。
## Android Chrome 与 iOS Safari 配置
Android 端将 `browserName` 设为 `Chrome`，Appium 会自动调用 Chromedriver 驱动浏览器：
```javascript
const caps = {
platformName: 'Android',
browserName: 'Chrome',
deviceName: 'Pixel 5'
};
```
iOS 端将 `browserName` 设为 `Safari`，Appium 通过 XCUITest 驱动 Safari：
```javascript
const caps = {
platformName: 'iOS',
browserName: 'Safari',
deviceName: 'iPhone 14',
automationName: 'XCUITest'
};
```
关键区别：Android 需要 Chromedriver 版本与设备 Chrome 版本匹配，版本不匹配时会报 SessionNotCreatedException，需通过 `chromedriverExecutable` 指定驱动路径或让 Appium 自动更新。
## 移动 Web 与原生 App 测试的差异
移动 Web 测试用 CSS 选择器和 XPath 定位 HTML 元素，而非 `accessibility id` 或 `uiautomator`。触摸交互需要用 W3C Actions API 模拟手势，比如滑动：
```javascript
await driver.actions([{
type: 'pointer', id: 'finger',
parameters: { pointerType: 'touch' },
actions: [
{ type: 'pointerMove', origin: 'viewport', x: 200, y: 800 },
{ type: 'pointerDown' },
{ type: 'pointerMove', origin: 'viewport', x: 200, y: 200 },
{ type: 'pointerUp' }
]
}]);
```
另一个常见陷阱：移动浏览器的地址栏会自动收起，导致元素坐标偏移，建议用元素相对定位而非绝对坐标。
## 响应式布局与横竖屏测试
用 `driver.setRect()` 改变窗口尺寸验证响应式断点，用 `driver.rotate()` 切换横竖屏：
```javascript
await driver.setRect({ width: 375, height: 667 });
// 验证移动端布局
const menu = await driver.findElement(By.css('.mobile-menu'));
assert(await menu.isDisplayed());
await driver.rotate({ screen: 'LANDSCAPE' });
// 验证桌面端布局
```
## 常见问题与排查
**元素定位失败**：移动浏览器渲染的 DOM 可能与桌面不同，用 `driver.getPageSource()` 检查实际 DOM 结构，注意浏览器可能注入了 meta viewport 或自定义样式。
**页面加载超时**：移动网络延迟大，需要设置更长的隐式等待，或用显式等待：
```javascript
await driver.wait(until.elementLocated(By.id('content')), 15000);
```
**Chromedriver 版本冲突**：Appium 2.0 默认不内置 Chromedriver，需安装 `appium-chromedriver` 扩展，或通过 `--chromedriver-version` 指定版本。
## 追问方向
- 混合应用中如何切换 WebView 上下文与原生上下文？用 `driver.getContexts()` 获取所有上下文后 `driver.switchTo().context('WEBVIEW_xxx')`。
- 如何在真机上抓取移动浏览器网络请求？通过 Chromedriver 的 CDP 支持（`cdpPort` 能力）或代理工具如 mitmproxy。
前端5月27日 21:17
Appium 如何进行元素定位？Appium 提供了多种元素定位策略，面试中需重点掌握各策略的适用场景和优先级选择。
## 核心答案
Appium 支持 ID、Accessibility ID、XPath、Class Name、CSS Selector、UIAutomator（Android）、iOS Predicate、iOS Class Chain 共 8 种定位策略。**优先级从高到低**：ID / Accessibility ID > 平台专属定位器 > XPath。
**ID 定位**最稳定，Android 用 `resource-id`，iOS 用 `name`，优先选用。**Accessibility ID** 跨平台统一，Android 对应 `content-desc`，iOS 对应 `accessibilityIdentifier`，是跨平台方案的首选。**XPath** 功能强但性能差，遍历 DOM 树开销大，且易因 UI 变动失效，应作为兜底方案。
平台专属定位器性能优于 XPath：Android 的 **UIAutomator** 用 `UiSelector` 组合条件查询，iOS 的 **Predicate String** 类似 SQL WHERE 子句，**Class Chain** 比 Predicate 更简洁，三者均在原生引擎执行，速度快。
```javascript
// 优先：ID 定位
driver.findElement(By.id('submit_button'));
// 跨平台：Accessibility ID
driver.findElement(By.accessibilityId('submit_button'));
// 兜底：XPath（避免绝对路径）
driver.findElement(By.xpath('//android.widget.Button[@text="Submit"]'));
```
## 追问：如何提升定位稳定性？
三点原则：**缩小搜索范围**（先定位父容器再找子元素）、**显式等待**（`driver.wait(until.elementLocated(...))` 替代硬编码等待）、**缓存元素引用**（避免重复定位同一元素）。
## 追问：元素找不到怎么排查？
依次检查：定位策略是否正确、元素是否尚未加载（加显式等待）、元素是否在其他上下文中（用 `driver.getContexts()` 检查，WebView 场景需切换上下文）。若定位到多个元素，改用更精确的属性组合或 `findElements` 加索引筛选。前端5月27日 21:17
Appium 如何进行手势操作？Appium 手势操作依赖 TouchAction（1.x）和 W3C Actions API（2.x 推荐）实现，核心是通过 press、moveTo、release 组合链模拟触摸行为，所有手势必须调用 perform() 才会执行。
## 核心手势怎么写？
**点击**：`element.click()` 最为直接；坐标点击用 `driver.touchActions([{action:"tap", x:100, y:200}])`。
**长按**：W3C Actions 写法——`driver.actions({async:true}).move({origin:el}).press().pause(2000).release().perform()`，pause 控制按压时长。
**滑动**：本质上就是 press → moveTo → release 的坐标链。上滑把 startY 设大、endY 设小即可，横向同理。
**拖拽**：`driver.actions({async:true}).dragAndDrop(src, target).perform()`，底层与滑动一致，只是起止都是元素。
## 多点触控怎么处理？
缩放（pinch/spread）需要两根手指同时操作。Appium 1.x 用 MultiTouchAction 分别添加两个 TouchAction 再 perform；2.x 推荐用 W3C PointerInput 创建多个 pointer，各自执行 press/move/release 后一起 perform。
关键点：两指必须真正"同时"，不是串行执行。用 MultiTouchAction 时两个 action 是并行发送的。
## 坐标怎么算才稳定？
绝对坐标在不同设备上必定偏移。正确做法是通过 `element.getRect()` 取元素位置后算中心点，或用屏幕尺寸算百分比坐标（如 `size.width * 0.8`）。这样换设备不会崩。
## 手势操作最常踩什么坑？
- **元素不可见就操作**——必须先 wait 直到 elementIsClickable
- **动画没结束就操作**——适当 sleep 或等动画元素消失
- **Appium 2.x 还在用 TouchAction**——已废弃，切换到 W3C Actions API
- **iOS 和 Android 手势 API 有差异**——iOS 支持 mobile: 系列扩展命令（如 mobile: swipe），Android 部分手势需要 UiAutomator2 配合
## 追问：Appium 1.x 的 TouchAction 和 2.x 的 W3C Actions 有什么区别？
TouchAction 是 Appium 自定义 API，链式调用 press/wait/release，2.x 起已废弃。W3C Actions 是 WebDriver 标准协议，通过 PointerInput + Sequence 描述动作序列，跨浏览器/跨平台兼容性更好。迁移时核心变化是把 TouchAction 链替换为 actions().move().press().pause().release() 调用链。前端5月27日 21:17
Appium 如何与测试框架集成？## 核心答案
Appium 本质是 WebDriver 协议的 HTTP Server，与测试框架的集成方式是：**框架负责用例组织和生命周期管理，Appium 负责驱动设备**。两者通过 Appium Driver 实例连接——在框架的 setup 中初始化 Driver，在 teardown 中销毁，测试方法内通过 Driver 操作元素。
选型上，JavaScript 生态用 Jest 或 Mocha，Java 用 TestNG，Python 用 PyTest。选择依据不是哪个"更好"，而是你项目的语言栈和团队习惯。
## 集成要点
**1. 生命周期绑定**
无论哪个框架，集成的核心都是把 Appium Driver 的创建和销毁挂到框架的生命周期钩子上：
- Mocha：`before` / `after`
- Jest：`beforeAll` / `afterAll`
- TestNG：`@BeforeClass` / `@AfterClass`
- PyTest：`@pytest.fixture` + `yield`
不要在每个测试用例里重复创建 Driver，这会拖慢执行速度并占用设备资源。
**2. 数据驱动**
PyTest 的 `@pytest.mark.parametrize`、TestNG 的 `@DataProvider`、Jest 的 `each` 都支持参数化。用外部数据源（JSON、CSV）驱动测试，避免硬编码，也方便覆盖多设备或多账号场景。
**3. CI 集成**
Jenkins Pipeline 或 GitHub Actions 中启动 Appium Server 作为后台进程，然后触发测试命令，最后收集 JUnit XML 报告。关键是确保构建环境预装 Node.js、Appium 和对应平台的 SDK。
## 常见坑点
- **并行冲突**：同一台机器上的一个 Appium Server 实例只能服务一个会话，并行测试需要启动多个 Server 实例并分配不同端口
- **Driver 泄漏**：测试异常退出时 teardown 未执行，Driver 未销毁，导致设备被占用。解决方案是用 `try/finally` 或框架的 `afterAll` 强制清理
- **超时不稳定**：移动设备响应慢于桌面浏览器，隐式等待建议设 5-10 秒，显式等待优于隐式等待
## 追问方向
- Appium 与 Selenium Grid 如何配合实现多设备并行？
- PO 模式在 Appium 项目中如何分层？BasePage 应封装哪些能力？
- Appium 2.0 的 Driver 插件机制对框架集成有什么影响？前端5月27日 21:16
Appium 的等待机制有哪些？## 三种等待机制
Appium 继承了 Selenium WebDriver 的等待体系，核心有三种：
**隐式等待** — 全局生效，设置一次后所有 `find_element` 自动等待。只对元素查找有效，对点击、输入等操作无效。
```python
driver.implicitly_wait(10) # 全局等待10秒
```
**显式等待** — 针对特定条件等待，是实际项目中最常用的方式。默认每 0.5 秒轮询一次，条件满足立即继续执行。
```python
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
element = WebDriverWait(driver, 10).until(
EC.element_to_be_clickable((By.ID, "submit"))
)
```
**强制等待** — `time.sleep()` 固定阻塞，仅在必须等固定时间的场景使用（如数据推送、短间隔操作），正常测试中应避免。
## 隐式等待 vs 显式等待
| | 隐式等待 | 显式等待 |
|---|---|---|
| 作用范围 | 全局所有 find 操作 | 单个元素或条件 |
| 能否判断元素状态 | 不能，只判断是否存在 | 能，可判断可见、可点击等 |
| 灵活性 | 低 | 高，支持自定义条件 |
实际项目中两者**不要混用**。混用会导致等待时间不可预测，官方也不推荐。通常选一种即可，优先显式等待。
## 面试怎么答
先说结论：Appium 有三种等待——隐式、显式、强制等待，实际项目优先用显式等待。
再展开：隐式等待全局生效但只能判断元素存在，显式等待灵活精确可判断元素状态，强制等待只在特殊场景使用。关键是两者不要混用。
## 追问
- 隐式等待和显式等待同时设置会怎样？— 等待时间叠加，行为不可预测，应避免混用
- 显式等待的轮询间隔能改吗？— 能，`WebDriverWait(driver, 10, poll_frequency=1)` 第三个参数
- 页面加载超时怎么设置？— `driver.set_page_load_timeout(30)`前端5月27日 21:15
Appium 的工作原理是什么？Appium 采用客户端-服务器架构，通过 WebDriver 协议将测试脚本翻译成平台特定的自动化指令，再由设备端引擎执行操作并返回结果。核心流程：Client 发送 HTTP 请求 → Appium Server 解析命令 → 自动化引擎（UiAutomator2/XCUITest）在设备上执行 → 结果沿原路返回。
## 为什么 Appium 能跨平台？
关键在于 Appium Server 充当了翻译层。Client 端统一使用 WebDriver 协议发送命令，Server 根据平台选择对应引擎——Android 走 UiAutomator2，iOS 走 XCUITest——将同一套 API 调用转换成不同平台能理解的指令。这就是"一套代码，多端运行"的实现基础。
## 会话是怎么建立的？
Client 向 Appium Server 的 4723 端口发送 POST /session 请求，携带 Desired Capabilities（平台、设备名、应用路径等）。Server 解析这些参数后选择引擎、启动应用、建立会话，返回 session ID。后续所有操作都通过这个 ID 关联。
## 元素定位和操作怎么执行？
定位请求（ID、XPath、Accessibility ID）到达 Server 后，被转换为平台特定的查询语句，由引擎在设备上执行查找。操作命令（click、sendKeys）同理，Server 将其翻译成引擎 API 调用。整个过程对 Client 透明，开发者只需调用标准 WebDriver 方法。
## 混合应用如何处理 WebView？
Appium 通过上下文切换实现。获取可用上下文列表后，切换到 WEBVIEW 上下文即可用 CSS 选择器操作 WebView 内元素，切回 NATIVE_APP 则操作原生控件。本质是两套引擎交替工作。
## 追问：Appium 2.0 有什么变化？
Appium 2.0 将驱动拆分为独立插件（Driver），通过 appium driver install 按需安装，不再内置。同时支持 WebSocket 通信替代纯 HTTP，降低延迟。架构层面仍是 C/S 模式，但扩展性和维护性大幅提升。前端5月27日 21:15
Appium 与 Selenium 有什么区别？## 核心区别
Appium 测移动端，Selenium 测 Web 端，这是二者最根本的差异。虽然都基于 WebDriver 协议，但架构和应用场景完全不同。
## 测试对象
Selenium 只能操作浏览器中的 Web 页面，无法触及原生 App。Appium 则覆盖原生应用、混合应用和移动端 Web 页面三类场景。如果你的测试目标跑在手机上，只能选 Appium。
## 架构差异
Selenium 的架构链路短：测试脚本 → WebDriver → 浏览器驱动 → 浏览器。Selenium 4 之后不再需要独立 Server，直接通过驱动与浏览器通信。
Appium 多了一层中转：测试脚本 → Appium Client → Appium Server → 平台自动化引擎 → 移动设备。Android 端走 UiAutomator2 或 Espresso，iOS 端走 XCUITest。这层 Server 负责把 WebDriver 命令翻译成各平台能识别的指令。
## 定位与交互
Appium 继承了 Selenium 全部定位策略（id、className、xpath 等），并扩展了移动端特有的 accessibilityId、androidUIAutomator、iOSNsPredicateString 等。
交互方面，Selenium 仅支持 click、sendKeys 等简单操作。Appium 额外支持滑动、多点触控、长按等手势，还能在原生视图和 WebView 之间切换上下文——这是混合应用测试的刚需。
## 设备能力
Selenium 的 Desired Capabilities 只需指定浏览器名和版本。Appium 则要配置平台版本、设备名、app 包路径、udid、自动化引擎等，复杂度高出几个量级。
## 怎么选
测 Web 应用选 Selenium，测移动应用选 Appium，两者也可以在同一项目中配合使用。选型的关键不是哪个更好，而是你要测什么。
## 追问
- Appium 为什么选择基于 WebDriver 协议而不是自建协议？——复用成熟协议降低学习成本，且 Selenium 生态的工具链可直接迁移。
- 混合应用测试时，NATIVE_APP 和 WEBVIEW 上下文切换失败怎么排查？——先确认 WebView 调试已开启，再检查 chromedriver 版本与 WebView 内核是否匹配。
- Selenium 4 的相对定位器能否在 Appium 中使用？——可以，Appium Client 基于 Selenium Client 封装，大部分新特性自动继承。前端2024年7月20日 14:49
如何在安卓版Ubuntu中设置Appium要在安卓版Ubuntu上设置Appium，你可以按照以下步骤进行：
1. **安装Java**：
- 首先，确保已经安装了Java开发环境。可以通过在终端运行 `java -version` 来检查Java是否已安装。
- 如果没有安装，可以使用以下命令安装Java：
```bash
sudo apt update
sudo apt install openjdk-11-jdk
```
2. **安装Node.js 和 npm**：
- Appium需要Node.js，可以使用以下命令安装：
```bash
sudo apt install nodejs
sudo apt install npm
```
3. **安装Appium**：
- 通过npm全局安装Appium：
```bash
npm install -g appium
```
4. **安装Android SDK**：
- 需要Android SDK来进行Android应用的自动化测试。
- 下载并解压Android SDK，然后将其路径添加到环境变量中：
```bash
export ANDROID_HOME=/path/to/android/sdk
export PATH=$PATH:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools
```
5. **配置环境变量**：
- 设置正确的环境变量以确保所有工具都能正确找到。
- 在你的`.bashrc`或`.profile`文件中添加上述`ANDROID_HOME`和`PATH`的导出命令，然后执行`source ~/.bashrc`来应用这些更改。
6. **启动Appium服务器**：
- 使用命令行启动Appium服务器：
```bash
appium
```
7. **验证安装**：
- 为了确认一切设置正确，可以尝试运行一个简单的测试脚本来检查Appium是否能够连接到Android模拟器或真实设备。
这些步骤大致涵盖了在安卓版Ubuntu上安装和配置Appium的过程。确保所有工具和依赖项都正确安装，并且环境变量正确设置，这样Appium就能正确地与Android SDK和Java进行通信。