移動應用框架Appium應用問與答
1、提問:Appium的對Hybrid App的支援有限制麼?
答:就我的瞭解,Appium的對Hybrid App的支援有些限制,首先需要Android版本是4.4或以後的手機(關於此項可以參考appium.io文件中的說明),其次測試Hybrid App需要將WebView類的setWebContentsDebuggingEnabled設為True。另外在Android上我知道僅對Chrome的核心支援。
2、提問:怎麼測試 APP中 即有原生又有H5的頁面
答:我理解你問的是如何測試Hybrid App。如果是的話按普通的測試步驟執行到有WebView的畫面,然後呼叫Appium Client的按以下步驟(以python為例):
1. 呼叫driver.contexts獲取到當前可用的context,如果一切OK的話,你能看到兩個context,一個為Native,另外一個WebView的Context。
2. 呼叫driver.switch_to.context(context),將Web的Context傳入這個方法,切換到WebView的Context
3. 然後按測試Web頁面的步驟通過find_element_*的方法查詢頁面的element,開始H5的測試。查詢使用的方法也都是類似的。
4. 當網頁內的測試完畢後要切換為Native的測試時,要將Context切換回來。
3、提問:swipe滑動時有時會報錯,尤其是用模擬器時基本都報錯
答:建議把滑動的時間可以減慢一點,預設的時間比較短,可能會造成兩點之間的連線沒有連續起來。
4、提問:我們團隊也在用appuim進行安卓自動化測試,但是發現hybrid和reac-native的頁面有一些控制元件元素使用安卓sdk自帶的uiautomator無法識別出來,就無法編寫appuim case,請問你們有沒有遇到類似情況。
答:這樣的問題我們也有遇到,請參考問題一和問題二的答案先確定符合Hybrid App的測試條件,另外WebView裡面的內容需要用Chrome瀏覽器通過Debug方法連線到被測得WebView來檢視裡面的內容。最後再看是否是方法的問題。
5、提問:react.js開發的H5頁面怎麼用appium測試做UI測試
答:如果是純網頁App的話,那測試方法和Selenium測試網頁的方法一致,可以參考下這個視訊https://www.youtube.com/watch?v=b9fmf9Ka6Zw。如果是H5嵌入到Activity這樣的App的話就需要使用Hybrid App的測試方法,這可以參考前面的前面的答案。
6、提問:appium啟動應用程式時,會在手機上安裝appium setting,這個是什麼作用?
答:這個apk的作用主要是用來輔助Appium伺服器在執行時對手機的設定功能.比如需要設定網路為wifi,或者關閉網路等。
7、提問:appium怎麼實現跨應用測試,能大概說下什麼方法嗎?
答:這裡我不清楚你說的跨應用是不是指一個應用喚起另外一個應用的場景。比如很多程式登入喚起微信,再從微信返回這樣的場景。如果是的話,就是當微信被喚起後在當前畫面找微信的控制元件,按普通的流程往下進行就是了,因為Appium是基於當前畫面進行自動化的,不是基於某程式的Context進行自動化的。
8、提問:appium怎麼模擬滑動的手勢
答:不同語言實現的Appium Client引數可能不一樣,但大致相同。Python的是“driver.swipe(start_x=75, start_y=500, end_x=75, end_y=0, duration=800)”。 Java的是“driver.swipe(75, 500, 75, 0, 0.8)”,可以參考http://appium.io/slate/en/master/
9、提問:platformversiong為什麼必須4.3以上?
答:這裡糾正我自己的一個錯誤,不是必須4.3,而是建議。 因為4.2以下的版本是使用的Selendroid,4.2及以後的版本使用的是UiAutomator。
10、提問:之前 pip install robotframework-appiumlibrary正確的應該是pip Appium-Python-Client 吧?
答: pip install robotframework-appiumlibrary是用於安裝基於robotframework的appium客戶端,而Python客戶端是“pip install Appium-Python-Client”,請參考https://github.com/appium/python-client。
11、提問:如何對各個機型進行快速適配呢?如何識別控制元件的顏色?針對地圖這種特別依賴網路好壞的應用,除了增加延時外,是否還有其他方法來增加指令碼的穩定性?如何實現多機互動?例如藍芽、接打電話
答:問題1:個人感覺Appium已經是非常好的適配各種機型了,因為該工具是直接通過控制元件的資訊來查詢控制元件,與手機的解析度無關,在大螢幕上要顯示哪些UI元素,那麼在小螢幕手機也應該顯示。
問題2:appium是基於UiAutomator實現的,就我所知是沒有方法獲取控制元件的顏色,其實我們測試過程中也沒關注UI上的顏色,更多關注邏輯上是否OK的。
問題3:對於網路這種不確定因素,我們採用的方法是動態等待,我們封裝了一個WaitForElement方法,我們會傳入根據業務情況傳入一個較長的等待時間,在該方法中是每隔一秒去檢查一下控制元件是否顯示,如果顯示了就返回,如果沒顯示就繼續等待。我們所有的需要等待的場景都是使用這樣的方法,這樣避免死等,可以儘可能快返回。
問題4:關於多機互動的情況,我們的業務沒有接觸到這樣的場景。但也不是沒有辦法,建立搭建兩個Appium Server 了或者一臺Server多個裝置來完成,兩個裝置分別執行不同的程式,通過同一個測試指令碼來整體控制。另外我個人覺得,如果這個功能不是你們的最核心的功能的話,如此複雜的互動場景人工測試可能效率會更高點。
12、提問:公共的業務邏輯,是怎麼判斷、合理地抽取出來?
答:公共的業務邏輯需要大家對自己的義務和自動化目標非常熟悉,能知道需要實現哪些用例,這些用例中是否有可重複使用的過程,提取出來就是了。就如我舉例時說到的取消使用者引導頁過程。
13、提問:每個用例從程式啟動開始會不會增加用例執行時間
答: 這個時間肯定是有所增加的,但是如果指令碼執行過程因為狀態不對導致的錯誤比較多的話,後期調研的時間會比這一點時間多出N倍,因此需要測試人員自己去平衡。
14、提問:整合是怎麼做的?用的是Android模擬器嗎?
答: 我猜測這位朋友說的是 持續整合吧。地圖專案有一個自動編譯伺服器,會定期編譯最新的版本。Appium主要用於每個版本的冒煙測試中,用例只覆蓋了最主要功能的場景。每天晚上測試伺服器發起任務定時去拉取編譯伺服器上最新的版本到本地進行測試,完畢後將測試結果通過郵件反饋給專案成員,大家在第二天早上來時可以直接看結果。之所以在晚上執行是因為UI的自動化測試執行還是比較慢的,如果對測試執行的快速性要求很高的情況的話,建議選用介面級別的自動化方案,會快很多;或者就是用多臺機器同時執行不用的用例,這樣也可以縮短時間。
另外我們的所有自動化測試都是使用真機測試的,畢竟模擬器並不是使用者真實的使用環境,即使在模擬器上全通過了可能也不能確保在使用者真機環境中是OK的。
15、問題: 1. 在自動化測試時,線上怎麼保證線上資料不受自動化測試的影響?比如下單,線上不受汙染? 2. 測試資料是怎麼獨立的?
答: 如果你的測試包是直接上線的包的話,難免會有你說的情況。對於交易系統的話儘量還是直接用測試環境測試。或者在包中埋個彩蛋,讓程式做某個操作後或者在某個路徑放一個特殊內容的檔案後就連到測試環境,這樣應該可以解決一些問題。
測試資料與UI資料不太一樣,當然測試資料也可以像UI資料定義為常量,但測試資料脫離了指令碼邏輯的話是很難看出它的含義的;此外即使獨立出來後,你敢幾個指令碼共用一個數據嗎?如果這樣用了,可能出現改了一個數據可能導致多個指令碼失敗,所以測試資料我們是沒有獨立成檔案的。不過如果是同一個用例場景,不同的測試資料的話,那是屬於資料驅動的測試,這就另當別論。
PS:
1. Appium 官方站點:http://appium.io/