在執行腳本前，需確定被測終端是否可以與Appium server進行通訊，驗證被測app是否能被調起，Appium desktop提供的會話檢查器可以滿足此需求。Appium desktop會話管理器提供了一個編輯器可以生成desired_caps。SoloPi提供的converter轉換后該變量需要根據實際重新賦值，參數包含platformName，platformVersion，deviceName，appPackag，appActivity，automationName等，具體如下
1、deviceName可以通過命令adb devices獲取。
2、appPackag、appActivity獲取前，測試手機連接電腦，啟動被測APP，執行以下命令：
adb shell dumpsys activity |find "mFocusedActivity"（注：android 7.0以下）或adb shell dumpsys window w|findstr \/|findstr name=（注：android 7.0及以上）。執行后獲得appPackage 和 appActivity ，其中appPackage = com.android.bankabc，
appActivity=com.alipay.mobile.quinox.LauncherActivity。
需要注意的是，對于有啟動頁的app來說，appActivity需要設置啟動頁的值，也就是說在啟動頁打開后立即使用adb shell命令。目前Appium 1.51.1和安卓10使用uiautomator2有兼容性問題，automationName使用uiautomator1。啟動Appium desktop打開會話管理器，將上述值填入，編輯器自動生成JSON格式的字符串，該JSON串需要賦值給desired_caps變量，如下圖所示，會話管理器啟動后，如顯示Appium編輯窗口，即證明連接成功。
SoloPi Converter將導出的JSON文件轉換為Appium腳本，轉換后的代碼需要簡單修改即可執行，需要修改的內容如下。
SoloPi轉為的Appium腳本缺少關鍵參數，首先將上文中的JSON賦值給desired_caps，定義remote server，測試用的一部安卓10系統的手機存在兼容問題，這里指定automationName為uiautomator1。
此段代碼由轉換工具自動生成，獲得的SCREEN可供測試人員后續使用，如無需要可將該段代碼注釋以避免編譯失敗。通過使get_screenshot_as_file獲取設備屏幕截圖后得到其width, height值，存入SCREEN變量中。這里腳本的臨時存儲路徑默認為“/tmp/xxx.png”，修改為本地實際路徑即可。
① 在原代碼中使用tag_name定位元素，該函數是通過H5的tag標簽查找，測試過程中轉換時選擇的是classname，需要修改。此處生成的代碼首先獲取app當前節點類型的rect屬性（該屬性獲取元素的大小和維度，這里沒直接使用返回屏幕大小的相關函數，可能為了考慮app在窗口模式運行/或是有底部bar的情況），為后續屏幕滑動的相關參數提供基礎。
② 下圖中自定義函數swipe將Appium框架的滑屏函數swipe進行封裝，Appium框架函數swipe的參數包括startx、starty、endx、endy，duration，其中startx，starty，endx，endy需要輸入屏幕的像素坐標。SoloPi原始腳本中記錄的起始和終止位置的坐標偏移區間為[0,1]（該值表示位置相對屏幕中心點的偏移量，默認屏幕左上角為(0,0)、右下角為(1,1)）。
在原始代碼中，結束滑動的坐標值出現了負數，手動將其改為正確的值，這里最好手工debug獲得滿意的位置。
自定義swipe方法將參數傳送給了load_x_y加工成屏幕像素坐標，將2組偏移值用load_x_y處理，得到滑動的實際像素坐標值(fx,fy)和(tx,ty)。
注：在load_x_y中，rect.left和rect.top也是轉換工具自動生成的，從步驟①返回的字典中并無此項，要刪除。在索引width、height值時，也要改為字典的取值方式。此外，swipe中的driver參數也要刪除。
③修改具體執行步驟，從Appium 1.5開始已經移除對by_name的支持。
assert driver.find_element_by_android_uiautomator('text(\"尊敬的用戶，您好\")').text == "尊敬的用戶，您好"
執行過程可以通過寫日志的方式來記錄，但對于移動端判斷錯誤具體發生的情況來說，并不是最優。對每一步驟執行后進行截圖保存，更有利于測試人員定位問題原因。執行過程中，通過增加一個截圖函數放在每一步的后面。測試結束后，截圖即可自動生成在文件夾中。
使用jenkins之前，需要先在遠程機器上使用PyCharm執行，驗證客戶端與
服務器端的聯通性，然后啟動jenkins，通過建一個空項目，并為測試用例的目錄建立一個環境變量，便于后續修改。然后輸入編譯命令，保存該項目后編譯，結果執行成功。
需要注意的是，腳本中截圖路徑要改為jenkins服務器的路徑，而非Appium server服務器上的路徑，這取決于jenkins是否和Appium server部署在一起。
上述的操作中，只使用了1臺android設備，下面介紹多臺設備執行的方法。首先驗證和服務器的聯通性，修改desired_caps，使用2臺安卓設備，分別為安卓7.0和10.0，首先使用會話編輯器做聯通性驗證。
使用命令查看2臺設備已經連接到Appium server后，啟動2個Appium server，每個server與其中一臺手機通訊，如果4臺手機，需要啟動4個Appium server。啟動2個Appium時，要對第二個Appium設置獨立的端口。服務器正常啟動后，執行腳本中，用例主流程定義在run方法里，run方法包含3個參數，url和desired_caps是啟動會話必須的參數，picloc是指定截圖生成的位置。
通常編寫多線程或者多進程多做使用threading和multiprocess來實現，2種方法，如圖所示：
上述代碼執行后，實際是按CPU時間分片來執行的，如果代碼邏輯很短，或執行很快，就會立即得到結果，如果代碼執行效率很慢，最后的結果實際上是在串行操作。上述代碼中，MEIZU和honorV20在實際執行過程中，MEIZU會先執行一遍，然后honorV20才會執行，循環反復。
因此，這里使用concurrent.futures模塊下的ProcessPoolExecutor進程池，該方法可以利用多核cpu的優勢，讓腳本并行執行。Submit將實例提交到進程池中，如果CPU有空閑核心，就會調度進程執行。
主函數如下，這里需要注意的是，當多臺設備并行執行的時候，需要在 desired_caps中指定參數udid，通過adb devices獲取，newCommandTimeout指服務器新獲得命令的超時時間：
執行后，可以看到進程完成不是“串行”執行的，最后的執行結果，兩臺機器可以同步一起執行，并將截圖保存在各自的文價夾中。
本文主要從實踐操作的角度，以手機銀行界面測試為例，比較詳細地描述了基于SoloPi執行過程錄制轉為Appium腳本的過程，并對需要使用的工具和環境、參數等配置進行了說明。通過將Appium腳本集成式jenkins，實現了腳本的自動化部署及自動化執行和結果存儲，并描述了單機執行和多機執行的實踐過程。
手機銀行測試的方式方法需要在實踐中不斷探索，優秀的互聯網測試前沿技術和工具，對商業銀行的引領和借鑒意義正在不斷加強，希望本文的測試實踐能夠對移動端APP界面級測試提供有益借鑒，促進測試領域不斷開拓新思路，新境界。
加我VX：17324089390 回復關鍵詞“測試”領取限量軟件測試學習資料哦~~
