作者簡(jiǎn)介

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

引言

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

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

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

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

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

二、行為驅(qū)動(dòng)開(kāi)發(fā)BDD的引入

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

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

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

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

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

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

近年來(lái)，AI技術(shù)被集成到UI自動(dòng)化中，特別是以GPT為代表的大模型出現(xiàn)后，因?yàn)樗旧砭陀写a生成能力。業(yè)界也開(kāi)始試著通過(guò)大模型來(lái)直接把Gherkin的測(cè)試用例描述語(yǔ)言生成成測(cè)試代碼。

不過(guò)，當(dāng)前大模型生成的測(cè)試代碼并不能完全達(dá)到預(yù)期，主要有幾個(gè)問(wèn)題：首先，生成出來(lái)的腳本，因?yàn)檎Z(yǔ)法錯(cuò)誤可能無(wú)法運(yùn)行；其次，也可能沒(méi)有準(zhǔn)確的覆蓋到測(cè)試用例需要它去測(cè)試的校驗(yàn)點(diǎn)。在我們的實(shí)踐下，真正能第一次就成功的比例不超過(guò)5%。

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

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

四、AI全自動(dòng)的來(lái)編寫有效的測(cè)試腳本

為了解決這個(gè)問(wèn)題，我們重新思考了AI生成測(cè)試腳本的整個(gè)過(guò)程。

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

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

具體的測(cè)試用例和代碼如下：

首先，需要滑動(dòng)到訂單詳情頁(yè)下放的用戶權(quán)益模塊，然后點(diǎn)擊訂房?jī)?yōu)化區(qū)域，來(lái)彈出價(jià)格浮層。

然后再看，費(fèi)用明細(xì)里面是否包含黑鉆貴賓。

最終生成的測(cè)試代碼如下：

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

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

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

5.1 提示詞

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

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

5.2 調(diào)試工具

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

5.3 頁(yè)面信息獲取工具

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

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

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

5.4 進(jìn)一步拆分AI

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

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

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

甚至還可以把它再進(jìn)行拆分。

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

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

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

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

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

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