2019年10月26日，由Testin主辦的第二屆NCTS中國云測試行業(yè)峰會在京召開，此次峰會以“AI+未來”為主題，匯聚來自國內(nèi)外測試領(lǐng)域的知名專家學(xué)者、領(lǐng)先企業(yè)決策者、高層技術(shù)管理者、媒體從業(yè)者等，共同探討高端云測試技術(shù)，幫助測試從業(yè)者了解最前沿行業(yè)趨勢，及最新的行業(yè)實踐。

[[283751]]

會上，北京大學(xué)計算機(jī)系博士李元春做《強(qiáng)化學(xué)習(xí)在自動測試中的應(yīng)用》主題演講。李元春介紹了關(guān)于GUI測試相關(guān)的研究并指出，“將強(qiáng)化學(xué)習(xí)應(yīng)用到GUI測試的難點主要是狀態(tài)的表示和獎勵函數(shù)的設(shè)計，即如何將交互界面中的圖像、文本等多模態(tài)特征進(jìn)行有效的編碼，以及如何將測試的目標(biāo)轉(zhuǎn)化成對測試輸入的獎勵。”

以下為李元春演講實錄：

各位同行大家好！很榮幸在這里分享我做的關(guān)于GUI測試相關(guān)的工作，我叫李元春。我研究的方向是移動應(yīng)用的隱私和安全，做隱私安全相關(guān)分析時，我經(jīng)常用到靜態(tài)分析或者動態(tài)分析的技術(shù)，在動態(tài)分析中，如何對應(yīng)用進(jìn)行動態(tài)的測試，使得應(yīng)用能夠覆蓋足夠多的代碼，觸發(fā)足夠多的隱私安全的敏感行為，直接決定了隱私安全分析結(jié)果的完整性。因此，接觸到GUI測試的研究方向，也做了微小的探索性工作。我今天和大家分享的內(nèi)容更多的是偏技術(shù)落地。

首先介紹一下GUI測試的背景，基于軟件的圖形界面，生成交互動作序列作為測試的用例。主要的應(yīng)用場景是兩種，一種是GUI的遍歷測試，即如何對軟件的功能進(jìn)行充分的探索，第二是功能測試，比如對一個應(yīng)用的登陸功能進(jìn)行測試，生成的測試用例可能就是輸入賬戶名，輸入密碼，點擊登陸。

根據(jù)這兩個場景，我分別使用深度學(xué)習(xí)和強(qiáng)化學(xué)習(xí)技術(shù)進(jìn)行了探索。

首先是基于深度學(xué)習(xí)的GUI遍歷測試。自動的GUI遍歷測試主要有兩種主流的策略，一種是隨機(jī)的策略，比如安卓的官方工具M(jìn)onkey就是隨機(jī)的策略，這些工具在測試應(yīng)用的時候是像猴子一樣看不懂應(yīng)用具體的GUI和代碼，生成完全與代碼內(nèi)容無關(guān)的測試用例。第二種是基于模型的策略，對代碼進(jìn)行靜態(tài)分析或動態(tài)分析，建立起一個模型，用這個模型去指導(dǎo)輸入。比如右邊的圖有一些學(xué)術(shù)論文中的工具，通過分析代碼的執(zhí)行路徑，用符號執(zhí)行求解路徑到達(dá)方式，這樣能生成一個更加有針對性的測試用例。這些方法的共同點，都是在測試的易用性和測試效率之間做一個權(quán)衡。比如Monkey就是追求易用性而犧牲效率，對任何應(yīng)用都可以快速的測試，但是缺點也特別明顯，隨機(jī)測試用例很難去解釋、拓展和重現(xiàn)。基于模型的策略，通過分析代碼，生成用例，主要缺點是需要對代碼進(jìn)行分析。現(xiàn)在很多應(yīng)用的代碼都特別復(fù)雜，有很多種語言混合，用了各種高級語言的特性，使得靜態(tài)分析難度很大。還有，黑盒測試時拿不到源代碼，或者代碼進(jìn)行了加密，這種情況下很難用基于模型的靜態(tài)分析的方法來做。現(xiàn)在主流的方法是在這兩者之間的平衡，同樣是基于模型生成測試用例，但這個模型不是對代碼進(jìn)行分析建模，而是對應(yīng)用執(zhí)行過程中界面轉(zhuǎn)換關(guān)系進(jìn)行建模，僅僅作為記憶的功能，在之后的生成測試用例的時候避免無效的輸入。

這就是剛才所說的第三種方法，常用的一種界面轉(zhuǎn)換圖的模型，比如在這個模型里面，每個節(jié)點都是界面的狀態(tài)，每一條邊都是狀態(tài)之間的轉(zhuǎn)換關(guān)系，構(gòu)造出這樣模型之后，可以對應(yīng)用進(jìn)行測試。右面的圖是我之前做的一個工具DroidBot，可以針對任意應(yīng)用，在黑盒情況下把界面轉(zhuǎn)換圖構(gòu)造出來。基于界面轉(zhuǎn)換圖，任何人可以編寫遍歷測試的策略，例如可以設(shè)計深度優(yōu)先，寬度優(yōu)先，隨機(jī)探測，或者啟發(fā)式規(guī)則等等。

然而，使用這些簡單的規(guī)則探索應(yīng)用功能的效率往往不高，算法往往無法快速地到達(dá)應(yīng)用中重要的界面和功能。我們想到一個很奇妙的點，當(dāng)進(jìn)行人工測試的時候，不管是真實的測試人員，還是用戶，他們雖然對代碼沒有任何理解，他們往往可以很高效的對應(yīng)用界面進(jìn)行探索。我們思考了一下其中的原因，主要是兩點，第一點，不同應(yīng)用的GUI交互模式是存在共性的，比如說不管什么應(yīng)用，都有一些搜索功能，很多應(yīng)用都是一個向下滑的瀑布式的信息流的結(jié)構(gòu)，就算是功能沒有相似性，交互模式也是有相似性的。第二個原因，很多人雖然之前沒有測試經(jīng)驗，但是使用過很多應(yīng)用，潛意識中學(xué)習(xí)到了各種各樣的交互模式。那么，我們想，能不能用機(jī)器學(xué)習(xí)的方法把人使用應(yīng)用的交互模式學(xué)出來，用這樣的交互模式形成機(jī)器學(xué)習(xí)模型，用這個模型去指導(dǎo)自動測試數(shù)的生成。當(dāng)然這里有很多挑戰(zhàn)，例如如何對軟件GUI的狀態(tài)和動作進(jìn)行機(jī)器表示；如何設(shè)計模型把GUI的這些交互模式進(jìn)行高效的捕捉等等。

基于這個想法，我們做了一個工作，叫Humanoid，主要架構(gòu)如下，首先在離線學(xué)習(xí)階段，假設(shè)收集了很多真實用戶的交互數(shù)據(jù)，這些交互數(shù)據(jù)不是來自于被測應(yīng)用，可以來自于任何應(yīng)用。在離線的用戶交互記錄數(shù)據(jù)里面進(jìn)行學(xué)習(xí)，把學(xué)出來的東西捕捉在交互模型里面，然后用這個模型不斷的去指導(dǎo)測試UI交互數(shù)據(jù)的生成。

這是我們在Humanoid如何解決交互界面狀態(tài)和動作表示的方法，把每一個UI狀態(tài)表示為一個UI的結(jié)構(gòu)圖，我們忽略了UI里面的圖像和文本信息，僅僅是每一個UI上面文本的區(qū)域是哪些，圖片的區(qū)域是哪些。這樣做的目的，可以在有限的數(shù)據(jù)里面收集到更多更簡化的UI特征，在機(jī)器學(xué)習(xí)的時候更容易被泛化。在表示交互動作的時候，我們是由兩個部分組成，第一是交互動作的類型，包括點擊，滑動、輸入等等。第二個元素是交互動作的位置，這個交互動作發(fā)生在界面上的位置，也是直接用X、Y坐標(biāo)來表示，但是往往需要把孤立用戶點擊的點，轉(zhuǎn)化成一個以這個點為核心的分布圖，在學(xué)習(xí)的時候，每一個數(shù)據(jù)點都不是孤立的而是分布的，更容易進(jìn)行學(xué)習(xí)。

有了上面的兩種表示之后，就明確了模型輸入和輸出之間的映射關(guān)系，當(dāng)前界面情境context，包含了當(dāng)面界面S，還有最近若干次交互。輸出是兩個概率分布，包括交互位置概率分布和交互動作類型概率分布，基于這兩個概率分布可以計算出每個交互動作的概率。

這是我們使用的深度學(xué)習(xí)模型用來捕捉界面情境和界面交互動作之間的關(guān)系，大家可以看到用了很多CNN捕捉界面上的圖像信息。我們使用了4個交互序列，除了當(dāng)前的交互界面狀態(tài)之外，還使用了之前的三次交互歷史，我們把這四個交互動作輸入一個LSTM，提取出界面交互特征之后，把這個特征重新映射到原來交互輸入上，要生成的交互動作位置的概率分布。

這是我們模型訓(xùn)練之后真實使用的偽代碼，測試的時候我們隨機(jī)的選擇進(jìn)行探索，或者對模型進(jìn)行利用，如果進(jìn)行探索，使用剛才的模型生成交互動作，然后執(zhí)行交互動作。如果是進(jìn)行利用的話，根據(jù)界面轉(zhuǎn)換圖導(dǎo)航回之前的某一個界面。

Humanoid實驗評估，我們使用的是Rico dataset，涉及很多用戶使用應(yīng)用時的交互記錄。我們用這些數(shù)據(jù)給UI轉(zhuǎn)換模型進(jìn)行訓(xùn)練。我們與6個代表性工具進(jìn)行對比，一個是Monkey，還有PUMA等。

學(xué)習(xí)交互模式的效果，這個模型能夠把真實用戶交互動作預(yù)測到更高的概率，我們的模型能夠把真實用戶使用的交互動作排到前面，說明我們的模型是有效學(xué)到了交互信息。把這個模型應(yīng)用到真實測試中，雖然這些測試工具之間的覆蓋率差異不是很大，但是Humanoid能達(dá)到最高的代碼行覆蓋率，對于市場流行應(yīng)用也能達(dá)到比較高的界面覆蓋率。這是Humanoid和其他工具進(jìn)行覆蓋率提升速度的評測結(jié)果，可以看到紅色的線是Humanoid的結(jié)果，它是能夠比較快的達(dá)到較高的覆蓋率，而且這個曲線還有繼續(xù)上漲的趨勢。

第二部分，基于強(qiáng)化學(xué)習(xí)進(jìn)行UI功能測試。先介紹UI功能測試的背景，我們的目的是生成一系列UI的交互動作，對軟件的特定功能進(jìn)行驗證，比如剛才舉的登陸的例子，測試用例第一行是open App，第二行是輸入一個電子郵件地址，下面一個代碼是在密碼框里輸入密碼，最后點擊登陸按鈕。人工編寫的測試用例是耗時耗力的，人工要手工進(jìn)行測試修復(fù)，這是有很大效率問題。右面展示了主流工具，人工測試的樣本，比如這個Sikuli工具，已經(jīng)把測試用例編寫變得很簡單了，但是對于沒有測試經(jīng)驗的，想寫這樣的代碼還是比較復(fù)雜的。我們想追求的目標(biāo)是，給定測試用例的文本描述，基于這個文本描述自動生成測試的腳本。比如對于Lyft/Uber網(wǎng)站，一個測試用例描述可能是“估算從某一個位置到另外一個位置的打車費用”，我們希望通過理解自然語言，以及理解軟件的交互界面，生成右下角這個測試腳本。在強(qiáng)化學(xué)習(xí)問題里面有一個測試執(zhí)行環(huán)境，這個測試執(zhí)行環(huán)境包括Web瀏覽器和Reward模型，還有一個強(qiáng)化學(xué)習(xí)的agent，與測試執(zhí)行環(huán)境進(jìn)行交付，最后得到最終的測試腳本。

強(qiáng)化學(xué)習(xí)里面很重要的一個就是強(qiáng)化學(xué)習(xí)環(huán)境environment，強(qiáng)化學(xué)習(xí)環(huán)境給定執(zhí)行任務(wù)的初始狀態(tài)，告訴模型agent當(dāng)前狀態(tài)下可以執(zhí)行哪些動作，當(dāng)agent在當(dāng)前狀態(tài)中執(zhí)行一個動作，返回該動作的獎勵reward和新的狀態(tài)。將強(qiáng)化學(xué)習(xí)應(yīng)用到GUI測試的難點主要是狀態(tài)的表示和獎勵函數(shù)的設(shè)計，即如何將交互界面中的圖像、文本等多模態(tài)特征進(jìn)行有效的編碼，以及如何將測試的目標(biāo)轉(zhuǎn)化成對測試輸入的獎勵。在測試中，agent觀察到的狀態(tài)就是當(dāng)前界面UI結(jié)構(gòu)，可執(zhí)行的動作就是當(dāng)前界面中所有可行交互輸入的集合，測試環(huán)境需要允許agent執(zhí)行一個動作，返回對于該動作的獎勵。設(shè)計強(qiáng)化學(xué)習(xí)環(huán)境的獎勵機(jī)制（reward function）的時候，設(shè)計目標(biāo)是給正確的動作序列賦予更高的Reward，這樣強(qiáng)化學(xué)習(xí)才可以找到正確的測試用例。我們這里的觀察是，如果一個交互動作序列是正確的測試用例，一般滿足以下三個指標(biāo)：一個是動作應(yīng)該是和任務(wù)參數(shù)匹配的。比如我剛才說的A到B，兩點的打車費用，AB就是這個任務(wù)的參數(shù)，我們肯定有兩個動作跟這兩個參數(shù)是相匹配的。第二是UI的文本和描述的句子是重合的。第三是動作序列需要符合真實用戶的交互習(xí)慣，比如生成測試用例的時候，不能說在頁面底部點一下，中間點一下，跳來跳去的，這樣很有可能是不正確的，我們需要加一些約束，使得測試的時候agent可以對UI進(jìn)行正確的交互。

現(xiàn)在主流的用強(qiáng)化學(xué)習(xí)算法之一是Q network，用深度神經(jīng)網(wǎng)絡(luò)估計一個Q函數(shù)，Q函數(shù)以當(dāng)前狀態(tài)s和選取的動作a為參數(shù)，返回當(dāng)前狀態(tài)s下執(zhí)行動作a的價值。在我們的模型中，把狀態(tài)s和交互動作a，分別提取圖像信息和文本信息，并進(jìn)行交叉融合，作為Q network的輸入，，最終去估算Q值。

這是強(qiáng)化學(xué)習(xí)算法最終生成的樣例，從A到B打車費用的測試用例，可以生成三個腳本，每個腳本都有一些最終的Reward分值。

我們對基于強(qiáng)化學(xué)習(xí)的測試輸入生成方法進(jìn)行了評估，選取了十大類網(wǎng)站，一共73個網(wǎng)站，在這些網(wǎng)站上定義了41個測試描述，比如“在波士頓預(yù)訂一個下午8點四人的桌子”就是一個測試用例描述，把這些作為測試用例，然后就得到了172個測試用例描述和網(wǎng)站的組合，我們的目標(biāo)是對于每一個組合生成一個測試腳本。最后我們評估的時候，讓我們的強(qiáng)化學(xué)習(xí)算法針對每一個測試用例描述和網(wǎng)站跑一小時，得到最高的交互訓(xùn)練，然后進(jìn)行人工評估。

這是我們最后評估的結(jié)果，top 1的準(zhǔn)確率是65.7%，top 5的準(zhǔn)確率是76.6%，我們與常見的搜索算法進(jìn)行了比較，能夠看到強(qiáng)化學(xué)習(xí)能達(dá)到比較高的優(yōu)勢。

最后總結(jié)一下，雖然將深度學(xué)習(xí)和強(qiáng)化學(xué)習(xí)應(yīng)用于測試有廣闊的前景，但是目前想要達(dá)到大規(guī)模實用還有很長的路要走。其難點包括：首先測試這個問題本來就是十分復(fù)雜的，目前的深度學(xué)習(xí)主要是拿圖片或者文字作為輸入，而UI是更為復(fù)雜的一種信息，既有視覺信息又有文本信息，現(xiàn)在沒有特別好的模型或方法去捕捉UI上的特征。第二個問題，強(qiáng)化學(xué)習(xí)算法成功的領(lǐng)域往往都是游戲，例如強(qiáng)化學(xué)習(xí)可以把圍棋解決得很好，一個重要的原因是，在游戲領(lǐng)域，Reward是比較明確的，但是在測試?yán)锩妫朐u估一個測試用例是好是壞，沒有一個準(zhǔn)確的指標(biāo)，最后評估下來，每一個測試用例，不管是正確的還是錯誤的，得到的Reward都是非常相近的，這就導(dǎo)致強(qiáng)化學(xué)習(xí)模型很難區(qū)分正確和錯誤。要解決這些問題，一方面也有研究挑戰(zhàn)，一方面也有很多工程問題要解決，需要學(xué)術(shù)界和產(chǎn)業(yè)界共同努力去解決。

今天要演講的內(nèi)容就是這些，謝謝大家！