作者簡介

Thales Fu，攜程高級研發(fā)經(jīng)理，致力于尋找更好的方法，結(jié)合AI和工程來解決現(xiàn)實中的問題。

引言

在快速迭代的軟件開發(fā)周期中，用戶界面（UI）的自動化測試已成為提高效率和確保產(chǎn)品質(zhì)量的關(guān)鍵。然而，隨著應(yīng)用程序變得日益復(fù)雜，傳統(tǒng)的UI自動化方法逐漸顯露出局限性。AI驅(qū)動的UI自動化出現(xiàn)了，但仍面臨著準確性和可靠性的挑戰(zhàn)。在這個背景下，本文提出一個創(chuàng)新的視角：通過實時調(diào)試技術(shù)，顯著提升AI編寫的UI自動化腳本的有效性。

這個問題不僅僅是技術(shù)上的挑戰(zhàn)，它關(guān)系到如何在保證軟件質(zhì)量的同時加速軟件的交付。本文將探討實時調(diào)試如何幫助AI更準確地理解和執(zhí)行UI測試腳本，以及這種方法如何能夠為軟件開發(fā)帶來革命性的改變。

一、UI自動化的現(xiàn)狀

從最初的記錄與回放工具到復(fù)雜的腳本編寫框架，UI自動化經(jīng)歷了顯著的發(fā)展。然而，盡管技術(shù)進步，傳統(tǒng)的UI自動化方法在應(yīng)對快速變化的應(yīng)用界面時仍然面臨諸多挑戰(zhàn)。

手動編寫測試腳本不僅效率低下，而且在應(yīng)用更新時需要大量的重新工作。據(jù)行業(yè)調(diào)查顯示，UI自動化測試腳本的維護可能占到整個測試工作的60%至70%。在一個典型的敏捷開發(fā)環(huán)境中，每次應(yīng)用更新可能需要超過100小時來重新編寫和測試現(xiàn)有的自動化腳本。這種高昂的維護成本凸顯了傳統(tǒng)UI自動化方法的低效性和資源消耗。

二、行為驅(qū)動開發(fā)BDD的引入

行為驅(qū)動開發(fā)（BDD）是一種敏捷軟件開發(fā)的實踐，它鼓勵軟件項目的開發(fā)者、測試人員和非技術(shù)利益相關(guān)者之間進行更有效的溝通。Cucumber是實現(xiàn)BDD方法論的一個流行工具，它允許團隊成員使用自然語言編寫明確的、可執(zhí)行的測試用例。

Cucumber使用一種稱為Gherkin的域特定語言（DSL），這種語言是高度可讀的，使得非技術(shù)背景的人員也能理解測試的內(nèi)容和目的。測試場景被寫成一系列的Given-When-Then語句，描述了在特定條件下系統(tǒng)應(yīng)該如何響應(yīng)。

例如，一個在線購物網(wǎng)站的購物車功能可能有如下的Gherkin場景：

這種方法通過使用自然語言描述功能，幫助技術(shù)和非技術(shù)團隊成員之間建立更好的理解和溝通。自然語言的測試場景也充當了項目文檔，幫助新團隊成員快速理解項目功能。讓非技術(shù)人員可以直接參與測試用例的編寫和驗證過程，確保開發(fā)工作與業(yè)務(wù)需求緊密對齊。

但是它也存在著局限性，盡管測試場景用自然語言編寫，每個步驟背后的實現(xiàn)（步驟定義）仍然需要技術(shù)人員使用編程語言來編寫。這意味著實現(xiàn)測試邏輯可能涉及復(fù)雜的代碼編寫工作。隨著應(yīng)用程序的發(fā)展和變化，維護和更新與之相對應(yīng)的測試步驟可能會變得繁瑣。特別是在UI頻繁更改的情況下，相關(guān)的步驟定義也需要相應(yīng)地進行更新。還有靈活性和適應(yīng)性限制：Cucumber測試腳本依賴于預(yù)定義的步驟和結(jié)構(gòu)，這可能限制測試的靈活性。對于一些復(fù)雜的測試場景，實現(xiàn)特定的測試邏輯可能需要創(chuàng)造性地規(guī)避框架的限制。

三、當前AI在UI自動化中的應(yīng)用

近年來，AI技術(shù)被集成到UI自動化中，特別是以GPT為代表的大模型出現(xiàn)后，因為它本身就有代碼生成能力。業(yè)界也開始試著通過大模型來直接把Gherkin的測試用例描述語言生成成測試代碼。

不過，當前大模型生成的測試代碼并不能完全達到預(yù)期，主要有幾個問題：首先，生成出來的腳本，因為語法錯誤可能無法運行；其次，也可能沒有準確的覆蓋到測試用例需要它去測試的校驗點。在我們的實踐下，真正能第一次就成功的比例不超過5%。

它生成失敗后，接著就需要人介入再進行一些補救的工作。包括：調(diào)試，修改用例重新生成，或者直接修改生成的腳本。

而這些工作本身也需要消耗不少的人力，和我們系統(tǒng)通過AI來自動生成測試腳本的初衷相違背。

四、AI全自動的來編寫有效的測試腳本

為了解決這個問題，我們重新思考了AI生成測試腳本的整個過程。

我們把人的工作也放在里面一起考慮。人在系統(tǒng)中做了調(diào)試和修改的工作，那這部分工作是不是可以讓AI來做呢，讓系統(tǒng)自己運行生成的代碼，讓AI來調(diào)試和修改自己生成的錯誤代碼。

因此，我們調(diào)整了系統(tǒng)設(shè)計，讓AI代替人自主地來做這些工作。最終，對于攜程酒店訂單詳情頁的全部用例，在無人參與的情況下，生成可以執(zhí)行成功的占全部的83.3%，在生成腳本過程中，有8%的case就已經(jīng)發(fā)現(xiàn)了Bug。我們連續(xù)生成這些用例三次，成功率分別在84.3%，81.4%和83.3%，系統(tǒng)是穩(wěn)定有效的。

具體的測試用例和代碼如下：

首先，需要滑動到訂單詳情頁下放的用戶權(quán)益模塊，然后點擊訂房優(yōu)化區(qū)域，來彈出價格浮層。

然后再看，費用明細里面是否包含黑鉆貴賓。

最終生成的測試代碼如下：

五、系統(tǒng)實現(xiàn)

整個系統(tǒng)的核心架構(gòu)示意圖如下。系統(tǒng)的核心部分是一個langchain框架的程序。它會去訪問大模型，我們給它配備了多個工具，主要分成兩類，一類是頁面信息的獲取工具，一類是調(diào)試工具。

Langchain會自動根據(jù)需要，使用頁面信息獲取工具，去拿頁面的數(shù)據(jù)，來判斷當前的操作需要具體哪個控件，來生成代碼。然后再使用調(diào)試工具在手機中真實的執(zhí)行代碼，基于調(diào)試的反饋來判斷自己生成的代碼是否正確。

5.1 提示詞

有了基本的架構(gòu)后，我們需要提示詞，來把這些工具粘合起來，讓AI理解它該如何工作。我們的提示詞從結(jié)構(gòu)上來說包含了幾部分內(nèi)容：首先告訴AI它該如何思考和工作，其次告訴它一定要通過Debug調(diào)試它每一句生成的語句，再次告訴它輸出格式是什么，最后是告訴AI要處理的完整用例文本。

對于告訴AI它該如何思考和工作，展開包含以下部分：首先看頁面有哪些模塊，我要操作的這個步驟應(yīng)該是哪個模塊，這個模塊里有哪些控件和組件，我當前要操作的是哪個控件或組件，我要操作的動作是什么，以及我可以用的特殊的語法是什么，然后生成語句。

5.2 調(diào)試工具

調(diào)試工具的本質(zhì)是通過adb工具遠程連接到手機上。連接后，我們就可以把AI生成的指令發(fā)送給手機去運行，并且讀取到運行后的結(jié)果給到AI，讓AI去判斷自己生成的指令是否正確。

5.3 頁面信息獲取工具

頁面信息獲取工具的最終目的是幫助AI判斷出，BDD的用例上面寫得要操作的內(nèi)容，它具體要操作的控件的ID是什么，有了ID才能基于ID生成后續(xù)的程序指令。而為了拿到ID，我們需要有個控件和組件庫，這個庫里面的核心是每個控件和組件的ID以及它們的描述。有了這兩項內(nèi)容后，才能幫助AI看了BDD用例后，基于控件的描述去猜需要的是哪個控件。

為了達到這個目的，我們建立了一個頁面控件庫。這個庫除了包含頁面上每個控件的ID和描述外，還包含了頁面和組件的關(guān)系，以及組件和控件的關(guān)系。能方便AI一步步的進行查詢。

而這個控件庫本身是基于我們通過job對代碼進行靜態(tài)分析來生成的。不過實際應(yīng)用中，因為頁面當前真正展示的控件會根據(jù)場景狀態(tài)的不同而不同，在某些場景下頁面上的控件會隱藏。因此頁面信息獲取工具會把頁面當前真實存在的控件和控件庫中查詢出來的控件做交集，從而獲取到當前頁面真實展示出的控件和它的描述信息。

5.4 進一步拆分AI

當做了這些工作后，AI基本上已經(jīng)可以把上面這張圖黃色的部分，也就是人的工作自動去做了。生成成功率也從5%提升到了55%，但是55%的成功率還是不夠的。

我們進一步分析了失敗的case。發(fā)現(xiàn)主要問題是AI的幻覺，雖然提示詞已經(jīng)比較詳細了，但是AI有時會沒有按照要求處理，有的時候會自己胡說八道。

我們的結(jié)論是，給AI的責任太多了，它要考慮的東西太多。倒不是說它的Token不夠，而是讓它做的事情太多，會遺忘，無法精準完成要求。因此我們考慮進行拆分，還是利用了langchain的function的功能，既然AI能通過工具去完成功能，那這個工具為什么本身不能也是個AI呢。

甚至還可以把它再進行拆分。

通過這些拆分，我們讓每一個AI需要考慮的工作變得更少更簡單，也讓它處理得更加精準，最終生成成功率提升到了80%以上。

六、后續(xù)的發(fā)展

當前，通過我們的工作，能讓AI在無人參與下以80%左右的成功率去生成自動化測試的代碼，很讓人振奮，但還有很多問題需要繼續(xù)去解決。

1）大模型的調(diào)用成本還是不低，是否有更好的辦法，更低的成本去完成工作。

2）當前還有些比較難處理的操作或者校驗，成功率80%還有不小的提升空間，以及目前最后還是需要人來復(fù)核生成結(jié)果。

3）除此之外，其他方面也都有提高的空間，值得我們繼續(xù)去完善。