Android自動化測試解決方案

桌面應用程序與浏覽器端的自動化測試都已經歷了十年的發展，無論是從工具上還是項目管理方 法論上都已經趨於成熟。而移動設備端應用程序的自動化測試近兩年才剛起步，似乎一切尚處於探討與研究階段。但我們似乎已經看到其爆炸性的需求增長勢頭。可 以從這兩方面著眼分析：其一，移動應用從數量上和邏輯復雜程度上的增長，以及產品發布周期的緊縮，使得快速回歸測試迫在眉睫；其二，安卓系統的開放性造成 硬件廠商百家爭鳴的局面，設備款式之多，迫使移動應用的兼容性測試提上日程。縱觀當前智能手機兩 大主流陣營iPhone與Android，似乎安卓應用開發商與設備制造商更能體會兼容性測試的切膚之痛。鑒於此，並結合傳統桌面系統上的自動化測試經 驗，我們在此探討基於Android平台應用程序的關鍵字驅動自動化測試的可能性，並摸索一條適合在移動應用開發過程日新月異的現實情況中切實有效的實現 和實施自動化測試的路子。

理論基礎

在傳統的桌面應用軟件與浏覽器端應用的自動化測試領域，已經有相當成熟的工具可供用戶選擇，例如商業工具HP QTP，IBM Robot/RFT，Borland SilkTest等；開源工具如Selenium，Watir等。剖析這些工具，它們似乎都有著相同的功能結構：

● 對被測應用界面對象/界面元素的捕獲與識別，並對其進行管理與操作；

● 對於測試腳本的編輯功能與語法解析功能；

● 對於測試數據的組織與管理；

● 對於腳本執行結果的分析與輸出；

如果細說，還可以牽扯到如腳本錄制功能，插件管理功能，與測試管理工具、缺陷跟蹤工具的整合等內容，涵蓋面相當廣泛。但所有這些都是為了一個目的：模擬測試人員行為，達到功能性回歸測試的目的。本文嘗試從以下最關鍵的幾點來分析自動化測試工具的核心構成部分。

1、關鍵字驅動

關鍵字測試的主要思路是以面向對象的方式來管理被測應用的對象、對象的相關操作、測試數據以及這些測試數據之間的組合關系。關鍵字驅動是自動化測試中行之有效的方式，它可以幫助測試工程師更方便的維護測試腳本、構建復雜的業務邏輯測試用例、並節省手工測試的執行時間（尤其是在回歸測試階段）。關鍵字驅動主要由以下三種元素構成：

1）被測對象，即被測應用界面上的元素；

2）針對這些對象的操作，如點擊（按鈕）、填充（文字）、選擇（單選框/多選框）；

3）以及基於這些操作的數值；

上述三種元素可以描述為以下表格：

對象 操作 數值 文本框 輸入 文本值 按鈕 點擊 無 選擇框 選擇 選項值

或者以面向對象的文法表述為：

對象.操作（值）

該語句是關鍵字驅動腳本的構成基礎。

2、對象庫

對象庫是用於儲存被測應用程序界面對象（界面元素）的地方。它是關鍵字驅動測試工具的關鍵點。有了它，用戶可以更容易的維護被測對象、更快速的構建測試腳本。它是如何做到這些的呢？讓我們看看下面的結構：

實踐探討完上述關於不同測試工具的使用特點，更准確的說，是安卓應用自動化測試工具的特點，我們不妨來實踐（其實是模擬）一個移動應用的測試過程。這裡我們選用API Demo作為被測應用，選用DroidPilot作為測試工具。

分析被測應用

被測應用API Demo使用標准Android SDK作為開發控件，且被測應用未加擾碼，因此，界面上所有元素可以被DroidPilot識別。

對於一些非標准Android SDK控件開發的應用，這裡有兩種情況：一種情況控件完全由自己開發，如果是這種情況，DroidPilot完全無法識別對象；另一種情況是在標准控件基 礎上做了二次開發，這樣的話DroidPilot只能識別到原生SDK那一層。對於這兩種情況，都可以聯系DroidPilot開發團隊為非標准控件度身 定制專屬插件，用於識別被測控件。

對於擾碼問題，正如上述《前置條件》章節所描述的，DroidPilot本身是無能為力的，只能請開發團隊去掉擾碼，打包一個不加擾碼的測試包給測試團隊使用了。

設計測試用例

這裡我們假設一個測試用例是進入\App\Activity\Animation\Fade in\界面，對界面的元素（按鈕、文本框、多選框、單選框、下拉列表）進行操作，並驗證文本框的文字是否符合我的預期結果。測試步驟如下：

測試用例1 -驗證\App\Activity\Animation\Fade in\界面元素 前置條件：API Demo已經啟動，停留在起始頁 步驟 動作 期望結果 1 點擊App項 點擊Activity項 點擊Animation項 點擊Fade in項 在文本框輸入”put your text here” 勾選Checkbox1 向下滑動一次屏幕 點擊下拉框 勾選Venus 檢查文本框 文字=”textColorPrimary”

開發測試腳本

先使用DroidPilot腳本編輯工具抓取各個屏幕的對象，然後把這些對象選入腳本設計器，按照測試用例的順序來排列，如下圖：

如下圖，傳統模式，測試工程師可能在第一輪測試才有一次Full Test,在後續的回歸測試中，可能只能做到部分回歸。

如果引入自動化測試工程師，同步開發測試腳本（理想情況，每個應用自動化比率達到70%~80%,整體自動化比率達到60%~70%），有可能使得回歸測試比率有所提高。

從零做起

既然如此，何不從現在開始，從零開始，在項目中嘗試引入自動化測試，哪怕只是抽調部分人力著手部分應用的自動化測試，至少可以達到Daily Build Smoke Test的效果。再者，移動應用自動化測試行業正處於起步階段，此時介入也不失為一個好時機。

結論

回顧上述討論的內容，我們設想能在移動應用自動化測試領域延續桌面系統自動化測試的成功經驗，從理論基礎、工具支持、以及後續項目管理方面都做了一番探討。盡管主要還是局限於安卓應用的自動化方面，對於iOS提及較少。不難理解，iOS本身支持的機型有限，對於設備 兼容性測試並不是重點關注的內容。而在功能性回歸測試方面，它本身也有相關工具支持。至於像Blackberry之類的平台，因為本身並沒有呈現爆炸性的 應用增長，所以也沒有列在討論范圍。所以，本文仍以安卓平台作為自動化測試的突破口，希望從中能結合市面上的一些商用工具，嘗試實踐以“關鍵字驅動”為基 礎的自動化測試，而非原始的以“坐標點”為基礎的屏幕點擊測試。對於開源工具也沒有提及，原因是考慮到像Robotium和MonkeyRunner之類 的流行工具可能更貼近於開發工程師使用，而非更貼近於測試工程師。所以，我們希望在上述的討論中能帶給讀者在測試項目中新的啟發。