AWS Device Farm介紹及Appium踩過的坑

       本文記錄了在AWS Device Farm上進行Appium TestNG進行手機應用UI自動化測試的流程及遇到的問題，及具體的解決方法。同時記錄了使得測試腳本更穩定的一些代碼寫法。

       Device Farm是Amazon Web Service推出的云應用測試工具，允許你在數量眾多的物理移動設備上測試你的應用。DF提供了兩項功能。其中Remote Access允許你通過網頁遠程操控云端的設備，并可上傳安裝自己的應用。另外Automated Tests還允許你上傳自己的自動化測試腳本，在云端的設備上執行自動化測試。

       DF支持多種UI測試框架如：Appium Java JUnit, Appium Java TestNG, Appium Python, Calabash等。經過與JUnit的對比，最終我選擇了Appium Java TestNG。

       類似的平臺有Xamarin Test Cloud以及國內騰訊的WeTest上的云真機。

Device Farm使用步驟：

1、本地設備上測試通過你的測試腳本

2、將腳本按照官方教程使用Maven方法打包成zip文檔

3、上傳zip以及ipa/apk，選定設備池，執行測試

4、等待執行完成，分析執行結果，修正直到全部通過

備注：

       唯一的麻煩是使用官方特定的Maven打包方式，可以直接github下官網的Demo，復制到自己的項目。

踩過的坑：

autoAcceptAlerts和autoDismissAlerts在XCUITest中被棄用了，對話框需要代碼中處理。

android：

Valid locator strategies for this request: xpath, id, class name, accessibility id, -android uiautomator

ios：

Valid locator strategies for this request: xpath, id, name, class name, -ios predicate string, -ios class chain, accessibility id

IOS必須指定bundleId、UDID、deviceName

Android雖說deviceName沒有意義，但不指定編譯不通過

IOSDriver中沒有AndroidDriver的許多方法，例如：pressKeyCode();

對于不能獲取焦點的EditText，IOS中也能使用sendKey()來輸入文本，而Android只能使用driver.pressKeyCode()，向設備發送鍵值的方式。

對于一個列表而言：

IOS會把看不見的未顯示到當前屏幕的元素也找出來，這個時候需要使用isDisplay來判斷是否可見。

因為不可見意味著不可點擊。而Android初步測試不會把看不見的列表元素找出來。

driver.swipe(start_x, start_y, end_x, end_y, duration);

這里的end_x, end_y實踐證明就是目的坐標，論壇上許多人說是偏移量，版本不對嗎？

有的時候findElement找不到的時候，使用findElements獲得數組，并使用對應的下標，常常可以找到。

特別是對付對話框里的元素

appium沒有提供直接判斷是否找到元素的方法，可以用findElement方法是否拋出NoSuchElementException來判斷，或者判斷findElements返回數組的size是否為零。

對于滾動查找列表項的操作，會發生目標項只有部分顯示就被找到的情況。這個時候如果你需要偏移坐標查找如CheckBox之類的元素，有可能發生偏移后的坐標超出屏幕的情況。

此時相應方向的坐標需要防止越界。可以在找到后再滑動一次屏幕，以保證目標完全顯示。click操作也是如此，因為click默認是tap元素的中心坐標，而元素的中心坐標可能尚未顯示。

Appium支持中文：

在Capabilities 中添加

capabilities.setCapabilities("unicodeKeyboard",true);

capabilities.setCapabilities("resetKeyboard",true);//必須

在設置上面兩個屬性后，如果腳本中途崩潰，容易出現系統輸入法被替換為Appium輸入法的問題，該輸入法是沒有界面的。

錯誤：xcodebuild failed with code 65

解決：將WebDriverAgentRunner安裝到iphone上。方法如下

1、使用Appium Inspector建立Session成功，會自動安裝

2、運行測試代碼建立Session成功，會自動安裝

3、使用Xcode或xcodebuilder將WebDriverAgent直接安裝到設備上

4、以上都不行，則到WebDriverAgent的github官網下載最新的替代現有的

UI自動化測試具有不穩定性，任何微小的延遲或界面不同于預期，腳本就會失敗。要寫出在多種機型上正確運行的腳本，需要不少時間，如果你要結合云測試平臺進行云端設備的自動化測試，不穩定性會更高。所以設定合理的等待時間，在可能出現彈框的地方進行判斷。

AWS Device Farm注意：

AWS官網的文檔很可能不是最新的，比如：官網最新支持appium1.6.3， Github上最新支持appium1.6.5。官網說明項目需要修改POM.xml文件，Github上直接給出詳細步驟，對于詳細技術文檔，Github才是王道，官網更新常常不及時。

Device Farm會把所有的JUnit Test Case轉換成TestNG Test Case。但官方說不會有影響。

實際上對于注解的支持就不一樣了，例如JUnit中的@BeforeClasss在被轉換成TestNG后是否會相當于TestNG的@BeforeClass，并且JUnit要求@BeforeClass方法必須是Public static修飾，而TestNG并無這樣的限制。所以還是改用TestNG吧，免得疑神疑鬼，況且需要改的也只是注解和稍微調整邏輯而已。

Device Farm(Appium1.6.5)已經可以重寫DesiredCapabilities覆蓋服務器。例如添加：NoReset = true。官方例子中明確寫出DesiredCapabilities必須為空，信息不同步，那指的是1.4.3版本的appium。

（不能重寫的信息來自Github官方例子，可以重寫的信息來自stackoverflow的官方工程師答疑）

Device Farm上IOS使用driver.manage().window().getSize().getWidth();在執行getSize()的經常時候返回null，Android沒有這個問題，有時候需要用固定數值。

同樣在執行element.getLocation()時也是經常直接崩潰。后來又莫名奇妙好了，這么不穩定，測試個球。

AWS默認每個用例執行后都會resetApp。也就是清空所有狀態。

所以如果你的app需要登錄，則每個用例執行前都需要重新登錄一遍，

方法一：可以把Login的邏輯放在JUnit的@Before或TestNG的@BeforeMethod方法里。

方法二：設置Desired Capabilities的NoReset設為true，讓其不要在會話前重置應用狀態

理論上本地使用Appium相同版本測試通過的代碼，放到DeviceFarm上是不應該有問題的，現實卻不是這樣。Device Farm上提供了多種記錄：Vedio、Appium Java Output、Appium Server Output、Logcat等。答案只能在這里找了。

遠程調試遠比本地調試麻煩的多，網絡的限制，實時性的限制等。遠程調試一次花費的時間遠比本地調試來的長。并且只能通過返回的日志信息查找問題。

千奇百怪的手機，就有千奇百怪的彈框，還有兩個平臺的適配，耐心方得始終。

Device Farm需要借助Maven將項目打包成指定格式的zip格式，如果官網看不明白，直接上github下載官方Demo，參照它的代碼結構寫即可。主要是一個pom.xml和zip.xml。官方Demo使用Page Object的結構組織代碼，可以了解一下：https://github.com/SeleniumHQ/selenium/wiki/PageObjects

Device Farm允許一次測試選擇多部設備，并且是并行執行測試，如果你的腳本包含了測試登錄功能，那么很可能出現一個賬號在多臺設備間相互踢出再登錄的情況。這時候只能一次選一臺設備單獨執行，除非能在登錄時判斷不同設備登錄不同賬號。

惱人的系統對話框

做機型適配時，最麻煩的就是系統對話框了，不同系統版本，不同廠商的權限對話框出現時機可能不同，可能多個權限對應一個對話框，也可能多個權限對應多個對話框。還有偶爾出現的其他app的對話框，這個沒轍。例如google service被登出，iTune賬號在其他平臺登錄被提出，IOS推送服務Push Notification失敗，千奇百怪，寫代碼有什么難的，適配才難。

保證對話框位置固定后再查找元素：

對話框查找元素時使用的id，最好是包含包名的如com.hello.name:id/button1。使用button1容易找不著。

彈出對話框時，需要注意findElement操作執行之前對話框是否顯示到位（動畫效果完成），動畫執行過程中findElement獲取Element的坐標不是最終的坐標。所以會出現，findElement可以找到，click等交互操作沒反應的情況。同樣需要注意在對話框顯示之前等待一定時長保證軟鍵盤完全消失。

如果發現查找對話框元素時，同時查找到了對話框下onStop狀態的元素，則可能是使用findElements找數組元素時，在該元素還是onResume狀態時就找到了，而當你對其進行操作時，該元素已經onStop不可交互了。這時候可以等待一下對話框完整展示再查找。

調試系統權限對話框

系統對話框如權限對話框只有在第一次啟動App時才會顯示，允許過后就不再顯示了。這造成適配對話框的代碼不好測試。每次測試都需要進系統權限界面把授予的權限取消或者IOS需要重新安裝ipa。可以在@AfterTest中執行driver.resetApp()將App的狀態重置。這樣每次測試的app都和重新安裝一樣。