【架構拾集】移動應用的自動化測試（BDD 方式）
我的上一篇關於自動化測試的文章，大抵已經在一年以前——一篇關於前端自動化測試的 BDD 框架對比。這麼長的時間裡，沒有相關的文章，總得給自己找一個合適的理由。
編寫測試是開發人員日常工作的一小部分，但並非是全部。即使是專業的測試人員，自動化測試也並非是全部的工作。與此同時呢，有了單元測試之外，對於自動化測試的需求，並不是那麼強烈。速度，是我們不考慮自動化測試的主要原因，執行起來慢了，進一步地導致編寫測試也慢了。UI 上一旦有一丁點的修改，那怕是得引起多少的不愉快，不得不噗呲噗呲地去修改測試。我想說的無非就是，避免編寫 “可怕” 地自動化測試 ，儘量用你的單元測試來保障質量。要是你們有 KPI 的限制，請將以上的文字當成廢話。
似乎在有些公司裡，自動化測試、單元測試並不是技術負責人要考慮的問題，可在我司並非如此，測試也在技術的範圍裡。每每開始一個專案時，就不得不去考慮自動化測試的問題，選用什麼框架合適、需要前後端如何配合、怎樣去替換第三方的服務。這些內容完全交給測試人員吧，怕是會遇到一些不順。測試人員有自己的測試技術棧，擁有自己的 “銀彈” —— 過去的經驗和程式碼庫。哪怕經驗再豐富的測試人員，有時遇到一些新的專案、技術棧，這些東西可能就用不上了，又或者是使用某些框架可能會更加便利。因此呢，要成為更好的技術人，測試也是要考慮的範疇。
說到 Web 方面的自動化測試，我算是個有經驗的老手。從頂層的 DSL 到底層的 Web Driver，到底來說，還是頗有經驗的。可是說到 APP 的自動化測試，在專案上嘗試過，但也不敢說經驗豐富。而最近的專案，正在實施相應的移動應用自動化測試。看了看方案，與之前的 Web 或者是 React Native 的自動化測試，從底層對比架構吧，相似、差距也不是太大。便想著寫篇文章來記錄一下，相應的架構設計。
技術遠景
作為一個團隊的技術負責人，我希望：擁有一個移動應用測試架構，它能快速讓測試人員快速上手——閱讀、編寫測試用例。與此同時，我希望這些測試用例是能讓非技術人員閱讀，諸如業務分析人員，並且符合真實的使用者使用場景。
架構設計
當我們談到業務分析人員也能編寫的測試，我們說的只有 BDD（Behavior Driven Development，行為驅動開發）。它是一種敏捷軟體開發的技術，它鼓勵軟體專案中的開發者、QA（測試人員）和非技術人員或商業參與者之間的協作。
BDD 在這一種上相當的迷人——能讓非技術人員編寫測試。而其核心的部分在於：建立了一個環境隔離的 DSL，仿人類語言的 DSL。咳咳，這個 DSL 實現起來，可不輕鬆。關注頂層 DSL 的同時，開發人員還要努力實現好底層的實現。舉個簡單的例子，如下是之前在 BDD 一文中的 DSL 示例，這是頂層的設計：
功能: 失敗的登入 場景大綱: 失敗的登入 假設 當我在網站的首頁
對應的，開發人員需要編寫實現：
...
Given('當我在網站的首頁', function() {
return this.driver.get('http://0.0.0.0:7272/');
});
..
從上述的程式碼中，一眼就可以看出複雜的地方，實現一個領域特定（業務特定）的 DSL 語言。
我們要完成的 DSL 實現，上層是提供一個 DSL，下層則是對接 driver 的 Agent 層。在 Web 領域裡，這個 driver 的 Agent 層負責對接不同的瀏覽器，諸如 Selenium，driver 則視不同的瀏覽器而有所不同，如 ChromeDriver、FirefoxDriver、PhantomJSDriver 等等。Selenium 這樣的測試框架，除了通過 driver 直接操作了瀏覽器，還提供了不同語言的程式設計介面。
相似的，在 APP 領域也有這樣的方案，它要通常這個 agent 來連線物理裝置，並提供一系列的程式設計介面。
架構設計方案
對整個架構有了一個基本的認識之後，讓我們繼續往下移動，來重新發掘一下：我們究竟需要哪些基本元素？
- BDD 測試框架，為開發人員提供可建立 DSL 的介面。
- 移動裝置的測試程式設計介面，提供一個操作移動應用的介面。
- 連線移動裝置的操作庫，即移動端的 WebDriver。
- 用於編寫測試時的 UI 檢查工具。
從這一點上來看，它與 Web 應用的 BDD 架構差不多。為此，我們需要準備如下的一些框架：
- Robot Framework，一個支援 BDD 的、基於 Python 編寫的功能自動化測試軟體框架。
- Appium，是一個開源測試自動化框架，用於原生，混合和移動 Web 應用程式。它使用 WebDriver 協議來驅動 iOS、Android 和 Windows 應用程式。
- XCUITest Driver，基於 Apple 官方的介面自動化測試 XCUITest 封裝的測試介面，可以直接執行 iOS 的自動化測試。
- UiAutomator2 Driver，則是 Google 官方提供的用於 Android 系統的測試介面，可以直接執行 Android 的自動化測試。
- Appium Inspector，用於查詢 iOS/Android 上的元素
- UiAutomator Viewer，由 Android SDK 自帶的元素查詢工具。
由於我們計劃的頂層是由 DSL 來實現，而對應的 BDD 層實現是由 Robot Framework 來完成的。Robot Framework 使用的是 Python 語言，我們就需要找到對應的 Python 主要依賴有：
- robotframework，即 Robot Framework 本身
- robotframework-appiumlibrary，用於為 Robot Framework 提供 Appium 相應的介面封裝
- robotframework-ride，用於 Robot Framework 的測試資料編輯器
有了這些主要的庫，我們就可以編寫我們的 DSL？不，我們還需要配置好，對應的移動端 Driver。
Android Driver 依賴
比較簡單，通過appium-uiautomator2-driver
庫就擁有了 driver。
iOS Driver 依賴
為了實現對 iOS 裝置的自動化測試，需要安裝 XCUITest，為此我們需要下面的這一系列工具：
libimobiledevice carthage ios-deploy xcodebuild xcpretty
看，有了這一系列的知識，我們幾乎知道怎麼做搭建移動應用的自動化測試。
結論
還是 Web 大法好。