本期作者

項目參與人員：

顧伊凡、陳鈺廣、張又中、楊雨浩、樊執(zhí)政、熊夢園、何璇、譚楠

UI自動化測試能夠在一定程度上確保產(chǎn)品質量，尤其在降本提效的大背景下，其重要性愈發(fā)凸顯。理想情況下，UI自動化測試不僅能夠能幫我們規(guī)避不少線上問題，又能加快產(chǎn)品上線速度。然而現(xiàn)實卻往往相去甚遠，在多數(shù)情況下，編寫測試腳本的工作量很大，且由于應用程序的頻繁迭代，這些腳本很快就會過時。此外，網(wǎng)絡數(shù)據(jù)的多變也常常導致測試結果不穩(wěn)定，從而影響測試的可信度。

基于這些挑戰(zhàn)，我們開發(fā)了一套UI自動化測試平臺- AutoMotion，旨在降低UI自動化測試的使用門檻、提升易用性。該平臺不但能便捷地生成用例，且借助最新的大型語言模型，該平臺也具備了用例自愈能力，能夠智能適應界面的合理變動，并自動修正測試腳本；同時，通過構造數(shù)據(jù)沙箱來隔離和控制測試數(shù)據(jù)，使平臺能夠確保測試的一致性和可重復性。

本文將對AutoMotion平臺的設計理念、核心功能以及實現(xiàn)原理進行介紹，希望能與大家一同交流進步。

背景

我們組內(nèi)曾嘗試過使用cypress等常見工具進行UI自動化測試，但遇到不少問題和痛點，主要歸為以下四類：

手寫腳本成本高

頁面多如繁星，手寫自動化測試腳本成本很高。（這點無需贅述）

（有些工具支持根據(jù)錄制你的操作，然后生成腳本，但普遍能力有限，比如cypress提供的這種工具就無法記錄滾動操作）

網(wǎng)絡數(shù)據(jù)變化導致測試結果不可信

無論是線上、預發(fā)還是測試環(huán)境，數(shù)據(jù)都會不斷變化，導致很多情況下執(zhí)行通過與否不能正確反應實際功能邏輯有無問題。哪怕指定某個固定測試賬號去做某個特定用例的測試也會如此，比如存在一些非冪等的操作時便可能導致問題。

舉個簡單的例子。某活動頁，用戶可報名參與該活動（每人只能報名一次），測試用例是“登錄賬號1，點擊活動的報名按鈕，頁面顯示’報名成功‘” ，假如第一次執(zhí)行用例成功了，此時活動會變?yōu)椤耙褕竺睜顟B(tài)，第二次執(zhí)行該用例將無法再次報名，用例不通過，但此時前后端代碼并無任何問題。

當然，可以考慮寫個重置數(shù)據(jù)的腳本，然而：第一，需要后端同學的配合；第二，數(shù)據(jù)背后的關聯(lián)邏輯可能很復雜（比如以上例子下可以重置賬號1的報名狀態(tài)，但活動可能還會有報名結束時間，或活動被下架，或報名名額達到上限，等等各類情況），且針對不同項目不同場景要準備不同數(shù)據(jù)，實現(xiàn)成本很高；第三，很難重置線上數(shù)據(jù)。

項目迭代頻繁導致用例腳本維護成本高

當頁面發(fā)生迭代后，哪怕從功能上看此次迭代與某用例無關，也往往會導致該用例腳本失去作用，需要被更新。

參考如下例子：

測試用例是”...點擊任務的’去完成‘按鈕...“。

頁面結構如圖所示：

在自動化測試腳本中，我們可以通過“.task > .btn”這個selector選取到“去完成”按鈕，然后執(zhí)行點擊操作，cypress代碼為：

cy.get('.task > .btn').click()

但在后續(xù)迭代中，可能發(fā)生一些變化，比如在“.btn”外多包了一層“.task-content”：

此時通過“.task > .btn”就獲取不到了，所以我們需要在用例腳本中將selector更新為”.task > .task-content > .btn“。

當然，在這個特定例子下，我們還可以將selector寫成“.task .btn”，這樣即使在“.btn”外多包了任意層元素也不影響。但如果“.btn”被改成了“.btn-primary”呢？類似的情況還有很多，很多理應與舊用例無關的迭代，都需要我們?nèi)ジ掠美_本，大大提高了維護成本。甚至在有些時候，每次迭代都需大幅更新大量用例腳本，導致自動化測試完全失去了意義，還不如人肉回歸。

如何接入標準流程中

如何把各項目的自動化測試任務便捷地、靈活地接入到開發(fā)、發(fā)布流程中。（此條也無需贅述）

為了解決以上問題，我們決定自研一個UI自動化測試平臺：

UI自動化測試平臺 - AutoMotion

針對以上四大問題，該平臺對應提供了四大機制以解決：

針對以上四大問題，該平臺對應提供了四大機制以解決：

用例腳本錄制生成

用以解決：手寫腳本成本高

提供chrome插件，開啟錄制后，你可以模仿用戶在頁面中進行一系列操作，該插件可識別你的操作，自動生成UI自動化測試腳本。支持點擊、鍵盤輸入、滾動、拖動等大部分常見操作。

數(shù)據(jù)沙箱

用以解決：網(wǎng)絡數(shù)據(jù)變化導致測試結果不可信

為了對之有更確切的理解，這里不妨先將目光從該問題本身向上拉至更一般的角度。

我們可將某瀏覽器看做一個函數(shù)，該函數(shù)的“輸入”為前端代碼、用戶操作、接口數(shù)據(jù)、日期、隨機數(shù)等，“輸出”為渲染后的界面，在幾乎99.9%的情況下，可以認為該函數(shù)是確定的、無副作用的、可預測的（即在以上“輸入”保持不變的情況下，使瀏覽器運任意次，“輸出”也應始終不變）。

然后帶著以上視角下重新審視UI自動化測試：

如下圖，通常，在某次迭代后執(zhí)行UI自動化測試用例時，相比前一次的執(zhí)行，“用戶操作”是不變的（寫死在測試腳本里），但在它之外可能存在多個輸入項的變化，此時若渲染結果發(fā)生了變化，導致用例執(zhí)行失敗(中斷或不符合斷言)，我們很難直接將其歸因為“前端代碼變更所致”：

而若能使得每次執(zhí)行UI自動化測試用例時，僅前端代碼存在變化，若某次用例執(zhí)行失敗，便能更確切地得知其為“前端代碼變更所致”：

至此，“數(shù)據(jù)沙箱”的想法應運而生：

在用例錄制階段，于錄制用戶操作的同時，收集過程中的接口請求、storage、cookies、窗口大小等外部數(shù)據(jù)（你也可以自行修改這些數(shù)據(jù)），并在用例執(zhí)行階段1:1地“復現(xiàn)”出來。

當然，使用“數(shù)據(jù)沙箱”是有取舍的，使用后雖然避免了接口數(shù)據(jù)干擾問題，大幅省心，但這樣相當于只測前端代碼了。所以該平臺也支持根據(jù)需要關閉特定數(shù)據(jù)沙箱（比如關閉接口請求沙箱以測到后端邏輯、保留cookies沙箱以避免登錄問題）。

用例可視化編輯、用例自愈機制

用以解決：項目迭代頻繁導致用例腳本維護成本高

首先，上文介紹的“用例腳本錄制生成”能力就已很大程度上解決了該問題，用例需要更新時重新錄制一遍即可。

其次，該平臺還提供了：

1. “用例可視化編輯”能力，在用例僅需小幅更新時，可快速編輯、更新；

2. “用例腳本編輯”能力，錄制的用例可直接轉為cypress腳本（后續(xù)考慮支持playwright），以進行更加靈活、無約束的編輯。

這些更新方式都較為便捷，但在實際使用中依然存在一大問題：

經(jīng)過某些迭代后執(zhí)行用例時，可能很多用例執(zhí)行不通過，但大部分是頁面結構的合理更新后所至，而非新引入的bug，此時需人工一一審閱報錯原因，確認是feature或bug。且此次因feature導致的用例不通過，若不及時更新，則下次執(zhí)行時將有極大概率依然不通過，如此不斷疊加，不通過的用例越來越多，導致我們不得不在每次迭代后及時地花費很大精力去排查、更新用例，完全違背了“自動化測試”的初衷。

其實觀察該類問題后會發(fā)現(xiàn)，它們大部分都出自同一個“簡單”的原因：頁面更新后，用例執(zhí)行時獲取不到目標元素（請回顧一下上文“③ 項目迭代頻繁導致用例腳本維護成本高”中所舉的例子）。

針對這種情況，我們對傳統(tǒng)的css selector規(guī)則進行了擴展，并基于現(xiàn)有的LLM實現(xiàn)了目標元素的智能識別與“用例自愈”。使得在頁面結構變化后（非大的功能更新），依然能夠獲取到目標元素，并自動根據(jù)最新頁面結構自動更新用例腳本。

Open API

用以解決：如何接入標準流程中

對于錄制保存后的每個用例，該平臺都會生成相應的open api，調(diào)用該api即可執(zhí)行用例并得到結果。該api可被靈活地接入gitlab、流水線/構建/發(fā)布平臺、cli工具等，實現(xiàn)在任意流程節(jié)點上執(zhí)行自動化測試。

也可在該平臺上設置定時器進行定期自動化測試。

方案與原理介紹

以下會介紹該平臺的部分關鍵技術點和一些背后的思考。

用例錄入

chrome插件

用例錄入是通過chrome插件實現(xiàn)的，在開啟錄制時，該插件會進行以下處理：

• 在頁面頭部植入一段js腳本，侵入頁面運行時環(huán)境，通過操作頁面window對象捕獲錄制過程中的所有操作行為、storage數(shù)據(jù)等；

• 在devtools page中捕獲錄制期間所有接口數(shù)據(jù)；

• 在background page（service worker）中捕獲cookies；

• 在content script中捕獲useragent、窗口大小等信息。

錄制結束后，該插件會將以上收集到的信息轉成符合我們定義規(guī)范的用例DSL，存儲至后臺。除了以上基礎能力，該插件中還實現(xiàn)了DSL可視化/編輯、元素可視化拾取、環(huán)境識別、異常檢測、用例試運行等功能。

由于chrome插件的一些限制，在實際實現(xiàn)以上功能時，需要按照chrome插件支持的能力范圍劃分模塊，且很多模塊間不能直接通信，導致數(shù)據(jù)流相對難以管理（所以我們對通信數(shù)據(jù)的類型和格式進行了一定規(guī)范，這里不展開）。部分細節(jié)如下（示意圖，僅供參考，大致瀏覽即可）：

構建與更新

chrome插件與常規(guī)前端項目結構有所不同，且該chrome插件目前僅為公司內(nèi)部使用（未上傳至chrome商店），故在構建、打包、版本更新方面也做了一些處理，封裝在我們的構建腳本中，運行后可自動完成如下流程：

1. 使用webpack對devtools頁面（即本插件中所有UI展示的部分）進行構建；

2. 對devtools頁面以外全部文件進行構建（如統(tǒng)一替換環(huán)境變量）；

3. 更新manifest中版本號；

4. 將整個項目壓縮為zip包，上傳至線上；

5. 更新數(shù)據(jù)庫中最新版本號；

6. （用戶在打開舊版本chrome插件時會提示更新，點擊即可下載）。

用例執(zhí)行

我們是通過nodejs和cypress實現(xiàn)用例執(zhí)行的。nodejs服務會在容器中初始化cypress項目環(huán)境，在需執(zhí)行用例時，將用例DSL轉為可執(zhí)行的cypress腳本和相關數(shù)據(jù)文件，其中包含用戶操作、數(shù)據(jù)沙箱等信息，然后通過cypress運行（支持數(shù)個cypress實例并發(fā)），最后生成運行結果，并觸達給前臺觸發(fā)方或預警方。

行為監(jiān)聽

在上文中已經(jīng)提到了，在用例錄制時，chrome插件會在頁面頭部植入一段js腳本，監(jiān)聽操作者行為，這里進一步闡述一下監(jiān)聽方式。

基礎事件監(jiān)聽

chrome插件植入的js腳本會在頁面window對象上進行全局事件委托，以監(jiān)聽用戶相關操作。如：

window.addEventListener('input', this.handleInput, true)

特殊事件監(jiān)聽

以上“基礎事件監(jiān)聽”方式似乎已經(jīng)足夠，但細想一下，mouseenter、mouseleave、mousemove、mouseover、mouseout等事件也能通過這種方式綁在window或document節(jié)點上進行監(jiān)聽嗎？

顯然不合理，比如若在document上監(jiān)聽mouseenter事件，那么當我們的鼠標劃過頁面中任意元素時，都會觸發(fā)該事件，這些信息是冗余的?？梢詫Ρ纫幌耤lick，因為用戶在頁面中的大部分點擊操作都是“有意義”的（是整個”頁面函數(shù)“中的一個有意義的輸入），所以整個頁面中任意位置觸發(fā)click是都可以記錄，而大部分鼠標移動操作都對頁面無實際意義。

這里應當反過來思考：只有本身已經(jīng)綁定了這些事件的元素，觸發(fā)這些事件對它來說才大概率是有意義的，我們對這些元素做監(jiān)聽就行。比如頁面中有個元素A，它被綁定了mouseenter事件以在鼠標移入時展示tips，那么在用例錄制時，若用戶將鼠標移入元素A，觸發(fā)了tips展示，就需要將該mouseenter事件錄制下來、在用例執(zhí)行時觸發(fā)，否則就無需記錄。那么如何知道哪些元素被綁定了這些事件呢？可以將頁面中window.Element.prototype.addEventListener函數(shù)替換成我們自己構造的函數(shù)，實現(xiàn)對任意頁面中原本的所有”事件綁定“行為的攔截，當然同時也需調(diào)用原函數(shù)，不影響原功能。代碼示意如下：

const originalAddEventListener = window.Element.prototype.addEventListener;
// 替換所有元素的addEventListener
window.Element.prototype.addEventListener = function(type, originalListener, ...others) {// 替換所有元素的listener回調(diào)函數(shù)，進而攔截mouseenter、mouseleave、mouseover、mouseout事件const listener = function(event) {if (isRecording && ['mouseenter', 'mouseleave', 'mouseover', 'mouseout', 'mousemove'].includes(event.type) && event.target === this) {handleMouseAction(event)}originalListener.call(this, event)}return originalAddEventListener.call(this, type, listener, ...others)
}

目標元素定位

“行為”實際上包括“動作”和“作用對象”（即“目標元素”）兩塊。比如“用戶點擊元素A”，其中“動作”是“點擊”，“目標元素”是“元素A”。上文已經(jīng)介紹了如何識別“動作”，這里介紹如何定位“目標元素”。

基礎定位

以“從根節(jié)點到目標元素的唯一路徑的css selector”作為定位方式。如：body > div > #app > div.app-right > div > div:nth-child(2) > div.text

基礎定位增強

請先看一個例子，如下圖，“導出”按鈕是目標元素，通過“基礎定位”記錄下的selector可能是“xxx > div:nth-child(2)”：

但在某次迭代后，在“導出”之前新增了一個“重置”按鈕：

此時“xxx > div:nth-child(2)”定位到的就是“重置”按鈕了。

這里我們會發(fā)現(xiàn)，常規(guī)css selector的描述能力似乎并不夠，對于某個元素，你可以準確描述它的class，也可以準確描述它是當前層級中的第幾個元素，但無法將二者結合，即無法描述“它是當前層級中class為xx的第幾個元素”（前端界的“測不準原理”？😑）。

所以不如定義一套新的規(guī)則（基于css selector進行擴展），如“xx > div.btn.primary:nth(2)”，含義為“在xx的子節(jié)點中，選取所有符合div.btn.primary的節(jié)點，再在其中選取第2個”，這樣放在上面的例子里，新增“重置”按鈕后也不會影響到“導出”按鈕的定位了。

此外，我們還可以加入文本內(nèi)容信息，如“xx > div.btn.primary:contains('導出'):nth(1)”，這樣哪怕新增的“重置”按鈕也是“.btn.primary”，也不影響了（當然，若信息過多，在頁面迭代后、進行精準匹配時反而更容易出錯。但倘若是“模糊匹配”，則信息越多越好，這點下面會探討）。

（其實xpath就能夠描述這些信息，但最新的cypress已不支持xpath了，而手動實現(xiàn)xpath查找的成本很高，所以我們選擇手動實現(xiàn)自定義增強版的“css selector”）

基于LLM的目標元素智能識別與用例自愈

方案

使用以上增強版的css selector在部分情況下能夠降低頁面結構變化后元素定位失敗的概率，但依然有很多情況會導致失敗，比如元素class改變、元素位置改變、元素內(nèi)容文本改變等。

可以想象一下，在人工回歸時，大部分情況下我們“聰明的人類”能輕松地識別出變化后的目標元素，那么能否讓UI自動化測試擁有接近人類的目標元素識別能力呢？

一個最顯然的方案是：基于圖像識別選取元素。這原本也幾乎是唯一最佳選擇，但隨著近幾年LLM的迅速發(fā)展，我們想到了另一種可能：基于LLM實現(xiàn)目標元素智能識別。畢竟最新LLM模型的文本理解能力已經(jīng)相當驚人，而“頁面結構”本身也是通過文本（dom）進行描述的。因為對圖像識別相關經(jīng)驗不多，且第二種方案也有望擴展至“目標元素智能識別”以外的各種場景，故選取了第二種。

該方案大致為：在用例執(zhí)行中，若selector獲取失敗，則暫停執(zhí)行，將頁面dom、selector等信息交由LLM進行處理，讓其識別出該“過時的”selector真正想獲取的元素是什么，返回更新后的selector路徑，然后更新相應用例并重新執(zhí)行，達到“用例自愈”。

DOM壓縮

在將信息輸入LLM前，有一個很明顯的問題：頁面dom可能會很大，導致LLM處理時間很長，甚至可能直接超過LLM支持的大小上限。比如這是b站首頁渲染完成后的dom大小：

高達22萬tokens！不過其中大部分信息對“目標元素識別”來說都幾乎是無意義的，我們可以將它們?nèi)縿h除，進行“dom壓縮”：

• 刪除script、style、link等結構無關tag

• 空格、換行合并

• 對于剩下的所有tag，僅保留tag、id、class、text信息，其它全部刪除

經(jīng)過這些步驟后，該頁面占用的tokens大幅降低至1.3萬：

可剩下的dom中重復內(nèi)容還是不少的。比如某個class名可能在頁面中出現(xiàn)很多次，占用了很多字符。所以可生成一個”class壓縮映射表“，把每個class名映射為一個數(shù)字，最終可能用0-500這些數(shù)字就能表示所有class名，當然，數(shù)字每位”密度“還是太低了（只能包含10個不同的值），且class名開頭不能為數(shù)字，所以用字母”計數(shù)“更佳，比如先從a到z，再+1就是aa，以此類推，大部分class名都會被壓縮至兩個字符以內(nèi)（經(jīng)過試驗，僅此步就可將該頁面tokens數(shù)進一步降低至0.9萬）。

同理，tag名稱也可壓縮。甚至”class“這個字段本身也可壓縮（比如壓縮成”c“）。

經(jīng)過這些壓縮后，dom確實會繼續(xù)縮小，然而這些壓縮會丟失不少”有語義“的信息，無論是一些class名（比如”task-btn“）還是tag名，它們有助于LLM去理解頁面內(nèi)容、做出更準確的目標元素識別，所以我們最終未選擇這些進一步壓縮的方式（另一種方式是將壓縮映射表也告知LLM，不過也會提高LLM理解難度，有待試驗）。

實際上，b站首頁算是b站dom最龐大的頁面之一了，大部分頁面經(jīng)過第一步的壓縮后，tokens會遠低于1.3萬（比如很多移動端頁面壓縮后tokens數(shù)為1500-5000）。

Prompt

壓縮完dom后，便可以構造promot了，我們的prompt結構大致如下：

其中會先通過一些例子讓LLM學會如何進行“模糊匹配”（即根據(jù)“不準確的selector”找到正確的元素），然后將壓縮后的dom、selector交由它完成任務。

對于實際效果，我們進行了一些初步試驗：

在一般情況下，“用例自愈”能力已可滿足要求（仍在優(yōu)化中）。對于確實變化很大難以“自愈”的，將提示用戶重新錄制用例。

執(zhí)行流程

采用標元素智能識別與用例自愈后的執(zhí)行流程如下：

Fine-Tuning？

目前我們對LLM的所有要求都被囊括在prompt中，這可能并不是最佳方式，畢竟prompt的長度有上限，我們無法灌輸給LLM足夠多的信息去提高正確率，也會消耗較多處理時間和費用。

而fine-tuning允許我們根據(jù)自己的特定需求和數(shù)據(jù)集來定制和優(yōu)化模型，以適應特定場景，相比上面的純prompt方案，我們可以預先喂給大模型多得多的“模糊匹配”例子，進一步提高其識別目標元素的能力，且prompt大小可大幅縮減（prompt中“前置能力學習”的部分可以去掉了）。所以fine-tuning應該是更好的方式，由于當下時間有限暫未嘗試，后續(xù)會深入。

唯一標識符定位

基礎方案

上面介紹了常規(guī)定位+智能定位的方案，已經(jīng)可以相對絲滑地覆蓋大部分場景，但有時LLM也會出錯以及部分敏感頁面可能不適合傳入LLM。有沒有其它可選的、接入成本稍高一點的、但更加穩(wěn)定的方式呢？當然有，很直接：為所有目標元素加上唯一標識。

可于用例錄制前，為需要錄制操作的元素綁上唯一標識，如：“

<div data-atm-id="(uuid)" ”（這里沒有直接使用“id”屬性是為了避免影響原項目業(yè)務邏輯），在用例錄制時，若目標元素有此類標識，則記錄該標識即可。因為該標識全局唯一，故任何dom結構的變動后都不影響獲取該元素（除非刪除該元素，當然，這時也說明該用例已與新需求不符，應重新錄制用例了）。

問題與改進

有一些細節(jié)但關鍵的問題需要處理：

問題1：

若只有元素2綁定了唯一標識，而錄制時是元素1被點擊，對不上，這樣記錄下的依然是元素1的selector。

解法：用例錄制時，若被捕獲的元素沒有data-atm-id，則向上找到離其最近的含data-atm-id的節(jié)點，作為真正的目標元素并記錄。

問題2：難以給一些npm組件庫中某組件的內(nèi)部元素打上標識。

解法：增加“data-atm-parentId”標識，寫在組件最外層（若不方便寫，也可在組件外自己加一層div寫上該標識），用例錄制時，若被捕獲的元素沒有data-atm-id，（且在問題1解法未滿足時），向上找到離其最近的含data-atm-parentId的節(jié)點，構建以它為開頭的selector（如“[data-atm-parentId="xxx"] > div”），若找不到才記錄當前元素的常規(guī)selector。

權衡

當然，唯一標識符定位也存在一些弊端：

1. 有一定接入成本，需侵入被測項目，修改其項目代碼；

2. 處理組件庫內(nèi)部元素的方式依然不夠穩(wěn)定可靠；

3. 倘若后續(xù)想進一步實現(xiàn)“全自動”用例生成（結尾“展望”部分會介紹）——要對成百上千個頁面生成用例，此方案就不適用了。

可見，在”元素定位“方面，幾乎沒有既簡單高效、又穩(wěn)定可靠的完美方案，現(xiàn)在可以做的是將以上方案結合，讓使用者能夠按需要自行選擇。不過，我們認為在“目標元素智能識別與用例自愈“上仍然有不斷優(yōu)化的空間，也是我們主要著眼的方向，且在使用fine-tuning或更強大的LLM問世后，此方案大概率將得到又一次增強。

數(shù)據(jù)沙箱

這里介紹一下“數(shù)據(jù)沙箱”中的核心部分：“網(wǎng)絡請求沙箱”。

基礎方案

基礎方案很簡單：

1. 用例錄制時，通過chrome插件的chrome.devtools方法捕獲所有接口數(shù)據(jù)；

2. 用例執(zhí)行時，通過接口入?yún)?#xff08;url(含query)+method+body）匹配錄制時記錄下的相應網(wǎng)絡數(shù)據(jù)、通過cypress的cy.intercept方法進行攔截和mock。

問題與改進方案

基礎方案乍一看挺美好，但仔細一想坑不少。

問題1：“url(含query)+method+body”并不足以精準匹配。比如同樣的接口被先后請求兩次，但返回值不一樣，基礎方案下記錄的信息并不能區(qū)分這兩次接口請求。舉例：用戶進入某活動頁，調(diào)用接口a獲取報名狀態(tài)，返回“未報名”，點擊報名按鈕，成功，重新調(diào)用接口a，返回“已報名”，用例執(zhí)行時如何得知每次接口a的調(diào)用應該返回什么呢？

解法：兩次接口調(diào)用之間，接口入?yún)⑼耆蛔?#xff0c;那什么發(fā)生了變化可能導致接口出參改變呢？操作行為和時間。所以在記錄每個接口信息時，我們還會進行“數(shù)據(jù)歸因”+“時間對齊”，將其“歸因”到某個用例節(jié)點上，并記錄相對時間。如：接口a歸因于“點擊報名按鈕”節(jié)點，滯后200ms左右。

問題2：有些項目的接口入?yún)⒅袝恍┣岸松傻碾S機信息，導致執(zhí)行用例時每次的入?yún)⒍疾灰粯?#xff0c;匹配不上（有了“隨機數(shù)沙箱”后倒可以解決，還未實現(xiàn)）；頁面迭代可能會修改接口入?yún)?#xff0c;導致匹配不上；頁面迭代后運行時間可能變化較大，導致歸因的時間對不上；等等。

解法：這些問題都是“精準匹配”導致的，其實解決思路與上文的目標元素定位類似，即增加“模糊匹配”。這里目前不需要LLM，因為匹配信息結構固定且可被量化，所以我們制定了"接口相似度匹配算法"，根據(jù)url、query相似度(kv匹配、k匹配、多余的k等)、method、距歸因節(jié)點時間等指標綜合計算得分，選擇得分最高的接口然后返回。（若無一個得分高的，則發(fā)往真實后端）

問題3：頁面迭代后可能會引入新接口，該接口甚至可能跟用例所測模塊毫無關系（所以正常來說，肯定不想因為它去更新用例），但因匹配不上，會發(fā)往后端，此時若無登錄態(tài)會跳登錄頁或使頁面出錯，導致用例失敗。

解法：用例錄制時記錄下cookies，用例執(zhí)行時注入。這樣通過”模糊匹配“也匹配不上的接口，會攜cookies發(fā)往后端，至少大概率保證頁面不報錯。

如此，我們將“接口數(shù)據(jù)沙箱”劃分為如下圖所示的三層，每當上一層匹配失敗時，觸發(fā)下一層：

多環(huán)境與多用例并發(fā)執(zhí)行

如圖，由于需要支持在不同環(huán)境執(zhí)行用例，所以我們將“用例執(zhí)行”的部分單獨拆了出來，作為“runner”，分別部署在不同環(huán)境，”runner“容器中也需預先裝好無頭瀏覽器、cypress和相關運行環(huán)境；將常規(guī)的crud部分作為”server“，同時它也負責將用例分發(fā)至對應環(huán)境的”runner“。

此外，每個用例的執(zhí)行需占用一定資源和時間，執(zhí)行器支持的最大用例并發(fā)數(shù)有上限，所以，用例進入runner時會進入隊列中等候，在執(zhí)行器有空余時執(zhí)行。

主要流程如下：

1. 在用例錄制時，獲取每個url最終指向的ip地址，自動識別出當前運行環(huán)境，保存在用例中（也支持手動修改環(huán)境）；

2. 觸發(fā)用例執(zhí)行時，server將用例發(fā)往對應環(huán)境的runner執(zhí)行；

3. 用例進入runner的隊列中等待執(zhí)行。

DSL

我們測試框架代碼之上定義了DSL層，它是對于用例的結構化描述，JSON格式，包含某個用例的全部信息。它的作用是：

1. 便于用例錄制時快速生成，便于存儲；

2. 便于可視化展示以及可視化編輯；

3. 對用例進行結構上的約束，減小出錯概率，收斂系統(tǒng)復雜度；

4. 理論上可被轉為各類測試框架代碼并執(zhí)行。

導出用例腳本并編輯

部分用例需高度定制，通過可視化編輯無法滿足，因而我們提供了將用例DSL導出為cypress腳本的功能（后續(xù)考慮支持playwright腳本），通過修改cypress腳本便能實現(xiàn)一切cypress可實現(xiàn)的能力。

從上方“DSL“章節(jié)的圖中可知，DSL可以轉成cypress腳本代碼，但該過程不可逆（DSL的能力是cypress腳本的子集），所以在用戶導出cypress腳本后，該腳本會成為新的用例，作為”腳本類型用例“與”DSL類型用例“區(qū)分開來。

我們提供了cli工具，可在任意目錄下初始化cypress項目，然后可將任意用例轉為cypress腳本下載至此，以便在本地修改和運行調(diào)試，修改完成后可通過cli將用例上傳至線上，成為一個新的”腳本類型用例“?！蹦_本類型用例“能夠與”DSL類型用例“一樣在線上執(zhí)行。

流程示意如下：

展望

現(xiàn)在已經(jīng)實現(xiàn)了錄制后自動生成用例腳本、代碼小幅更新后自動修復用例腳本，但“錄制”操作本身依然需要人工執(zhí)行，而且在這之前還需制定用例，能否把這些過程也“自動”做掉？

一個直接的想法是：讓LLM了解產(chǎn)品背景、閱讀最新產(chǎn)品需求，生成用例。理論上讓LLM生成文字描述的用例顯然是可行的，而想要進一步生成用例DSL或用例腳本，還需使LLM知曉所有相關頁面運行時的具體結構，如何運行、如何存儲、如何理解、如何關聯(lián)等都會是難題。

所以不如換一個角度：頁面最終是服務于線上用戶的，他們的操作本身不就是最好的”用例“么？所以可以自動采集線上線上用戶的真實操作鏈路，自動識別出高頻鏈路、核心鏈路，自動歸總為用例。相比之下，該方案更易實現(xiàn)（當然尚待深入的細節(jié)問題依然不少），且生成的用例質量甚至可能更好，同時也有借助LLM繼續(xù)優(yōu)化的可能性。

流程示意如下：

如此，在設定好策略后，便可自動批量產(chǎn)出用例、自動執(zhí)行，做到“全流程全自動”，這才是真正“自動”的“自動化測試”。預期主要可以服務于數(shù)量龐大的、非核心的前端頁面（數(shù)量太多難以一個個錄入和維護，但又想一定程度上保證質量），大幅降低生產(chǎn)和維護用例的時間。