[[429539]]

前言

筆者入職 Trip.com 已滿一年，回顧這一年的工作歷程，約一半的時間都在做 UI 自動化測試相關內容。從而，筆者更深入地研究了 iOS 平臺下的自動化測試技術，目前也在負責部門 App 自動化測試平臺的搭建和維護。故想借這篇文章一并將所踩過的坑以及學習到的技術，系統且全面地整理出分享給大家。

本文的內容大致如下：

• iOS/macOS UI 自動化測試框架 XCUITest 原理詳解
• 基于 Web Service 的自動化測試平臺架構設計
• Appium 與 Macaca 介紹與對比
• Trip.com App UI 自動化測試現狀

自動化測試可以分為白盒測試、黑盒測試以及灰盒測試，本文主要圍繞 Apple 官方提供的 XCUITest 測試框架，逐步闡明 iOS 操作系統下的 UI 自動化測試原理、架構設計思想以及應用場景。

XCUITest 原理詳解

iOS UI自動化測試核心技術

2015 年，Apple 發布了 UI 自動化測試框架 XCUITest 并集成在 Xcode7 中，而 iOS/macOS UI 自動化測試依賴兩個核心技術：XCUITest 和 Accessibility。

XCUITest 是集成在 Xcode 中的測試框架，若想使用 UI 測試功能，可以在創建 iOS 項目時勾選 Include Tests 選項，從而使項目具備自動化測試的能力。而 Accessibility 技術，則是 Apple 官方為視障用戶提供的一整套使用 iOS/macOS App 的解決方案。

Xcode 項目創建 UITests Target 并運行測試，其編譯產物 Test App 本質上是一個 Deamon 守護進程，該進程有獨立的應用程序生命周期，依靠 XCUIApplication 類型進行管理。UITests 的 Test App 進程在運行時會驅動 Host App(項目的主 Target 產物)，并且利用元素審查的相關 API 驅動 Host App 模擬用戶行為交互，從而進行 UI 自動化測試。

對于 Accessibility 技術，開發人員需要注意的是，XCUITest 框架默認并不能將所有視圖元素審查到，只會審查到可以被 VoiceOver 功能讀取文字的元素。比如，UIButton 和 UILabel，這些視圖對于視障用戶而言可以通過語音來獲知其內容，而對于 UIImageView、 UIView 這種對于視障人士并不友好的 UIKit 視圖元素默認是不會審查到的，所以編碼時要另行配置 Accessibility 相關屬性，以保證其支持 Accessibility 從而在 UI 自動化查詢的元素層級中可見。

基于 XCUITest 框架 和 Accessibility 技術的自動化測試，有利于 App 進行數據一致性校驗，但 UI 一致性校驗能力較弱。比如，App 可以針對某些數據請求結果或者某個元素是否存在進行校驗，而視覺展示效果卻仍需要人工介入。

XCUITest 框架結構

XCUITest 測試框架 API 主要包含：元素查詢(UI Element Queries)相關類型，如 XCUIElementQuery，UI 元素(UI Elements)相關類型，如 XCUIElement，以及測試 App 生命周期類型(Application Lifecycle)類型，如 XCUIApplication。

接下來，我們創建一個簡單 Demo 項目，來學習如何使用 XCUITest 框架編程，并進行 iOS UI 自動化測試。

利用 Xcode UITests Target 進行自動化測試

創建一個 Demo 工程，勾選 Include Tests 選項，在 ViewController 里編寫如下代碼。本文 Demo 工程可訪問鏈接 https://github.com/niyaoyao/UITestDemo 。

import UIKit 
 
class ViewController: UIViewController { 
    lazy var testImageView: UIImageView = { 
        let testImageView = UIImageView(frame: CGRect(x: 0, y: 0, width: 100, height: 100)) 
        testImageView.backgroundColor = .red 
        testImageView.accessibilityIdentifier = "test imageview" 
        return testImageView 
    }() 
    lazy var testLabel: UILabel = { 
        let testLabel = UILabel(frame: CGRect(x: 0, y: 130, width: 100, height: 20)) 
        testLabel.backgroundColor = .green 
        testLabel.text = "test label" 
        return testLabel 
    }() 
    lazy var testView: UIView = { 
        let testView = UIView(frame: CGRect(x: 0, y: 170, width: 100, height: 50)) 
        testView.backgroundColor = .blue 
        testView.accessibilityIdentifier = "test view" 
        return testView 
    }() 
    lazy var testButton: UIButton = { 
        let testButton = UIButton(frame: CGRect(x: 0, y: 230, width: 100, height: 50)) 
        testButton.backgroundColor = .yellow 
        testButton.setTitle("測試按鈕", for: .normal) 
        return testButton 
    }() 
     
    override func viewDidLoad() { 
        super.viewDidLoad() 
        view.addSubview(testImageView) 
        view.addSubview(testLabel) 
        view.addSubview(testView) 
        view.addSubview(testButton) 
    } 
} 

源碼解釋，上面的這段代碼創建了四個視圖實例，分別為 UIImageView、UILabel、UIView 和 UIButton 類型，并將四個視圖實例添加到當前頁面中。其中，UILable 和 UIButton 僅設置了frame、字符串、背景顏色等屬性，但是對于 UIImageView 和 UIView 視圖除了一般的視圖屬性，還設置了 accessibilityIdentifier 個屬性是為了讓 UIImageView 和 UIView 支持 Accessibility 功能，但僅設置這個屬性并不能使這兩個視圖在 Accessibility 的元素層級結構中可見。接下來就對 Accessibility 功能做簡要介紹。

讓 App 支持輔助功能

使用 Accessibility Inspector

前文中提到 Apple 對于視圖元素會默認審查能夠通過 VoiceOver 播放文字的視圖元素，而對于 UIImageView、UIView 這種默認不支持 Accessibility 功能的需要配置相關特性，而開發人員在開發過程中可以通過 Accessibility Inspector 查看不同進程的 Accessibility 元素層級，該應用可以審查 iOS 和 macOS 的元素。

選擇 Xcode 的圖標菜單并選擇 Open Developer Tool 選項，點擊 Accessibility Inspector 即可開始使用。

當我們沒有設置 isAccessibilityElement 屬性時，在 Accessibility 元素層級結構中就無法看到 UIImageView 和 UIView 元素，只能看到 “test label” 和“測試按鈕”。而當我們將 UIImageView 和 UIView 的 isAccessibilityElement 屬性設置為 true 時， UIImageView 和 UIView 元素才能在元素層級中可見。

Accessibility 相關屬性

UIAccessibility: var accessibilityLabel: String? { get set } 

accessibilityLabel 屬性可以解決絕大部分的 Accessibility 問題，當光標將焦點放在設置該屬性的元素師時，它的內容可由 VoiceOver 讀取的人類可讀的字符串。但如果不是需要被視障用戶獲知的視圖元素，僅用于自動化測試，就可以不用設置該屬性。

UIAccessibility: var accessibilityIdentifier: String? { get set } 

accessibilityIdentifier 屬性不會被 VoiceOver 誦讀，而是面向開發人員的字符串，可在不希望用戶操作 accessibilityLabel 的情況下使用。

UIAccessibility: var isAccessibilityElement: Bool { get set } 

如果 isAccessibilityElement 未設置為 true，那么這個視圖將不會在 Accessibility 視圖層次結構中可見。

• The default value for this property is false unless the element is a standard UIKit control, in which case, the value is true. —— Apple Documentation

另外，根據 Apple 官方中的介紹 UIControl 的子類的 isAccessibilityElement 屬性都默認設置為 true。

手動編寫測試 case

import XCTest 
 
class UITestDemoUITests: XCTestCase { 
 
    override func setUpWithError() throws { 
        // ... 
    } 
 
    override func tearDownWithError() throws { 
        // Put teardown code here. This method is called after the invocation of each test method in the class. 
    } 
 
    func testExample() throws { 
        // UI tests must launch the application that they test. 
        let app = XCUIApplication() 
        app.launch() 
        let label = app.staticTexts["test label"] 
        XCTAssertTrue(label.exists) 
        let button = app.buttons["測試按鈕"] 
        XCTAssertTrue(button.exists) 
        let imgview = app.images["test imageview"] 
        XCTAssertTrue(imgview.exists) 
        let view = app.otherElements["test view"] 
        XCTAssertTrue(view.exists)   
        // Use recording to get started writing UI tests. 
        // Use XCTAssert and related functions to verify your tests produce the correct results. 
    } 
 
    func testLaunchPerformance() throws { 
        if #available(macOS 10.15, iOS 13.0, tvOS 13.0, watchOS 7.0, *) { 
            // This measures how long it takes to launch your application. 
            measure(metrics: [XCTApplicationLaunchMetric()]) { 
                XCUIApplication().launch() 
            } 
        } 
    } 
} 

源碼解釋，XCUIApplication 類型的實例，是管理 Test App 生命周期的實例對象，可以通過該對象獲取 Accessibility 視圖層級結構，通過 XCTAssertTrue 斷言元素是否存在。

錄制交互行為自動生成測試 case

對于相對復雜的 Test Case，可以通過 Xcode 提供的測試行為錄制功能進行自動代碼生成。

UITest 執行過程

點擊 Test 定義的 function 前方對應的播放按鈕或者 Test Navigator 中對應 function 的播放按鈕，就可以開始執行 UI 測試。而開始 UI 測試后，會先執行源碼編譯，將 Target 中的源碼編譯出產物，啟動 Test App 進程，進入 Test 程序執行 app.launch() 則會啟動 App，然后執行斷言源碼。

iOS 自動化測試工具鏈

編寫了基本的 UI 測試的 UITest Target 方法之后，我們可以利用相關命令行工具鏈，將 iOS UI 自動化測試腳本化，從而可以方便集成入 CI 流程。

xcodebuild

xcodebuild test -project UITestDemo.xcodeproj -scheme UITestDemoUITests -destination 'platform=iOS,id=<iPhoneUDID>' 

可以利用上述命令執行自動化測試，也可以將命令進行拆分，拆分為測試編譯命令和測試執行命令，以便細化自動化測試過程。測試編譯命令：

xcodebuild build-for-testing -project ****.xcodeproj -scheme **** -configuration Debug -sdk iphonesimulator -destination 'platform=iOS Simulator,id=XXXXX' -derivedDataPath ~/derived_path -quiet COMPILER_INDEX_STORE_ENABLE=NO GCC_WARN_INHIBIT_ALL_WARNINGS=YES | tee build.log 

測試執行命令：

xcodebuild test-without-building -xctestrun ****.xctestrun -configuration Debug -sdk iphonesimulator -destination 'platform=iOS Simulator,id=XXXXXX' -derivedDataPath ~/derived_path -resultBundlePath ****.xcresult -only-testing:****-UITests/TargetTests 

xcrun simctl

simctl 命令是 xcrun 的一套自命令，提供一系列用來控制 iOS 模擬器的命令。

列舉當前已經啟動的模擬器 xcrun simctl list devices | grep booted

啟動模擬器 xcrun simctl boot XXXXX

關閉模擬器 xcrun simctl shutdown XXXXX

設置模擬器權限 xcrun simctl privacy XXX grant location-always xx.xx.xxx

安裝 App xcrun simctl install {} {}'.format(uuid, app_path)

運行指定 App xcrun simctl launch {} {}'.format(uuid, bundle_id)

結束指定 App xcrun simctl terminate {} {}'.format(uuid, bundle_id)

卸載指定 App xcrun simctl uninstall {} {}'.format(uuid, bundle_id)

ideviceinstaller

與控制模擬器相似，iOS 真機也有相應的控制命令行工具鏈，例如 ideviceinstaller。

安裝 apppath 下的 app ideviceinstaller -i apppath

安裝 xxx.ipa 為應用在本地的路徑ideviceinstaller -u [udid] -i [xxx.ipa]

卸載應用 ideviceinstaller -u [udid] -U [bundleId]

查看設備安裝的第三方應用 ideviceinstaller -u [udid] -l

同上，查看設備安裝的第三方應用 ideviceinstaller -u [udid] -l -o list_user

查看設備安裝的系統應用 ideviceinstaller -u [udid] -l -o list_system

查看設備安裝的所有應用 ideviceinstaller -u [udid] -l -o list_all

列出手機上所有的用戶安裝的app ideviceinstaller -l

ios-deploy

查看當前鏈接的設備 ios-deploy -c

安裝APP ios-deploy --[xxx.app]

卸載應用 ios-deploy --id [udid] --uninstall_only --bundle_id [bundleId]

查看所有應用 ios-deploy --id [udid] --list_bundle_id

查看應用是否安裝 ios-deploy --id [udid] --exists --bundle_id

利用以上命令行工具鏈，就可將 UI 自動化測試根據不同項目進行自定義的腳本接入 CI 流程，比如接入 GitLab Pipelines 中，對 code review、 merge request 等過程進行干預。

基于 Web Service 的架構設計

App 自動化測試平臺的架構設計

從前文中我們了解到，我們可以利用 Xcode 創建 UITest Target，編寫 UITest Case 測試腳本，輔以 xcodebuild 等相關命令工具鏈編寫自動化腳本，就能接入 CI/CD 流程，實現 iOS App 的 UI 自動化測試，從而達到釋放人力資源，降低人工測試的成本的目的。

但與此同時，又有新的問題出現，那就是業務頻繁的迭代的情況下，我們寫的 Test Case 腳本，很容易因為業務的改變而導致廢棄，測試腳本復用率低，又增加了開發成本。如果不同系統平臺的 App，如，Android、iOS 甚至 Web App 能共用一套測試腳本，提高腳本復用率，會降低開發成本，更有利于業務回歸。

除此之外，對于復雜業務的回歸測試，若希望提高大量測試 case 的業務回歸效率，必然要提高并發性，縮減測試時間。故在這樣的需求下， Facebook 團隊就設計出了 Appium 這樣的基于 Web Service 的自動化測試工具。類似 Appium 的測試工具還有阿里巴巴團隊設計的 Macaca，這類測試工具的設計架構如下圖可視。

基于 Web Service 的自動化測試的架構主要可以分為命令分發服務 Web Service 模塊和 UI 測試驅動模塊。

對于命令分發服務模塊，其任務是搭建通用測試 case 腳本與底層驅動之間的通信橋梁，而 HTTP RESTful API 恰能滿足這樣跨平臺的需求。因此，Web Service 模塊需要搭建 HTTP Web Service 進行命令轉發，將自動化測試中的 Test Case 腳本作為 Web Service 的 Client 端，向 Web Service 的 Server 端發送請求。而 Web Service 的 Server 接收到請求后，再將請求轉發到底層的 UI 測試的驅動進程，以便后續驅動 UI 測試。

對于 UI 測試驅動模塊，其主要任務是，接收 Web Service Server 端轉發來的請求，并觸發驅動進程進行 UI 自動化測試，最終收集測試結果，并生成測試報告。Android 操作系統的底層驅動一般是 UIAutomator 程序;而對于 iOS 系統， Appium 用的是 WebDriverAgent，Macaca 是 XCTestWD。而不論 WebDriverAgent 還是 XCTestWD 都是一個基于 XCUITest 的 Xcode project，其技術核心也就是我們前文介紹的以 XCUITest 和 Accessibility 為基礎的 iOS UI 自動化測試技術。

App 自動化測試平臺，需要先運行 Web Service Server，Server 作為測試指令的發出者，向測試驅動發出請求，從而驅動 Test App 進程操作 App。因此，需要先在 Jenkins Slave 機器啟動運行 Web Service Server，例如，在本地 4722 端口創建 Web Service，并監聽 Client 向該端口發送的請求，再轉發給驅動層。

驅動項目(WebDriverAgent 或 XCTestWD)編譯成功后，都會在運行的設備上創建并運行一個 Runner 程序，該程序就是利用 XCUITest 編譯成 Test App，但與前文 Demo 不同的是，這個程序會在設備上也會創建一個 Web Service，接收 Server 發來的請求，并根據 Test App 中程序處理請求，最后返回響應結果給 Server。

例如，創建測試 Session 過程，WebDriverAgent 編譯成功后會在測試設備的 8080 端口創建 Web Service，從而 Jenkins Slave 上運行的 Web Service Server 能夠將 Client 的請求轉發給 WebDriverAgent 創建的 Web Service，然后經過 WebDriverAgent 的內部路由/wd/hub/session 進行映射，找到對應創建 session 的具體代碼，保存 Session ID 值，并將 Session ID 作為響應結果返回給 Jenkins 的 Web Server。其他測試操作如，查找 element、查找元素 value，滾動某個元素等操作，這些操作 Jenkins 的 Web Service C/S 和底層驅動間的通信過程，都與建立 Session 過程相類似。

所以，有了基于 Web Service 的 UI 自動化測試工具，我們可以更加高效地進行自動化測試，復用性更高、可支持多平臺，跨平臺測試，甚至可以利用其 Web Service 搭建分布式的測試平臺，基于 Jenkins 服務的架構設計如下圖所示。

根據上圖架構設計，我們可以利用多臺機器搭建 Jenkins 集群，根據我們 CI/CD 流程所需，向 Jenkins Server 發送請求，再由 Jenkins Server 分配不同 Jenkins Slave 執行 Job，每個 Jenkins Slave 都配置好 UI 自動化測試平臺驅動多臺設備進行自動化測試。從而實現分布式的自動化測試平臺，提高并發性、提升測試效率，縮減回歸測試的時間。

接下來就分別介紹 Appium 和 Macaca 的簡單使用。

Appium 工具鏈矩陣

WebDriverAgent

WDA 是 Facebook 基于 XCUITest 測試框架開發的 iOS UI 自動測試 Driver。類比 Macaca Runner。

源碼安裝 WDA

git clone https://github.com/appium/WebDriverAgent.git 

真機測試修改 Team ID

選擇 Apple 開發賬號的 Team。

Appium Web Service Server

Appium Server 用于 HTTP 命令轉發，驅動底層 Driver WDA。

利用 Appium Desktop 啟動 Server

下載鏈接 https://github.com/appium/appium-desktop/releases/download/v1.21.0/Appium-mac-1.21.0.dmg

安裝 Appium App，并用 GUI App 啟動 Server。

利用 Appium Command 啟動 Server

安裝 Nodejs 依賴

執行命令行

npm install -g appium 

啟動 Server

執行命令行

appium -a 127.0.0.1 -p 4722 

參數列表：http://appium.io/docs/en/writing-running-appium/server-args/index.html

端口映射

執行命令行

iproxy [LOCAL_TCP_PORT] [DEVICE_TCP_PORT] 

http://manpages.ubuntu.com/manpages//trusty/man1/iproxy.1.html

https://github.com/libimobiledevice/libusbmuxd/blob/master/tools/iproxy.c

端口映射關系

執行命令行

appium -a 127.0.0.1 -p 4722 --webdriveragent-port 8123 

如果啟動 appium server 時設置了 WDA 的 Port 為 8123，則 iproxy 命令第一個入參須是本地監聽端口可任意隨機選擇，第二個入參必須對應 appium 命令指定的 WDA 的端口，可如下執行

iproxy 8100 8123 

驅動 Runner 存儲位置

全局安裝 appium server 到本地后，WebDriverAgent.xcodeproj 存儲在以下路徑中。

/usr/local/lib/node_modules/appium/node_modules/appium-webdriveragent/WebDriverAgent.xcodeproj 

Web Service Client —— Test Case

測試項目

https://github.com/appium/appium/tree/master/sample-code

javascript-webdriverio

安裝依賴

執行命令行

cd appium-master/sample-code/javascript-webdriverio 
npm install 

修改配置

修改測試腳本中 capabilities 配置。

const iosCaps = { 
  platformName: 'iOS', 
  automationName: 'XCUITest', 
  deviceName: process.env.IOS_DEVICE_NAME || 'iPhone', 
  udid: 'iphone udid', 
  platformVersion: process.env.IOS_PLATFORM_VERSION || '13.6.1', 
  noReset: true, 
  bundleId: 'your app id', 
  app: undefined // Will be added in tests 
}; 

capabilities 文檔 https://appium.io/docs/en/writing-running-appium/caps/

https://appium.io/docs/en/writing-running-appium/default-capabilities-arg/

運行 Case

執行命令行

npm test 

Macaca 工具鏈矩陣

與 Appium 相類似，Macaca 的工具鏈矩陣也包含 Driver、Web Service Server 和 Web Service Client。

安裝 Macaca 工具鏈

# 本地安裝 
$ npm i macaca-ios --save-dev 
# 全局安裝 
$ npm i macaca-ios -g 
# 安裝有 TEAM_ID 的 macaca-ios 
$ DEVELOPMENT_TEAM_ID=TEAM_ID npm i macaca-ios -g 

更多詳細安裝過程可參閱官方文檔 https://macacajs.github.io/zh/guide/environment-setup.html#%E5%AE%89%E8%A3%85-node-js

Appium 與 Macaca 的對比

框架名稱相同點不同點

我們的 UI 自動化測試平臺最初僅接入 Macaca 框架，獨立維護一份倉庫以供內部平臺使用。而維護過程中也會遇到各種問題并自行解決，驗證無誤后也會反饋給官方，并提供相應解決方案。目前也已開始逐步接入 Appium 框架對現有平臺進行技術改造，以適應更多場景，以及保障框架長期穩定可持續地維護。

Trip.com App 自動化測試現狀

Trip.com App 在日常開發迭代過程中， UI 自動化測試的應用場景有很多，例如冒煙測試、探索測試，以及基于 Web Service 的 UI 自動化測試平臺。接下來，向大家分別介紹不同測試在 CI/CD 中扮演的角色和作用。

應用場景

冒煙測試

基本概況

• 在程序設計和軟件測試領域 ， 冒煙測試 (也包括信心測試 、健全性測試、 [1] 構建驗證測試 ( BVT ) [2] [3]、構建驗收測試 )是指初步地進行測試，并以此展示一些簡單但足以影響發布軟件版本的這一高級別的錯誤。—— Wikipedia

在 Trip.com 實際應用場景中，冒煙測試所擔任的角色主要是 Merge Request 卡點檢測，其主要作用是對 Trip.com App 的集成編譯以及運行時閃退的預先校驗。比如，對于多模塊并行開發的情況下，不同團隊的某些改動就會造成符號名找不到的問題，而冒煙測試就可以預先對此進行卡點，避免集成打包失敗降低試錯成本和時間成本。

而對于 Trip.com iOS 的冒煙測試具體實踐，就是在主項目中創建 UITest Target 編寫簡單的 UI 視圖校驗程序，并接入 GitLab Runner Pipeline，利用 xcodebuild 工具鏈對編譯過程和運行時健壯性進行初步校驗，以保證合入主分支的代碼，不會使 App 出現明顯的重大閃退等問題。

數據體現

冒煙測試在 Trip.com 快速迭代開發的過程中，作為 Merge Request 的卡點任務，利用多臺 GitLab Runner 實現并發執行六個冒煙測試任務，大大縮減了卡點校驗的時間，單個冒煙測試時間控制在 6min 之內，不僅達到了驗證集成包的編譯構建和健壯性的目的，還大大節省了測試驗證的時間成本。

探索測試

基本概況

探索性測試(Exploratory Testing)是軟件測試方法的一種，它的特點為在進行測試時，同時探索開發更多不同型態的測試方式，以便改善測試流程。—— Wikipedia

探索測試在 Trip.com App 實際應用場景中，主要擔任的角色是 App 頁面隨機測試，主要用于驗證集成打包 App 的質量，隨機點擊頁面，并收集和統計 Page View 以及 Crash 數據，最終整理成報告發給相關開發同學。

Trip.com iOS 探索測試是基于 Google eDistantObject 和 EarlGrey 開源項目開發的白盒/灰盒 UI 測試框架。區別于 XCUITest 編寫 Test Case 并且必須結合 Accessibility 的測試方式，白盒/灰盒的探索測試框架，則是利用 Test App 和 Host App 進程間通信，使 Test App 驅動 Host App 進行 UI 自動化測試，而 App 的元素審查、用戶交互以及數據收集則都是在 Host App 進程中完成。 沒有了 Accessibility 的限制，白盒/灰盒的探索測試元素審查更全面，穩定性更高，測試數據也相應更全面。

數據體現

Trip.com 探索測試是用于驗證 App 集成包穩定性的日常 Jenkins 任務，收集全部觸達頁面，可有效預先發現 Crash 問題，并發送測試結果的報告郵件給研發組。iOS 的探索測試在并發數為 5 的情況下，2 小時測試有效觸達非重復頁面可達 180 個，場景涉及首頁 Feed 流、玩樂旅拍、訂單頁面等場景。探索測試收集的 Crash 問題，會收集崩潰調用棧整理成表格，分配給相關研發同學，推動產線修改相關問題代碼。

UI 自動化測試平臺

基本概況

Trip.com App UI 自動化測試平臺，是由 IBU 公共測試團隊和 IBU 公共無線共同設計搭建的可視化、數據統一管理的質量保證平臺。在 App 快速迭代的開發過程中，為提高測試效率，利用多臺機器，搭建 Jenkins 集群，實現用例并發執行 Case，進行 App 回歸測試，減少人力測試成本，并將測試問題報告反饋給相關開發同學，推動開發同學完善功能，從而，保證 App 上線前的質量。而選用的測試框架主要是 Macaca，并且將逐步向 Appium 遷移改造。

數據體現

UI 自動化平臺目前處于開發的一階段，日常回歸測試中，對于復雜業務場景的測試，機器性能穩定且并發數目 6 的情況下，測試總耗時可控制在 40 分鐘，測試總用例數可達 209 個，Step總數 3077 步，Feature 通過率達 97.14% ，Case 通過率達 98.56%。

以上不同的自動化測試應用實踐，接入不同的 CI/CD 流程中，都為 Trip.com App 快速開發迭代過程中提供了質量保證。

總結

對于 iOS 平臺下的 UI 自動化測試技術，Apple 官方提供的兩個核心技術是 XCUITest 和 Accessibility。而為了能夠增強復用性，更利于分布式進行自動化測試，不同廠商又在此基礎上設計實現了基于 Web Service 的自動化測試平臺，優點是具有易部署、跨平臺等特性，可以更大程度上利用分布式增強并發性，提高測試效率，減少人力測試成本。

當然，市面上 UI 自動化框架還有很多，例如 STF 和 Airtest，這類框架底層驅動利用圖形圖像識別進行 App 元素的定位。而對于目前 Trip.com iOS 的自動化測試應用實踐，則更多是基于 XCUITest 框架實現的，所以本文暫不討論此類測試框架。但不論何種驅動進行 App 的自動化測試，整體的架構設計都會以文中介紹的 Web Service 進行設計，以達到跨平臺、易集成、高復用等目的。

本文轉載自微信公眾號「Swift社區」