本文來自作者我是壞蛋 在 GitChat 上分享「論 APP UI 自動化測試的可行性」，「閱讀原文」檢視交流實錄

「文末高能」

編輯 | 家輝

背 景

在這個科技時代，app 數量也是逐年遞增，只要能想到，大多數都可以在相應的平臺找到相關的 app!

那一款 app 在市場上出現之前，會經過哪些「加工鍛造」的過程呢？又經過哪些流程，來確保從市場上下載下來的 app 能正常使用呢？

在這裡我，以測試的視角來說我對 app 一些粗淺認知,在這過程一些意見，純屬個人臆斷，如有不對歡迎指正！

不管是何種事物的產生，都是基於需求，有需求才能存在發展的內在驅動力，因此 app 的產生的第一階段是需求；

有了需求就要基於該需求，調查市場上的使用者的群體，分析獲取使用者的功能性需求，設計 app 的功能性需求，因此這一階段為產品設計；

根據產品的文件，開始 app 的製作加工階段，這個階段不展開解說，包括內容太多，例如開發框架的選擇、UI 設計、編碼等等，這個階段為 app 設計與實現階段；

根據 app 設計與實現完成，要確保能正常使用，需要進行相應的測試，該階段稱為 app 測試階段；

測試完成之後，app 上線，至此一個 app 的產生就完成了，至於市場運營，那是以後的事情了！

因此，app 的加工鍛造的過程，大致為：獲取市場需求、提取需求設計產品文件、根據需求設計並實現 app、app 測試、app 上線！

本篇文章，是針對 app 測試階段中的 UI 自動化測試的可實施性進行分析作為背景，從需求、技術、維護三個階段來分析 UI 自動化測試在 app 的可行性！

需求變更頻繁

不管是測試還是開發，所有的出發點都是基於需求，那麼目前市場上一些app，為了保持使用者的新鮮感，不斷的更新版本，來確保使用者獲得更好的體驗！

在 App 每個版本更新過程中，一些功能入口會發生變化、頁面的一些元素會發生變化、之前有的一些功能會被替換掉、增加新的功能等！

這點對於自動化測試是致命的威脅，目前自動化測試都是通過編碼實現的，來實現模擬使用者點選行為。

一旦 app 進行版本更新，就要對自動化指令碼進行維護，維護成本比較高，由於需求變更頻繁，造成開發完成，後期沒人維護，被廢棄。

不過這可不是來說通我們的 boss，放棄 App UI 自動化測試想法的重要砝碼！

他們會給你新的想法，不過這些想法，有時候會讓我頭疼，但是他們說的確實在理，無法反駁，那就按著他們的想法去試試，萬一成功了呢？

這不是發現了測試中的一個新大陸嗎，對自己的能力增長那是很大的不是嗎？

就以我遇到的一些問題為例，每個 App 產生的時候，都有自己的一些核心業務，後期的版本更新都是基於這些核心業務來擴充套件設計新的功能。

這些核心業務基本很少甚至不發生變化，那麼能不能對於 app 中成熟的業務來設計 UI 自動化測試用例呢？

那麼對於這個想法，我做了如下嘗試，把遇到坑歸納如下：

· 核心業務是否有單獨穩定的UI入口？

核心業務是否有單獨穩定的 UI 入口，這是重中之重，這能保證測試的正常進行，自動化測試的初期，都是對業務流進行梳理分析，選擇一些成熟穩定的業務流！

這麼做的好處主要有：需求變更對業務流影響較少、有效的資料比較多、業務之間的邊界清晰！

如果核心業務沒有單獨穩定的入口，那麼 UI 的自動化還沒開始就會遭遇滑鐵盧，因為入口變更頻繁的話的，那麼業務流就無法成功走下去，後續的測試用例也無法成功執行！

其實測試做到後期，都有個認識，UI自動化測試都是基於業務流的測試，業務流發生變化，直接影響的是一個測試集的，因此針對 APP 的 UI 自動化測試而言，業務流的選擇是基石！

· 一些開發的編碼格式是否規範？

開發人員的編碼規範與否，對於自動化測試的也是有一定影響的，規範的編碼，對於後期的技術實現影響是相當大的。

所以早期，最好能與開發協商，你測試過程中需要的一些元素屬性一定不能為空，方便後期元素定位，因此開發人員編碼規範也是相當重要的！

· App 開發框架更新？

APP開發框架一般對於業務流影響不大，可能會影響部分測試集中的測試用例，導致測試用例無法正確執行，這個影響程度要看測試用例的數量，因此這個對UI自動化影響大小看情況而定！

因此，根據上述可以看出，APP UI自動化測試可行性在一些場合下是可行，在一些場合下是不可行的！

可行場景：產品變動小、頁面UI改動小，這些是可以做的；其他一些可以通過介面測試，來實現業務的自動化！ 

APP UI自動化技術

目前市場上主流的 APP UI 自動化工具包括 Appium、UiAutomator、UIAutomation、XCUITesting 等等。

這些自動工具都是通過頁面元素一些屬性來定位頁面元素，來實現使用者一些日常操作行為的模擬操作，元素點選、拖動、截圖等！

那下面以 Appium 這個目前最火一款工具，來分析它有哪些弊端。

環境部署

針對 Appium 環境部署，這裡不講如何安裝配置，如果想學習 Appium+Python 在 Windows 下面的安裝，這裡給我之前的一篇部落格連結：(http://blog.csdn.net/henni_719/article/details/51682081)

這個安裝方法，我試過，是可以成功安裝，如果在安裝過程遇到一些問題，可以在該部落格下留言，我會及時回覆的！

本人在剛開始，配置部署這個開發環境時，就踩了好多坑，環境配置是我目前最麻煩的之一，比 Spark 叢集稍微簡單點，但是它的需求太多，好多想要使用該工具的人，估計 90% 的人被環境配置難住！

環境配置結束之後，那就是需要跑一個測試，來了解下簡單的操作流程。本文不做贅述，連結：appium 簡單例項( http://blog.csdn.net/henni_719/article/details/51722043 )

示例程式碼：

元素定位

接觸過 selenium 的，對於元素定位，以 Python 語言為例給出方法名稱：

• find_element_by_id( )：根據元素的 id 屬性進行定位；  

• find_element_by_name( )：根據元素的 name 屬性進行定位；

• find_element_by_class_name( )：根據元素的 class 屬性值進行定位；

• find_element_by_tag_name( )：根據元素的 tag 名進行定位；

• find_element_by_link_text( )：根據連結文字進行定位；

• find_element_by_partial_link_text( )：根據連結文字中包含的部分文字資訊進行定位

• find_element_by_xpath( )：根據 xpath 進行定位；

• find_element_by_css_selector( )：根據 css 進行定位；

關於定位元素組的，只需要把 find_element 改成 find_elements 就可以。

上述是 selenium 的定位方法，目前 IOS 使用 XCUITesting 後，元素定位方法與 selenium 元素定位方法一致。

這是 Appium+XCUITest 的 Python 連結：

Appium+XCUITest 基於 Python 的操作例項以及環境搭建(http://blog.csdn.net/henni_719/article/details/62037676)

那麼 appium 如何在安卓裝置上進行定位呢？

在安卓裝置上使用的是 uiautomator，以 Python 為例，使用方法如下：find_element_by_android_uiautomator ( )，該方法與 Uiautomator 的 UiSelector( ) 聯合使用來定位元素。

下面給出一段程式碼示例截圖：

可以檢視我的部落格連結：python 封裝安卓查詢元素方法V1.0(http://blog.csdn.net/henni_719/article/details/65630889)    

效能

appium 對裝置的要求比較高，如果裝置配置的比價低的，執行指令碼時會相當卡頓，不能及時響應操作，總體來說效能不怎麼好！

使用難度

從環境的配置，到編碼的使用，都要求較高，需要有一定的編碼基礎，不然很難入門使用，所需要花費的成本較高！

不過可以與 robot framework 結合使用，使用者不需要關心後臺程式碼邏輯！關於如何與 robot framework 可以從網上查詢，比較多的！

針對上述可以發現，app UI自動化測試上技術是可行的，不過對於測試人員的技術要求比較高，學習成本比較大！需要專業的人員指導，才能順利實施！

關於在 windows 下對安卓進行的自動化測試，我做了做了一個研究，把 adb+python 結合起來，把 adb 的命令和 Python 結合起來，來實現元素點選操作，具體程式碼連結：通過 adb 與 python 結合建立的裝置驅動指令碼 deviceDriver.py

部分程式碼截圖：

改指令碼實施原理是，通過 adb 命令把裝置當前頁面的資訊 dump 下來儲存為 xml 檔案，通過 xml 的樹定位元素在頁面所在的位置，具體可以看上述程式碼連結。

具體實施是可行的，只要是頁面中有都可以定位點選，準確度和效能都不錯！

缺點是需要 adb 支援，不支援ios。我把該指令碼封裝好，與robot framework結合起來，連結：與 robot framework 結合起來( http://blog.csdn.net/henni_719/article/details/73087463 )

自化測試指令碼維護

在需求穩定，頁面穩定的時候，自動化測試指令碼維護成本比較低；在需求變化比較頻繁、頁面變化比較大，維護成本比較高！

自動化測試指令碼，也需要定期的進行迭代管理，需要制定合理規範化的管理流程！

要有規範化的測試用例編寫規範、測試集模組功能介紹、各測試集管理人員、操作手冊等相關文件，避免人員在流失導致自動化測試指令碼廢棄！

指令碼維護，是儲存自動化測試持續的必要條件，人員流失、文件少，是自動化測試指令碼廢棄的主要問題！

總結

其實，在研究 app UI 自動化測試可行性分析，發現最大的問題是：入口和UI經常變化、時間緊，導致維護成本高！

其實，app UI 自動化指令碼開發都是提高工作質量，但是由於 app 更新頻次快，時間緊，手動測試比較自由及時，使用指令碼還要去除錯校驗、編寫程式碼，比較耗時！

總而言之，APP UI 自動化因公司而定，如果有規範化的管理流程，自動化測試在迴歸測試方面還是很高效的！

福利

「閱讀原文」看交流實錄，你想知道的都在這裡