1. 项目概述为什么iOS UI自动化测试需要EarlGrey在iOS应用开发的后期尤其是回归测试阶段你是不是也经历过这样的场景每次发版前测试同学都要拿着十几台不同型号的iPhone一遍又一遍地手动点击相同的按钮、滑动相同的列表、填写相同的表单。这个过程不仅枯燥、耗时而且极易因为人为疲劳导致漏测。更头疼的是随着功能迭代测试用例像滚雪球一样增长手动测试的成本和风险直线上升。这时候UI自动化测试就成了一个必须考虑的选项。市面上iOS的UI自动化框架不少比如老牌的Appium、苹果自家的XCUITest。但用过的同学可能都体会过它们的“痛点”Appium基于WebDriver协议跨平台是优势但在iOS端的执行速度和稳定性上尤其是在复杂交互和异步加载的场景下常常力不从心XCUITest作为“亲儿子”与Xcode集成度最高但它的API在某些时候显得不够直观编写和维护测试脚本的门槛不低而且对测试环境的纯净度要求极高。那么有没有一个框架既能像XCUITest一样深度集成、执行高效又能提供更强大、更稳定的元素同步与交互能力呢这就是我今天想跟大家深入聊聊的EarlGrey。它并不是一个横空出世的新鲜玩意儿而是由Google开源并长期用于其自家iOS应用如YouTube、Google Maps测试的“工业级”框架。它的核心设计哲学就一句话让UI自动化测试像真实用户操作一样可靠和稳定。这听起来简单实现起来却需要解决无数底层同步和状态判定的难题而EarlGrey恰恰在这些方面做了大量精巧的设计。简单来说如果你正在为iOS应用的UI自动化测试寻找一个执行快、稳定性高、能处理复杂异步场景的解决方案EarlGrey绝对值得你投入时间深入研究。它可能不是最简单的入门选择但一旦掌握其带来的测试效率和可靠性提升将是巨大的。2. 核心设计哲学与架构拆解2.1 “同步即一切”的设计理念EarlGrey与许多其他UI测试框架最根本的区别在于它对“同步”的极致追求。传统的测试脚本常常需要写大量的sleep()、waitForExistence之类的显式等待这不仅让代码变得冗长更是测试不稳定的万恶之源。因为你永远无法精确预测一个动画要播多久一个网络请求何时返回或者一个列表何时刷新完成。EarlGrey的解决思路是釜底抽薪的它将整个测试执行过程与UI线程、主运行循环、网络请求、动画等所有可能引起状态变化的事件源进行同步。这意味着当你执行一个类似tap()的操作时EarlGrey内部会做大量工作检查UI层次结构是否稳定当前是否有正在进行的动画视图树是否正在更新检查主线程是否空闲是否有未完成的GCD任务或主线程调用等待网络请求框架会监听URL加载系统等待相关的网络活动完成。轮询目标元素在以上条件都满足的前提下持续检查目标元素是否确实存在于视图树中并且是可见、可交互的。只有所有这些条件都满足tap()操作才会真正被执行。如果条件不满足框架会自动等待有一个超时机制而不是立即失败。这就从根本上避免了“元素未找到”、“元素无法交互”这类最常见的脆性测试失败。2.2 三层架构与核心组件理解EarlGrey的架构有助于我们更好地使用和排查问题。它的核心可以划分为三层第一层测试脚本层 (EarlGrey API)这是我们编写测试代码直接接触的部分。它提供了一套丰富、链式调用的Swift/Objective-C API例如EarlGrey.selectElement(with: grey_accessibilityID(“loginButton”)).perform(grey_tap())。这层API的设计非常注重可读性和流畅性。第二层同步引擎层 (Synchronization Engine)这是EarlGrey的“大脑”也是其稳定性的基石。它包含了多个“同步器”UI线程同步器确保所有操作都在主线程安全执行。运行循环同步器排空主运行循环确保所有待处理的UI更新如setNeedsLayout完成。网络同步器通过NSURLProtocol拦截和跟踪网络请求这在测试依赖网络数据的页面时至关重要。动画同步器跟踪CALayer的动画等待它们结束。数据存储同步器如Core Data等待数据持久化操作完成。这个引擎持续监控这些事件源并为上层的“交互”操作提供“现在是否可以安全执行”的判断。第三层注入与驱动层 (Injection Driver)这是框架与iOS系统交互的“手”和“脚”。EarlGrey通过dyld动态库注入的方式将自身的代码加载到被测应用中。这使得它能够直接访问应用内存和对象无需像Appium那样通过远程调试协议从而获得极高的操作速度和更深的控制能力。驱动UI事件直接模拟触摸、滑动、键入等事件发送到系统的响应链。遍历视图层次直接访问UIView层级结构实现精准的元素查找。这种“白盒”测试的方式是它性能远超基于远程协议的框架的关键。2.3 与XCUITest的深度对比很多人会问既然有了XCUITest为什么还要用EarlGrey它们确实有相似之处深度集成、高性能但侧重点不同特性维度EarlGreyXCUITest同步机制主动、多维度同步。内置强大的同步引擎自动等待UI、网络、动画空闲。相对被动。主要依赖expectation和waitForExistence需要开发者显式处理更多等待逻辑。元素查找更灵活。支持丰富的GREYMatcher匹配器链可以进行非常精细和复杂的元素定位。标准。主要通过XCUIElementQuery进行查找语法直观但复杂条件匹配能力稍弱。执行速度极快。由于是进程内注入交互延迟极低。快。与测试Runner在同一进程但通过XCTest框架调度比EarlGrey稍慢。稳定性理论上更高。得益于自动同步对异步操作的容忍度更强。高但对测试环境的“洁净度”和开发者编写的等待逻辑依赖更大。学习曲线较陡峭。需要理解其同步理念和丰富的匹配器API。相对平缓。与Xcode和Swift/Obj-C开发体验无缝衔接。社区与生态由Google维护社区相对较小但用于大型生产项目验证过。苹果官方维护生态完善文档丰富第三方工具支持多。调试支持提供GREYConfiguration进行详细调试并可结合[GREYFailureHandler](http://GREYFailureHandler)定制失败处理。深度集成Xcode调试器测试失败时可直接高亮元素体验流畅。实操心得如果你的应用交互复杂、异步操作多如大量使用Combine/RxSwift、频繁网络请求追求测试套件的极致稳定性和执行速度EarlGrey是更好的选择。如果你的团队更看重与苹果生态的无缝集成、更快的上手速度或者项目已经大量使用XCUITest那么继续深耕XCUITest也是完全合理的。3. 从零开始搭建EarlGrey测试环境3.1 项目集成与依赖管理目前集成EarlGrey到你的iOS项目最推荐的方式是通过Swift Package Manager (SPM)。这种方式比古老的CocoaPods手动下载更简洁依赖关系更清晰。在Xcode中添加包依赖打开你的iOS项目或专门为UI测试新建一个Target。导航到File - Add Packages...。在搜索框中输入EarlGrey的GitHub仓库地址https://github.com/google/EarlGrey.git。将Dependency Rule设置为Up to Next Major Version例如2.2.0。Xcode会自动获取包。点击Add Package。选择产品与目标添加包后Xcode会弹窗让你选择要集成的产品。关键步骤来了你需要为你的UI测试Target通常是YourAppUITests添加EarlGrey和EarlGreyApp这两个产品。EarlGrey包含框架的核心逻辑和API供你的测试代码调用。EarlGreyApp是一个动态库它将被注入到你的被测应用中。这是实现进程内控制和同步的桥梁。确保不要把这些包添加到你的主App Target中。验证集成 在你的UI测试类中例如LoginUITests.swift尝试导入模块。如果SPM配置正确你应该可以成功编译。import XCTest import EarlGrey // 核心API // EarlGreyApp 会在后台自动链接通常不需要显式import class LoginUITests: XCTestCase { // ... 你的测试代码 }注意事项如果你的项目因某些原因无法使用SPM例如需要支持较低版本的Xcode仍然可以使用CocoaPods。在Podfile中针对你的UI测试Target添加pod EarlGrey。但请注意官方对CocoaPods的支持和维护可能不如SPM及时。3.2 基础配置与首个测试用例环境搭好了我们来写一个最简单的测试验证一切是否工作正常。假设我们有一个登录页面上面有一个ID为usernameField的文本框和一个ID为loginButton的按钮。创建测试类并设置setUp 在每个测试用例执行前我们需要初始化EarlGrey。最好的地方是在XCTestCase的setUp()方法中。import XCTest import EarlGrey class SimpleLoginUITests: XCTestCase { override func setUp() { super.setUp() // 关键在每次测试开始前重置EarlGrey的状态。 // 这能确保测试之间的独立性避免状态污染。 GREYTestHelper.enableFastAnimation() } }GREYTestHelper.enableFastAnimation()是一个非常有用的辅助方法它会将动画速度调到最快从而显著减少测试执行时间。这在CI/CD流水线中能节省大量时间。编写你的第一个交互测试 我们来模拟用户输入用户名并点击登录。func testUserCanTapLoginButton() { // 1. 查找元素使用 accessibilityID 是最稳定、推荐的方式。 let usernameField GREYElementInteractionMatchers.matcher(forAccessibilityID: usernameField) let loginButton GREYElementInteractionMatchers.matcher(forAccessibilityID: loginButton) // 2. 执行交互链式调用清晰表达“找到元素然后执行操作”。 EarlGrey.selectElement(with: usernameField) .perform(grey_tap()) // 先点击文本框获取焦点 .perform(grey_typeText(testUser\n)) // 输入文本\n可以模拟键盘回车 EarlGrey.selectElement(with: loginButton) .perform(grey_tap()) // 点击登录按钮 // 3. 添加断言验证点击后是否跳转到了新页面例如通过新页面的一个特征元素来判断。 // 假设登录成功后会显示一个ID为“welcomeMessage”的标签。 EarlGrey.selectElement(with: GREYElementInteractionMatchers.matcher(forAccessibilityID: welcomeMessage)) .assert(grey_sufficientlyVisible()) // 断言该元素是可见的 }运行测试确保你的模拟器或真机正在运行你的主应用。在Xcode中选择你的UI测试Scheme然后使用快捷键CmdU运行测试或者点击测试方法旁边的菱形按钮。如果一切顺利你会看到模拟器自动启动应用执行输入和点击操作然后测试通过。踩坑记录首次运行很可能失败并报错提示“EarlGrey has not been invoked yet”。这通常是因为EarlGreyApp动态库没有正确加载。请务必检查你的UI测试Target的Build Phases中是否自动添加了Embed App Extensions或Embed Frameworks阶段并包含了EarlGreyApp.frameworkSPM通常会处理好但有时需要手动确认。主应用的Info.plist是否需要添加NSPrincipalClass对于较新版本的EarlGrey2.0和Xcode通常不需要了。如果遇到问题查阅EarlGrey GitHub仓库的Issue和最新文档是首选。4. EarlGrey核心API与最佳实践详解4.1 元素定位的艺术GREYMatcher详解稳定UI自动化的第一步是精准地找到元素。EarlGrey提供了强大的GREYMatcher体系它远比简单的accessibilityID丰富。基础匹配器grey_accessibilityID(_:)首选方式。为UIView设置accessibilityIdentifier它专为测试设计不会影响UI或无障碍功能且优先级最高。grey_accessibilityLabel(_:)匹配元素的无障碍标签。注意如果标签是动态的如显示用户名会导致测试脆弱。grey_text(_:)匹配UILabel、UITextField等控件的文本内容。grey_kindOfClass(_:)匹配特定类的元素如grey_kindOfClass(UIButton.self)。组合匹配器强大之处 你可以通过逻辑运算符组合多个匹配器进行精细筛选。// 找到一个既是UIButtonaccessibilityID是“submit”并且当前是可见的元素 let submitButtonMatcher grey_allOf([ grey_kindOfClass(UIButton.self), grey_accessibilityID(submit), grey_sufficientlyVisible() ]) // 或者使用更易读的链式组合 let matcher grey_kindOfClass(UIButton.self) .and(grey_accessibilityID(submit)) .and(grey_sufficientlyVisible())相对位置与索引匹配器// 找到第一个匹配的元素默认就是第一个 EarlGrey.selectElement(with: matcher).atIndex(0) // 找到最后一个匹配的元素 EarlGrey.selectElement(with: matcher).atIndex(GREYInteraction.INDEX_LAST) // 找到某个元素下方的兄弟元素在同一个父视图内 EarlGrey.selectElement(with: grey_accessibilityID(“cell1”)) .perform(grey_tap()) EarlGrey.selectElement(with: grey_accessibilityID(“cell2”)) .inRoot(grey_kindOfClass(UITableView.self)) // 限定搜索范围在TableView内 .assert(grey_below(grey_accessibilityID(“cell1”))) // 断言cell2在cell1下面实操心得accessibilityID是定位元素的“银弹”。在开发阶段就和开发同学约定好为所有需要测试的交互元素添加唯一的ID。这能从根本上解决因UI文本、布局改动导致的测试用例大面积失效问题。组合匹配器非常强大但应谨慎使用依赖于文本、坐标的匹配器它们会使测试变得脆弱。4.2 丰富的交互与断言API找到元素后就是与之交互和验证状态。常用交互操作grey_tap()点击。grey_longPress()/grey_longPressWithDuration(_:)长按。grey_typeText(_:)输入文本。对于有安全输入的文本框使用grey_replaceText(_:)。grey_clearText()清除文本。grey_swipeFast(_:)/grey_swipeSlow(_:)快速/慢速滑动可指定方向.left,.right,.up,.down。grey_scrollToContentEdge(_:)滚动到列表或滚动视图的边界。grey_multipleTap(_:)多次点击。常用状态断言grey_sufficientlyVisible()元素足够可见并非完全在屏幕内但主要部分可见。grey_notVisible()元素不可见。grey_enabled()元素处于可交互状态。grey_selected()元素被选中如UIButton的isSelected状态。grey_text(_:)断言元素文本内容。grey_hasValue(_:)断言UISlider等控件的值。链式调用与错误处理 EarlGrey的API设计支持流畅的链式调用使测试代码读起来像自然语言。EarlGrey.selectElement(with: grey_accessibilityID(“switch”)) .assert(grey_notNil()) // 断言元素存在 .perform(grey_tap()) // 执行点击 .assert(grey_selected()) // 断言点击后变为选中状态如果链中任何一步失败测试会立即终止并抛出包含详细信息的错误例如元素未找到、交互超时等。4.3 处理复杂场景弹窗、WebView与系统控件处理系统弹窗如权限请求 系统弹窗不在你的应用视图层级内EarlGrey无法直接定位。标准做法是使用addUIInterruptionMonitor。// 在setUp或测试方法开始处添加中断监视器 addUIInterruptionMonitor(withDescription: 系统权限弹窗) { (alert) - Bool in // 判断是否是目标弹窗 if alert.buttons[允许].exists { alert.buttons[允许].tap() return true // 表示已处理此中断 } return false // 未处理传递给其他监视器 } // 注意需要在触发弹窗的操作如调用相册之前添加此监视器。 // 触发操作后可能需要一个简单的用户交互如tap来激活监视器。 AppDelegate.shared?.requestPhotoPermission() // 触发系统弹窗 EarlGrey.selectElement(with: grey_anything()).perform(grey_tap()) // 激活监视器测试WebView内容 EarlGrey 2.0之后对WKWebView的支持需要借助EarlGreyApp的注入。你需要确保WebView内的内容可以通过无障碍属性访问。通常与前端开发协作为关键交互元素添加测试ID如>// LoginPage.swift import EarlGrey class LoginPage { // 元素定位器 private var usernameField: GREYMatcher { return grey_accessibilityID(“usernameField”) } private var passwordField: GREYMatcher { return grey_accessibilityID(“passwordField”) } private var loginButton: GREYMatcher { return grey_accessibilityID(“loginButton”) } private var errorMessageLabel: GREYMatcher { return grey_accessibilityID(“loginErrorMessage”) } // 页面操作 discardableResult func enterUsername(_ name: String) - Self { EarlGrey.selectElement(with: usernameField).perform(grey_typeText(name)) return self // 支持链式调用 } func enterPassword(_ password: String) - Self { EarlGrey.selectElement(with: passwordField).perform(grey_typeText(password)) return self } func tapLogin() - Self { EarlGrey.selectElement(with: loginButton).perform(grey_tap()) return self } // 页面断言 func assertErrorMessageIsVisible() { EarlGrey.selectElement(with: errorMessageLabel).assert(grey_sufficientlyVisible()) } func assertLoginButtonIsEnabled(_ isEnabled: Bool) { let assertion isEnabled ? grey_enabled() : grey_not(grey_enabled()) EarlGrey.selectElement(with: loginButton).assert(assertion) } } // 在测试用例中的使用变得极其简洁 func testLoginWithInvalidCredentials() { LoginPage() .enterUsername(“wrongUser”) .enterPassword(“wrongPass”) .tapLogin() .assertErrorMessageIsVisible() }这样做的好处显而易见UI定位逻辑只在一处定义如果登录页的accessibilityID改了你只需要修改LoginPage类测试用例本身只关心业务逻辑和测试数据可读性大大提升。5.2 测试数据管理与准备UI测试不应依赖生产环境的不确定数据。你需要可控的测试数据。后端Mock这是最彻底的方式。在测试构建阶段部署一个专门用于测试的Mock服务器或者使用像WireMock这样的工具在本地模拟API。测试开始时通过API调用准备测试用户和数据。本地数据注入对于数据层使用Core Data或Realm的应用可以在测试setUp中直接向内存中的持久化容器插入预设好的数据。测试结束后在tearDown中清空。利用开发后门在Debug模式下为应用注入一些“后门”代码例如通过特定的摇一摇手势或隐藏的设置页面一键切换到测试账户或重置为初始状态。这种方式对开发者友好但需要主应用代码配合。UI操作准备如果以上都做不到那就只能通过UI操作来准备数据。例如每个测试用例都从注册一个新用户开始。但这会显著增加测试执行时间并引入更多的不稳定性。应尽可能避免。5.3 测试组织与CI/CD集成测试分类与标签使用XCTest的setUp()/tearDown()以及setUpWithError()/tearDownWithError()来管理测试生命周期。对于耗时的测试如端到端流程可以为其打上标签在CI中与快速冒烟测试分开运行。class CriticalPathUITests: XCTestCase { override class func setUp() { /* 整个类执行一次如启动Mock服务器 */ } override func setUpWithError() throws { /* 每个测试执行前如登录 */ } func testPurchaseFlow() { /* 打上耗时标签 */ } }CI/CD集成使用专用设备/模拟器在CI机器上使用xcrun simctl命令行工具创建、启动和关闭特定型号和系统的模拟器。确保环境一致。并行测试利用Xcode的-parallel-testing-enabled和-maximum-parallel-testing参数将测试用例分发到多个模拟器上并行执行大幅缩短反馈时间。测试报告CI工具如Jenkins, GitLab CI, GitHub Actions通常能解析Xcode输出的xcresultbundle生成可视化的测试报告。也可以集成第三方工具如Slather生成代码覆盖率报告。失败重试与截图在CI脚本中可以对失败的测试用例进行有限次数的重试。同时在EarlGrey测试失败时自动截图并上传到CI日志或文件服务器这对于后续排查问题至关重要。EarlGrey可以通过GREYConfiguration启用截图功能。6. 高级技巧与疑难问题排查6.1 自定义匹配器与操作当内置的GREYMatcher和GREYAction无法满足需求时你可以自定义它们。这是EarlGrey框架扩展性强的体现。自定义匹配器例如你想匹配一个特定颜色的按钮。func grey_buttonWithBackgroundColor(_ color: UIColor) - GREYMatcher { return GREYElementMatcherBlock(matcherName: “Button with background color”) { element in guard let button element as? UIButton, let bgColor button.backgroundColor else { return false } return bgColor.isEqual(color) } } // 使用 EarlGrey.selectElement(with: grey_buttonWithBackgroundColor(.systemBlue)).perform(grey_tap())自定义操作例如你想实现一个复杂的多点触控手势。let customPinch GREYActionBlock.action(withName: “Custom Pinch”) { element, errorOrNil in // 在这里实现具体的手势逻辑可能需要直接调用私有API或使用其他方式 // 注意这可能会降低测试的稳定性和可维护性 return true // 返回操作是否成功 }注意事项自定义匹配器和操作是一把双刃剑。它们提供了极大的灵活性但也可能引入复杂性并使测试与具体的UI实现细节耦合过紧。优先考虑是否可以通过改进应用的无障碍属性或调整测试设计来避免自定义。6.2 性能调优与超时控制默认情况下EarlGrey的同步超时时间可能较长以保证稳定性。但在CI环境中你可能需要调整以平衡速度与稳定性。override func setUp() { super.setUp() let config GREYConfiguration.sharedInstance() // 将交互超时从默认的30秒减少到15秒 config.setValue(15.0, forConfigKey: kGREYConfigKeyInteractionTimeoutDuration) // 将同步超时从默认的30秒减少到10秒 config.setValue(10.0, forConfigKey: kGREYConfigKeySyncTimeoutDuration) // 禁用动画可以极大加速测试 GREYTestHelper.enableFastAnimation() // 在不需要网络同步的测试中可以关闭网络同步以提升速度 // config.setValue(false, forConfigKey: kGREYConfigKeySynchronizationEnabled) }关键权衡缩短超时可以加快失败测试的反馈速度但也可能增加因设备瞬时卡顿导致的“假阴性”失败。你需要根据自己项目的稳定性和CI环境性能来找到一个合适的值。6.3 常见失败原因与调试手段即使有强大的同步机制测试依然可能失败。以下是一些常见原因和排查步骤元素找不到No element found首先检查accessibilityIdentifier是否设置正确是否在正确的线程上设置必须在主线程元素是否真的被添加到了视图层级中使用调试工具在测试失败后EarlGrey会打印出当前的UI层次结构。仔细查看这个输出确认你寻找的元素及其ID是否存在。你也可以在测试中临时插入printHierarchy()来打印。EarlGrey.selectElement(with: grey_anything()).perform(grey_printHierarchy())检查同步状态是不是有永不结束的动画或死循环阻塞了主线程EarlGrey的同步引擎在等待它们。尝试在setUp中全局禁用动画。元素不可交互Element is not interactable检查元素是否被其他视图遮挡userInteractionEnabled属性是否为false是否在屏幕可见区域内使用grey_sufficientlyVisible()断言先验证可见性。尝试滚动如果元素可能在屏幕外先尝试滚动到其位置。EarlGrey.selectElement(with: matcher).perform(grey_scrollToContentEdge(.top)) // 先滚动到顶部 EarlGrey.selectElement(with: matcher).perform(grey_scrollToContentEdge(.bottom)) // 或底部测试在CI上失败本地却成功环境差异CI机器的模拟器型号、iOS版本是否与本地一致CPU和内存资源是否充足清理构建尝试清理Derived Data重新构建。CI环境需要确保每次构建都是全新的。增加稳定性适当增加超时时间在CI脚本中加入测试前的模拟器重启步骤。日志与截图确保CI配置能捕获完整的设备日志和测试失败时的屏幕截图这是远程调试的生命线。使用GREYFailureHandler定制失败行为 你可以实现自己的GREYFailureHandler在测试失败时执行自定义操作比如保存更详细的日志、录制屏幕、或者尝试一些恢复操作而不是让测试立刻崩溃。这对于构建健壮的自动化测试套件很有帮助。我个人在大型项目中推行EarlGrey的体会是前期的投入框架学习、为元素添加ID、搭建页面对象确实比直接用XCUITest要多。但一旦这套体系建立起来其带来的长期收益是巨大的测试用例的稳定性极高维护成本随着页面对象的复用而降低整个团队的开发节奏因为有了可靠的自动化回归保障而变得更加自信和快速。它更像是一个为“工程化”和“可持续性”而生的测试解决方案。如果你正在为复杂的iOS应用寻找一个坚实的UI自动化基石EarlGrey无疑是一个需要认真考虑的选择。