如何讓AI幫你做前端自動化測試？我們這樣落地了

阿里妹導讀

本文介紹了一個基於AI的UI自動化測試框架在專有云質量保障中的工程化實踐。

引言

隨著AI大模型技術的快速發展並在各行業/場景下的爆發式應用，如何利用AI技術提高測試效率也成為了熱門話題。具體到我們團隊的日常工作中，一個痛點就是前端測試很耗費人力，體現在：

1. 前端用例自動化率低/無自動化，每個版本、每輪測試依賴手工執行，在多版本、快速迭代的背景下就會導致覆蓋不足，漏到客戶現場的前端缺陷多

2. 前端自動化實現門檻高、且維護成本大，在版本快速迭代的背景下，前端頁面更新換代很快，會出現一個版本花大力氣實現的自動化用例，在下個版本因為前端元素變動導致無法執行，還需要繼續投入大量人力進行適配的情況

藉助AI的能力，讓解決這一痛點成為了可能，也即本文將要介紹的“基於AI的UI自動化測試框架”在專有云質量保障的工程化落地。

核心原理

技術棧

框架主要使用了開源的browser-use[1]工具，此外主要使用瞭如下技術棧：

playwright[2]：用於前端操作、元素判斷，browser-use也是使用它實現的
pytest[3]：用例管理和排程
allure[4]：測試報告生成
大模型選用的是qwen-max

架構

框架圖

主要包括：

後端服務層，用於提供服務給外部呼叫或整合，如web server、cicd
框架管理層，主要完成用例的管理和排程
測試用例層，主要為用例自動化需要用到的各個模組

流程圖

主要分為三個部分：

1. 測試任務的管理、排程、結果展示部分，即左上部分；

2. 測試用例的編寫、維護、管理部分，即右上部分；

3. 測試執行的執行時管理部分，即下半部分；

實現機制

1. 自然語言驅動的測試用例

測試用例的編寫採用yaml格式，將測試步驟以自然語言的方式編寫為用例，框架會讀取並分步以prompt提示詞的形式與大模型互動，轉換為具體的action呼叫。下面是一個簡單的VPC建立用例：

testType: ascmtestName: create_vpc_uniquetestId: 74****98, 74****3testDescription: 使用預設引數建立VPCpreSteps: - common/product/ascm/login.yamltestSteps: - task: 開啟"{{ ASCM_URL }}/vpc/console/vpcPage?{{ DEFAULT_ORG_ID }}" - task: 點選“建立專有網路”按鈕# {{ VPC_NAME_UNIQUE }} 為用例自定義變數，參見py檔案 - task: 在“專有網路名稱”輸入框輸入“{{ VPC_NAME_UNIQUE }}” - task: 點選“提交”按鈕

其中的重點在preSteps和testSteps：

preSteps也即用例的前置步驟，並不是當前測試所關心的內容，因此可以引用common/product下的公共檔案，比如示例中就是ascm登入操作；引用的檔案也是以yaml形式組織的原子類/公共類步驟，實際執行為重放的方式（見後文），框架會遞迴解析並判斷是否有迴圈引用
testSteps為當前測試需要執行的步驟，也即大模型能直接看到的提示詞，因此用例的編寫實質上轉換為提示詞工程(PE)，如何讓大模型準確的理解需求並完成操作，是實現用例自動化的要考慮的核心問題另外task中的“{{ }}”為Jinja2格式的變數，框架會根據用例的實際執行環境，替換為對應的值，支援全域性層面已定義好的變數、用例自定義使用到的變數

關於提示詞的組織原則，以及具體的實現原理，內容較多，後續會單獨寫一篇進行分析。

2. 動態元素定位

在傳統的UI自動化實現中，一般會根據頁面的xpath、css selector等方式，定位到具體元素然後進行後續操作。這也是維護成本高的一個主要原因，因為一旦頁面排布發生變化，用例就無法執行。 browser-use在這裡有較大的優勢，它的穩定性好，是決定我們技術選型的一個重要因素。具體機制為：

browser-use會抓取當前頁面存在的元素，並以文字方式組織成大模型能理解的內容，同時若大模型具備視覺能力，也會將當前截圖一併提供，便於大模型識別和決策出使用者需要操作的元素是什麼。因此只要提示詞足夠準確，在頁面內容沒有翻天覆地變化的情況下，均可以動態定位到具體元素
在大模型決策出使用的action和操作的元素後，這部分元素資訊會被儲存下來用於後續回放執行時的輔助定位。主要包括元素的xpath、attributes和完整的parent層級，在回放執行中，若當前頁面元素的index編號與前述執行不一致，會根據儲存的資訊進行頁面遍歷搜尋，然後更新為新找到的index編號來操作

3. 執行回放與自適應更新

使用AI的過程中有兩個問題是必須要考慮的：

1. token使用量，在大量的測試用例自動化之後，多個環境、多個版本執行，會發起大量的大模型互動、消耗大量token

2. 大模型進行分析決策的速度問題，也即速度、效果、價格不能兼得，同時過程中會伴隨著較多網路互動，也會影響用例的執行速度

基於這兩個問題，框架支援了測試回放能力，即大模型決策生成的action呼叫和引數儲存為json檔案，在測試排程執行的時候，優先會執行json檔案中內容的回放，這裡完全不涉及大模型呼叫，並且用到了2中提到的index更新能力；若回放失敗，再呼叫大模型執行，同時更新json檔案為新生成的內容。

4. 斷言機制

browser-use的設計目的是利用AI能力，分析使用者給出的task並規劃出相應操作瀏覽器的行為直至完成task。顯然它是以目標為導向，自動化完成任務的一個工具，並不是天然為自動化測試設計的工具，所以它缺少測試需要的最關鍵一環，也就是斷言。測試框架補充了這一部分，在對應的task執行後，能夠對當前瀏覽器頁面進行元素抓取和結果判斷。框架設計上支援3種斷言能力，當前已實現2種，1種實現中：

1. playwright原生斷言能力，同樣以前述建立VPC用例為例，最後一個task裡可以這麼寫：

- task: 點選“提交”按鈕 expected: - type: playwright locator: get_by_text("操作成功", exact=True) method: to_be_visible()

此處type告訴框架為playwright斷言、locator為playwright的page locator支援的所有方法[5]、method為locator支援的所有expect assertion方法[6]這種方式的優點是即開即用，斷言嚴格且準確，適合需要精確判斷的用例場景

2. 用例自定義斷言能力，type值改為validator，由測試用例自己實現validator函式並解析後續的yaml expected欄位，以進行用例定製化的判斷

3. 大模型斷言（實現中），type值改為ai，呼叫大模型能力，對自然語言進行解析，結合當前頁面元素、截圖進行判斷，可能存在不穩定性

實施過程中的挑戰與解決方案

在框架的開發、用例實現和除錯過程中，遇到了比較多的問題，這裡挑幾類典型問題及其應對方案進行介紹

1. 大模型幻覺問題

使用AI能力，就避免不了大模型產生幻覺，這是由大模型的機率特性所決定的。具體來講，我們遇到了這幾個問題：

對action產生幻覺

雖然系統提示詞中寫明瞭"Don't hallucinate actions"，大模型不會返回不存在的action，但在規劃出具體應該使用什麼action以及當前狀態上，會出現和步驟task目的不匹配的情況。特別是在頁面出現異常的場景下（如未完全載入成功），大模型會嘗試使用scroll_down、go_back等多種action來操作，導致最終任務失敗。解決方案採用瞭如下兩種：

task拆分，在測試用例編寫規範中，我們指明瞭很多規則，其中幾條可以改善這個情況，如：task本身完成的任務要儘可能簡單和明確、如果task過於複雜則需要拆分為多步、如果上一個操作執行後頁面元素會變化，則需要將後續操作拆分到下一個task中，以強制大模型更新當前狀態
大模型最大步驟限制，browser-use預設的設定是100，它的設計是希望大模型能從使用者給出的任何目標中規劃出具體步驟並以迭代的方式執行直至最終達成目標。這顯然不適用於測試步驟，而且從用例編寫上，我們不希望每一步太複雜，因此規劃出的action不應該太多，經過除錯，這個數字我們限制在了3，即一旦一個測試步驟沒有在3個action以內達成，則認為此步驟失敗

對task目標產生幻覺

在某些測試步驟task已經完成後，會出現大模型繼續決策產生幻覺action呼叫的情況，進而導致非預期的狀態，影響後續task。這個問題與task本身的內容關係較大，但無法歸納出哪些情況下會出現。好在框架本身設計上就是使用的browser-use的follow up task能力，將測試用例分步驟提供給大模型的，因此在每個task提示詞之後，框架預設加上了“… and done”，引導大模型在決策出對應的action後，再加上“done” action。由於系統提示詞中指明瞭“Use the done action as the last action as soon as the ultimate task is complete”，結合起來就能較穩定的避免task幻覺問題，下面是一個常見的task規劃結果：

"action":[{"click_element_by_index":{"index":264}},{"wait":{"seconds":1}},{"done":{"text":"Clicked on the 'VPC ID:vpc-ad7*******j9ap' link and waited for 1 second, task completed.","success":true}}]

對斷言產生幻覺

框架中的斷言模組利用了browser-use的custom action能力，即擴充套件了大模型可以使用的function_calling tools。大模型看到task中需要進行斷言時，會決策呼叫框架的expected action處理。實際使用中會出現兩種非預期情況：大模型返回的決策結果中實際沒有呼叫、斷言失敗後大模型誤認為task沒有完成而繼續執行其它操作。

解決這兩種情況依然是要從提示詞入手，browser-use支援對系統提示詞進行修改，即Override和Extend兩種方式。框架採用的當然是Extend，browser-use的系統提示詞是經過大量測試的，Override可能會導致很多穩定性問題。在系統提示詞中，我們增加了如下章節：

REMEMBER the most important RULE:1. ALWAYS use 'expected' tool with the provided expected stringin the task2. If 'expected' action isnot success, just stop the task and done with the message

2. browser-use與測試場景的適配

前文也有提到，browser-use的設計目的和我們工程化要應用的測試場景，還是有一些偏差的，在使用的過程中主要遇到兩種問題：

browser-use本身的缺陷和不足

我們遇到了諸如設定keepalive為True之後browser資源無法銷燬、點選元素跳轉到新tab後元素抓取仍然在原tab中進行等缺陷。有些缺陷在新版本的browser-use中修復了，有些還沒有。依賴browser-use本身的版本迭代無法滿足我們的需求，因此框架層面直接將browser-use的核心物件派生後進行定製化修改。一方面可以快速修復發現的問題，這裡的修復可能是直接解決問題、也可能是透過適配繞開問題；另一方面可以在已有功能的基礎上，開發我們需要的功能，如agent run方法的前後置hook介面，在history rerun時不支援，我們進行了補充，進而實現了每個測試步驟之後都能自動截圖等功能，且大模型呼叫和回放執行效果一致。這種方式避免了直接修改browser-use原始碼，因此後續升級browser-use版本不會存在衝突問題，同時又能享受開源社群貢獻的成果。

測試場景需要的能力缺失

我們的主要目的是實現UI自動化測試，browser-use並不能完成所有事情，因此在框架層面，對缺失的能力進行了補充實現，並完成了與browser-use功能的結合，主要為：

斷言能力，前述章節已經介紹了相關機制，這裡不再贅述；
測試排程和執行發起能力，利用了我們團隊比較成熟的後端自動化框架經驗，使用pytest進行了實現，並接入了現有的IAAS Test測試平臺；
測試報告生成和展示，使用allure進行實現，同時結合了基於browser-use定製化的一些能力，下面是一個測試報告示例。

3. 頁面元素識別問題

在測試用例自動化的過程中，基本流程是將人眼看到的頁面元素，轉換成prompt讓大模型理解和定位，這裡會存在不少gap，出現大模型死活給不出預期元素index資訊的情況，我們採取了下面幾種方式來改善這個問題：

提示詞最佳化

結合用例除錯過程，將與大模型進行互動的資訊儲存到日誌中，輔助最佳化提示詞，其中“[Start of page]”和“[End of page]”之間的內容，即為大模型真實看到的頁面元素佈局，其中的標籤、屬性、相對位置等資訊能非常好的提升提示詞編寫的有效性，我們的測試用例編寫規範中也針對這一部分進行了說明指導，如“新出現的xx”、“xx後面的yy元素”等。涉及的系統提示詞中為如下部分：

-Only elements withnumeric indexes in [ ] are interactive

- (stacked) indentation (with \t) is important and means that the element is a(html) child of the element above(with a lower index)

- Elements with \*arenew elements that were added after the previous step(if url has not changed)

元素提取範圍擴充套件

為了控制消耗的token，browser-use並不會抓取所有的頁面元素資訊傳給大模型，如果某些特殊屬效能幫助識別唯一元素，可以進行新增，對應如下引數：

include_attributes: list[str] = ['title','type','name','role','aria-label','placeholder','value','alt','aria-expanded','data-date-format', ],

換個思路&兜底方案

有些時候並不一定要透過某些難定位元素來完成測試步驟，可以換個思路用一些簡單、確定性強的方法組合起來達成目標。

如果確實無路可走，部分常用action其實支援指定xpath和css selector作為兜底，這種方式就會遇到傳統UI自動化的問題，即頁面佈局變動可能導致定位失效。在一些動態頁面的測試中，有過使用：

  - task: 滑鼠移動到xpath為“//*[@id="icestarkNode"]/main/section[2]/section[2]/section[2]/section/section/div/div/div[1]/div[2]/div/div/div/div[2]/div[2]/table/tbody/tr/td[4]/div/div/div/div”的元素上

- task: 點選新出現的 <i> 元素

4. 測試穩定性

提升自動化用例的執行穩定性，是一個比較大的話題，也是一定需要解決的問題。特別是隨著自動化用例數量、測試輪次的增加，無效執行的用例數量會增多，即非產品缺陷導致的用例失敗。當前我們採用了下面幾個方式：

測試用例編寫規範task提示詞直接決定了大模型決策的穩定性，因此從專案一開始我們就建立了測試用例編寫規範文件並持續補充規則，便於不同的人編寫用例時進行參考。包括用例通用規則、變數替換使用場景、常用task提示詞和action對應關係、常見問題及修改方案等。基於此規範，提示詞的準確性能夠得到提升，結合框架的自適應更新機制，能夠實現有效的測試穩定性提升。
模型穩定性也即模型調優，初期主要依靠qwen系列的模型選型、引數調整（top_p/temperature/seed）來提升穩定性。後續會使用模型訓練和微調來讓大模型更懂我們的應用場景
環境健康檢查及feature檢測在測試執行前會對環境的健康狀態及具備的feature進行檢查，以此決定排程的用例是否能執行。一個具體的例子就是ascm服務目錄功能，叢集部署與否、開關開啟與否，均會全域性性的影響例項建立頁面的元素佈局和文字展示。我們主要採取瞭如下3種方案：

如果頁面會被類似功能影響，則task提示詞中需要指明不同情況下的操作方式；
如果過於複雜無法在提示詞中相容，則可以將用例拆分為不同場景編寫，結合框架的feature檢測和pytest的@pytest.mark.skipif實現不同場景執行不同用例；
框架在環境檢查階段，將全域性性開關恢復為預設狀態再進行用例排程；針對開關及對應功能本身的測試，則由相關用例負責配置和處理；

使用大模型但不依賴大模型對於某個具體的前端測試用例，只關心自己的步驟操作及結果，對於前置步驟、依賴等，沒有必要依然靠大模型解析頁面並一步步操作完成，可以直接使用更快速、穩定的後端API能力。因此框架支援了雲產品的後端API呼叫，包括OpenAPI、InnerAPI和OpsAPI，測試用例可以在setup階段直接呼叫完成前置步驟/資源建立和配置。