Android App自動化測試實戰（基於Python）（一）

1.Hybrid App自動化測試概要

什麼是Hybrid App?

Hybrid App（混合模式移動應用）是指介於web-app、native-app這二者之間的app，兼具「Native App良好用戶交互體驗的優點」和「Web App跨平臺開發的優點」。

它雖然看上去是一個Native App，但只有一個UI WebView，裏面訪問的是一個Web App，好比街旁網最開始的應用就是包了個客戶端的殼，其實裏面是HTML5的網頁，後來才推出真正的原生應用。再完全一點的，如掌上百度和淘寶客戶端Android版，走的也是Hybrid App的路線，不過掌上百度裏面封裝的不是WebView，而是本身的瀏覽內核，因此體驗上更像客戶端，更高效。

Hybrid App同時使用網頁語言與程序語言開發，整體特性更接近Native App可是和Web App區別較大。只是由於同時使用了網頁語言編程，因此開發成本和難度比Native App要小不少。所以說，Hybrid App兼具了Native App的全部優點，也兼具了Web App使用HTML5跨平臺開發低成本的優點。

使用python驅動Appium測試Hybrid APP的流程以下圖，和Native App相同的是，Hybrid APP原生的自動化框架Selendroid也是基於Java語言開發的；

2.Appium基於Selendroid的原理、元素識別工具、腳本設計原則--SLOVE原則

2.1，Appium原理

 

2.2，Selendroid架構

2.3，元素識別工具

Web App頁面部分使用Chrome Inspector；Java實現的框架部分仍然可使用UIAutomatorviewer來定位；

2.4，腳本設計原則

2.5，如下圖爲例進行後面的介紹

3.基於Appium的Hybrid App自動化環境差別

3.1，Appium的配置如圖1；

爲何要添加測試app的路徑呢？

由於Selendroid是須要把測試app重簽名的，既然要進行重簽名，那就須要有一個app包在；appium會根據這個路徑來把app進行重簽名

4.Hybrid App自動化腳本的實現

4.1，腳本的初始化部分

如圖2，初始化部分，Hybrid App比Native App多了一個「automationName」=「Selendroid」；Native App初始化時使用的是默認的automationName，即appium，能夠省略不寫；

4.2，腳本的編寫部分

如圖3，包含了2種定位方式，一種是經過UIAutomaterviewer，一種要藉助於Chrome瀏覽器的Inspector工具；

如圖4，測試app啓動後先進入一個搜索界面；

 

如圖5，測試app頂端的搜索框和clear、search兩個button都是Native框架部分，仍然能夠用UIAutomaterviewer來定位；

如圖6，整個搜狗搜索的主頁是一個元素，名字是webkit.WebView，也就是所整個主頁是一個WebView，此時就不能經過UIAutomatorviewer來定位了；

如圖七、八、9，展現了經過Chrome瀏覽器的Inspector工具來獲取元素Xpath的步驟；

如圖10，能夠經過返回結果的第一條做爲判斷腳本是否跑成功的依據；

如圖11，print self.driver.contexts的輸出結果是[u'NATIVE_APP'，u'WEBVIEW_0']，說明當前頁面既有NATIVE實現部分，也有WEBVIEW實現部分；

5.Appium其餘相關API的介紹與實踐

上面的腳本實現過程用到了以下的API：

 

下面經過腳本介紹find_elements_by_xpath()的用法，如圖12：

如圖1三、14，webview頁面中，推搜部分的xpath是表格形式的，能夠經過「tr/td」來定位全部的推搜元素；

如圖15，能夠在控制檯中看到輸出了推搜的文案，說明腳本執行成功了。