透過即時調試，讓AI編寫有效的UI自動化

作者简介

Thales Fu，携程高级研发经理，致力于寻找更好的方法，结合AI和工程来解决现实中的问题。

引言

在快速迭代的软件开发周期中，用户界面（UI）的自动化测试已成为提高效率和确保产品质量的关键。然而，随着应用程序变得日益复杂，传统的UI自动化方法逐渐显露出局限性。AI驱动的UI自动化出现了，但仍面临着准确性和可靠性的挑战。在这个背景下，本文提出一个创新的视角：通过实时调试技术，显著提升AI编写的UI自动化脚本的有效性。

这个问题不仅仅是技术上的挑战，它关系到如何在保证软件质量的同时加速软件的交付。本文将探讨实时调试如何帮助AI更准确地理解和执行UI测试脚本，以及这种方法如何能够为软件开发带来革命性的改变。

一、UI自动化的现状

UI自动化经历了长足的发展，从最初简单的记录与回放工具发展到如今的复杂脚本编写框架。尽管技术不断进步，但传统的UI自动化方法在处理快速变化的应用界面时仍面临挑战。随着应用程序变得更加复杂和动态，传统方法可能无法满足需求。因此，工程师们正在寻找更灵活、可靠的解决方案来提高UI自动化的效率和可靠性。新一代的UI自动化工具和技术不断涌现，以

根据行业调查结果显示，手动编写测试脚本效率低下，而且在应用更新时需花费大量时间进行重新工作。调研显示，维护UI自动化测试脚本可能占整个测试工作的60%至70%。在敏捷开发环境中，每次应用更新可能要花费超过100小时来重新编写和测试现有的自动化脚本。这种高昂的维护成本凸显了传统UI自动化方法的低效性和资源消耗。

二、行为驱动开发BDD的引入

行为驱动开发（BDD）是一种敏捷软件开发的实践，它鼓励软件项目的开发者、测试人员和非技术利益相关者之间进行更有效的沟通。Cucumber是实现BDD方法论的一个流行工具，它允许团队成员使用自然语言编写明确的、可执行的测试用例。

Cucumber使用一种名为Gherkin的领域特定语言（DSL），这种语言极易阅读，使得非技术人员也能理解测试的目的和内容。测试场景以一系列Given-When-Then语句的形式书写，清晰地描述了系统在特定条件下应该做出何种响应。

例如，一个在线购物网站的购物车功能可能有如下的Gherkin场景：

這種方法利用自然語言描述功能，促進技術和非技術團隊之間更好的溝通和理解。同時，自然語言測試場景也扮演了專案文件的角色，幫助新團隊成員快速了解專案功能。這使得非技術人員能夠直接參與測試案例的編寫和驗證過程，確保開發工作與業務需求緊密契合。

但它也存在著局限性，儘管測試場景用自然語言編寫，每個步驟背後的實作（步驟定義）仍然需要技術人員使用程式語言來編寫。這意味著實現測試邏輯可能涉及複雜的程式碼編寫工作。隨著應用程式的發展和變化，維護和更新與之相對應的測試步驟可能會變得繁瑣。特別是在UI頻繁更改的情況下，相關的步驟定義也需要相應地進行更新。還有靈活性和適應性限制：Cucumber測試腳本依賴預先定義的步驟和結構，這可能會限制測試的靈活性。對於一些複雜的測試場景，實現特定的測試邏輯可能需要創造性地規避框架的限制。

三、當前AI在UI自動化中的應用

近年來，AI技術被集成到UI自動化中，特別是以GPT為代表的大模型出現後，因為它本身就有程式碼產生能力。業界也開始試著透過大模型來直接把Gherkin的測試案例描述語言產生成測試程式碼。

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

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

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

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

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

#

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

因此，我們調整了系統設計，讓AI取代人自主地做這些工作。最終，對於攜程酒店訂單詳情頁的全部用例，在無​​人參與的情況下，生成可以執行成功的佔全部的83.3%，在生成腳本過程中，有8%的case就已經發現了Bug。我們連續產生這些用例三次，成功率分別在84.3%，81.4%和83.3%，系統是穩定有效的。

具體的測試案例與程式碼如下：

首先，需要滑動到訂單詳情頁下放的用戶權益模組，然後點擊訂房優化區域，來彈出價格浮層。

然後再看，費用明細裡面是否包含黑鑽貴賓。

最終產生的測試程式碼如下：

五、系統實作

整個系統的核心架構示意圖如下。系統的核心部分是一個langchain框架的程式。它會去訪問大模型，我們給它配備了多個工具，主要分成兩類，一類是頁面資訊的獲取工具，一類是調試工具。

Langchain會自動根據需要，使用頁面資訊來取得工具，去拿頁面的數據，來判斷目前的操作需要具體哪個控件，來產生程式碼。然後再使用調試工具在手機中真實的執行程式碼，基於調試的回饋來判斷自己產生的程式碼是否正確。

5.1 提示詞

##有了基本的架構後，我們需要提示詞，來把這些工具黏合起來，讓AI理解它該如何運作。我們的提示詞從結構上來說包含了幾部分內容：首先告訴AI它該如何思考和工作，其次告訴它一定要透過Debug調試它每一句生成的語句，再次告訴它輸出格式是什麼，最後是告訴AI要處理的完整用例文字。

對於告訴AI它該如何思考和工作，展開包含以下部分：首先看頁面有哪些模組，我要操作的這個步驟應該是哪個模組，這個模組裡有哪些控制項和元件，我目前要操作的是哪個控製或元件，我要操作的動作是什麼，以及我可以用的特殊的語法是什麼，然後產生語句。

5.2 偵錯工具

##偵錯工具的本質是透過adb工具遠端連接到手機。連線後，我們就可以把AI產生的指令傳送給手機運行，並且讀取到運行後的結果給到AI，讓AI去判斷自己產生的指令是否正確。

5.3 頁面資訊取得工具

#頁面資訊取得工具的最終目的是協助AI判斷出，BDD的用例上面寫得要操作的內容，它具體要操作的控制項的ID是什麼，有了ID才能基於ID產生後續的程式指令。而為了拿到ID，我們需要有個控制和元件庫，這個庫裡面的核心是每個控制項和元件的ID以及它們的描述。有了這兩項內容後，才能幫助AI看了BDD用例後，基於控制項的描述去猜需要的是哪個控制項。

為了達到這個目的，我們建立了一個頁面控制項庫。這個庫除了包含頁面上每個控制項的ID和描述外，還包含了頁面和元件的關係，以及元件和控制項的關係。能方便AI一步步的進行查詢。

而這個控制項庫本身是基於我們透過job對程式碼進行靜態分析來產生的。不過實際應用程式中，因為頁面目前真正展示的控制項會根據場景狀態的不同而不同，在某些場景下頁面上的控制項會隱藏。因此頁面資訊取得工具會把頁面目前真實存在的控制項和控制項庫中查詢出來的控制項做交集，從而取得到目前頁面真實展示出的控制項和它的描述資訊。

5.4 進一步拆分AI

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

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

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

甚至可以再把它分割。

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

六、後續的發展

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

1）大模型的呼叫成本還是不低，是否有更好的辦法，更低的成本去完成工作。

2）目前還有些比較難處理的操作或是校驗，成功率80%還有不小的提升空間，以及目前最後還是需要人來複核產生結果。

3）除此之外，其他方面也都有進步的空間，值得我們繼續去完善。

以上是透過即時調試，讓AI編寫有效的UI自動化的詳細內容。更多資訊請關注PHP中文網其他相關文章！