首先，我們看一下對于單個平台，是如何做控件的查找與操作的：
當平台擴充為多個時，一般來講，如何進行同一個控件的操作呢？比如對應同一個按鈕，在ios平台，我們可以知道他的name屬性，但是在安卓平台，對應的同一個控件，沒有name屬性，需要通過id屬性來擷取，那代碼就會演變成如下樣式：
衆所周知，對于ui自動化，控件的查找是使用相當頻繁的一種操作，那麼問題來了，有沒有一種方式，可以統一控件的查找而不必通過一個接一個的if else分支來完成呢？
測試的穩定性，是影響自動化測試的另一大因素，因為移動端操作場景的複雜性，測試用例執行的過程中可能出現多種意料之外的響應，比如點選某一個按鈕，預期結果是進入下一個頁面，但是卻彈出了某個彈框，或者真正跳轉的頁面并不是我們所預期的頁面，或者跳轉了我們所預期的頁面，但因為網絡資料的加載主視圖并沒有重新整理，這樣一來，針對我們的目标頁面所做的操作都會失敗，因為我們無法找到預期頁面的目标控件，在這種情況下，我們需要在保證預期頁面已經加載的情況下再執行預期流程的用例，如何做到這一點呢？
再者，長距離到達元件入口的問題也是影響自動化穩定性的另一因素，比如我們想要測試某個基金詳情頁，但是要進入某個詳情頁，必須經過登入-首頁-a頁面-b頁面-目标頁面幾個必須步驟，在到達目标頁面之前的任何一個鍊條中出現中斷，這次測試就等于無效了，這種問題怎麼破？
當然，影響自動化測試穩定性的場景還有很多，這些在真正的業務實踐中會逐漸暴露出來，如何保證自動化測試的穩定性，是自動化測試的又一個難題。
對應每一項測試流程，執行完畢之後我們都希望能看到詳盡的測試報告，如何快速高效的輸出可讀性強的測試報告，同樣是一個必須解決的問題。
自動化平台或者工具如果對環境配置、使用規範，腳本等有較複雜要求的話，那麼對于入門剛剛的測試工程師來說有一定的學習成本。另外，跟随目标産品的版本疊代，自動化腳本要做對應的調整，如果對應的調整成本比較高，也很難保證将自動化的工作方式堅持下去。
研究上面的第一個問題，我們會發現控件的擷取雖然根據平台不同而需要單獨處理，但是控件的擷取方式其實都是統一的，擷取控件有兩大要素，一是擷取控件的方式，比如name,id,xpath,css,class name等等，二是要擷取控件的值，這個值是與擷取控件的方式想對應的，針對移動端測試來說，目前一般覆寫ios,android兩個平台，我們以這個為例，其實對于ui操作上的一個控件，提供兩個平台分别的擷取方式以及值就可以解決控件一緻性的問題，代碼如下：
如上圖這樣，我們就統一了控件的一次性擷取問題，通過這一層封裝，如果要表示跨兩個平台的一個控件，就可以簡化為如下這樣：
1、對于要測試的頁面抽象成類，增加頁面是否加載成功的邏輯，所有頁面内部的測試邏輯，均在确認該頁面加載成功後再執行進而保證自動化穩定性。
2.對于長距離到達元件入口的問題，通過scheme跳轉解決。具體來講，對于目标頁面，隻要支援scheme跳轉，我們可以直接通過scheme的方式從首頁直接進行加載，這樣可以一步到達目标頁面，省略掉了前面的諸多鍊路，進而保證了測試的穩定性。當然，這種方式需要依賴開發同學的支援，隻有在開發層面上盡可能多的支援獨立頁面的scheme跳轉方式，才能真正使這個解決方案大放光彩。
當然，除了這些之外，對于其他分支的阻塞場景，一方面需要我們對業務複雜度的深入了解，一方面需要在今後的實踐中不斷積累。
對于這個問題，我們是分這麼幾步走的：
1.按照業務需求将錯誤類型進行分類整理
2.規範化結果輸出的規則
3.在對應節點按照既定規則輸出日志并寫入檔案
這樣，用例執行結束後，我們就可以看到具體的執行過程以及結果了，規範化日志輸出的規則還有一個好處是便于今後結果的內建展示，比如我們要通過web直覺的看到執行進度以及結果的時候，就可以通過解析日志得到相應資料。
關于學習成本，就要回到我們的标題，我們這裡講的是macaca-java版最佳實踐，其實在最早的調研階段，我們都是通過javascript寫用例的，但是考慮到大部分同學的學習成本，是以在macaca支援java後，我們立即轉型到java版本上來，這樣大大減小了學習成本，另外，我們在設計自己的架構的時候，設定了config配置檔案來配置通用資訊，比如應用資訊、使用者資訊等都可以通過配置檔案配置，對于用例編寫中常用的類進行了封裝，形成了一套用例編寫規範，這些對于新上手的同學都降低了接入成本，甚至對于不熟悉java的同學，都可以比較easy的比葫蘆畫瓢的編寫自己的用例。
關于維護成本，我們對于控件的封裝使控件更新的成本變低，對于page的封裝，使得同一個頁面的測試入口都集中在一起，每個頁面各自維護自己的操作入口，這樣當我們需要測試一個流程時，隻需要把經過的頁面對應的操作組裝到一起就可以了，當我們需要更新某一個頁面的某個操作時，隻需要去頁面對應的類中去修改指定的操作，而不影響原有的流程化邏輯，具體請參考源碼。
廣告時間結束，正片從這裡開始。
如果下載下傳依賴過程中報錯，可能是由于mvn -s指令沒有生效導緻的，建議将根目錄下settings.xml中的依賴配置到本地maven目錄下的settings.xml中。
注意：執行ios用例時需要将xcode更新到最新的8.1，執行用例前請先啟動目标模拟器。
注意啟動server時不能加代理，因為server在本機啟動需要連接配接localhost,加代理會導緻無法建立連接配接。
如果你成功跑起來了用例，那麼下一步我們就來詳細研究一下demo的源碼部分了，如果你非常不幸的因為各種原因沒能run起來，請先保證macaca的環境已經正常安裝(macaca-doctor)，如果環境正常但還是啟動失敗，請毫不吝啬的聯系我。
下面給出一張各package的作用講解，在看過這部分之後相信大部分人已經基本清楚這個架構的基礎結構了，然後更深入的了解，還需要大家認真去研究一下源碼。
目前的架構已經解決了一些自動化測試用例編寫中的基本問題，但是在寫過一定量的case後，我們會發現case的組裝實際上是一種類似的邏輯：擷取控件(通過多種方式) -> 對控件進行某種操作(click)->與預期結果進行對比得到case執行結果，這有限的幾種，既然這些操作如此相似，那我們是不是可以通過一種資料驅動的方式更有效的進行case的管理，就像如下這張圖這樣：
最後我們期望達到的效果是建立一個管理系統，将所有的流程通過用例管理系統進行如上資訊的管理，最終實作零編碼的自動化用例設計，當然這其中還需要解決諸多問題，需要我們在積累編寫經驗的同時不斷完善。也歡迎志同道合的同學們加入到這個過程中一起努力！
想象一下我們的自動化測試工作已經正常投産，然後在運作過程中我們發現了一些bug,這時候開發就需要去解決這些bug，對于開發同學，我們現在能提供的是bug出現時的螢幕截圖，但是很多時候僅僅依賴一個截圖是不能幫助開發同學去定位真正的問題的，如果能擷取使用者當時的請求和後端的傳回資料，結合螢幕截圖，則能大大的友善開發同學定位并解決問題，這一步要如何實作，還需要我們進一步的思考。如果這一步完成了，那麼我們相當于将線上巡檢與ui自動化結合在了一起，無疑是一件很有意義的大跨越。
除了網絡資料，還有很多可以和ui自動化結合的點子，比如埋點，比如監控，因為ui操作是一切app行為的基礎，是以從ui自動化出發，我們有很多事情可以做，有沒有熱血沸騰了呢？