AEStudio跨平台UI自动化测试框架实战指南

1. 关于AEStudio，我为什么想写这份手册

这几年移动端和跨平台应用的测试工作越来越复杂，光靠手点或者单一平台的自动化工具，很难覆盖全链路场景。AEStudio是我在实际项目里用了很久的一套跨平台UI自动化测试解决方案，它同时支持Android、iOS、Mac和Windows平台，解决了我在多端回归测试中的不少痛点。如果你正在寻找一个能统一管理脚本、不需要反复切换工具链的自动化测试框架，那这份手册应该能帮到你。

先说说AEStudio到底能干什么。简单来说，它是一套基于Node.js生态的UI自动化测试框架，核心能力是通过编写JavaScript/TypeScript脚本来驱动不同平台上的应用完成点击、输入、滑动、断言等操作。它和Appium这类工具最大的区别在于，它把多平台支持做进了同一个引擎里，而不是依赖不同平台的WebDriver实现来拼接，这意味着你在写用例的时候，可以用几乎同一套API去操作iOS和Android上的同一个功能点，不需要为平台差异写大量适配逻辑。

我最早接触AEStudio是在一个同时维护iOS和Android两个App的团队里，当时最头疼的就是同一套用例要在两套框架里各写一遍，维护成本翻倍，而且两边跑出来的结果还不一定一致。后来用了AEStudio，整体脚本量大概减少了四成，回归效率提升非常明显。这篇手册不是官方文档的翻译，而是我把实际项目中踩过的坑、验证过的配置、沉淀下来的规范整理成的一份实战向的使用指南，适合已经有一点自动化测试基础、想引入AEStudio的团队，也适合刚接触UI自动化、想找一个友好工具入门的测试新人。

如果硬要用一句话概括AEStudio的核心价值，那就是：用一套代码、一套API，稳定地驱动多个平台完成自动化验证，把测试工程师从“每个平台写一遍”的重复劳动里解放出来。

2. 整体设计思路与核心概念拆解

2.1 AEStudio的技术思路：为什么它能把多平台统一起来

AEStudio的设计思路可以从三个层面来理解：设备连接层、指令解析层和脚本执行层。设备连接层负责和各种终端建立通信，比如Android通过ADB，iOS通过XCTest，桌面端则通过系统级API来做事件注入。这一层做的事情，简单说就是把“操作手机/电脑”这件事抽象成统一的指令协议。

指令解析层是AEStudio比较核心的设计。它把脚本里的步骤，比如tap、inputText、swipe，翻译成各个平台能理解的原生指令，再交给设备执行。这个翻译过程在AEStudio里是做在引擎内部的，所以你在Android上写一句await driver.tap(100, 200)，在iOS上写的还是这一句，不需要像Appium那样依靠不同平台的driver类去区分，也不需要你去手工配置desired capabilities里的一大堆平台专属参数。

脚本执行层则是负责生命周期管理、断言、报告生成这些外围工作。测试用例什么时候开始、什么时候失败、失败后怎么截图、测试报告怎么汇总，都是在这一层处理的。每一层各司其职，互不干扰，这也是AEStudio比较适合工程化落地的原因。

2.2 核心概念：Session、控件树与指令链

使用AEStudio之前，有几个概念值得先弄清楚。第一个是Session。Session可以理解为你和被测设备之间的一条专用通道，脚本里的所有操作都是通过当前这个Session下发到设备上的。启动Session的时候，AEStudio会完成应用安装、权限处理、页面初始化等一系列动作，所以Session的启动速度直接影响到整个用例的执行效率。

第二个核心概念是控件树。AEStudio启动Session后会在内存里维护一份当前页面的UI层级结构，你可以通过选择器从这个树里查找元素。这个树和你在Android Studio里看到的Layout Inspector、在浏览器里看到的DOM树结构类似，是一棵层级嵌套的节点树。查找到的元素会绑定到这个树上的某个节点，后续的操作都基于这个节点进行。

第三个概念是指令链。AEStudio把一次完整的用户操作路径拆成一条链式的指令序列，比如“点击输入框 -> 输入内容 -> 点击搜索 -> 等待结果出现 -> 断言结果”，每一步都是一条指令。这种链式设计让脚本的逻辑非常清晰，也方便在中间任意一步插入等待、条件判断或者截图。理解了这三个概念，基本上就掌握了AEStudio的工作主线。

2.3 为什么选择AEStudio而不是其他方案

我知道很多人会在AEStudio和Appium、Maestro这些工具之间纠结，我简单分享一下我的对比感受。Appium非常灵活，生态成熟，但它为了兼容所有平台，引入的依赖和配置项非常多，团队上手成本高，而且每次环境变化都可能踩到各种奇奇怪怪的坑。Maestro上手极简，但实质上是基于iOS和Android各自的底层能力做了封装，遇到复杂断言或者自定义逻辑的时候，能做的事情相对有限。

AEStudio给我的感觉是在灵活性和易用性之间找到了一个比较好的平衡点。它内置了一套统一的交互协议，脚本写起来跟写普通业务逻辑差不多，不像Appium那样需要你理解WebDriver那一整套协议。另外，AEStudio对自定义扩展的支持比较友好，你可以写自己的插件和辅助函数，这在做复杂业务断言的时候非常管用。根据我的实际使用体验，一个中等熟练度的测试开发，大概一到两周就能上手AEStudio并独立编写用例，这个学习成本在同类工具里算是比较低的。

3. 环境搭建与项目初始化

3.1 本地环境准备：从零到能跑通第一个脚本

AEStudio的基础运行环境是Node.js，建议使用14以上的版本，我自己长期用的是16和18，稳定性都还不错。如果你电脑上还没装Node.js，直接去官网下载LTS版本安装即可，安装完在终端里执行node -v能输出版本号就算就绪。另外，AEStudio的依赖包里包含一些原生模块，所以Windows用户建议提前装好Visual Studio Build Tools，macOS用户建议确认Xcode Command Line Tools已经安装，否则安装依赖阶段可能会报编译错误。

装好Node.js之后，在终端里执行：

npm install -g aestudio-cli

这是AEStudio的命令行工具，负责项目初始化、用例执行、报告生成这些操作。安装完成后输入aestudio --version，能正常输出版本号说明CLI装好了。

接下来初始化一个自动化测试项目。找一个干净的目录，执行：

aestudio init my-auto-project

这个命令会自动生成一套标准的项目骨架，包括配置文件、用例目录、测试数据目录和报告输出目录。初始化完成后，目录结构大致长这样：

my-auto-project/ ├── aestudio.config.js ├── package.json ├── cases/ │ └── demo.spec.js ├── screenshots/ └── reports/

3.2 配置文件逐项解析：这些参数到底影响什么

AEStudio的全局配置集中在aestudio.config.js里，这个文件是项目跑得稳不稳的关键，我建议你逐项理解后再根据自己的项目调整，而不是直接复制别人的配置。

module.exports = { driver: { platform: 'android', // 平台：android / ios / mac / windows deviceName: 'emulator-5554', // 设备ID appPackage: 'com.example.app', appActivity: '.MainActivity', sessionTimeout: 60000, // 会话超时时间，单位毫秒 }, runner: { retryTimes: 2, // 用例失败重试次数 parallel: false, // 是否并发执行 screenshotOnFail: true, // 失败自动截图 }, reporter: { type: 'html', // 报告类型 outputDir: './reports', }, };

platform决定当前执行目标平台，deviceName填设备的序列号。Android设备可以通过adb devices查看，iOS设备可以在Xcode里查看UDID。appPackage和appActivity是针对Android平台的配置，如果跑iOS，这两个字段要换成bundleId。

sessionTimeout这个参数值得多说一句。Session启动时AEStudio要安装应用、初始化控件树，这一步在部分低配设备上可能耗时较长，如果超时时间设置太短，容易出现误报。我一般设置为60秒到90秒，比较稳妥。screenshotOnFail强烈建议开启，用例失败时的截图能帮你省去大量排查问题的时间。

3.3 连接设备与启动Session：第一步实操

配置写好后，先确认设备和电脑的连接正常。Android设备打开USB调试，连接电脑后在终端执行：

adb devices

能看到设备列表且状态是device，说明连接成功。iOS设备相对麻烦一些，需要在Mac上安装Xcode，然后在终端执行xcrun xctrace list devices列出可用设备，确认后把设备UDID填到配置里。

设备就绪后，写一个最简单的冒烟用例，验证整个链路是通的。在cases/目录下新建一个smoke.spec.js：

const { test, expect } = require('aestudio'); test('打开应用并验证首页标题', async ({ driver }) => { // 等待首页渲染完成 await driver.waitForElement({ text: '首页' }, 10000); // 断言首页标题存在 const title = await driver.findElement({ text: '首页' }); expect(await title.isDisplayed()).toBeTruthy(); });

这个用例做的事情很简单：启动应用，等待页面出现“首页”这个文本元素，然后断言这个元素是可见的。如果这一步能跑通，说明设备连接、Session启动、控件树解析、断言机制这整条链路都是通的，后续写复杂用例就有了基础。

执行用例的方式很直接：

aestudio run cases/smoke.spec.js

执行结束后，终端会输出详细的步骤日志和最终结果，reports目录下会生成一份HTML报告，用浏览器打开就能看到每一步的执行状态和失败时的截图。

4. 自动化脚本开发：从基础操作到复杂场景封装

4.1 元素定位的几种方式和选择策略

元素定位是UI自动化里最基础也最关键的一环，定位不稳定的用例，跑起来就跟抽奖一样，时好时坏。AEStudio支持按文本、ID、类名、坐标、XPath等多种方式定位元素，每种方式都有自己的适用场景。

最常用的是按文本定位，比如上面例子里的{ text: '首页' }。这种方式对用户可见的按钮、标签非常有效，直观、易读、方便维护。但也有个问题，如果页面里有两个相同文本的元素，这种定位方式会命中多个节点，需要配合index参数处理。

按资源ID定位是我在Android端最推荐的方式。开发在布局文件里给每个控件都设置了android:id，比如@+id/btn_login，这种ID在控件树里是唯一的，定位起来又稳又准。AEStudio里这样写：

const loginBtn = await driver.findElement({ id: 'btn_login' });

iOS端对应的是accessibilityIdentifier，开发设置了这个标识符之后，你也可以用同样的方式定位。按XPath定位是最后的兜底方案。XPath功能强大，能处理各种复杂的层级关系，但代价是性能和稳定性都不太好，页面结构稍微一变就失效。我用XPath的频率很低，一般是实在找不到合适的定位方式才会考虑，而且会尽量把XPath写得简单、有针对性。

选择定位策略的顺序，我个人的优先级是：资源ID > accessibilityIdentifier > 文本 > 坐标 > XPath。这个顺序能最大程度降低用例的脆弱性。

4.2 等待策略：为什么你的用例总是时好时坏

UI自动化的等待处理，是新手和老手拉开差距的地方。很多人刚开始写用例的时候习惯用sleep(3000)这种方式，固定等三秒再操作。这种做法在小项目里看起来没问题，但实际上隐患很大：真机性能不稳定、网络延迟波动，导致页面加载速度忽快忽慢，固定等待要么太短导致元素还没出现就报错，要么太长无限拉长整个用例的执行时间。

AEStudio的等待策略建议以条件等待为主。条件等待的思路是：等待某个条件成立，而不是等待固定时间。AEStudio内置了丰富的条件等待API：

// 等待元素出现，最长10秒 await driver.waitForElement({ text: '登录' }, 10000); // 等待元素消失 await driver.waitForElementGone({ text: '加载中' }, 10000); // 等待元素可点击 await driver.waitForClickable({ id: 'btn_submit' }, 10000);

条件等待的原理是AEStudio内部以一定频率轮询控件树，检查元素状态，一旦条件满足就立即继续往下执行。这种方式既保证了稳定性，又不会浪费多余的时间。我在团队里定的规范是：所有涉及网络请求的用例，一律使用条件等待，禁止裸sleep；只有极少数动画场景，在条件等待无法覆盖的情况下，才允许用短时间的等待来缓解问题。

4.3 常用交互操作与手势封装

UI自动化除了点击和输入，还有不少滑动、长按、拖拽这类手势操作。AEStudio对手势做了统一的API封装，写起来非常顺手。

滑动操作最常见的场景是列表滚动：

// 从屏幕中心向上滑动 await driver.swipe({ startX: 200, startY: 800, endX: 200, endY: 300, duration: 300 }); // 在元素上执行滑动 const list = await driver.findElement({ id: 'list_view' }); await list.swipe({ direction: 'up', distance: 500, duration: 300 });

长按操作在iOS应用里比较常见，比如长按某个列表项弹出操作菜单。AEStudio支持指定长按坐标和时长：

await driver.longPress({ x: 180, y: 420 }, 1500);

这些手势操作有个共同点，就是都依赖坐标或者元素位置。屏幕上不同机型的页面布局差异可能导致坐标偏差，所以我在封装手势的时候，会优先尝试在元素级别执行手势，而不是直接在屏幕坐标上执行，这样能保证用例在不同分辨率设备上的兼容性。

4.4 页面对象模型：告别脚本里到处硬编码

随着用例数量增加，直接在测试用例里写各种元素定位和操作逻辑，会让代码变得臃肿且难以维护。比如登录页面的“登录按钮”，如果你在20个用例里分别写过driver.findElement({ id: 'btn_login' })，一旦开发改了ID，你就得满项目去替换这20处代码。这种问题可以通过页面对象模型（Page Object Model，POM）模式解决。

POM的核心思路是：把每个页面的元素定位和操作方法封装成一个独立的类，用例脚本只负责调用这些方法，不直接操作元素。我通常会在项目里建一个pages/目录，每个页面一个文件，比如登录页：

// pages/login.page.js const { BasePage } = require('aestudio'); class LoginPage extends BasePage { constructor(driver) { super(driver); this.usernameInput = { id: 'input_username' }; this.passwordInput = { id: 'input_password' }; this.loginButton = { id: 'btn_login' }; } async login(username, password) { await this.driver.findElement(this.usernameInput).inputText(username); await this.driver.findElement(this.passwordInput).inputText(password); await this.driver.findElement(this.loginButton).tap(); } } module.exports = LoginPage;

用例里只需要这样调用：

const LoginPage = require('../pages/login.page'); const loginPage = new LoginPage(driver); await loginPage.login('testuser', 'testpass123');

封装之后，页面元素的定位集中在一个地方，改动成本从“全局替换”降到了“只改一个文件”。这是我在所有自动化项目里都强制执行的规范，也是保证自动化项目能持续迭代不腐化的关键之一。

4.5 数据驱动测试：同一套用例跑N组数据

很多测试场景是同样的操作流程，只是输入数据不同，典型的就是登录测试：不同的用户名、密码组合，验证不同的提示信息。如果把每组数据都写成一个独立的用例，代码冗余会很严重。AEStudio支持数据驱动的方式，可以很方便地复用同一套用例逻辑。

const { test, expect } = require('aestudio'); const LoginPage = require('../pages/login.page'); const loginCases = [ { username: 'user1', password: 'pass1', expectedError: '密码错误' }, { username: 'user2', password: 'pass2', expectedError: '用户不存在' }, { username: '', password: '', expectedError: '请输入用户名' }, ]; for (const [index, data] of loginCases.entries()) { test(`登录场景-数据组${index + 1}`, async ({ driver }) => { const loginPage = new LoginPage(driver); await loginPage.open(); await loginPage.login(data.username, data.password); const errorElement = await driver.waitForElement({ text: data.expectedError }, 5000); expect(await errorElement.isDisplayed()).toBeTruthy(); }); }

数据驱动让测试数据和用例逻辑分离，新增一组测试数据只需要在数组里加一条记录，用例代码完全不用动。测试数据也可以放在JSON或YAML文件里，配合脚本动态读取，这样非技术人员也能维护测试数据，对团队协作比较友好。

5. 调试手段与执行策略

5.1 调试时别硬跑：利用定位器验证和调试模式

写完用例直接跑，遇到失败再一行行看日志，这种调试方式效率不高。AEStudio提供了一个定位器验证命令，可以单独验证元素的定位是否有效，不用执行完整用例。

aestudio inspect

这个命令会连接设备并进入一个交互模式，你输入元素定位表达式，它实时显示匹配到的元素信息，包括元素属性、在页面上的坐标、可见性状态。我调试用例时习惯先用这个命令确认元素能稳定匹配到，再回到用例脚本里跑，能节省大量反复执行用例的时间。

另外，AEStudio支持在用例中插入断点调试。如果你在VS Code或WebStorm里写脚本，可以直接在代码里打上断点，然后以调试模式运行用例：

aestudio run cases/login.spec.js --debug

调试模式会在Session启动后挂起，等待你在IDE里附加调试器。这时候你可以像调试普通Node.js代码一样，查看驱动上下文中的元素状态、执行表达式、逐步跟踪脚本运行。对于定位复杂页面的问题，这种调试方式非常管用。

5.2 测试报告怎么配置才能真正辅助定位问题

AEStudio默认生成的HTML报告已经包含了用例步骤、执行时长、失败信息、截图等内容。但如果不做额外配置，报告在大型项目里会变成一堆详细而庞杂的信息，反而很难快速定位问题。我通常会做三方面的优化。

第一，在用例中加入业务步骤描述，让报告可读性更强。AEStudio允许给用例步骤添加描述信息：

await test.step('输入账号密码并点击登录', async () => { await loginPage.login('testuser', 'testpass123'); }); await test.step('验证首页加载成功', async () => { const homeTab = await driver.waitForElement({ text: '首页' }, 10000); expect(await homeTab.isDisplayed()).toBeTruthy(); });

这样生成的报告，每一步都有清晰的中文描述，即使不看代码，也能从报告里还原出完整的测试流程。

第二，在关键节点主动添加截图。AEStudio提供了显式截图API：

await driver.captureScreenshot('login-success');

我通常会在登录成功、下单成功、支付完成这类关键业务节点主动截图，这些截图即使用例没失败，也能作为功能验证的辅助证据。

第三，配置报告保留策略。如果项目持续集成每天跑几百条用例，所有历史报告都保留会占据大量磁盘空间。我会在aestudio.config.js里配置只保留最近30天的报告，或者直接在持续集成流水线里定期清理旧报告。

5.3 用例分组与执行顺序：怎么跑效率最高

当用例数量上了规模之后，全量执行会花很长时间，很多中间步骤的用例其实没必要每次提交都跑。我的习惯是把用例分成三个级别：冒烟级、中等回归级和全量回归级。

冒烟级用例只覆盖核心主流程，比如登录、首页加载、核心功能入口，数量在20条以内，每次代码提交后跑一遍，保证系统核心功能没有明显破坏。中等回归级覆盖大部分业务模块的主链路，数量在50到100条，每天在测试环境跑一遍，用来发现跨模块的集成问题。全量回归级就是所有用例，包括各种边界条件和异常场景，每周跑一次，作为质量保障的最后一道防线。

AEStudio提供了用例标签机制，可以在用例声明时指定标签：

test('登录成功-正确账号密码', async ({ driver }) => { // ... }).tag('smoke', 'login');

执行时按标签筛选即可：

aestudio run cases/ --tag smoke

这种分级策略让自动化测试在有限的时间内产生最大的价值，而不是盲目追求全量执行的次数。

6. 持续集成与兼容性提升

6.1 配置Jenkins/GitLab CI流水线：让用例自动跑

手工在本地执行自动化测试只是自动化的一半价值，另一半价值在持续集成流水线里。把AEStudio用例接入CI流水线之后，每次代码提交、每个夜构建版本，都可以自动触发测试，测试结果实时反馈给开发团队。

以Jenkins为例，流水线的核心步骤很简单：拉取代码 -> 安装依赖 -> 启动模拟器/连接真机 -> 执行用例 -> 收集报告。

pipeline { agent any stages { stage('checkout') { steps { git url: 'https://git.example.com/my-auto-project.git' } } stage('install deps') { steps { sh 'npm install' } } stage('start emulator') { steps { sh 'nohup emulator -avd test-device &' sh 'adb wait-for-device' } } stage('run tests') { steps { sh 'aestudio run cases/ --tag smoke' } } stage('archive reports') { steps { publishHTML(target: [ allowMissing: false, alwaysLinkToLastBuild: true, keepAll: true, reportDir: 'reports', reportFiles: 'index.html', reportName: 'AEStudio Test Report' ]) } } } }

GitLab CI的配置思路是相似的。CI跑用例和本地跑最大的区别是环境一致性，CI机器上的Node版本、系统补丁、SDK版本如果和本地不一致，很容易出现本地通过CI失败的情况。我的经验是在流水线最开始加一步环境检查脚本，输出Node版本、ADB版本、SDK版本到构建日志里，出问题的时候第一件事就是对版本。

6.2 多机型兼容性：如何在真机池中稳定执行

自动化用例的兼容性问题，很大程度来自不同设备的屏幕尺寸、分辨率和系统版本差异。UI元素的位置在不同屏幕上的坐标可能完全不同，控件的层级结构也可能因为系统版本不同而有细微差异。

AEStudio的设备管理机制支持同时连接多台设备，并且可以在配置中指定执行策略。我建议有条件的话，搭建一个小规模的真机池，至少覆盖高、中、低三个档位的设备，系统版本覆盖Android 10到最新的稳定版本。

真机池执行过程中最常见的问题是设备断连。USB连接不稳定、设备休眠、应用崩溃都可能导致Session中断。AEStudio的用例重试机制在这里很有用，配置retryTimes可以在设备临时异常时自动重跑用例。我通常设置重试两次，第一次失败后会先检查设备连接状态，再决定是否继续重试。

6.3 提升稳定性的几条实战经验

稳定性是自动化测试的生命线，一套天天闪退的用例，没有人会愿意维护。我在多个项目里沉淀了几条提升稳定性的经验，这里分享出来。

第一条，用例之间必须完全独立。每个用例开头负责启动应用并进入指定页面，结尾负责清理环境、退出登录。不能依赖上一个用例执行后的页面状态，否则整个测试套件就像一个多米诺骨牌阵，一条用例挂了后面全挂。

第二条，减少对坐标的依赖。能用控件定位的，不要用坐标。坐标定位天然脆弱，稍微换个分辨率就失效，而且页面滚动之后坐标会变。如果实在只能用坐标，建议先通过元素定位获取元素的位置再计算坐标，而不是写死数值。

第三条，严格控制并发数量。AEStudio虽然支持并行执行，但并发太高会显著增加跨用例的资源竞争和系统负载，反而降低整体的通过率。我实践下来，三到四条并发是比较稳定的阈值，优先保稳定，不盲目追求速度。

第四条，失败用例的日志和截图一定要足够详细。我每次写用例的时候，都会在关键节点加上注释、日志和截图逻辑，确保用例失败后，光看报告就能大概判断是环境问题还是业务问题，不需要重新跑一遍或反复问开发。

7. 常见问题整理与排查思路

7.1 元素定位失败：连不到控件树的典型案例

元素定位失败是UI自动化里出现频率最高的报错，AEStudio的报错信息通常长这样：Element not found: {"id":"btn_login"}。遇到这种报错，我的排查路径是固定的：先确认页面是否真的加载到了这一步，再看元素属性是否发生了变化，最后检查是否被遮挡或不可见。

第一步可以在报错位置前面插入一句等待driver.waitForElement，给页面留出加载时间。第二步使用aestudio inspect命令，在当前页面实际查询一下这个元素是否存在，以及它的实际属性值是什么。很多时候是因为开发改了ID或者加了前缀，这种情况直接更新定位表达式就行。第三步检查元素是否被其他浮层遮挡，AEStudio在点击元素前会检查元素是否可点击，如果被遮挡会提示元素不可见，这时需要先关闭浮层或者改用坐标点击。

7.2 Session启动失败：根源基本都是环境问题

Session启动失败和元素定位失败的原因差别很大，绝大多数情况下是环境问题。常见的表现有几种：提示连接不到设备，大概率是USB连接问题或者设备休眠，重新插拔设备、在设备设置里关闭自动休眠就可以。

提示应用启动失败，一般有两条排查方向。一是确认配置里的appPackage和appActivity是否正确，Android端的Activity路径如果写少了一层，比如写了MainActivity而不是.MainActivity，都可能导致应用无法拉起。二是确认被测应用是否正常安装，部分应用在调试机上可能因签名问题装不上，需要在设备上手动确认应用能正常打开。

还有一类Session启动失败是权限弹窗造成的。应用首次启动经常弹出各种权限请求，比如定位权限、通知权限，这些弹窗会打断Session的初始化流程。我在配置里会预先处理权限，或者写一个全局启动阶段的辅助函数，自动点击“允许”按钮，跳过弹窗干扰。

7.3 用例稳定性问题速查表

把常见的用例不稳定表现、可能原因和解决方法整理成一个速查表，方便排查时对照定位：

这张表是我排查问题时的第一手资料。如果你遇到表里没覆盖的问题，我的建议是先打开AEStudio的详细日志模式：

aestudio run cases/demo.spec.js --verbose

详细模式下会输出脚本执行的每一步命令和设备返回的原始信令，很多隐蔽的兼容性问题，都能在原始信令里找到线索。

7.4 一个典型的排查案例：登录用例为什么时好时坏

讲一个实际遇到的案例，更生动地展示排查思路。有段时间团队里反馈登录用例的通过率很低，十个用例跑下来经常挂掉两三个。我第一反应是网络问题，因为登录请求依赖后端接口，网络波动可能导致响应超时。但看失败截图，页面停在登录成功后的跳转页，说明登录请求已经发出去了，问题出在跳转之后的页面加载上。

于是我去加了跳转页的等待时间，发现情况并没有明显改善。后来用verbose模式跑了一次，看到日志里有报错提示某个深层的Activity渲染超时，这才意识到是应用在部分设备上的跳转动画过长，导致跳转页的控件树一直不稳定。

最后的解决方案是两方面的：一方面和开发确认了跳转动画的时间，在测试环境把这个动画时长调短；另一方面在用例里把跳转后的等待条件从“等待文本出现”改成了“等待目标页面的资源ID出现”，因为文本有时要等字体渲染完成才出现，而资源ID在界面框架搭好时就存在了。改完之后用例通过率从七成提升到了九成八以上。这个案例说明，定位不稳定的根因，往往需要结合应用自身的实现逻辑来分析，不能只看表面现象。

8. 最后再分享一点我的实际体会

AEStudio这套工具我用到现在，最大的感受是它的设计理念在尽力把UI自动化的门槛降低，让测试人员能把精力集中在场景设计和业务验证上，而不是每天和技术框架较劲。但工具能做到的只是提供一套好上手的骨架，真正让自动化测试产生价值，还是要靠使用者的规范意识和工程化能力。

我见过不少团队，工具选得挺好，但用例写得随意，没有页面对象模型，没有等待策略，没有失败重试，结果自动化测试跑了一段时间之后，维护成本比手工测试还高，最后不了了之。如果你决定在团队里推行AEStudio，我的建议是：先把基础规范定下来，定位方式的选择顺序、等待策略的使用规范、用例分组和标签体系、报告和日志的标准，这些都前置解决，然后才谈得上大规模铺用例。

另外，自动化测试这件事，不要把通过率当成唯一的考核指标。通过率固然重要，但更重要的是让自动化测试成为研发流程中的一环，提交代码、构建版本、自动触发、及时反馈，形成一条真正能提升研发效率的闭环。我在推行过程中踩过不少坑，也走过弯路，如果这篇手册能帮你少走几步弯路，那就是值得的。