@作者 彭海波 轉載請注明出處
前言
由於需求的快速迭代和敏捷測試的要求，在測試過程中引入自動化成為必不可少的手段。作為一個互聯網測試團隊，我們自然也引入了自動化測試這個環節。在眾多的測試框架中，我們選取了相對成熟穩定，支持多種平台的Appium框架。雖然Appium自身的Api能解決大多數的測試場景，但總有漏網之魚。不巧，就是這些漏網之魚往往成為我們自動化實施中的那些梗。本文主要介紹我們測試團隊在Appium UI自動化實施過程遇到的梗，以及對應的解決方法。
自動化測試
Appium自動化框架
我們這里先簡單介紹下Appium。Appium是一個移動端的自動化框架，可用於測試原生應用，移動網頁應用和混合型應用。Appium的核心是一個遵守REST設計風格的web 服務器，它接受客戶端的連接，接收客戶端的命令，在手機設備上執行命令，然后通過HTTP的響應收集命令執行的結果。這種架構給我們提供了很好的開放特性：只要某種語言有http 客戶端的api，我們就可以通過這個語言寫我們的測試代碼。
自動化過程
自動化過程廣義上來講是對測試過程的一個建模，就是說通過測試腳本來模擬手工測試的過程。測試過程的三要素是：前提條件，測試步驟，結果校驗。那么對應的自動化測試過程也應該包含這三個要素。我們在實施自動化的過程是怎么體現這三個要素的呢？這里可以看下一個典型的測試腳本。
從上面的測試腳本我們可以看出，我們自動化測試是通過找到對應的元素，然后執行相應的動作，即可達到自動化的效果。但這個過程只是最基本的，實際項目過程中，我們會遇到很多更復雜的過程。下面，我為大家介紹幾個我們項目過程中遇到的問題以及解決方案。
Appium自動化常見問題分析
由於我們的框架對Appium的API進行了二次封裝，通過在Web端錄入“偽代碼”的方式提供給用戶。很多問題，我們解決起來的成本更加高，這里主要分析幾個典型的案例。
結果校驗的問題
我們知道，測試步驟執行完成之后，要判斷是否達到預期結果。在實際的測試過程中，我們判斷是否執行通過，一般判斷是否跳轉到預期頁面，頁面上是否有預期元素或者文案。那自動化過程中其實也是類似的處理方式。我們在測試步驟的最后，加上一個或者多個判斷某個頁面元素是否存在的步驟即可。如果通過，則表示測試用例執行成功。比如判斷登錄成功，我們通過檢查當前頁面是否出現登錄的賬號名稱來校驗。
具體實現方式，我們可以調用Appium查找元素的API，將查找方式和元素標識作為參數，如果查詢成功，則說明校驗成功，否則校驗失敗。
腳本復用的問題
在測試過程中，很多測試步驟都是通用的，比如登錄。因此，我們要引入腳本復用的概念。在我們的自動化實施過程中，我們有三種方式來實現腳本復用：前置腳本，腳本復制，腳本引用。下面分別介紹這三種方式的實現過程。
- 前置腳本
前置腳本一般是用在一些用於初始化或者實現前提條件的地方，比如App啟動初始化。我們通過指定某個腳本為前置腳本，然后在錄入其他腳本的時候，將前置腳本的ID作為錄入前置。在執行腳本的時候，我們先執行前置腳本，再執行自身腳本。從而達到復用的效果。
- 腳本復制
腳本復制是為了提高寫腳本的效率。我們在寫代碼或者寫文章的過程中，如果發現一些相似的內容，我們喜歡復制過來，然后修改一下。同樣，我們寫測試腳本的過程中，很多測試步驟都非常類似，我們也需要將以前的測試腳本復制過來，修改后變成一條新的測試腳本，節約大量重復工作。
具體實現過程，我們只是針對我們自身框架的特點設計，通過前端js的方式，將要復制的測試腳本全部渲染到web頁面。如果是通過代碼方式實現的自動化過程，其實是不存在該問題的。
- 腳本引用
類似前置腳本，有些腳本，我們不一定是作為前置腳本去引用，我們可能在腳本中間引用，在腳本結尾引用。那就需要一個腳本引入的過程。我們通過在測試步驟中增加一個動作類型，該動作類型的參數是待引用腳本的ID。在執行測試的過程中，遇到該類型，我們就先執行引用腳本的步驟，然后再繼續執行下面的步驟。該方式支持嵌套。
分支邏輯的問題
前面提到的腳本復用問題，是為了解決腳本之間的相互關聯。那么腳本內部的各個步驟之間關聯怎么解決呢，比如分支邏輯的問題。該問題就類似於代碼中的if語句，由於我們框架並不是純粹的代碼，所以我們要模擬代碼的方式解決該問題。我們通過引入ExistGoto和NotExistGoto兩個動作類型，參數表示要跳轉到的步驟來實現判斷邏輯。這兩個動作類型分別根據檢查指定的頁面元素，如果存在則跳轉到某個步驟以及如果不存在則跳轉到某個步驟。
實現方式我們需要在測試步驟的執行過程中，判斷如果是該動作類型，而且條件滿足的話，直接跳轉到指定的步驟開始執行。
手勢密碼怎么輸入
由於Appium自動化一般都是針對單個步驟進行處理，而手勢密碼的輸入是一個連續的過程，我們在處理手勢密碼的時候，需要對測試步驟特殊處理。但最重要的是，要獲取手勢密碼的路徑。手勢輸入頁面一般有九個點。這九個點其實對應了九個控件，而手勢的軌跡其實是針對這九個點的坐標繪制出來的連線。比如對於下圖這樣一個Z字形的密碼，我們要經過的點是1235789這七個點。我們分別獲取到這七個點的坐標，然后調用Appium的TouchAction進行繪制。
核心代碼如下：
1 public void gestureInputAction(List<Point> gesturePoints){ 2 Point prePoint = gesturePoints.get(0); 3 //Point p1 = ae.getLocation(); 4 TouchAction touchAction = new TouchAction(ad); 5 TouchAction cur = touchAction.press(prePoint.getX(),prePoint.getY()).waitAction(2000); 6 for(int i = 1;i<gesturePoints.size();i++){ 7 Point nextPoint = gesturePoints.get(i); 8 cur = cur.moveTo(nextPoint.getX()-prePoint.getX(),nextPoint.getY()-prePoint.getY()).waitAction(2000); 9 prePoint = nextPoint; 10 } 11 cur.release().waitAction(2000).perform(); 12 }
而對應到我們的框架里面，還是要做下特殊處理。我們在動作類型中加入一個actionGesture動作類型，控件標志是每個點的xpath，參數則表示一共有多少個點。我們從第一個點開始調用TouchAction的press方法，一直到最后一個點釋放，從而實現連續的手勢滑動。
動態驗證碼如何輸入
現在很多App為了安全，尤其是金融類的App，在核心業務場景都需要短信驗證碼的校驗。這對於Appium來說其實是一個無法解決的瓶頸。不幸的是，我們的產品有很多的短信驗證環節，解決這個問題勢在必行。但幸運的是，在我們的測試環境下面，我們的短信驗證碼開放了查詢接口。因此，我們只需要在輸入短信驗證碼的時候，調用查詢接口獲取驗證碼，然后再通過Appium輸入到文本框中即可。當然，如果沒有開放接口，通過自動識別短信的方式也能解決，但相對復雜很多。
如上圖所示，我們也是在測試步驟中加入一個GetVerifyCode的動作類型，在執行步驟執行，先調用接口獲取驗證碼，然后再將返回的驗證碼作為參數輸入。
安全鍵盤的問題
我們在實施自動化的過程，遇到另外一個比較變態的問題，有些App的密碼輸入框是用的安全鍵盤，類似下圖這種。Appium自身的API根本無法輸入密碼。安全鍵盤的實現方式一般分為兩種：native控件繪制和webview動態加載。對於Webview動態加載的安全鍵盤，我們可以通過調用Appium的JavascriptExecutor類來實現。該類的executeScript方法可以執行一段js腳本。我們可以通過js腳本來模擬出密碼的點擊事件。但對於native的控件，我們暫時還在調研階段。基本的思路是通過圖像識別的方式獲取到鍵盤上每個字母的位置，然后發送點擊事件。具體過程還沒有實現，各路大神如果有更好的解決方案，請不吝賜教。
總結
如果你的團隊也用的Appium作為自動化測試框架，碰巧也遇到了我們類似的問題，不妨用我們上面介紹的方法試一試。雖然不一定是最好的解決方案，但我們已經通過實踐證明，它確實解決了我們的問題。另外，最后一個我們正在嘗試解決的梗，歡迎各路大神多多給出建議，參與交流和討論。