面向安卓手機App功能測試技術的方法

張 明，程寶雷,2，査偉忠，楊季文,2

(1.蘇州大學 計算機科學與技術學院，江蘇 蘇州 215006；2.蘇州大學 江蘇省計算機信息處理技術重點實驗室，江蘇 蘇州 215006)

0 引 言

目前業界普遍使用的Android手機App自動化功能測試工具按其工作方法可以劃分為基于錄制回放方法的測試工具、基于控件查找方法的測試工具、基于圖像模糊查找的測試工具和基于模型驅動的隨機操作的測試工具等幾大類[1-6]。這些工具普遍存在功能測試不全面、測試用例復用性差以及需要大量手工操作等問題。

為了解決這些問題，常見的方法是采用控件遍歷的方式來進行功能測試。例如，Tanzirul Azim等[7]提出的模擬用戶和Android應用的交互而實現控件遍歷的方法，該方法能夠動態檢測應用程序界面，并識別界面中的控件進行遍歷，具有較高的界面覆蓋率和方法覆蓋率，進而提高測試的覆蓋率，但是該方法需要在源碼的基礎上進行靜態分析，因此存在一定的局限性；文獻[8]中提出了在Robo-tium 框架基礎上遍歷App控件的方法，該方法能夠增強測試用例復用性并提高了測試效率，但是同樣要有源碼的支持，并且需要用戶自己編寫測試腳本，這就要求測試人員有一定的編程基礎，而且手工編寫測試腳本出錯的概率也比較高；百度公司的移動云測試中心[9]和東軟公司的易測云[10]測試平臺均提供了針對Android應用程序無源碼的遍歷測試功能，能夠自動遍歷應用程序中的控件，在遍歷過程中保留訪問到的界面截圖并記錄操作路徑，這種方法能夠對每個控件進行遍歷，提高了功能測試的覆蓋率，但是就目前的測試結果來看，自動遍歷控件的效率較低，而且該平臺的工具并不開源，不能為其它測試人員的研究提供幫助。

針對以上問題，本文提出了一種在標準路徑引導下基于控件遍歷的App功能測試方法。該方法以標準路徑作為引導，采用基于深度優先搜索原理自動遍歷控件得到測試用例，并使用測試用例進行功能測試。該方法在其它控件遍歷方法的基礎上，做了如下改進：①測試在無源碼條件下進行，增強了方法的適用性。②采用標準路徑作為引導，提高了測試效率。

相比一般的測試方法，該方法有以下幾點優勢：①生成的測試用例中包含多條測試路徑，提高了測試的覆蓋率；②采用不同的測試數據對測試用例進行驅動，增強了測試用例的可復用性；③提高了自動化測試程度，減少了人工干預，降低了測試過程的復雜性。文中對框架設計、腳本生成技術以及自動生成測試用例等關鍵技術進行了詳細說明，并通過實驗驗證了其可行性和有效性。

1 技術分析

1.1 測試方法概述

在自動化測試[11]中，測試效率是自動化測試工具的重要指標。本文從提高功能測試的全面性和測試用例復用性方面來提高測試效率，其中測試的全面性可以通過測試路徑覆蓋來實現。在白盒測試中，測試路徑覆蓋是指選取足夠多的測試數據，使程序的每條分支路徑至少執行一次。在本文中，由于無法獲取源程序中的分支路徑，所以測試路徑覆蓋可看成是在測試過程中出現了多條分支路徑，這些路徑可以作為不同的測試方式和測試場景來對程序進行測試，幫助更好地檢測出問題。

1.2 基于深度優先搜索算法的測試用例生成方法

深度優先搜索算法屬于圖算法的一種，其過程簡要來說是對每一個可能的分支路徑深入遍歷到不能再深入為止，實現了圖中的每一條路徑的覆蓋。在Android應用程序中，界面功能可以抽象成控件關系圖G=(V,E,s,e)。 這里，界面中的控件集合表示為圖中的節點V；控件間的執行順序代表圖中的邊，其集合表示為E；s和e分別表示功能測試的開始點和結束點，同時也是界面中的控件，屬于集合V。因此，對應用程序的功能測試可以看成是對圖的遍歷。

在自動遍歷控件時，首先由人工錄制一段測試腳本，并從測試腳本中提取有響應事件的控件作為標準路徑，然后基于標準路徑遍歷界面中的控件，實現自動測試。標準路徑作為圖G中的一個分支路徑，包括了G的開始點s和結束點e，其中結束點是標準路徑中設定的驗證點，目的是檢測控件在自動遍歷過程中是否達到預定的效果。圖1展示了一個功能測試時的控件關系圖。其中，s、V1、V2和e表示標準路徑中的控件，V3、V4、V5、V6表示標準路徑之外的有響應事件的控件。V3、V4在執行過后又能回到標準路徑中去，在測試過程中是有效的測試路徑，而V5和V6在執行到沒有下一個控件可執行的時候仍然沒有回到標準路徑中去，屬于無效的測試路徑。采用深度優先搜索原理遍歷控件，目的就是為了找到App功能測試中所有可能經過的路徑，因為這些路徑會對功能測試的結果產生影響，方法的執行流程如圖2所示，步驟描述如下。

圖2 自動遍歷控件流程

(1)訪問標準路徑中的s點，并對其進行標記，記錄對s的訪問次數、操作類型等；接著獲取當前界面中的控件信息并保存到xml文件中，其格式舉例如下：

(2)驗證是否包含e點。e點為滿足功能測試的驗證點，驗證方法是判斷當前界面中是否包含e點。例如，對登錄功能進行測試，測試結束后會在界面中顯示登錄成功或者登錄失敗等文字，這些文字可看成是界面中View類型的控件，同時也是我們設定的e點。功能測試結束后，如果界面中包含驗證點e，則驗證通過，功能測試結束，否則轉到步驟(3)。

(3)判斷頁面是否發生變化。在App功能測試中，對控件進行操作后可能會引起界面的變化。如果未發生界面變化，則從當前界面中選取下一個可執行控件，作為圖中下一個可訪問的節點s并重復步驟(1)；如果界面發生變化則轉到步驟(4)。

(4)當檢測到有界面變化時，首先驗證自動遍歷控件是否偏離標準路徑。本文中針對偏離標準路徑的定義是指在自動遍歷控件過程中出現兩次界面變化，且界面中均不包含標準路徑中的控件。遍歷標準路徑被認為與測試的功能點相差甚遠，其測試結果對功能點影響不大。測試中，如果沒有偏離標準路徑，則獲取界面中第一個可執行控件，作為圖中下一個可訪問的節點s并重復步驟(1)；如果偏離了標準路徑，則轉到步驟(5)。

(5)當自動遍歷控件偏離了標準路徑時，就要執行頁面返回操作，并保存測試路徑；然后從頁面中查找出最近訪問的標準路徑中的控件；最后從該控件開始選擇下一個未訪問的控件，作為圖中下一個可訪問的節點s并重復步驟(1)。

采用以上方法可以使程序在滿足驗證點前遍歷出多條測試路徑，每一條測試路徑都表示了一個基于控件訪問順序的事件結點序列，該序列就是我們需要的測試用例。

2 設計與實現

本文首先設計一種針對Android手機App功能測試的自動化測試框架，然后在該框架的基礎上實現了自動化測試工具。其主要功能包括錄制腳本、生成測試用例和執行測試用例等，并滿足如下特點：

(1)測試用例能夠針對一個功能采用多種測試路徑進行測試，實現功能測試的覆蓋。

(2)測試用例能夠針對不同的測試場景或不同的測試設備進行測試，增強了測試用例的復用性。

(3)從測試效果來看，在很大程度上采用自動化測試代替了功能測試中大量和重復的人工測試，提高了測試效率。

2.1 框架設計

框架設計如圖3所示，它由兩部分組成，分別為PC端和手機端。這兩部分通過Socket和Adb進行通信。

圖3 測試框架

PC端作為Socket客戶端，主要功能包括：①向手機端發送指令，如“開始錄制”指令，手機端在接收到指令后會開啟監聽input event事件功能，開始記錄操作事件。②獲取手機端的操作事件流，并將其轉化為基于控件的腳本；③自動遍歷控件生成測試用例，并根據測試用例執行功能測試。

手機端作為Socket服務端，主要提供錄制腳本、獲取控件信息和執行測試腳本功能，其中執行測試腳本功能是由PC端通過Adb向手機端發送可執行命令來實現。這里，Adb是直接操作和管理Android手機設備的必備工具，存在于Android的SDK當中。

2.2 標準路徑生成模塊設計

標準路徑作為自動遍歷控件中的引導路徑，在生成測試用例過程中起到關鍵作用。標準路徑是由錄制腳本中的控件組成的，作用是減少無效的測試路徑，其質量能夠影響測試用例的好壞以及測試用例的全面性等。標準路徑的質量是由測試人員錄制的腳本所決定的，為了保證標準路徑的質量，標準路徑的生成應遵循以下幾個特點：①測試人員錄制的腳本要保證能覆蓋所有的功能點。②錄制的腳本能夠正確執行，功能點得到正確的驗證。③標準路徑應能夠根據測試用例的覆蓋情況，增加或刪除控件以保證測試用例的全面性。

2.3 基于控件的腳本生成技術

基于控件的腳本生成技術是指測試腳本中的元素主要是控件信息，這不僅能夠提高腳本的靈活性，還能參數化腳本中的數據。本文提供了一種基于控件的腳本生成方法，并采用該方法錄制測試腳本，流程如圖4所示。

圖4 基于控件的腳本生成流程

(1)測試人員操作手機屏幕。

(2)獲取操作過程中input event事件，每次操作都會有一個對應的input event事件，事件內容如圖5所示。其中ABS_MT_POSITION_X和ABS_MT_POSITION_Y分別為操作點的中心坐標，其對應的值為一個十六進制的數。測試過程中通過JNI接口調用本地native方法可獲得每次觸摸屏幕的事件，從事件中獲取觸摸點的中心坐標。

圖5 事件內容

(3)通過Android輔助服務類AccessibilityService獲取界面中的控件信息，包括控件的名稱、類型、位置、控件坐標范圍等，將步驟(2)中的坐標與控件坐標范圍進行匹配即可獲得操作對應的控件。

(4)對每一次操作都將其操作點的坐標轉化為對應的控件，最后保存成基于控件的測試腳本。

2.4 控件自動遍歷技術實現

控件的自動遍歷技術是指不需要人工干預測試工具就能夠自動遍歷被測試程序中的所有控件。在本文實現的自動化測試工具中，我們以棧的形式存儲深度優先遍歷過程中訪問的控件，實現方法如下：

(1)獲取界面中的控件列表并將控件按照順序保存到棧中，其中先執行的控件放在棧頂。棧中的控件的數據結構包括對應控件的名稱、類型、坐標、訪問次數以及是否為標準路徑中的控件等。

(2)程序執行的時候首先執行出棧操作，獲取棧頂控件的類型并執行相應的操作，如控件類型為Button，則執行click操作，控件類型為EditText則執行input操作；然后判斷界面是否發生變化，如果界面發生變化，則獲取新界面中的控件并保存到棧中并重復步驟(2)，如果界面沒有發生變化，則繼續執行出棧操作并執行控件。

(3)當偏離標準路徑時，首先執行界面返回操作，直到當前界面中的控件出現在標準路徑中；然后執行出棧操作，直到出棧的控件滿足存在于當前界面中且為標準路徑中的控件；最后選擇該控件之后的一個未執行控件并執行。當出棧控件滿足驗證點時，遍歷結束。

2.5 測試用例生成模塊設計

測試用例生成是測試工具的重要功能之一，一個好的測試用例能夠幫助測試人員有效發現應用程序中的問題。本文測試用例滿足以下兩個條件：①滿足對功能進行全面的測試。②增強可復用性。

圖6中給出了生成測試用例的流程：

首先，根據測試環境，由測試人員錄制測試腳本，提取腳本中的控件信息形成標準路徑。

其次，以標準路徑作為引導路徑，采用深度優先搜索算法自動遍歷控件，將控件的遍歷順序保存為測試路徑。

最后，根據控件的信息，分析控件的類型并給出針對控件的測試數據，結合測試路徑和測試人員設定的驗證結果最終生成測試用例。

圖6 測試用例生成

3 實驗及結果分析

為了驗證方法的可行性和有效性，本文采用基于方法實現的測試工具對一款常用的Android應用“微信”進行了功能測試，主要測試其“登錄”、“發送消息”和“退出”等功能。

實驗在電腦端和手機端同時進行，其中電腦端采用Windows 7操作系統，硬件平臺為Intel Core2 i5-4570 3.20GHz、4G RAM；手機端采用Android 4.4操作系統，硬件平臺為聯發科MT6595 1.7GHz、2G RAM。實驗過程如下：

(1)連接手機和電腦。打開手機wifi，讓手機和電腦處于同一個局域網中，從而進行Socket通信。

(2)錄制腳本。首先，電腦端向手機發送“開始錄制”指令。接著，由測試人員依次完成“登錄”、“發送消息”和“退出”等操作，操作過程會記錄到電腦端并保存為基于控件的腳本。

(3)生成測試用例。提取(2)中錄制腳本中的控件形成標準路徑。通過電腦端向手機端發送“自動遍歷”指令，測試工具會沿著標準路徑進行控件自動遍歷。當程序滿足驗證點的時候遍歷結束生成測試用例。

(4)根據測試用例進行測試。測試分為兩種情況，第一種情況是對功能進行全面測試，測試結果見表1；第二種情況對登錄功能采用不同的測試數據進行測試，測試結果見表2。

表1 第一種情況測試結果

表2 第二種情況測試結果

表1的主要字段中，測試路徑數表示在測試中能夠有多少路徑進行測試。界面覆蓋數是指對功能測試過程中所訪問的界面個數，其能夠反映功能測試的深度。控件覆蓋率是指對界面中控件的訪問情況，用公式表示為

η=m/n

(1)

其中，η表示控件覆蓋率，m表示測試中訪問的控件數量，n表示測試中所經過的頁面中的控件的總數量。控件覆蓋率的提高能夠反映功能測試的全面性，因為在功能測試過程中，對界面中的每一個控件訪問后都有可能影響功能測試的結果。本文中控件覆蓋率的測試充分性是指對界面中的每一個控件進行遍歷。但是在訪問控件過程中，可能會出現界面跳轉，所以很難對界面中的控件全部訪問，只能通過多條測試路徑，盡可能地對控件進行訪問。為了進一步驗證本文測試工具提高了控件覆蓋率，文中在相同實驗條件下對比了一款基于MonkeyRunner的錄制回放工具AutoTest[12]。其中MonkeyRunner是Android SDK中自帶的測試工具，目前常用于自動化測試工具中，測試結果見表3。

表3 AutoTest測試結果

從表3的測試結果可以看出，AutoTest工具在測試過程中，其測試路徑數滿足功能測試的最低要求，即只訪問能夠展示功能效果的一些控件。這樣一來就降低了控件覆蓋率、減少了界面覆蓋數，同時也降低了功能測試的全面性。采用AutoTest工具測試時，可以通過測試人員錄制多條測試路徑來提高控件覆蓋率，但是這樣會增加測試的工作量，提高測試成本。為了降低測試成本，還可以采用分析被測App代碼中的邏輯結構來編寫測試腳本，實現路徑分支的覆蓋，并提高控件覆蓋率。但是這種做法需要有源碼的支持，增加了測試的局限性，而且需要測試人員有一定的腳本編寫能力。

從表1和表3的測試結果可以看出，本文測試用例中包含了多條測試路徑，這些測試路徑又能夠覆蓋更多的界面和界面中的控件。所以采用文本方法生成的測試用例能夠有效提高功能測試的覆蓋率，保證了測試的全面性。

表2中針對登錄功能的測試給出了不同的輸入數據。其中每一條輸入數據可以由多個測試數據組成，每個測試數據都表示對控件的一次操作。當正確的輸入數據出現正確的結果，不正確的輸入數據出現錯誤的結果時，才能證明功能是好的。從表2的測試結果中可以看出，相同的測試腳本可以采用不同的測試數據進行測試，測試用例在測試過程中只需要獲取App中的控件信息即可。這也保證了其在不同測試平臺或設備上的通用性，驗證了測試用例的可復用性。

4 結束語

本文提出了一種在標準路徑引導下基于控件遍歷的App功能測試方法，實現了基于深度優先搜索算法來自動生成測試用例。根據該方法實現了一個測試工具，并在實際環境中進行實驗。實驗結果表明，采用該方法能夠提高功能測試的覆蓋率以及增強測試用例的復用性，這也驗證了本文方法的可行性和有效性。目前，基于本文提出的方法已基本完成了針對Android原生App的功能測試，對控件之間邏輯關系簡單的界面取得了良好的測試效果。未來工作計劃主要包括兩方面：一方面繼續優化本文提出的方法，對一些特殊和復雜的界面設計更加智能的控件遍歷方法；另一方面，我們將在本文方法的基礎上實現對包含HTML5界面的App進行功能測試。

[1]Lin Y,Rojas JF,Chu ET,et al.On the accuracy efficiency and reusability of automated test oracles for Android devices[J].IEEE Transactions on Software Engineering,2014,40(10):957-970.

[2]YANG Yijun,HUANG Daqing.Research and development of automated performance test tool for Android smartphone[J].Journal of Computer Applications,2012,32(2):554-556(in Chinese).[楊怡君,黃大慶.Android手機自動化性能測試工具的研究與開發[J].計算機應用,2012,32(2):554-556.]

[3]PENG Shunshun.The research and design of software component testing framework based on date-driver[D].Shenyang:Shenyang Normal University,2014:1-32(in Chinese).[彭順順.基于數據驅動的軟件組件測試框架的研究與設計[D].沈陽:沈陽師范大學,2014:1-32.]

[4]Anbunathan R,Basu A.Data driven architecture based automated test generation for Android mobile[C]//IEEE International Conference on Computational Intelligence and Computing Research.Piscataway:IEEE,2015:1-5.

[5]ZHAO Yaozong,CHENG Shaoyin,JIANG Fan.Automatic method for GUI traversal in Android applications[J].Computer Systems & Application,2015,24(9):219-224(in Chinese).[趙耀宗,程紹銀,蔣凡.Android應用程序GUI遍歷的自動化方法[J].計算機系統應用,2015,24(9):219-224.]

[6]ZHONG Shucheng.The design and implementation of Android GUI automated testing tool based on recording and playback method[D].Beijing:University of Chinese Academy of Sciences,2015:9-24(in Chinese).[鐘書成.基于錄制回放的Android GUI自動化測試工具的設計與實現[D].北京:中國科學院大學,2015:9-24.]

[7]Azim T,Neamtiu I.Targeted and depth-first exploration for systematic testing of android apps[J].Acm Sigplan Notices,2013,48(10):641-660.

[8]ZHU Yangyang,HOU Yonghong,WANG Baoliang.Application of automatic test tool Robotium for Android[J].Information Technology,2015,39(10):198-200(in Chinese).[祝陽陽,侯永宏,王寶亮.Android自動化測試工具Robotium的應用與研究[J].信息技術,2015,39(10):198-200.]

[9]Baidu Inc.MTC[EB/OL].[2016-12-11].http://mtc.baidu.com(in Chinese).[百度公司.百度移動云測試中心[EB/OL].[2016-12-11].http://mtc.baidu.com.]

[10]Neusoft.Yiceyun[EB/OL].[2016-12-11].http://www.yiceyun.com(in Chinese).[東軟公司.易測云[EB/OL].[2016-12-11].http://www.yiceyun.com.]

[11]HOU Minju.Research on Android-based keyword-driven automated testing framework[D].Guangzhou:Sun Yat-Sen University,2012:6-60(in Chinese).[侯敏菊.基于Android的關鍵字驅動自動化測試框架研究[D].廣州:中山大學,2012:6-60.]

[12]WAN Mulin.Design and implement of functional test software for android cellphone application[D].Suzhou:Soochow University,2015:1-62 (in Chinese).[萬木林.面向Android手機應用的功能測試軟件[D].蘇州:蘇州大學,2015:1-62.]