王成志，楊哲慜，南雨宏，楊 珉

(復旦大學 軟件學院，上海 201203)

1 引 言

動態(tài)分析是在很多領(lǐng)域用到的一種通過實時執(zhí)行程序來進行測試評估的方法.現(xiàn)在有很多工作依靠動態(tài)分析來檢測移動應用程序的bug或者安全漏洞.常見動態(tài)分析方法如TaintDroid[1]、SMV-Hunter[2]和AsDroid[3]等通過運行時分析來檢測移動應用中的隱私泄露，不正確的SSL使用或者其他惡意行為.

在動態(tài)執(zhí)行應用的過程中往往會遇到應用需要用戶文本輸入的情況.例如，應用的登錄界面需要用戶輸入賬號和密碼.通常應用會通過輸入控件來接收用戶的文本輸入.缺少或為應用提供錯誤的文本輸入會導致應用中依賴這些文本輸入的代碼不能被觸發(fā)甚至造成應用崩潰.這使得在動態(tài)分析中，應用只能執(zhí)行少量的代碼，嚴重影響了動態(tài)分析的效率.因此，動態(tài)分析技術(shù)面臨著巨大的挑戰(zhàn).

在實際研究中，由于待分析的應用數(shù)目龐大，為了滿足大規(guī)模動態(tài)分析的需要，研究者將動態(tài)分析方法和自動化測試工具(例如，MonkeyRunner1)相結(jié)合，利用自動化測試工具驅(qū)動應用執(zhí)行，利用動態(tài)分析方法分析應用的行為.在大規(guī)模動態(tài)分析場景中，為了給應用提供相關(guān)的文本輸入，提高自動化動態(tài)分析的執(zhí)行代碼覆蓋率，研究者需要不斷和應用交互.然而，巨大的人工干預嚴重降低了自動化動態(tài)分析的效率.

本文分析了現(xiàn)有的能為應用產(chǎn)生輸入的工具，這些工具能夠為應用產(chǎn)生輸入，例如UI輸入和系統(tǒng)輸入.這些輸入能GUIPipper[5]、SwiftHand[8]和PUMA[9]等，這類工具會對應用的UI進行分析建模，以應用的Activity為狀態(tài)建立一個狀夠驅(qū)動應用的自動化執(zhí)，觸發(fā)應用代碼.本文發(fā)現(xiàn)大部分的工具無法為應用在動態(tài)執(zhí)行中生成相關(guān)的文本輸入.在這些工具中，有些工具如Dynodroid[4]依賴人工干預，需要研究者手動輸入相關(guān)文本.其他工具如AppsPlayground[12]和DroidFuzzer[7]采用基于特定啟發(fā)式的規(guī)則或者fuzzing技術(shù)(例如，給應用設(shè)置一個隨機產(chǎn)生的字符串)來為應用產(chǎn)生文本輸入.然而，通過上述方式產(chǎn)生的文本輸入往往無法滿足應用的測試需要.這主要是因為應用程序中很多用戶文本輸入具有非結(jié)構(gòu)化、且類型特殊的特征，使得測試環(huán)境難以自動生成有效的用戶輸入.例如，有效的電子郵件地址應包含“@”字符，電話號碼字段只能接受數(shù)字，而隨機生成的字符串很可能不符合這樣的要求.

為了能夠為應用自動化產(chǎn)生符合其要求的文本輸入，提高動態(tài)分析的覆蓋率從而使應用中代碼被盡可能多的執(zhí)行到，本文提出了一種名為AutoSim的分析框架，用于在動態(tài)分析時為應用產(chǎn)生相關(guān)文本輸入.對于一個給定的應用，AutoSim從應用反編譯得到靜態(tài)資源文件中提取出具有語義信息的文本，然后利用一個基于機器學習的分類器來識別UI控件所需要的文本輸入類型 (如，電子郵件地址，出生日期和信用卡號碼等).同時，AutoSim在應用動態(tài)執(zhí)行的過程中，通過監(jiān)聽應用的上下文信息來攔截需要文本輸入的UI控件，并將符合類型的文本注入到該控件中.此外，AutoSim提供了點擊模塊來觸發(fā)對應的事件，從而保證應用順利完成依賴于各類用戶輸入的測試場景.

為了驗證AutoSim系統(tǒng)的有效性，我們分別測試了AutoSim識別應用文本輸入類型的準確率以及AutoSim對需要文本輸入的控件處理效果，即能否正確識別控件需要的文本輸入類型.此外，通過測試AutoSim能否在應用動態(tài)執(zhí)行時幫助增加遍歷UI的數(shù)目來判斷AutoSim是否能夠提高動態(tài)分析的覆蓋率.實驗結(jié)果顯示，AutoSim識別文本輸入類型的準確率為88.68%，能夠正確處理89.74%的UI控件.對于需要用戶文本輸入的應用，AutoSim能夠幫助自動化測試工具提高33.7%的界面遍歷覆蓋率.

2 背景與相關(guān)工作

2.1 Android用戶界面

用戶界面是用戶可以在應用程序的屏幕上看到并與之交互的所有內(nèi)容.Android提供了豐富多樣的預置本地UI控件.比較常見的UI控件有輸入框、按鈕、單選框和標簽等，這些控件在Android中對應的類分別為EditText、Button、CheckBox和TextView.開發(fā)者可以通過這些控件和用戶進行交互，并且為這些控件定義不同的屬性以展示不同的內(nèi)容.除了Android框架提供的原生UI控件之外，Android允許開發(fā)人員設(shè)計自定義UI控件.這些自定義小部件通常繼承于Android原生控件，添加微小的修改，使得這些控件可以呈現(xiàn)出不同的外觀.

2.2 Android應用文本輸入

Android框架提供了一些可編輯的控件來接收用戶的文本輸入，例如EditText、AutoCompleteTextView和MultiAutoCompleteTextView等.用戶可以在這些控件中進行文本編輯，

將相應的文本內(nèi)容傳遞給應用.應用根據(jù)接收到的文本輸入，為用戶提供精準的信息或者服務.

圖1(a)展示了需要用戶輸入的UI.用戶通過圖 1(a)所示用戶界面的一些輸入框來接收用戶的個人信息，如email、first name、last name、birthday和phone等，在用戶填入這些信息之后，通過點擊“Sign Up”按鈕完成對應用的注冊.這些文本輸入是非常結(jié)構(gòu)化的，類型特定，例如電子郵箱地址、生日和手機號碼都是具有特定格式的.當這些UI中的輸入框沒有被填入內(nèi)容或者填入錯誤的內(nèi)容時，會導致該應用的核心功能以及大量的用戶界面無法被訪問到.

(a) (b)

2.3 Android用戶界面布局

在Android應用開發(fā)中，開發(fā)者可以通過兩種方式來聲明UI布局：在XML布局文件中聲明UI元素和在運行時實例化布局元素.在XML中聲明UI的方式可以更好地將應用的外觀與控制應用的行為分離，被絕大部分開發(fā)者采用.因此本文只考慮基于XML布局的應用.

圖1(b)展示了圖1(a)中UI界面對應的XML布局文件的部分內(nèi)容.圖1(b)中的EditText元素對應圖1(a)中的email輸入框.開發(fā)者通過在UI布局文件中定義控件的屬性來控制控件的顯示，例如，圖1(b)中EditText的屬性android：hint =“@string/create-email”(第4行和第5行)指示當輸入框的內(nèi)容為空時，應在UI中顯示的提示文本.這個EditText的inputType屬性(第6行)也表明該輸入框需要接收email類型的用戶輸入.從控件布局屬性中提取的內(nèi)容是語義相關(guān)的，UIPicker[6]利用這些內(nèi)容判斷控件接收的文本輸入是否為隱私相關(guān)，本文通過分析這些內(nèi)容來判斷UI控件需要文本輸入的類型.

2.4 Android代碼注入框架

Xposed2是一個可以在不修改應用程序情況下更改系統(tǒng)和應用程序行為的框架.Xposed可以通過hook一些關(guān)鍵函數(shù)來實現(xiàn)對系統(tǒng)或者應用功能的修改.在Android中，所有的應用進程都是通過zygote進程創(chuàng)建，zygote進程是運行的app-process，app-process在frameworks/base/cmds/app-process/下.Xposed將自己定制的app-process替換掉目標設(shè)

2http://repo.xposed.info/

備中的app-process從而修改zygote進程達到hook應用目的.Xposed會將需要hook的方法先指向XposedBridge.jar中的xposedCallHandler方法，然后調(diào)用beforeHookMethod和afterHooked-Method方法，這兩個方法分別在被hook的方法執(zhí)行前和執(zhí)行后被調(diào)用.開發(fā)者可以自定義beforeHookMethod和afterHookedMethod方法中的行為.在本文中，AutoSim利用Xposed攔截正在加載的UI中所有控件.

2.5 相關(guān)工作

在自動化分析方面，Choudhary[7]等人認為目前能驅(qū)動Android應用自動化執(zhí)行的自動化工具根據(jù)其采用的對應用采取策略主要分為三類：隨機探索策略類自動化工具，基于模型的探索策略類自動化工具和系統(tǒng)探索策略類自動化工具.采用隨機探索策略的自動化工具有Dynodroid[4]，這類工具為應用產(chǎn)生隨機的事件，例如，隨機點擊UI上某個位置，來驅(qū)動應用執(zhí)行以及UI的跳轉(zhuǎn).基于模型的自動化工具主要有態(tài)機來指導應用的自動化執(zhí)行以及UI跳轉(zhuǎn).而系統(tǒng)類的自動化工具則采用較為復雜的技術(shù)，如進化算法[10]來不斷改變輸入驅(qū)使應用自動化執(zhí)行.

這些自動化工具均無法有效應對需要用戶文本輸入的UI.在遇到需要文本輸入的UI時，有的工具會為需要文本輸入的控件產(chǎn)生隨機化的文本，如MonkeyRunner、PUMA[9]和Vanar Sena[11]等，有些則直接忽略掉需要文本輸入的UI，如Dynodroid[4]等.還有一些如AppsPlayground[12]采用極為簡易的基于關(guān)鍵字的方法來為識別控件需要的文本輸入類型，并且無法有效處理如開發(fā)者自定義控件等情況，效率較為低下.Peng[13]等人采用深度學習的方法為應用生成相關(guān)的文本，但是他們的方法無法有效生成結(jié)構(gòu)化特定類型的文本輸入.相比于這些工具，AutoSim能夠有效的識別應用需要的文本輸入的類型，并能夠在動態(tài)執(zhí)行過程中高效的將相關(guān)的文本注入到應用中.

3 AutoSim的基本框架

圖2描述了AutoSim的基本框架.如圖2所示，AutoSim自動化生成文本內(nèi)容的過程主要包括兩個階段：靜態(tài)UI解析

圖2 AutoSim框架示意圖Fig.2 System overview of AutoSim

階段和動態(tài)UI驅(qū)動階段.在靜態(tài)UI解析階段，AutoSim使用靜態(tài)分析的方法來分析應用程序中需要文本輸入的UI控件所對應的文本類型.在動態(tài)UI驅(qū)動階段，AutoSim在應用執(zhí)行的過程中將準備好的符合UI要求類型的文本注入到UI控件中.靜態(tài)UI解析階段產(chǎn)生的配置文件將指導動態(tài)UI驅(qū)動器在應用動態(tài)執(zhí)行時的注入操作.

3.1 靜態(tài)UI解析階段

在靜態(tài)UI解析階段，AutoSim首先反編譯Android應用，獲取到應用的資源文件.從資源文件中提取出UI控件的語義相關(guān)的描述信息，通過分析這些語義相關(guān)的描述信息來判斷控件需要的文本輸入類型.為了能夠精確的識別UI控件所需要的文本輸入的類型，AutoSim采用機器學習的方法，利用從應用中提取出來的語義相關(guān)的描述信息訓練出一個分類器.該分類器將從應用中提取出的UI控件的語義相關(guān)的信息作為輸入，輸出該控件所需文本輸入的類型.

3.2 動態(tài)UI驅(qū)動階段

在動態(tài)UI驅(qū)動階段，AutoSim會在應用實際執(zhí)行時監(jiān)視應用運行的上下文.該階段主要包含三個模塊：基于Xposed的Android框架攔截模塊，輸入模塊和點擊模塊.攔截模塊在應用加載UI的過程中通過Hook的方式攔截即將加載到當前屏幕的所有UI控件，并根據(jù)生成的應用的配置文件來檢索需要文本輸入的UI控件.輸入模塊會依據(jù)配置文件上記錄的UI控件所需文本類型的信息將符合該類型的有效文本注入到該控件中.在實現(xiàn)動態(tài)UI驅(qū)動階段中，利用Xposed工具在Android框架層攔截UI控件不需要對應用做出任何修改.

4 AutoSim的設(shè)計與實現(xiàn)

4.1 語義信息的提取

AutoSim首先利用apktool3工具對Android應用進行反編譯，提取應用的資源文件，從反編譯的APK程序包中的界面布局文件中提取出控件的UI文本和UI描述文本來獲取有價值的語義信息進行分析.

UI文本是在應用屏幕中向用戶顯示的文本，例如Button的標簽，輸入框內(nèi)部用于提示用戶的文字.在反編譯應用中，大多數(shù)UI文本位于/res/values/strings.xml文件中，在控件的屬性中由語法@String/[identifier]來定義和引用，此外有些UI文本會直接寫在界面布局文件中，如android：hint=“password”.這些語義相關(guān)的UI文本能夠有效提示和指導用戶的操作.本文通過提取UI布局文件中控件的hint屬性和text屬性的值來獲取UI文本.

控件的UI描述文本是僅位于/res/layout/的UI布局文件中，用于描述控件的內(nèi)容，主要包含控件的id、位置和大小等信息.本文通過提取UI控件的id屬性和inputType屬性的值來獲取語義相關(guān)的UI描述文本.表1描述了提取的UI文本和UI描述文本內(nèi)容樣例.

表1 從圖1(a)所示UI中提取出的部分資源Table 1 Part of extracted resources from UI shown in Figure 1(a)

AutoSim主要從能夠接受用戶文本輸入的UI控件中提取語義相關(guān)的內(nèi)容進行分析.表2展示了本文中主要關(guān)注的能夠接受用戶輸入的UI控件.從表2中可以看出，本文不僅分析能夠接受用戶文本輸入的控件，如EditText，還分析了一些需要點擊的控件，如RadioButton和Checkbox等.這主要是因為在UI界面中需要用戶交互的不只是輸入文本，還需要一些點擊選擇操作，例如通過點擊CheckBox同意相關(guān)的協(xié)議，通過RadioButton選擇性別.此外，本文提供相應的機制來幫助觸發(fā)點擊控件上對應的事件，例如在填寫個人信息后，自動點擊注冊頁面上的注冊按鈕來完成應用自動注冊.

3https://ibotpeaches.github.io/Apktool/

表2 十種常見的需要用戶輸入的控件Table 2 Top ten widgets that require user input

表2中的UI控件均為Android系統(tǒng)提供的原生控件，除了這些原生控件外，本文還分析了開發(fā)者自定義的UI控件.開發(fā)者在Android系統(tǒng)提供的原生控件基礎(chǔ)上進行定義和開發(fā)新的UI控件，這自定義控件的源碼包含在應用中.對于這些控件，本文通過分析反編譯應用獲得的這些控件的smali文件得到這些控件繼承的Android原生控件.在本文中，我們認為這些自定義的控件和這些自定義控件所繼承的原生組件是等同的，這是因為在應用動態(tài)執(zhí)行中使用攔截原生控件的方法同樣可以攔截到繼承該原生控件的自定義控件.

4.2 基于SVM的分類器

為了能夠精確的識別UI控件所需要的文本輸入的類型，本文利用標準支持向量機(SVM)和從UI控件中提取出的語義信息訓練一個能夠精確識別文本輸入類型的分類器.標準支持向量機是一種廣泛使用的監(jiān)督式學習模型，能夠高效的對數(shù)據(jù)分類.然而SVM實質(zhì)是一個二元分類器，而控件需要文本的類型的種類多于兩種，因此本文采用一對多(one-versus-rest)的分類策略來實現(xiàn)支持多分類的分類器.在實現(xiàn)時，我們使用了scikit-learn包中的LinearSVC來訓練支持多分類分類器.

在訓練分類器之前，我們需要確定用戶文本輸入的種類.由于Android應用的多樣性和實際需求，應用會要求用戶輸入各種各樣的信息，導致文本輸入的種類數(shù)目龐大.在本文中，AutoSim選取最常用的文本輸入種類.本文分析了超過1000個從Google Play上下載的應用，收集需要用戶輸入的控件，人工識別這些控件需要的文本類型，統(tǒng)計各種文本輸入類型的數(shù)目，并選取比例最高的14種作為要識別的分類.表3顯示了本文選取的進行分類的用戶文本輸入種類以及所占的比例，從表3可以看出，像email、phone、credit card number、birthday和zipcode這些文本輸入都是格式化的，隨機的內(nèi)容無法滿足需要這些類型輸入的控件.

在訓練階段，本文首先分析了超過2000個從Google Play上下載的應用來獲取訓練樣本.我們從這些應用的UI界面中提取出接收用戶文本輸入控件的語義信息，并且人工標注每一個需要文本輸入控件所需要文本輸入的類型，將控件的語義信息和需要文本輸入的類型一一對應.為了訓練分類器，AutoSim需要將訓練樣本中具有語義信息的原始文本轉(zhuǎn)化成向量.在實現(xiàn)中，我們從字符層面(Character-level)上對文本進行向量轉(zhuǎn)化.相比于常用的從單詞，短語和句子層面上對文本進行向量轉(zhuǎn)化，字符層面上的向量轉(zhuǎn)化能夠不受文本詞法，語法以及句法結(jié)構(gòu)的影響，并且具有良好的效果.本文選用包含26個英文小寫字母的字典對訓練數(shù)據(jù)中的文本進行編碼.從4.1可知，對于每一個控件，本文分別提取了控件4種屬性(hint、text、id和inputType)的文本值.在編碼時，我們將每一個屬性的文本編碼為長度為26位的向量.這個向量上第n位的值表示在字典中偏移量為n的小寫英文字母在這個文本中出現(xiàn)的頻率.對于每一控件，我們可以得到4個26位的向量，并且把這4個向量組合到一起，形成新的104位長度的向量.SVM將這個104位長度的向量和該控件對應的所需文本的類型作為輸入進行分類器的訓練.

表3 本文選取的用戶文本輸入類型在統(tǒng)計樣本中所占比例Table 3 Input types and their corresponding ratio in dataset

4.3 配置文件的生成

在獲得分類器后，對于一個未知的應用，靜態(tài)UI解析會提取應用中需要用戶文本輸入控件的語義文本信息，按照4.2中所述的方法對語義文本信息進行編碼，用訓練好的分類器對編碼好的語義文本進行分類，判斷控件需要文本的類型.AutoSim將應用中每一個需要文本輸入控件的分類結(jié)果保存在以該應用包名命名的靜態(tài)配置文件中，這些配置文件將會被保存在待測設(shè)備中.在應用動態(tài)執(zhí)行時，動態(tài)UI驅(qū)動器會根據(jù)應用的包名加載配置文件，根據(jù)配置文件中的信息進行操作.

在靜態(tài)文件中，除了識別出的控件需要的文本輸入類型外，本文還記錄了控件的類型.控件唯一的十進制ID可以被用來標記存儲在配置文件中的該控件的信息(需要的文本輸入類型和控件類型).Android會為每一個在資源文件中定義的控件分配一個唯一的ID，這些ID以十六進制形式存儲在應用資源文件的/res/values/public.xml中.在應用動態(tài)執(zhí)行時，控件ID和保存在public.xml中該控件的ID是一致的，因而AutoSim可以在應用動態(tài)執(zhí)行時通過ID來追蹤控件.并根據(jù)配置文件中保存的控件的信息對控件進行處理.配置文件連接了AutoSim的靜態(tài)分析階段和動態(tài)驅(qū)動階段，使AutoSim能夠滿足大規(guī)模自動測試分析應用的需要.在大規(guī)模自動測試分析應用的場景下，研究者可以用靜態(tài)UI解析批量處理待測應用，生成對應的配置文件，并將配置文件存儲在文件中.動態(tài)執(zhí)行應用時根據(jù)應用的包名加載不同的配置文件進行操作.

4.4 基于Xposed的動態(tài)UI驅(qū)動

在獲得應用配置文件之后，動態(tài)UI驅(qū)動器會把為應用輸入控件準備好的填寫內(nèi)容在應用動態(tài)執(zhí)行的過程中注入到控件中.AutoSim利用Xposed工具在android framework層面上進行攔截和注入操作，使得UI在加載完成后，UI中所有需要文本輸入的控件都被填寫符合類型的文本.動態(tài)UI驅(qū)動器主要由3個核心部分組成：Android框架攔截模塊，輸入模塊，點擊模塊.

4.4.1 Android 框架攔截模塊

AutoSim利用Xposed工具在Android框架層面上進行增強，獲取應用執(zhí)行時的一些信息.在應用啟動階段，通過Xposed工具AutoSim可以攔截到當前正在被打開的應用的包名.通過獲取到的包名，AutoSim可以檢索到存儲配置文件的位置中是否存在與包名相匹配的配置文件.如果存在，則說明該應用是待測應用，反之則不是.對于存在配置文件的應用，AutoSim會立即加載配置文件，并開始監(jiān)聽應用的執(zhí)行情況，并在執(zhí)行時進行自動的填寫以及點擊操作.不存配置文件的應用在執(zhí)行的過程中將不會受到AutoSim的影響.

在應用執(zhí)行階段，AutoSim通過對Android系統(tǒng)框架中的一些API的監(jiān)聽來攔截正在加載UI的控件.由于Android在繪制UI控件過程中，會調(diào)用系統(tǒng)框架提供的API，因此可以通過監(jiān)聽這些API的調(diào)用對象來攔截正在繪制的控件.例如通過監(jiān)聽這些控件從android.widget.TextView中繼承的的onDraw()方法來獲取所有正在繪制的TextView類型的UI控件.通過進一步的確認UI控件的具體類型，可以判斷出控件的類型是否為MultiAutoCompleteTextView、CheckBox和EditText等.通過監(jiān)聽setOnclickListener()函數(shù)來攔截需要點擊的控件，如Button，ImageButton等.之后AutoSim根據(jù)控件的類型將被攔截到的控件交給輸入模塊和點擊模塊進行處理.

4.4.2 輸入模塊

在攔截到當前正在加載UI的所有控件后，輸入模塊負責將準備好的內(nèi)容根據(jù)控件需要的輸入類型自動填寫到控件中.對于攔截到的正在繪制的UI控件，AutoSim通過這些控件從android.view.View中繼承的getId函數(shù)獲取控件的id.如果應用的配置文件中存在這個id，則表明這個控件是需要用戶輸入的控件.通過id去檢索配置文件中這個控件需要的輸入類型，并獲取符合該類型的輸入.本文事先為14個不同的輸入類型各自準備好符合其類型的輸入，這些輸入均為真實有效的輸入.

AutoSim通過調(diào)用Android框架提供的API將文本注入到控件中.例如，對于一個類型為EditText的輸入框，可以在攔截階段獲取到這個輸入框的實例對象.通過調(diào)用setText()函數(shù)，AutoSim可以將事先準備好的符合這個文本框要求類型的輸入注入到該文本框中.在當前界面加載完后，可以看到被注入的輸入已經(jīng)顯示在屏幕上.

4.4.3 點擊模塊

除了輸入模塊之外，本文也提供了點擊模塊，使得動態(tài)UI驅(qū)動器能夠自動的觸發(fā)相應的事件.例如，在一個登陸注冊的頁面，在填寫完與注冊相關(guān)的信息之后，AutoSim能夠自動的去點擊注冊按鈕以提交注冊信息.同時點擊模塊也為自動的遍歷應用內(nèi)所有UI提供了新的思路.在將來的工作中，我們會用點擊模塊來實現(xiàn)一個高效的Android應用自動化遍歷工具，使得更多應用的代碼被執(zhí)行.

對于攔截到的需要點擊的控件，AutoSim通過調(diào)用這個控件從android.view.View中繼承的performClick函數(shù)來實現(xiàn)自動點擊.需要注意的是，我們不能在攔截到需要點擊的UI控件時立即自動點擊該控件，這主要是因為其他需要填寫的輸入控件還沒有處理完成.鑒于上述問題，本文采用了延時點擊的策略，即通過使用Android框架提供的AsyncTask4來實現(xiàn)一個定時器，在定時器結(jié)束后AutoSim會自動點擊需要點擊的控件.

5 實驗與效果評估

在本節(jié)中，本文從三個方面對AutoSim進行測試評估：對靜態(tài)UI解析部分的評估，對動態(tài)UI驅(qū)動部分的評估和對AutoSim對自動化測試增強效果的評估.在靜態(tài)UI解析階段，本文將測試分類器的平均準確率以及對每一類文本輸入類型識別的精確率.在動態(tài)UI驅(qū)動階段，本文將測試AutoSim能夠正確處理UI控件的數(shù)目.最后本文將測試AutoSim在自動化測試Android應用的場景下是否能夠有效增大自動化測試框架的UI覆蓋率.

本文靜態(tài)UI解析階段以及分類器訓練實驗環(huán)境為：具有40核心(Intel Xeon E7-4830，2.20GHz)內(nèi)核版本3.16.0，物理內(nèi)存大小為132G的Linux服務器.服務器運行的操作系統(tǒng)為64位的Debian，支持python 3.4.2.動態(tài)UI驅(qū)動階段的實驗環(huán)境為具有2GB RAM，運行Android 4.4.4的Nexus 5.

5.1 分類器的訓練以及識別效果測試

為了訓練分類器，本文從Google Play上隨機挑選了1000個應用，從這些應用中提取出997組需要文本輸入的UI控件的語義信息，對這些UI控件需要的輸入類型進行手工標注，之后用這些數(shù)據(jù)進行訓練和測試分類器的效果.本文采用十折交叉驗證的方法來測試基于SVM分類器的平均準確率和在識別不同種文本輸入類型的精確度，即隨機將數(shù)據(jù)集分成10份其中9份做訓練1份做測試，并通過10次十折交叉驗證取平均值來獲取準確度和精確度.此外本文還將基于SVM的分類器與AppsPlayground使用的基于關(guān)鍵詞的分類器進行對比.由于AppsPlayground沒有開源，因此我們實現(xiàn)了簡易的符合其描述的基于關(guān)鍵詞的分類器.

表4是分類器的測試以及對比結(jié)果，從表4中可以看出基于SVM的分類器識別平均準確率為88.68%，高于準確率只有62.7%的基于關(guān)鍵詞的分類器.除了平均準確率以外，基于SVM的分類器在識別單個文本輸入類型的精確率和召回率均超過基于關(guān)鍵詞的分類器.在識別個別輸入類型，如fullname，birthday時，基于關(guān)鍵詞的分類器的精確率遠不如基于SVM的分類器.這是因為基于關(guān)鍵詞的分類主要依賴于有限的關(guān)鍵詞列表，根據(jù)關(guān)鍵詞列表中的關(guān)鍵詞是否出現(xiàn)在語義信息中來判斷輸入類型.有限的關(guān)鍵詞列表會造成較多的錯誤，例如，“password”這個詞可以被寫成“passwd”、“pwd”或者“passcode”等，因而準確識別文本輸入類型“password”需要多個關(guān)鍵詞.為了能夠精確識別并且區(qū)分所有14種輸入類型需要龐大的關(guān)鍵詞列表，而這是不現(xiàn)實的.因此采用機器學習的方法訓練出來的分類器會更加高效.

4https://developer.android.com/reference/android/os/AsyncTask

5http://appium.io

表4 不同分類器的識別效果對比Table 4 Classifier comparison result of identifying input types

5.2 動態(tài)UI驅(qū)動對單個控件處理效果測試

在測試AutoSim的動態(tài)UI驅(qū)動部分時，本文測試了AutoSim處理單個控件的效果，通過統(tǒng)計AutoSim在應用動態(tài)執(zhí)行時能正確處理控件(將正確的文本填入到正確的控件中)的數(shù)目來測試AutoSim對單個控件的效果.本文從200個隨機挑選的應用中收集到了234個需要用戶文本輸入的控件，其中有60個控件是開發(fā)者自定義的控件.在通過分類器對控件進行輸入類型識別以及生產(chǎn)配置文件后，我們動態(tài)執(zhí)行相關(guān)應用，并觀察相關(guān)控件是否被填入正確的內(nèi)容.除了測試AutoSim對單個控件的處理效果之外，本文也分別測試了fuzzing技術(shù)和AppsPlayground對單個控件的處理效果，并進行對比.

表5為本次測試的結(jié)果，由結(jié)果可以看到，AutoSim能夠正確處理210個輸入控件，包括167個Android框架提供的原生控件和43個開發(fā)者自定義的控件，分別占比95.98%和71.67%. AutoSim在處理Android原生控件和開發(fā)者定義控件上的效果均強于Fuzzing和AppsPlayground.Fuzzing由于采用給控件輸入隨機的內(nèi)容，導致其能正確處理的控件數(shù)目較少.而AppsPlayground由于采用了基于關(guān)鍵詞的分類識別方法，使得其能夠識別100個原生控件，但是由于其在處理開發(fā)者自定義的控件時采用了fuzzing的技術(shù)，沒有對自定義控件的輸入類型進行有效的識別，因此只能正確處理較少的開發(fā)者自定義控件.

表5 針對單個控件的不同方法測試效果對比Table 5 Effectiveness of testing results by different approaches

5.3 AutoSim對自動化測試Android應用影響的評估

為了評估AutoSim是否能夠增大自動化測試框架的UI覆蓋率，本文測試了AutoSim是否能夠有效增加自動化框架在測試Android應用時遍歷應用UI的數(shù)目.這主要是因為當自動化測試框架遍歷到的UI數(shù)目的增加表明能夠執(zhí)行到的應用的代碼的增加.本文從Google Play上隨機選擇了30個應用進行測試.此外，我們利用Appium5和深度優(yōu)先算法來點擊UI上的每一個可以點擊的控件以實現(xiàn)自動遍歷Android應用的工具，通過該工具來自動遍歷安裝在Nexus 5上的Android應用，統(tǒng)計能夠遍歷到的UI的數(shù)目.我們將AutoSim部署在Nexus 5上，分別測試給需要文本輸入的控件填寫隨機內(nèi)容時能夠遍歷的UI的數(shù)目和給輸入控件由AutoSim注入的內(nèi)容時遍歷的UI數(shù)目.我們用基于Appium的自動化遍歷工具運行測試應用，統(tǒng)計能夠遍歷的UI數(shù)目.對于每一個測試應用，測試時間不超過1個小時.

表6 AutoSim對應用界面覆蓋率的提示效果Table 6 Improvement of AutoSim on improving UI coverage

測試結(jié)果表明AutoSim能有效擴大33.7%的UI覆蓋率.表6為本次實驗的結(jié)果，在測試中共有13個應用包含需要用戶文本輸入的UI，如表6中所示，14個應用不需要用戶文本輸入，另外3個在打開應用時由于無法連接服務器而導致崩潰.從表6中的數(shù)據(jù)可以看出，在13個需要文本輸入的應用中，AutoSim能夠顯著增加其中6個應用遍歷的UI數(shù)目.我們分析另外7個遍歷UI數(shù)目沒有增加的應用時發(fā)現(xiàn)，在這些應用中，需要用戶文本輸入的UI并不會影響應用的正常訪問.例如，包名為“com.protogeo.moves”應用中包含有創(chuàng)建應用賬號的功能，但是這個功能在設(shè)置頁面中，即使不創(chuàng)建賬號，我們也基本可以訪問到應用的所有UI和功能.

6 總 結(jié)

在對移動應用自動化動態(tài)分析過程中，缺少或者為應用提供錯誤的文本輸入會嚴重的限制自動化動態(tài)分析效率和覆蓋率.為了解決這個問題，本文提出了AutoSim.AutoSim采用機器學習的方法來高效的識別應用需要的文本輸入的類型，并通過基于Xposed的技術(shù)將符合需要類型的文本，在應用動態(tài)執(zhí)行的過程中準確高效地注入到對應的控件中，使自動化動態(tài)分析能夠通過需要用戶輸入的UI，執(zhí)行更多的代碼.針對AutoSim的實驗評測結(jié)果表明，AutoSim能夠有效識別應用需要輸入的類型，并且能夠有效增加在動態(tài)分析中遍歷到更多的UI，執(zhí)行更多的代碼.