基于模型的移動應用功能場景自動標注方法

鄭曉梅，錢正軒，李 剛，王天舒

(1.南京中醫藥大學 人工智能與信息技術學院，江蘇 南京 210023；2.南京大學 計算機科學與技術系，江蘇 南京 210023；3.南京大學 計算機軟件新技術國家重點實驗室，江蘇 南京 210023)

0 引 言

隨著移動應用開發逐漸成為現代軟件開發的主流，移動應用模型的重要性也逐漸凸顯出來。移動應用的主要特點是事件驅動的設計方式，應用執行流程取決于用戶產生的事件，場景對應著應用功能，場景的理解對測試和軟件演化至關重要。

在對移動應用進行建模時，常見方法是人工對其進行測試，觸發盡可能多的事件跳轉。人工測試模型符合用戶使用邏輯，且執行腳本標注場景信息，但是成本較高。

現在流行的很多自動化測試工具，如UI Automator[1]、Monkey[2]、Appium[3]、Q-testing[4]等，它們接受人工編寫的腳本文件或是調用框架提供的接口，驅動在虛擬機或真機上運行的應用執行跳轉。這些自動化測試工具對移用應用進行建模會具有較高的探索度，模型的覆蓋度較高，但執行序列較為包含過多冗余路徑，且無場景信息。

本文提出一種基于模型的移動應用功能場景自動標注方法AFSLM，通過構造執行路徑模型反映測試腳本的執行過程，并基于該模型實現人工標注信息的泛化。該方法首先根據移動應用的相關屬性及其運行時的狀態信息，基于IFML(interaction flow modeling language)國際標準[5]構建了一個平臺無關的、抽象的概念模型——應用執行路徑(app running path，ARP)，用以保持對移動應用測試腳本的對應。以具有場景功能標簽的人工測試模型為基準，通過對布局文件進行相似性計算，找出機器測試模型中具有同樣場景的路徑集合，并標注相應的功能場景標簽，從而以較低的成本構建擁有較多信息尤其包含完整的功能場景信息，同時具有一定規模的移動應用模型庫。

AFSLM方法屬于移動應用界面場景理解[6-10]，該工作主要應用在測試腳本的重用和遷移、自動化測試工具等工作中。很多功能場景在設計之初就是具有連接性和依賴性的，這些功能的關聯均是通過界面間固有的跳轉關系連接，因此在功能場景分類中引入跳轉關系是有必要的，而以往的相關研究工作所提出的測試框架[4，11，12]均未考慮跳轉關系。文獻[11]所提出的測試框架，通過利用機器學習技術將應用程序界面分類成通用的功能場景，并重用這些通用功能場景的測試腳本以達到減輕手動功能測試的負擔的目標。文獻[12]同樣構建了一個自動化測試框架，該框架定義了一種新的測試腳本語言，該工作的亮點之一也是通過機器學習來對界面的功能場景劃分以確定界面的功能。該工作同樣認為控件的類型、數量、所處的位置區域對分類至關重要，并沿用了文獻[11]的屏幕分區方式和拓展了其特征提取方式。除了僅僅統計布局文件3個區域中可以點擊、滑動、編輯的控件數量之外，還增加了可聚焦的控件、類型為圖像文件的控件、可選中控件數量等，因此構造成了包含16個特征的特征向量。經過與Ariel的工作的對比實驗，該工作驗證了將拓展后的特征輸入到多類別的邏輯回歸分類器進行功能場景分類能夠得到更高的準確率。文獻[4]提出了一個基于強化學習的測試工具Q-testing，記錄測試過程中已經探索過的界面狀態并且通過判斷兩個狀態是否屬于同一個功能場景來決定在探索過程的獎勵，這就避免了在測試的一開始就局限在幾個相同的功能場景測試，引導工具向未探索的功能方向探索，能夠有效解決其它工具測試代碼覆蓋度較低的問題。

布局文件中提取控件的屬性信息是目前功能場景理解主要的方式，以往研究工作在場景判斷時主要通過的是單個UI的信息，而不同UI之間的跳轉關系并沒有得到充分利用。本文的研究工作增加了對UI跳轉關系的理解，進一步挖掘了可以利用的語義信息。

1 方法概要

這部分介紹AFSLM方法的整體框架，整體框架如圖1所示。

圖1 AFSLM方法整體框架

1.1 構建ARP模型

IFML是國際標準化組織OMG發布的一種圖形化建模語言，主要針對UI驅動類軟件的交互過程進行設計建模，其特點是以UI界面和交互元素為主要對象刻畫執行過程。本文工作主要參考了IFML的建模方式，并針對移動應用軟件的特點進行了定制，提出了ARP模型用于描述測試腳本所對應的執行路徑信息。

ARP模型刻畫了移動應用及其運行時的狀態，使用如下信息進行建模：①應用的元信息，包含應用的名稱、概要、版本、開發者等信息；②應用的狀態集合；③應用的執行路徑，執行路徑是一系列跳轉關系 ； ④應用的場景信息，即應用功能，它對應著一系列帶標注的路徑集合，路徑是跳轉的集合，標簽信息指示了該路徑屬于應用某個具體的功能場景，標簽信息也是本文方法需要自動標注(泛化)的對象。

構建ARP模型部分將人工測試模型及自動化測試模型，處理加工為統一格式的ARP模型便于后續進一步的處理。

1.2 圖遍歷

圖遍歷部分主要實現標簽泛化功能，其依賴兩個相似度判斷模塊，分別是針對狀態的狀態相似度模塊與針對狀態間跳轉的跳轉相似度模塊。在計算兩種相似度的前提下，圖遍歷模塊使用一種基于寬度優先搜索(breadth-first search，BFS)的方法尋找與給定場景路徑所匹配的子圖，然后使用深度優先搜索(depth-first search，DFS)得到子圖中的對應相應功能場景的所有路徑。

1.3 模型合并

模型合并部分接受ARP模型，將兩種來源的ARP模型合并為一個ARP模型，格式不變，對于不同來源的狀態會以不同的前綴進行標注區分，還會將圖遍歷模塊得出的場景路徑添加到合并后的新模型上。這些新的模型組成了移動應用有功能場景標注的模型庫。將狀態集合合并后，對于跳轉模型，引入一個新的偽狀態作為合并后的ARP狀態入口點，在偽狀態和原本模型的入口狀態間添加跳轉關系。

2 方法實現

該部分介紹AFSLM具體實現的細節，相應的工具原型是基于Python語言來編寫的可執行腳本。

2.1 實現構建ARP模型

在具體實現時，各個狀態附帶的信息可以通過文件系統組織，使用時以讀取文件的形式將其內容讀入內存即可。對于模型的跳轉關系，其內存形式本文選擇使用Python的第三方庫NetworkX實現，而持久化存儲則選擇JSON格式的文件。

圖2是一個有兩個節點的有向圖的JSON對象和Python代碼的表示方法，有向圖中有一條從狀態1指向狀態2的邊，其邊有兩個屬性：weight和time_sequence。

圖2 有向圖的兩種表示方法

構建ARP模型時，本文將應用狀態使用唯一序號進行標注，使用序號命名應用所對應的布局文件，然后將跳轉信息轉換成上述的JSON格式，狀態的序號作為圖的節點，跳轉關系作為圖的邊，而跳轉動作作為邊的附加信息，如果一對狀態間有多個跳轉，則不同的跳轉動作組織成一個列表。除此之外，本文還在預處理時篩去了跳轉模型中的自環，對于應用元數據和場景路徑等信息，也同樣處理為JSON格式的文件進行保存。工具運行時將JSON格式的跳轉模型讀入內存，轉換成Python中的字典格式，然后創建NetworkX有向圖對象。

該部分實現為一個單獨的腳本文件，調用后將原始數據轉換并輸出為預處理后的ARP模型，后續的工具主體將基于該輸出結果進行處理，這樣設計的靈感來自于編譯器前后端分離的思路，該部分要處理多種不同來源的模型數據，需要針對不同的情況進行修改或擴展，這種特性決定了該部分和后續的合并主體不能有過高的耦合度。解耦后可以將多種不同的ARP構建模塊與合并工具進行組合，使用時只需鏈式調用即可。

2.2 實現相似度算法

移動應用UI使用XML文檔作為布局的描述格式，現在主流移動應用自動化測試框架均提供工具用以在測試時動態查看當前的布局信息，并且可以將布局信息持久化為外存中的文件(通常同樣為XML格式)。持久化的動態布局信息可以作為ARP模型狀態的布局信息。

此前已經有不少工作探索了XML文檔的相似度計算，包括基于語義和結構的XML文檔相似度計算[13]、基于樹編輯距離下界的相似度估計[14]、基于有效路徑權重的XML匹配算法[15]等。本文實現了其中一些算法，并且針對UI布局文件的特殊性做出了針對性的調整，也統一了相似度算法模塊的接口，使得狀態相似度算法可插拔可配置，不同的方法接受相同形式的輸入參數，輸出在[0，1]區間內的相似度數值，這樣的設計使得無需修改泛化算法的其它部分即可方便地更換相似度算法。且只要封裝為統一的接口，就可以輕松地添加新的相似度算法。

另外，在ARP模型中，除了狀態本身附帶的信息，觸發狀態間跳轉動作的信息也是十分重要的。在進行場景標注的過程時，僅僅考慮狀態間的相似程度是不夠完善的，一條場景功能路徑同樣需要考慮到狀態間跳轉動作的匹配程度。本文提出并實現了一種較為簡單直觀的跳轉相似度判斷算法，通過對比跳轉動作的交互區域進行相似度判斷。

2.2.1 基于語義和結構的相似度判斷

文獻[13]所提出的基于語義和結構的XML文檔相似度判斷方法，該算法整體分為3個層級：①基于語義相似度與編輯距離計算節點間相似度，②基于動態規劃方法計算路徑的相似度，③將XML文檔分解成從根節點出發的路徑集合，基于路徑間的相似度計算路徑集合的相似度。本文針對布局文件的特殊性對于3個層級都做了相應的修改。

首先是節點間相似度，原算法計算的對象是自然語言文本，算法會將文本分詞后計算其語義相似度，同時計算文本的字符編輯距離相似度，取二者的最大值作為節點的相似度。布局文件XML樹的節點是組件，其本身除了屬性并沒有其它內容，組件屬性中text、content-desc、resource-id以及package幾個對相似度的判斷比較重要。計算節點相似度時，首先判斷兩個節點的class屬性與package屬性是否相同，如果不同則認為兩個組件相似度為0，如果相同則將text，resource-id，content-desc這3個屬性的值拼接為一個字符串，使用字符編輯距離相似度作為節點的相似度。

在計算路徑相似度時，原算法提出了一種基于最大相似子序列(maximal similar subsequence，MSS)的路徑相似度定義。算法提出XML文檔中距離根節點更加近的節點往往更能反映文檔的結構信息，因此在定義路徑相似度時加入了基于深度的衰減因子，然而對于布局文件來說，距離根節點更近的組件通常是容器而非具體的控件，對于兩個狀態布局來說，控件相比容器往往含有更多的信息，因此在實現路徑相似度算法時，本文去掉了這個衰減因子，使用最大相似子序列作為路徑相似度，具體實現采用動態規劃的方法。

對于XML文檔得到的路徑集合的相似度，本文直接使用了原算法的方法，并沒有進行額外的修改，最終輸出的相似度被歸一化至[0，1]區間內。

2.2.2 基于樹編輯距離下界的相似度判斷

樹編輯距離(tree edit distance)是一種衡量樹結構之間相似度的參數，與字符編輯距離類似，其定義為將一顆樹通過插入/刪除/替換轉換為另一顆樹所需要的最小操作次數。顯然樹編輯距離越小，兩棵樹越相似。文獻[14]提出可以通過多種方法估計樹編輯距離的下界，通過取這些方法得出的編輯距離的最大值，即可較好地逼近真實的樹編輯距離。

原算法首先提出可以通過將樹轉換為字符序列，然后以字符序列的編輯距離作為樹編輯距離的下界。由于樹編輯距離是以節點為單位進行操作，因此在將樹轉換為字符序列時，每個節點需要對應一個字符。其中text、resour-ceid、content-desc屬性并不是所有節點都有非空的值，package屬性取值范圍較小，而class屬性既能較好地反映布局的結構，又具有有限的取值范圍，因此本文選擇將每個節點的class屬性映射為一個字符，得到一棵部分程度上反映布局組件嵌套結構的樹，對這棵樹分別做前序遍歷與后序遍歷，得到的字符序列可以用于計算字符編輯距離，字符編輯距離的最大值即為樹編輯距離的一個下界。

除了上述基于字符編輯距離的方法，文獻中同樣提出3種基于直方圖的估算下界的方法，本文實現了其中基于葉距離直方圖和度直方圖的方法。本文同樣實現了文獻中提出的基于二叉距離的估算方法，該方法兼顧了樹的結構信息和內容信息。在判斷兩個界面之間相似度的方法上，本文參考了Q-testing[4]的方法，將代表界面結構的layout樹形結構文件內容，編碼為214維向量，并使用文獻[4]中的LSTM預訓練模型計算相似度，最后映射為一個[0，1]的值。

2.2.3 基于LSTM的相似度判斷

Q-testing[4]是一個基于強化學習策略的Android應用自動化探索的框架，其用馬爾可夫決策過程描述對Android應用的探索過程，使用Q-learning的策略指導探索應用的過程，可以在較短的時間內達到較高的覆蓋度。Q-testing工具調用原生的UI Automator框架驅動應用和獲取應用狀態信息。

在基于強化學習的自動化測試工具Q-testing中使用狀態的相似度作為強化學習策略的獎賞，驅動工具盡可能探索更多不同的狀態。

Q-testing使用LSTM模型抽取狀態的特征，對于狀態的布局樹，其遍歷樹中的每個節點，將組件的屬性編碼為長度214的向量，整棵樹會被編碼成214*100的矩陣(組件數不夠的用0做填充)作為LSTM的輸入，輸出一個長為100的特征向量，計算向量的L1距離可以得到兩個狀態的相似度。

在判斷兩個界面之間相似度的方法上，本文參考了Q-testing[4]的方法，將代表界面結構的layout樹形結構文件內容，編碼為214維向量，并使用文獻[4]中的LSTM預訓練模型計算相似度，最后映射為一個[0，1]的值。

2.2.4 跳轉相似度判斷

本文提出的跳轉相似度判斷算法，較為簡單直觀，通過比對跳轉動作的交互區域進行相似度判斷。

對于有交互區域的動作，模型會記錄下兩個坐標，分別代表交互區域的左上端點和右下端點。在比較兩個跳轉動作時，算法會首先嘗試通過正則表達式匹配的方式提取交互區域坐標，如果兩個動作都是有交互區域的，則比較其交互區域的重疊程度，算法會首先根據截屏文件對應的分辨率將兩個坐標歸一化到[0，1]區間，然后計算兩個區域的Jaccard Index，如式(1)所示

(1)

兩個區域相交的面積除以兩個區域相并的面積，這是一個常用的集合相似度判斷方法。Jaccard Index 會輸出一個[0，1]區間的結果，越接近1說明兩個區域重合程度越高。在實際實驗時，本文發現在實驗數據中會有兩個交互區域包含的情況，如果按照公式計算并不會得到很高的相似度分數，但是在觀察原始數據后，本文發現這往往是同一個交互動作，交互區域產生區別的原因是不同來源的建模數據會將同樣的操作定位到不同控件，一個常見的例子是點擊一個列表項，有些記錄會定位到外層的Linear-Layout，而有些記錄會定位到內層的TextView。

為了處理這種情況，本文額外添加了規則，如果兩個區域成包含關系，則認為其相似度為1.0。這也比較符合設計移動應用的原則與使用時的經驗，如果兩個交互區域包含，其通常可以觸發相同的交互動作，一個比較典型的例子是大部分App的設置界面有可開關的選項，點擊Switch控件/文字標簽或是點擊該選項的容器部分都能切換功能的開關。

對于沒有交互區域的動作，這些動作除了滑動外基本都是系統事件，如Android的3個虛擬按鍵：menu、back、recent apps，對于這些動作，本文選擇采用正則表達式將動作類型提取出來，然后比較其是否相同，如果相同則認為動作相似度為1.0，否則為0.0。

跳轉動作相似度算法(算法1)的偽代碼如下：

算法1：跳轉動作相似度算法

Input：兩個待比較的動作

Output：動作的相似度

(1) if 兩個動作都有交互區域 then

(2) 計算兩個動作交互區域的Jaccard Index

(3) if兩個交互區域成包含關系then

(4) return 1.0

(5) else

(6) returnJaccardIndex

(7) end

(8) else if 兩個動作均有交互事件 then

(9) if交互事件相同then

(10) return 1.0

(11) else

(12) return 0.0

(13) end

(14) else

(15) return 0.0

(16) end

由于跳轉模型中一對狀態間可能有多個跳轉動作，在實際計算時，會對兩個跳轉動作列表中的每對跳轉動作分別計算相似度，結果取所有相似度的最大值。

2.3 實現圖遍歷

圖遍歷部分實現了一種基于寬度優先搜索(breadth-first search，BFS)的圖遍歷算法，用于將人工測試路徑對應的場景功能標注泛化到ARP模型的無場景標注的跳轉模型中。算法分為兩個部分，遍歷算法主體——標簽泛化算法以及一個Wrapper。標簽泛化算法接受一個圖中的結點作為輸入，輸出一個以該節點為根的有向無環圖，該圖中的路徑即是算法判斷與場景路徑相匹配的路徑，標簽泛化算法(算法2)的偽代碼如下所示：

算法2：標簽泛化算法

Input：起始節點，跳轉模型，場景路徑

Output：匹配的子圖

(1)初始化隊列q, 將起始節點放入q;

(2) 初始化結果圖G;

(3) 初始化已訪問節點集合visited;

(4) fori∈[1,len(path)] do

(5) 初始化隊列temp;

(6)visited←visited∪q;

(7) foreachnode∈qdo

(8) 將node加入G;

(9) 獲取場景路徑從第i-1個狀態到第i個狀態的跳轉動作;

(10) 根據跳轉動作相似度與狀態相似度,調用算法3, 獲取下一跳的節點列表next_nodes;

(11)next_nodes←next_nodesvisited;

(12)foreachnext_node∈next_nodesdo

(13) 在G中加入邊(node, next_node);

(14) 將next_node放入temp;

(15)end

(16)end

(17) q←temp;

(18)end

(19)returnG

算法2使用一個隊列存儲當前待處理的節點列表，并且在獲取下一跳的節點列表時會篩去已經訪問過的節點，以確保結果圖是一個有向無環圖。算法2較為核心的是如何獲取下一跳節點列表的部分，該部分使用了上文提到的狀態相似度模塊與跳轉相似度模塊，獲取下一跳節點算法(算法3)的偽代碼如下所示：

算法3：獲取下一跳節點列表

Input：當前節點，跳轉模型，源跳轉動作，源節點，狀態相似度算法，相似度閾值

Output：下一跳節點列表

(1)初始化列表next_nodes;

(2)根據跳轉模型, 獲取當前節點的所有后繼結點succs;

(3)foreachsucc∈succsdo

(4) 根據跳轉模型, 獲取從當前節點到succ的跳轉動作;

(5) 調用算法1, 計算源跳轉動作與目的跳轉動作的相似度action_sim;

(6) 計算源節點與succ的狀態相似度state_sim;

(7) similarity←action_sim+state_sim;

(8)ifsimilarity≥相似度閾值then

(9) 將succ加入next_nodes;

(10)end

(11)end

(12)returnnext_nodes

在算法3中將狀態相似度算法作為參數在調用時傳入，針對不同的相似度算法，本文給出了不同的相似度閾值。遍歷得到結果圖后，會從根節點出發遞歸進行深度優先搜索(depth-firstsearch，DFS)，由于結果圖是一個有向無環圖，這個遞歸過程一定能夠結束。算法使用一個棧驅動DFS，這個棧同樣保存了從根節點出發到當前節點的路徑，當遍歷到沒有后繼的節點時(即標簽泛化算法推進到最后一步時加入圖的節點)，便認為得出了一條完整的路徑，會將此時的棧內容保存下來，最終輸出一個路徑的集合。

除了遍歷結束后的DFS，遍歷前也需要確定起始節點，標簽泛化Wrapper的功能就是在跳轉圖中選擇起始節點，并且對每個起始節點都運行一次泛化算法，然后對得到的結果圖進行遍歷得出路徑集合，最后將所有路徑的集合合并后輸出結果，標簽泛化Wrapper算法(算法4)的偽代碼如下所示：

算法4：標簽泛化wrapper

Input：跳轉模型，場景路徑

Output：路徑集合

(1) 初始化路徑集合 paths;

(2) 在跳轉模型中計算每個節點與場景路徑第一個節點的相似度, 取相似度從高到低前10個節點作為candidates;

(3)foreachcandidate∈candidatesdo

(4) 以 candidate 為起始節點, 運行標簽泛化算法(算法2);

(5) 對得到的結果圖, 進行DFS得到路徑集合 temp;

(6) 篩去temp中長度小于1的路徑(即只有一個節點的路徑);

(7) paths ← paths∪temp;

(8)end

(9)returnpaths

由于場景路徑標注是基于跳轉路徑的，因此會篩去結果中沒有形成路徑的輸出。在得到路徑集合后，會將場景標注根據輸出結果添加到合并后的跳轉模型對應路徑中。

基于以上方法，開發了支撐命令行和API調用的原型工具，圖3展示了原型工具，用以支持批量數據處理和工具鏈的構造。

圖3 AFSLM原型工具

3 實例研究

本文選擇開源Android應用WorldWeather作為研究對象，首先進行人工測試，然后將測試數據構建為ARP模型。在該模型中，本文選取了測試人員標注的一條場景路徑：0-17-25-26，這條路徑代表的功能場景是調整應用顯示溫度的單位(攝氏度/華氏度)(狀態0：起始狀態，狀態17：擴展菜單，狀態25：設置界面，狀態26：溫度單位設置)，標注的場景路徑如圖4所示。

圖4 人工標注的場景路徑

接下來，AFSLM工具會同樣地將機器遍歷得到的路徑信息構建為ARP模型，然后根據算法4得出需要遍歷的起始節點集合，如圖5所示。

圖5 獲取遍歷起始節點

在獲取了起始節點列表[62，16，0，1，8，58，59，15，23，49]后，工具會對列表中每個節點依次執行算法2，這里本文以節點8作為例子，繼續演示工具的運行流程。以節點8作為起始節點，工具會以寬度優先搜索的形式開始遍歷，由于給定場景路徑的長度為4，故該遍歷會向外推進3次。遍歷的過程中對于下一跳節點的選擇使用了相似度計算模塊的功能，具體細節參考算法1與算法3。為了避免遍歷結果圖產生環，本文在遍歷過程中記錄了已訪問的節點集合。

如圖6所示，工具對每個起始節點都會進行遍歷過程，得到機器跳轉模型的一個子圖，然后在子圖上進行深度優先搜索得到路徑集合。這里本文也挑選出一條路徑：8-5-6-25，展示其界面截屏與跳轉動作。每個節點在遍歷后都會得到一個對應的路徑集合，工具會篩去其中僅有一個狀態的路徑，然后將路徑集合合并至一個集合，輸出結果會傳遞給模型合并模塊，以在合并過程中進行標簽泛化。

圖6 圖遍歷模塊進行功能場景標簽泛化

模型合并部分讀取之前得到的兩個ARP模型，同時也讀取了圖遍歷模塊得出的場景路徑集合，然后將兩個ARP模型合并，并且將場景路徑標簽泛化到合并后的模型上去。在實際運行時一個人工模型會有不止一條標注過的場景路徑，本文在構建ARP模型后會對每條路徑進行上述的泛化過程，并且用源路徑的功能標簽和功能描述來標注得出的路徑集合，最后再進行模型合并，合并過程中將得出的所有結果路徑一次性泛化到合并的模型上。模型合并過程如圖7所示。

圖7 模型合并過程

4 實驗評估

本文設計了實驗用于測試所提方法的標簽泛化效果，并且通過配置不同的相似度判斷算法，測試不同的算法在時間、泛化效果等方面的表現差異。

本文選擇開源的Android用作為實驗的對象，一共收集了5個不同類型App的模型數據，每個App有3個版本的模型，其中有兩個版本由測試人員手動生成，測試人員使用Appium作為驅動測試的框架，使用UIAutomatorViewer獲取App布局文件，并且根據布局信息編寫相應的Python測試腳本。基于布局文件作為模型的狀態，基于測試腳本的定位和調用信息作為狀態間的跳轉。測試人員在測試的同時也給出了相應的場景標注信息，標注信息由功能標簽、功能描述以及對應的場景路徑組成。除此之外，每個App還有一個無標注的Q-testing工具探索模型。

將上述實驗數據進行預處理構建ARP模型，得到了15個不同的ARP模型。在10個人工生成的模型中，篩選出32條功能各異的場景路徑，路徑長度從2個狀態到6個狀態不等。實驗時選擇對每個人工模型，將其與對應的機器生成的模型合并，并且泛化該人工模型附帶的場景路徑標注信息，一共得到 10個合并后的ARP模型。另，本文實現了3種不同的狀態相似度判斷算法，實驗一共進行了3組，用以對比不同算法的表現差異。為了能定量分析工具的泛化效果，本文定義了算法的匹配得分。對于一條有n個狀態的場景路徑：①如果其泛化的某條路徑有m個狀態與該場景匹配，則路徑的得分為m/n。②該場景路徑泛化的所有路徑得分的均值即為場景路徑的得分。③所有32條場景路徑得分的均值即為該算法的匹配得分。實驗運行環境為Windows10，IntelCorei5 2.5GHz，結果數據見表1。

表1 實驗數據

針對該數據，本文設計了兩組研究問題，通過實驗數據得出結論：

(1)RQ1：面向場景的模型合并，AFSLM工具運行的結果是否能夠擁有更多場景路徑信息標注的模型？

以基于LSTM的相似度算法得出的數據為例，按照定義的評估標準，算法的匹配得分超過了0.8，且泛化后的路徑數有268條，遠超原本人工模型作為輸入的32條路徑。在泛化的路徑中，超過四成是完全匹配，匹配程度過低的路徑占比不超過6%。據此可以看出，AFSLM有較好的效果，能夠將現有模型的場景路徑標記通過合并的方式泛化到規模更大的無標注模型上去，得到含有更多場景標注信息的模型。

(2)RQ2：相似度算法差異，不同的相似度算法在運行時間，泛化效果等方面有怎樣的差異？

實驗中更換不同的相似度比較算法，進行了3組實驗用于對比其效果差異，可以看出基于樹編輯距離下界的方法和基于 LSTM 的方法效果較好。在控制了泛化算法與跳轉相似度算法不變的情況下，本文改變了狀態相似度算法，比較了不同算法在各個維度的表現差異，這同樣也體現了AFSLM工具的靈活性，在未來可以實現更多的針對不同場景的算法，根據需要進行配置使用。

5 結束語

本文針對移動應用功能場景識別的問題進行研究，提出了一種用于刻畫執行過程特點的ARP模型，在此基礎上設計了度量功能場景相似度的模型匹配算法，并提出了相應的功能場景自動化標注方法AFSLM，將人工標注的模型泛化到自動化工具探索的模型上，實現了對移動應用測試腳本中功能場景的自動化標注。基于所提出方法，開發了原型工具并進行了相應的實例研究及實驗評估，展示出方法的有效性。本文的創新之處主要在于，通過建立反映移動應用程序執行特點的ARP模型，并設計針對場景相似度的模型匹配算法，實現了對功能場景的識別和標注。

本文方法的核心部分是功能場景相似度度量算法，在下一步的工作中，將結合計算機視覺技術，對UI界面的外觀特點進行分析，用于提高度量算法的有效性，并選取更多的案例展開實驗。