企业官网建设流程全解析

1. 别急着装框架，先搞明白你的自动化测试属于哪一类

Android自动化测试相关的框架这几年越来越多，几乎每隔一段时间就会冒出一个新名字。很多团队的做法是：先看朋友圈或技术大会推荐了哪个，项目里直接拿来用，用了一个月发现跑不动、维护成本高，再换下一个。这不是框架不行，而是根本没想清楚自己到底需要哪一种自动化测试。

我做了几年的移动端测试开发和自动化平台建设，一个很深的体会是：选框架之前，先回答两个问题——你的测试是黑盒还是白盒？你要稳的是端到端流程还是组件级行为？

1.1 黑盒与白盒：决定后续所有选型的第一个分岔口

黑盒测试可以理解为“站在用户角度”的测试。测试代码不依赖被测App的源码，也不需要知道内部类、控件ID怎么命名，只通过界面上的文案、位置、可点击状态来判断当前页面是否正确。黑盒方案的代表是Appium、UiAutomator 2.0，以及建立在它们之上的Robot Framework这类关键字驱动框架。

白盒测试则相反，测试代码通常直接运行在被测App的进程里，通过源码里的控件ID、ViewModel状态、甚至是Compose语义节点来做断言。Espresso和Jetpack Compose Test框架都属于这一类。它们的优点是稳定、执行快，缺点是要求你手里有源码，而且一般只能测自己的App，没法对跨应用的复杂链路做操作。

这个分岔口之所以重要，是因为它直接影响框架选择。很多团队在项目还没确定是自研App还是外包代码托管时，就盲目引入某个框架，最后发现要么拿不到源码用不了白盒工具，要么黑盒工具定位元素太慢、太重，整个自动化体系形同虚设。

1.2 五个框架在测试金字塔里的占位，以及“测试框架”这个词的歧义

还有一个常见的混乱来源是“测试框架”这个词本身。在Android社区里，有人说的“框架”是JUnit、TestNG这种单元测试运行器，有人说的是Espresso、Appium这种UI操作引擎，还有人说的是Allure报告、持续集成那一整套流水线。如果团队里不同成员的认知不在同一层，方案讨论就会变成各说各话。

我倾向于把框架分成三层：运行器层解决的是“测试用例怎么跑、生命周期怎么管理”，UI操作层解决的是“怎么找到界面元素并执行动作”，集成层解决的是“怎么把用例接进CI、生成报告”。这篇要聊的5个框架，覆盖的是中间那一层：负责实际驱动界面、执行操作、验证结果的工具。这层选好了，运行器层随便接JUnit、Pytest都行，集成层用Jenkins、GitHub Actions也都不冲突。

从整个测试金字塔来看，单元测试在底层，UI自动化在金字塔尖。金字塔尖的用例执行最慢、最不稳定，所以数量要克制，价值要聚焦。下面这5个框架，Appium负责跨平台的端到端回归，Espresso负责Android原生项目的核心交互验证，UiAutomator 2.0补上跨应用和系统级场景，Robot Framework负责让业务人员也能上手维护，Compose Test负责新项目里声明式UI的组件级验证。它们不是互相替代的关系，而是各自解决一块特定问题。

2. 五个框架逐个拆：核心原理、一句上手、适用边界

2.1 Appium：跨平台黑盒UI测试的事实标准

Appium大概是Android自动化测试里被提及最多、也最被误用的框架。它的核心思想很聪明：不直接调用Android系统的注入接口，而是实现了一套WebDriver协议，测试脚本统一发Http请求到Appium Server，Server再通过对应的驱动去操作Android或iOS设备。这意味着同一套用例，换一套驱动，理论上就能在iOS、Android上复用。

实际用起来，Appium 2.x版本之后需要单独安装驱动，比如appium driver install uiautomator2，不然连本地session都起不来。一个最简的Android用例大概长这样：

from appium import webdriver caps = { "platformName": "Android", "appium:automationName": "UiAutomator2", "appium:deviceName": "emulator-5554", "appium:appPackage": "com.example.demo", "appium:appActivity": ".MainActivity", "appium:noReset": True, } driver = webdriver.Remote("http://localhost:4723/wd/hub", caps) driver.find_element(By.ID, "com.example.demo:id/etUsername").send_keys("tester") driver.find_element(By.ID, "com.example.demo:id/btnLogin").click() assert driver.find_element(By.ID, "com.example.demo:id/tvHome").is_displayed() driver.quit()

很多团队选Appium是因为它跨平台，这是它的强项，但也意味着额外的Server进程、Python或Java客户端依赖、以及更慢的用例执行速度。在只做Android一个端的原生App项目里，如果全部用例都用Appium跑，等于用大炮打蚊子。我的建议是：Appium适合作为端到端回归的兜底方案，尤其是App有跨端需求、或者测试团队主要写Python的场景，它是最务实的黑盒选择。

2.2 Espresso：Google官方白盒方案，靠同步机制解决一大半的不稳定

Espresso是Google官方维护的Android UI测试框架，跑在设备的Instrumentation环境里。它和Appium最大的差异是同步机制：Appium基本靠sleep等界面加载，Espresso则自动等待主线程空闲、等待异步任务完成，再去执行下一步。这直接解决了一大类“测试不稳定”的麻烦。

一个标准的Espresso用例用Kotlin写出来非常干净：

@RunWith(AndroidJUnit4::class) class LoginFlowTest { @Test fun login_showHome() { onView(withId(R.id.etUsername)) .perform(typeText("test"), closeSoftKeyboard()) onView(withId(R.id.btnLogin)) .perform(click()) onView(withText("首页")) .check(matches(isDisplayed())) } }

Espresso是白盒测试的典型代表，需要项目在build.gradle里引入依赖，测试代码也要打进APK里一起安装。正因为能直接拿到控件ID，它做交互级验证非常稳、非常快，适合对核心业务流程做高频回归。它的短板也很明显：拿不到源码或用不了Android Studio构建流程的团队，用不了；跨应用跳转、系统级弹窗这类黑盒场景也力不从心。

实践经验是：View体系的老项目，Espresso是回报率最高的一个框架，没有之一。

2.3 UiAutomator 2.0：不需要源码也能做系统级黑盒自动化

UiAutomator 2.0也是Google提供的官方测试库，但它和Espresso走的路线完全相反。它借助系统的Accessibility服务能力，给测试进程一个从“系统视角”看界面的入口。最大的优势是不依赖被测App源码，而且能跨应用操作，比如从自己的App跳到系统设置再返回，或者操作通知栏。

一段典型的UiAutomator代码大概是这样的：

UiDevice device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation()); UiObject2 loginBtn = device.findObject(By.res("com.example.demo", "btnLogin")); loginBtn.click(); UiObject2 username = device.findObject(By.res("com.example.demo", "etUsername")); username.setText("tester");

这里用的是androidx.test.uiautomator:uiautomator这个依赖。注意力气要花在定位策略上：资源ID优先，其次文本，再次描述内容（content-desc），因为系统级界面里的元素不像自己App里那样规整。

还有一点值得说：Appium在Android端实际就是调用了UiAutomator2的驱动能力，所以如果你只能选一种方式做黑盒，先用UiAutomator2验证一下定位能否走通，会比直接套Appium更容易排查问题。真实的项目里，UiAutomator2最适合的场景是“跨应用闭环测试”，比如登录后跳转微信授权再回跳，这种链路在纯App测试框架里根本断不开。

2.4 Robot Framework：关键字驱动，让业务同学也能维护测试用例

Robot Framework严格来说不是一个Android专用测试引擎，它更像一个“测试编排层”。通过AppiumLibrary或SeleniumLibrary这些扩展库，把底层操作封装成接近自然语言的“关键字”，然后让测试用例看起来像一份格式化的需求清单。团队里有不写代码的QA或者业务人员参与维护用例时，这个框架的价值会非常明显。

一个Robot风格的用例大致是：

*** Settings *** Library AppiumLibrary *** Test Cases *** 打开App并完成登录 Open Application http://localhost:4723/wd/hub ... platformName=Android ... appPackage=com.example.demo ... appActivity=.MainActivity Click Element id=com.example.demo:id/etUsername Input Text com.example.demo:id/etUsername tester Click Element id=com.example.demo:id/btnLogin Page Should Contain Text 首页

如果你的团队全是一线开发转岗出来、代码能力很强的测试工程师，Robot Framework反而会显得累赘，因为关键字封装本身就是一层额外维护成本。但如果是“测开少数+业务测试多数”的配置，Robot Framework能让你把核心操作沉淀成关键字库，普通测试同学只需要像填表格一样编写业务流程，降低整个团队的自动化门槛。实际维护时建议把关键字设计得贴近业务语言，比如用户登录、添加购物车，而不是点击按钮X，否则可读性提升有限。

2.5 Compose Test：Jetpack Compose项目的原生测试姿势

Jetpack Compose普及之后，原来的控件树被语义树取代，用onView(withId())定位就失效了。于是Google推出了Compose UI Test，核心是createAndroidComposeRule加onNodeWithText、onNodeWithTag这类按语义定位的方法。

一个Compose测试大概是这样：

@get:Rule val composeRule = createAndroidComposeRule<MainActivity>() @Test fun 登录后显示首页() { composeRule.onNodeWithTag("usernameInput").performTextInput("tester") composeRule.onNodeWithText("登录").performClick() composeRule.onNodeWithText("首页").assertIsDisplayed() }

Compose测试的关键点是“Tag”策略。建议在页面里重要的交互组件上主动加Modifier.testTag("xxx")，而不要依赖文案匹配，因为文案会变的可能性远高于tag。对于正在全面转向Compose的新项目，Compose Test应该直接写进每次提交的流水线里。对于View和Compose并存的混合项目，则要注意二者的互操作测试：View体系用Espresso，Compose部分用Compose Test，两种情况在同一个测试里共存时需要小心IdlingResource的冲突，这点后面统一说。

3. 真实项目里到底怎么选：场景对照与决策路径

3.1 我见过的最常见选型错误

先说说我在各种团队里看到的典型错误，这比记住5个框架的API重要得多。

第一个错误是“一个框架包打天下”。曾经有个项目，全部自动化用例都跑在Appium上，从登录到订单流程，跑了3个月，维护量爆炸。原因很简单：登录注册这种高频验证用白盒的Espresso几十秒就够，用Appium黑盒跑一个最少两三分钟，还经常因为网络弹窗、页面加载延迟导致用例挂掉。不是Appium不好，是把所有鸡蛋都放进了一个篮子里。

第二个错误是“无视团队技术栈”。如果测试团队主力写Java或者Python，Espresso这个完全依赖Kotlin并嵌进Android工程的方式，落地难度会高很多；反之，如果团队本身就在Android工程里写代码，引入Robot Framework这种关键字框架反而增加了不必要的技术栈。

第三个错误是“不按App类型选型”。原生View工程、Compose工程、混合开发工程、H5套壳工程，四类项目的自动化最佳路径差异极大。H5占比高的App，与其用Espresso硬查原生控件，不如用WebView的调试协议做断言；Compose工程如果还按View的老一套定位方式，做出来的用例一定脆弱。

3.2 一份可照抄的选型表和一版落地顺序

整理一下，按我这些年的经验，直接看这张表：

再看落地顺序。我不推荐一上来就把5个框架都配上，那是灾难。正确做法是：确定一个主框架，先跑通一条最核心的业务链路，比如登录到首页。跑通之后，再用第二个框架补上主框架做不到的场景。等这两条线稳定下来，再考虑引入Robot Framework这类编排层或者介入CI。

我见过很多团队把顺序搞反了。环境没搭稳，用例还没跑通，就开始写报告、搞平台、发邮件。自动化测试的产出永远是“稳定运行的用例”，不是框架的数量和PPT上的体系建设进度。先把小闭环跑起来，比什么都重要。

4. 框架之外的事：环境、报告与CI才是自动化的七寸

很多团队选好了框架，用例也写了一批，最终还是跑不起来。原因往往不在框架本身，而在周围的基础设施：设备环境不稳定、失败报警没法定位、用例和CI完全脱节。测试框架只是自动化体系的一个零件，七寸其实在环境、报告和CI这三件“周边事”上。

4.1 环境一致性：模拟器、真机与版本锁定的经验

Android设备碎片化严重，API level不同、厂商ROM不同，同一个元素定位结果可能完全不同。如果团队没有统一的环境管理，用例今天在模拟器上过了，明天换个真机跑就挂了，你根本分不清是脚本问题还是环境差异。所以第一条经验就是：把环境当成代码的一部分来锁版本。

模拟器就用固定API level的镜像，比如统一用API 29或API 30的x86_64镜像，不要今天有人用API 27、明天有人用API 33。我用过一个很实用的命令行组合：

emulator -avd test_pixel_4 -no-window -no-audio -gpu swiftshader_indirect & adb wait-for-device adb shell settings put global window_animation_scale 0 adb shell settings put global transition_animation_scale 0 adb shell settings put global animator_duration_scale 0

后三条很关键。把系统动画关掉，能显著提高Espresso和Appium用例的稳定性，因为动画导致主线程迟迟不空闲，很多等待逻辑会超时。真机环境就尽量统一品牌和系统版本，至少保证团队内有一套“基准真机”，所有用例上线前在基准机上验证一轮。

还有一个容易忽略的点：Appium Server、驱动和客户端库的版本要统一。项目里锁一个appium版本，requirement文件固定一批依赖，不要每个开发本地自己装最新版，否则会出现这边能跑那边不能跑的经典烂账。

4.2 失败定位与报告：Allure、截图和录屏怎么和框架对接

用例跑挂之后，如果不能快速定位问题，自动化体系很快就会被人放弃，因为没有可维护性。至少要做到三件事：自动截图、导出页面结构、记录关键步骤。

Appium在Python里可以直接：

driver.save_screenshot("failure.png") driver.page_source # XML格式，保存后可用于定位复盘

Espresso可以在失败时配合androidx.test.runner.screenshot做截图，也可以给ScreenCapture配置SurfaceCaptureCallback。更省事的做法是直接接Allure报告框架：Python测试用pytest+allure，JVM测试用allure-junit或allure-android，失败信息、截图、日志能被汇总到一个HTML报告里。

这里有一个实践细节：截图不要只截一张。条件允许的情况下，失败前连续截3张（操作前、操作后、断言失败时），再配合当前的页面XML结构，基本够分析九成的定位问题。录屏在疑难杂症时很有用，Appium支持driver.start_recording_screen()，但普通回归任务里不需要给每条case都录，存储压力太大。

4.3 接入CI的最小方案：以GitHub Actions为例

自动化测试不接CI等于白做。我见过太多人本地跑通了就算完事，代码一变更，没人记得跑这些用例，过两周全烂了。接CI其实不复杂，关键是选对触发时机和任务粒度。

一个比较靠谱的CI设计是：

• 日常提交（push到dev或feature分支）：只跑核心流程，比如10条以内的高价值用例，控制在3-5分钟完成；
• 发布前（打tag或合并到main）：跑全量回归，可能上百条，允许20-30分钟。

下面这个例子是一个能跑Espresso的最小GitHub Actions配置：

jobs: android_test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: reactivecircus/android-emulator-runner@v2 with: api-level: 29 target: google_apis arch: x86_64 script: ./gradlew connectedDebugAndroidTest - uses: actions/upload-artifact@v4 with: name: test-reports path: app/build/reports/androidTests/

如果团队用的是Jenkins或者自建GitLab CI，思路完全一样：起一个模拟器容器，跑测试脚本，上传测试报告作为构建产物。差别只在于文件格式和插件封装不同。Appium的CI接入稍微麻烦一点，因为需要先启动Appium Server，再执行Python或Java测试脚本，GitHub Actions里有现成的action可以启动模拟器，Appium Server也可以在容器里直接用npm全局安装。

环境跑挂永远是CI里最让人崩溃的事，所以务必把模拟器软硬件参数固定：API level、RAM、存储、无窗口模式，尽量和本地开发保持一致。这样CI里出的问题才可能真的是代码问题，而不是环境随机问题。

5. 跑测时最容易翻车的几个坑

5.1 Appium 2.0的driver与desired capabilities变动

如果你还在照着网上Appium 1.x的教程写Android测试，很容易报“Unable to create a new remote session”这类的错。Appium 2.0把驱动的管理从内置改成插件化：必须先安装uiautomator2驱动，不然连session都建不起来。

appium driver install uiautomator2

同时，desired capabilities也有很多字段变了，最稳妥的写法是给Android相关的能力加前缀“appium:”，比如appium:appPackage、appium:automationName。现在很多社区教程里的旧写法在Appium 2.x里并不推荐，容易遇到字段被忽略、行为不可预期的问题。

除此之外，Appium每次启动session都要安装并启动一个io.appium.uiautomator2.server的APK在设备上，这个过程比较慢，经常是5到10秒。所以如果你用Appium做高频回归，尽量复用driver实例，不要每条用例都新建session、退出session，否则时间全浪费在初始化上了。

5.2 Espresso在动画、弹窗和异步请求下的三大不稳定源

Espresso虽然同步机制强大，但有三类问题会狠狠考验你的耐心。

第一是系统动画。系统开发者选项里的窗口动画、过渡动画、动画时长如果不关闭，Espresso会一直等主线程空闲，结果就是大量超时。前面提过的三条settings put命令一定要写进设备初始化脚本里。

第二是弹窗。权限弹窗是Espresso最大的天敌，比如Android 6.0以上运行时权限弹窗，它会打断当前Activity的焦点。处理方式有两种：一种是用UiAutomator单独处理权限弹窗，另一种是在测试前置步骤里用GrantPermissionRule把权限直接授予。官方有现成规则类，最好直接在测试里声明：

@get:Rule val grantPermissionRule: GrantPermissionRule = GrantPermissionRule.grant(Manifest.permission.CAMERA)

第三是异步请求。Espresso默认等待主线程闲置，但如果网络请求是用OkHttp回调或协程完成的，测试代码对异步结果的控制会差很多。解决办法是注册IdlingResource，或者在测试环境里预置mock数据，避免依赖真实网络。很多团队索性把网络层在测试构建变体里替换成mock实现，这样用例稳定性会大幅提升。这个思路本质上是可测试性设计的问题，框架能做的其实是兜底。

5.3 Compose Test与Espresso混用时的IdlingResource冲突

混合项目里最常见的坑：一个测试方法里既用了composeTestRule，又用了Espresso.onView，结果某个界面一直等待空闲，用例卡死。原因是两套框架分别维护主线程同步机制，如果Compose的动画在Espresso眼里不算空闲任务，或者Espresso的等待在Compose语义树里没有同步信号，就会出现互相等待的僵局。

我踩过几次后的结论是：同一个测试方法尽量只用一套框架。View页面就交给Espresso，Compose页面就交给Compose Test，不要在一个流程里反复横跳。实在避不开的互操作场景（比如Compose的ModalBottomSheet里嵌了一个原生View），就在执行后用composeRule.waitForIdle()强制同步一下，并且给关键节点加上明确的testTag，减少语义解析误差。

另外注意，Compose Text和Compose Input字段在测试时，即使是完全相同的界面，多次运行结果也可能因为IME弹出状态不同而不稳定。尽量用performTextInput输入，输入后主动关闭软键盘，不要让它挡住后续的点击目标。

5.4 Robot Framework长跑时的会话管理问题

Robot Framework配上AppiumLibrary，用例写起来很爽，但跑多了会遇到一个经典问题：上一条用例执行失败后，Android会话没关干净，下一条用例直接Open Application，报“Already started session”的错。原因很简单，AppiumLibrary默认会在一条用例结束时自动关闭session，但用例异常中断时“运行后清理”不一定被执行，session就留在设备上了。

解决办法是在每一条用例的[Teardown]里显式写Close Application：

*** Test Cases *** 登录流程 [Teardown] Close Application Open Application http://localhost:4723/wd/hub ...

另外，Robot Framework里关键字很多，但不要盲目相信“越多越好”的社区包装。核心操作该封装的封装，不该封装的长流程还是保持线性可读更重要。跟业务团队协作时，大规模编写用例之前一定要先定义好公共关键字的命名规范，不然过几个月关键字库会膨胀到没法维护。

最后再分享一句个人经验：框架跑通只是第一步，自动化测试真正做到有生产力，依赖的是持续关注失败用例。不要一看到红了就马上“加固脚本”，先分清是环境挂了、元素变了还是产品行为变了，对应处理。框架只是手，用例质量才是脑，两边都照顾到，Android自动化测试才能在项目里长期稳定运转。