張光蘭，萬(wàn)瑩

（四川大學(xué)計(jì)算機(jī)學(xué)院，成都 610065）

0 引言

據(jù)統(tǒng)計(jì)，全球智能手機(jī)用戶的數(shù)量預(yù)計(jì)將從2016年的21 億增加到2019 年的25 億左右[1]。這導(dǎo)致了對(duì)運(yùn)行在這些設(shè)備（應(yīng)用程序）上的新軟件應(yīng)用程序的持續(xù)需求，而目前針對(duì)移動(dòng)應(yīng)用的測(cè)試方法和傳統(tǒng)的桌面端軟件的測(cè)試方法一致，可分為手工測(cè)試和自動(dòng)化測(cè)試。手工GUI 測(cè)試方法，顧名思義，就是一種比較傳統(tǒng)也比較常見(jiàn)的方法，其存在的問(wèn)題是：人工成本高、工作進(jìn)度無(wú)法評(píng)估、工作成果依賴于測(cè)試工程師的經(jīng)驗(yàn)[2]。并且隨著時(shí)間的發(fā)展，GUI 軟件會(huì)變得大型化、復(fù)雜化和多元化[3]。此外，帶有GUI 移動(dòng)應(yīng)用程序的自動(dòng)化技術(shù)比帶有GUI 桌面應(yīng)用程序自動(dòng)化測(cè)試技術(shù)要更加復(fù)雜，例如：平臺(tái)多樣性、移動(dòng)應(yīng)用更新速度快、市場(chǎng)壓力都給移動(dòng)應(yīng)用的測(cè)試帶了新的挑戰(zhàn)。

1 GUI測(cè)試的定義

GUI（Graphical User Interface，圖形用戶界面）是底層程序代碼的前端表示形式，對(duì)諸如選擇下拉列表框、菜單、導(dǎo)航欄、按鈕控件等用戶操作會(huì)作出相對(duì)應(yīng)的前端反映[4]。因?yàn)閹в袌D形界面的軟件相對(duì)與傳統(tǒng)的軟件而言，其美觀的圖形用戶界面帶給了用戶們最直觀的體驗(yàn)，使得用戶可以快速上手而逐漸受到用戶的青睞。所以在目前市場(chǎng)上的軟件大多都帶圖形用戶界面。所以，針對(duì)GUI 進(jìn)行的軟件測(cè)試也應(yīng)該成為整個(gè)GUI 軟件測(cè)試中非常重要的一部分[4]。

而GUI 測(cè)試指對(duì)帶有GUI 的軟件進(jìn)行軟件測(cè)試，如文獻(xiàn)[5～8]中說(shuō)提及的GUI 測(cè)試是通過(guò)測(cè)試應(yīng)用程序的GUI，從而達(dá)到測(cè)試被測(cè)系統(tǒng)的功能、GUI 的結(jié)構(gòu)及實(shí)現(xiàn)GUI 的代碼。而移動(dòng)端的GUI 測(cè)試用例指的是一個(gè)完成的用戶行為的一系列相關(guān)的事件/動(dòng)作，即移動(dòng)應(yīng)用程序的GUI 測(cè)試用例是由一系列的事件/動(dòng)作組成。由此可見(jiàn)，移動(dòng)應(yīng)用的GUI 測(cè)試的輸入一般都是事件/動(dòng)作，而輸出一般是狀態(tài)的變化。狀態(tài)變化可能體現(xiàn)為頁(yè)面的變化，也可能是頁(yè)面中某些元素的狀態(tài)變化等。針對(duì)移動(dòng)應(yīng)用的GUI 測(cè)試用例中，事件/動(dòng)作之間的依賴關(guān)系也是一項(xiàng)非常重要的活動(dòng)[9]。

2 GUI測(cè)試方法

2.1 GGUUII測(cè)試框架

目前存在常用的GUI 測(cè)試框架如表1 所示，由于篇幅的原因，我們只是列舉了比較常見(jiàn)的框架，其中Uiautomator 框架中提供的API 可以對(duì)移動(dòng)應(yīng)用程序進(jìn)行頁(yè)面截圖及頁(yè)面的元素的結(jié)構(gòu)信息文件。

表1 常見(jiàn)的GUI 測(cè)試框架

●Instrumentation 是Android 主推的白盒測(cè)試框架。在單元測(cè)試的基礎(chǔ)上進(jìn)行功能擴(kuò)展，達(dá)到對(duì)Android系統(tǒng)的高度控制，Robotium[10]、Selendroid[11]、Athrun[12]都是基于Instrumentation 的二次封裝框架，其缺點(diǎn)是不能跨應(yīng)用使用。

●Calabash[13]是一個(gè)適用于iOS 和Android 開(kāi)發(fā)者的跨平臺(tái)App 測(cè)試框架，可用來(lái)測(cè)試屏幕截圖、手勢(shì)和實(shí)際功能代碼。缺點(diǎn)：測(cè)試步驟失敗后，將跳過(guò)所有的后續(xù)步驟，需要Calabash 框架安裝在iOS 的ipa 文件中，因此測(cè)試人員必須要有iOS 的App 源碼。除了Ruby，對(duì)其他語(yǔ)言不友好。

●Monkey[14]是谷歌提出的，它可以生成一些偽隨機(jī)用戶事件流發(fā)送到被測(cè)試系統(tǒng)中，然后模擬用戶的點(diǎn)擊等手勢(shì)，以及一些系統(tǒng)級(jí)的事件。它應(yīng)該是目前流行移動(dòng)端自動(dòng)化框架或者工具的一個(gè)鼻祖。Monkeyrunner 同樣是Android SDK 自帶的測(cè)試工具，它可以用于做功能測(cè)試，回歸測(cè)試并且可以自己定義測(cè)試擴(kuò)展，靈活性較大。Monkeyrunner 工具提供了一些API，可以通過(guò)該 API 來(lái)控制 Android 設(shè)備或者模擬器。

●Uiautomator 是通過(guò)以控件的方式來(lái)定位，當(dāng)然也是支持坐標(biāo)軸的方式來(lái)定位。缺點(diǎn)：Uiautomator 是Android 4.1 后加入的，所以僅支持Android 4.1 和以上的版本，但是不支持Webview。

●Appium[15]：同時(shí)支持 Android、iOS、FirefoxOS。并且Appium 可以用任何你熟悉的開(kāi)發(fā)語(yǔ)言來(lái)進(jìn)行編寫測(cè)試用例。例如 Java、Python、Ruby、PHP、JavaScript、Object-C、C#。采用的控件的定位方式對(duì)不懂Java 而熟悉其他語(yǔ)言的來(lái)說(shuō)還是相當(dāng)不錯(cuò)的選擇。缺點(diǎn)是穩(wěn)定性相對(duì)較差。

2.2 GGUUII測(cè)試技術(shù)

在移動(dòng)應(yīng)用程序的測(cè)試中，現(xiàn)有很多的測(cè)試手段：云測(cè)、眾測(cè)、自測(cè)、外包測(cè)試等不同的方式；目前提供云測(cè)試的平臺(tái)服務(wù)很多，最出名的是Testin 云測(cè)（Android&iOS）、百度 MT（Android&iOS）、阿里 MQC（Android&iOS）、貫眾云測(cè)試（Android&iOS）、騰訊優(yōu)測(cè)（Android）。其中括號(hào)內(nèi)表示云測(cè)試平臺(tái)可以支持的測(cè)試類型。此外，這幾個(gè)測(cè)試平臺(tái)都是用到Monkey 工具做兼容性，穩(wěn)定性測(cè)試。這幾個(gè)云測(cè)試平臺(tái)的測(cè)試場(chǎng)景如表2 所示。但是云測(cè)試在測(cè)試過(guò)程中真正使用真機(jī)來(lái)測(cè)試的很少，據(jù)我們所知，在測(cè)試過(guò)程中使用真機(jī)和模擬機(jī)是有很大的不同的，模擬機(jī)消耗的資源太大，使用它作為測(cè)試平臺(tái)的話，測(cè)試出來(lái)的很多問(wèn)題其實(shí)在真機(jī)中是不存在或者說(shuō)是反應(yīng)是不一樣的。另外，眾測(cè)、自測(cè)、外包測(cè)試其實(shí)是屬于同一種測(cè)試方法的不同形式，即可分為手工測(cè)試和自動(dòng)化測(cè)試。目前國(guó)內(nèi)外已經(jīng)存在很多關(guān)于移動(dòng)應(yīng)用GUI 測(cè)試方法。這些有關(guān)移動(dòng)應(yīng)用GUI 測(cè)試方法的研究方向可分為模糊技術(shù)、錄制/回放，基于模型，且在這些技術(shù)中，基于模型生成測(cè)試用例的方法被認(rèn)為是最具有希望的研究方向之一[14]。

表3 列出了自動(dòng)化GUI 測(cè)試方法的優(yōu)缺點(diǎn)，可供測(cè)試工程師選擇GUI 的測(cè)試方法作為一個(gè)依據(jù)。

2.3 GGUUII測(cè)試工具

表4 中列舉出針對(duì)現(xiàn)有的GUI 測(cè)試方法對(duì)應(yīng)的工具，其排名不分先后順序。這些工具來(lái)源于論文的整理得到，由于工具比較多，這里列出論文中出現(xiàn)較多次數(shù)的工具，包括隨機(jī)探測(cè)工具、基于模型探索、系統(tǒng)化探測(cè)工具及針對(duì)移動(dòng)應(yīng)用的錄制回放工具，另外我們還列出每個(gè)工作是否需要源代碼。

表2 云測(cè)試平臺(tái)對(duì)比表

表3 測(cè)試方法的優(yōu)缺點(diǎn)

表4 GUI 測(cè)試工具

2.4 GGUUII測(cè)試的評(píng)估方法

Amalfitano 等人在文獻(xiàn)[25]中提出GUI 測(cè)試的主要是以覆蓋率作為評(píng)價(jià)標(biāo)準(zhǔn)。其覆蓋率包括缺陷覆蓋率、活動(dòng)覆蓋率、事件覆蓋率。如公式（1）所示，缺陷覆蓋率是規(guī)定的測(cè)試時(shí)間內(nèi)或者執(zhí)行相同數(shù)目的測(cè)試用例時(shí)覆蓋的缺陷數(shù)目與缺陷總數(shù)的比值，是衡量測(cè)試工具或者測(cè)試用例有效性的主要指標(biāo)之一?；顒?dòng)覆蓋率如公式（2）所示是在規(guī)定的測(cè)試時(shí)間內(nèi)或者執(zhí)行相同數(shù)目的測(cè)試用例時(shí)已經(jīng)覆蓋的活動(dòng)數(shù)量與活動(dòng)總數(shù)的比值。事件覆蓋率如公式（3）所示是在規(guī)定的測(cè)試時(shí)間內(nèi)或者執(zhí)行相同數(shù)目的測(cè)試用例時(shí)已覆蓋事件數(shù)量與事件總數(shù)的比值。另外，現(xiàn)今軟件開(kāi)發(fā)人員通常采用更多的代碼來(lái)實(shí)現(xiàn)應(yīng)用軟件的GUI，幾乎能占到整個(gè)應(yīng)用軟件程序代碼量的60%[26]，現(xiàn)在也有代碼覆蓋率來(lái)評(píng)估工具的效率之一，例如文獻(xiàn)[20]、[28]中就使用代碼覆蓋率來(lái)評(píng)估。

2.5 GGUUII測(cè)試技術(shù)的挑戰(zhàn)

Ozlem Muslu 提出了基于模型的GUI 測(cè)試用例生成的三大挑戰(zhàn)，狀態(tài)相等的判斷，狀態(tài)搜索，輸入之間的等待時(shí)間[29]。在Choudhary S Rdeng 等人[24]對(duì)目前研究存在有關(guān)移動(dòng)應(yīng)用的自動(dòng)化工具進(jìn)行對(duì)比研究，目的是為了驗(yàn)證當(dāng)前的自動(dòng)化工具是否實(shí)現(xiàn)自動(dòng)輸入技術(shù)，最后發(fā)現(xiàn)，我們的自動(dòng)化輸入可以實(shí)現(xiàn)，但是輸入的值并不能模擬用戶的真實(shí)輸入，只能是簡(jiǎn)單的隨機(jī)輸入而已。正如因?yàn)槊媾R這些挑戰(zhàn)，使得自動(dòng)化測(cè)試在實(shí)際工程中使用甚少。這一結(jié)果和Vasquez M L 等人[27]通過(guò)向移動(dòng)應(yīng)用測(cè)試工作者發(fā)送問(wèn)卷調(diào)查的方式來(lái)統(tǒng)計(jì)實(shí)際工業(yè)中的測(cè)試工程師依然采用測(cè)試手段，最后發(fā)現(xiàn)實(shí)際測(cè)試工程中測(cè)試工程師偏向于手工測(cè)試。在表4 的工具只有Monkey、MobiGUITAR 在實(shí)際中也得到一些測(cè)試工程師的青睞。

3 結(jié)語(yǔ)

本文從GUI 測(cè)試的定義，自動(dòng)化的測(cè)試框架、工具特別多，但是在實(shí)際工作中并沒(méi)有得到真正意義上的應(yīng)用，存在這一現(xiàn)象的原因是很多方面的，最突出的原因如下：

（1）測(cè)試工程師缺少自動(dòng)化相關(guān)的測(cè)試知識(shí)；

（2）當(dāng)前的自動(dòng)化工具缺乏相應(yīng)的使用文檔；

（3）工具的安裝環(huán)境比較復(fù)雜，安裝過(guò)程比較耗時(shí)。

為了滿足實(shí)際測(cè)試工作者的需求，我們需要研究出可行度極高的移動(dòng)應(yīng)用GUI 自動(dòng)化測(cè)試方法，使得測(cè)試工作者從測(cè)試工作中的某些階段逐漸解脫出來(lái)，把更多的精力放在更重要的測(cè)試階段中。

4 未來(lái)展望

按照目前的發(fā)展趨勢(shì)，未來(lái)的移動(dòng)應(yīng)用會(huì)呈現(xiàn)爆炸式增大，而我們的移動(dòng)應(yīng)用的GUI 測(cè)試實(shí)現(xiàn)自動(dòng)化是必然的趨勢(shì)，我們當(dāng)前使用到的隨機(jī)測(cè)試、基于模型的測(cè)試、錄制回放測(cè)試中，基于模型的測(cè)試被認(rèn)為是最具有研究?jī)r(jià)值的測(cè)試，而基于模型的測(cè)試難點(diǎn)在于模型的構(gòu)建上?，F(xiàn)有的MobiGUITAR[5]工具主要應(yīng)用于在模擬器上，構(gòu)建出的模型是映射到被測(cè)系統(tǒng)的控件上，其控件的有效性沒(méi)有進(jìn)行驗(yàn)證，另外，通過(guò)控件模型轉(zhuǎn)化為事件模型，最后再轉(zhuǎn)化為有限狀態(tài)機(jī)模型。接下來(lái)，通過(guò)遍歷模型得到的測(cè)試用例并沒(méi)有進(jìn)行測(cè)試用例約簡(jiǎn)和優(yōu)先級(jí)的排序。導(dǎo)致在有限的時(shí)間內(nèi)，測(cè)試用例的執(zhí)行力不高。這樣子就沒(méi)有滿足盡快盡早暴露被測(cè)系統(tǒng)的缺陷。而Stoat[20]工具構(gòu)建出的模型是隨機(jī)模型，然后根據(jù)隨機(jī)模型進(jìn)行遍歷，從一開(kāi)始的模型就不能真正映射到系統(tǒng)，所以Stoat 構(gòu)建出來(lái)的模型不能完全代表被測(cè)系統(tǒng)。因此，在未來(lái)的研究中，對(duì)于模型的自動(dòng)化構(gòu)建以及如何構(gòu)建出可以映射被測(cè)系統(tǒng)的模型是未來(lái)研究方向之一。