過去大半年我一直在琢磨一件事怎么讓AI真正進到測試自動化的執(zhí)行鏈路里而不是只在對話框里寫個demo給人看。最開始我也試過最省事的辦法——直接把需求扔給AI讓它“寫一個登錄腳本”結果它確實寫了寫得還像模像樣但一提交代碼評審問題就全出來了沒用頁面對象、等待全靠sleep、定位符寫絕對XPath甚至直接new了一個新的driver實例。負責review的同事看完一臉懵說這代碼根本進不了我們的框架。后來我慢慢想明白一個道理AI不是不會寫代碼是你沒把它放進你家的規(guī)矩里。這篇文章是“AI for Testing 提效實戰(zhàn)”系列里執(zhí)行自動化的第一篇不聊概念就聊怎么讓AI在你的框架內產(chǎn)出能直接合入的腳本。1. AI生成的代碼為什么總是和你的工程格格不入1.1 看起來能跑的腳本實際上是一堆技術債你在AI聊天框里要一個“登錄并把用戶名拼到首頁上”的UI自動化用例它大概率給你類似這樣的東西from selenium import webdriver import time driver webdriver.Chrome() driver.get(https://demo-app.example.com/login) driver.find_element_by_id(username).send_keys(tester) driver.find_element_by_id(password).send_keys(123456) driver.find_element_by_xpath(/html/body/div[1]/div/form/button).click() time.sleep(3) assert 歡迎tester in driver.page_source driver.quit()單看這段代碼邏輯沒錯放到一個一次性爬蟲腳本里完全能跑。但如果你所在的是一個多人協(xié)作、要長期維護的自動化測試工程它幾乎是不可合入的。原因很直接工程里已經(jīng)規(guī)定所有頁面操作都要封裝到Page Object里driver實例統(tǒng)一由框架初始化并管理等待必須走框架封裝好的顯式等待方法定位符優(yōu)先使用測試專用屬性。而AI生成的代碼把這些全忽略了。有人可能會說這不就是讓AI生成完再人肉改一改嘛也能用。但“改一改”的成本往往比從零寫還高。尤其是當你一個月要生成幾十上百條用例時每條都要重構一遍那AI的價值就只剩個“偽代碼起草器”了。所以核心問題不在AI寫得好不好而在于你讓它開工之前有沒有把“你們家的代碼長什么樣、有什么規(guī)矩”告訴它。1.2 AI并不是不聰明而是沒有你頭腦里的“框架心智”大模型在訓練時看過海量代碼它對通用編碼風格非常熟悉包括公開教程里最常見的直接new driver、time.sleep、find_element_by_xpath那一套。但它不知道的是你們團隊的BasePage封裝了什么、用例層能做什么不能做什么、失敗截圖是誰負責處理的、測試數(shù)據(jù)從哪里讀。這些信息不會出現(xiàn)在任何公開代碼庫里而是你所在工程多年迭代沉淀下來的隱性約定。我把這些約定稱為“框架心智”。老測試開發(fā)在寫用例時腦子里會下意識地調用這些約定就像老司機開車不需要思考檔位和剎車。但AI默認沒有這套心智你不主動喂給它它就只能按通用套路來而通用套路和團隊標準之間隔著一大段代碼評審的距離。所以“讓AI在你的框架里寫”這句話字面上就是第一步要做的把項目結構、核心接口、參考用例、運行方式、禁用項整理成一份它能直接讀取的上下文。這一步做扎實了后面才有“直接合入”的可能性。2. 把“框架上下文”整理成提示詞是合入的第一步2.1 上下文包的五類材料我試過很多種喂AI的方式最后收斂下來一份高質量的上下文包只需要包含五類材料。不需要把整個倉庫塞給它也不需要寫幾百行的框架源碼重點是讓它知道“怎么寫才像我們自己人”。第一類是目錄結構節(jié)選。不需要完整列出只展示用例相關的三層核心層級就夠了比如project/ ├── pages/ # Page Object頁面元素與操作封裝在這里 ├── cases/ # 測試用例只負責業(yè)務流程與斷言 ├── utils/ # 公共工具比如數(shù)據(jù)生成、配置讀取 └── runner.py # 執(zhí)行入口第二類是核心基類接口。把頁面對象和用例基類里常用的方法簽名給出來AI才知道哪些動作是現(xiàn)成的不需要自己造輪子class BasePage: def click(self, locator: tuple) - None def input_text(self, locator: tuple, text: str) - None def wait_until_visible(self, locator: tuple, timeout: int 10) - WebElement def get_text(self, locator: tuple) - str class BaseCase: def login(self, username: str, password: str) - HomePage第三類是2到3條已經(jīng)合入的參考用例。最好挑典型的表單填寫、列表校驗、按鈕跳轉各一條。AI很擅長模仿給它一個高質量樣例它會照著風格寫比給它一堆抽象規(guī)則更有用。第四類是運行方式與測試數(shù)據(jù)約定。比如命令行入口是什么、測試數(shù)據(jù)放在哪個目錄、測試結束是否需要自動清理。這些不屬于代碼語法但決定生成出來的用例能不能直接接進執(zhí)行鏈路。第五類是明確禁用項。這條最重要。把你們歷史上踩過的典型坑直接寫成“禁止”比如禁止time.sleep、禁止絕對XPath、禁止在用例層直接寫locator、禁止調用未封裝的外部資源。AI是概率模型它的“默認行為”來自海量訓練數(shù)據(jù)只有用明確的負面清單才能壓過那些默認行為。2.2 一套可以直接抄的Prompt框架材料準備好之后每次生成用例時我會用下面這個提示詞框架它把剛才說的內容都壓縮成一段結構化的約束你是我團隊的測試開發(fā)工程師。請按照當前工程約定編寫一條UI自動化測試用例。 目標場景{具體操作步驟與業(yè)務預期} 工程結構 {pages/ 與 cases/ 目錄結構節(jié)選} 核心接口 {BasePage 與 BaseCase 方法簽名} 參考用例 {一條已合入標準的用例代碼} 運行方式 python runner.py --case {case_name} 硬性約束 1. 頁面元素定位必須寫在 pages/ 下對應的Page類中cases/ 里只允許調用Page對象方法 2. 禁止使用 time.sleep等待統(tǒng)一調用 wait_until_visible 或 wait_until_clickable 3. 禁止使用絕對XPath元素定位優(yōu)先使用專屬 test-id 或相對定位策略 4. 不要打印日志、不要直接截圖日志與截圖由框架統(tǒng)一處理 5. 輸出必須是完整可運行的代碼不要額外解釋 請給出 cases/ 下用例文件路徑與完整代碼。這個Prompt的核心是“場景描述 框架約束 參考樣式”。場景描述要具體到“進入列表頁點擊第一行的編輯按鈕修改狀態(tài)為啟用保存后斷言提示成功”而不是“測一下編輯功能”。約束越具體AI越不會自由發(fā)揮。2.3 上下文不需要“全量源碼”給接口和約定就夠了剛開始有同事會把整個項目代碼打包成一個文件喂給AI覺得信息越全越準。實際效果恰恰相反。上下文太長時模型注意力會被大量無關實現(xiàn)稀釋最后產(chǎn)出的代碼反而偏離約束。你只需要給“支撐這一個用例的最小上下文”——它要調用的接口、要遵循的寫法、要模仿的樣例。這就像新員工入職不需要讀全公司代碼庫只需要先了解自己崗位涉及的模塊和相關規(guī)范干幾天活自然就上手了。這個思路也直接決定了真實成本。大模型按token計費動不動喂全量源碼既貴又慢。用精簡上下文單次生成消耗很小而且迭代反饋時也能快速調整不會因為每次都帶一大堆歷史代碼而拖慢速度。我們后來甚至把上下文包按模塊拆成好幾個版本登錄測試用登錄上下文訂單測試用訂單上下文準確率比一個“全量包”高出一截。3. 從AI輸出到合入分支四道檢查一個都不能少3.1 自動檢查把“骨架一致性”交給腳本即使上下文包寫得很完善AI偶爾還是會漏掉一兩條約束。所以第一條質量閘門應該自動完成不要靠人肉review去盯“是否用了sleep”這種問題。我在團隊里做了一組靜態(tài)檢查腳本用AST解析AI生成的用例文件重點檢查是否 import 了 time、selenium 這類應該由框架統(tǒng)一管理的模塊用例類中是否直接出現(xiàn)定位元組或XPath字符串是否調用了 pages/ 下已經(jīng)存在的頁面對象方法是否在斷言前使用了框架要求的顯式等待。這些檢查規(guī)則不需要很復雜正則加AST就能搞定。檢查不通過時直接把報錯信息返回給AI讓它基于報錯再改一輪。我發(fā)現(xiàn)這一步能把“初版不經(jīng)用”的比例從七成以上降到四成以下效果立竿見影。3.2 框架內試運行先證明它能在你家的環(huán)境里跑靜態(tài)檢查過了不代表能跑。第二個閘門是把AI生成的用例真正放進你的執(zhí)行框架里跑一次。我們會把新生成的用例先放到cases/ai_pending/目錄標記為冒煙用例跑一個專門的快速冒煙任務。這個任務只覆蓋目標用例依賴的前置數(shù)據(jù)盡量控制在5分鐘內出結果。通過后腳本會自動把用例移動到正式cases/目錄失敗的話就把日志和錯誤信息回投給AI讓它自己修正。這個“生成—運行—回喂—再生成”的循環(huán)是整個執(zhí)行自動化鏈路里最值錢的部分。因為AI模型本身不具備執(zhí)行能力它無法感知“這段代碼在當前環(huán)境下能不能跑”但你的框架可以?？蚣茇撠焾?zhí)行和反饋AI負責根據(jù)反饋修改兩者配合才真正形成閉環(huán)。3.3 人工評審只看增量不給AI重寫試運行通過后才算輪到人工評審。這里最容易犯的錯誤是reviewer忍不住親自上手改代碼把AI寫的東西重寫一遍。一旦這樣做AI就變成只能生成“初稿”的工具效率提升非常有限。我的建議是人工評審只做語義審核給reviewer一張檢查清單業(yè)務斷言是否完備關鍵狀態(tài)有沒有校驗測試數(shù)據(jù)是否可復用會不會污染其他用例用例名稱與模塊劃分是否符合工程規(guī)劃有沒有把測試邏輯和業(yè)務邏輯混在一起只要不滿足就把意見描述清楚再交給AI去改。比如“這里只校驗了提交成功提示沒有校驗列表里新增數(shù)據(jù)的展示值”AI通常會很快補上。人工專注業(yè)務正確性語法和格式問題全部交給前面的自動檢查去管評審速度會快很多。3.4 合入之后在回歸集里觀察兩天合入分支不等于完事。執(zhí)行自動化最怕的就是用例剛合入時能跑過兩天就flaky。我們的做法是給新合入用例設置一個觀察期在CI報告里標記為new_case連續(xù)跑5次全量回歸全部通過后才轉成正式用例。觀察期內一旦出現(xiàn)偶發(fā)失敗先查定位符和等待邏輯不要簡單屏蔽。這個機制看著保守但能極大地減少“AI生成的用例污染回歸集”的風險。對“直接合入”這個目標來說前面三道閘門是讓代碼滿足工程規(guī)范第四道閘門是讓代碼滿足穩(wěn)定性要求。四道都過了AI產(chǎn)出才算真正進入資產(chǎn)池。4. 執(zhí)行自動化落地中真正毀掉“直接合入”的兩個隱藏殺手4.1 脆弱的定位符死在第一輪回歸執(zhí)行自動化里AI生成用例最常死在第一輪回歸的就是元素定位。你可以在提示詞里寫一百句“請使用穩(wěn)定的定位符”但如果沒給出可操作的標準AI還是很容易寫出/html/body/div[2]/div[3]/form/div/input或者帶隨機后綴的id。原因還是訓練數(shù)據(jù)大量公開腳本為了快速演示直接用絕對XPath和當前頁面結構。我們后來在上下文包和自動檢查里同時加了硬性規(guī)定優(yōu)先使用> 讓AI測試自動化代碼直接合入：框架上下文是關鍵
過去大半年我一直在琢磨一件事怎么讓AI真正進到測試自動化的執(zhí)行鏈路里而不是只在對話框里寫個demo給人看。最開始我也試過最省事的辦法——直接把需求扔給AI讓它“寫一個登錄腳本”結果它確實寫了寫得還像模像樣但一提交代碼評審問題就全出來了沒用頁面對象、等待全靠sleep、定位符寫絕對XPath甚至直接new了一個新的driver實例。負責review的同事看完一臉懵說這代碼根本進不了我們的框架。后來我慢慢想明白一個道理AI不是不會寫代碼是你沒把它放進你家的規(guī)矩里。這篇文章是“AI for Testing 提效實戰(zhàn)”系列里執(zhí)行自動化的第一篇不聊概念就聊怎么讓AI在你的框架內產(chǎn)出能直接合入的腳本。1. AI生成的代碼為什么總是和你的工程格格不入1.1 看起來能跑的腳本實際上是一堆技術債你在AI聊天框里要一個“登錄并把用戶名拼到首頁上”的UI自動化用例它大概率給你類似這樣的東西from selenium import webdriver import time driver webdriver.Chrome() driver.get(https://demo-app.example.com/login) driver.find_element_by_id(username).send_keys(tester) driver.find_element_by_id(password).send_keys(123456) driver.find_element_by_xpath(/html/body/div[1]/div/form/button).click() time.sleep(3) assert 歡迎tester in driver.page_source driver.quit()單看這段代碼邏輯沒錯放到一個一次性爬蟲腳本里完全能跑。但如果你所在的是一個多人協(xié)作、要長期維護的自動化測試工程它幾乎是不可合入的。原因很直接工程里已經(jīng)規(guī)定所有頁面操作都要封裝到Page Object里driver實例統(tǒng)一由框架初始化并管理等待必須走框架封裝好的顯式等待方法定位符優(yōu)先使用測試專用屬性。而AI生成的代碼把這些全忽略了。有人可能會說這不就是讓AI生成完再人肉改一改嘛也能用。但“改一改”的成本往往比從零寫還高。尤其是當你一個月要生成幾十上百條用例時每條都要重構一遍那AI的價值就只剩個“偽代碼起草器”了。所以核心問題不在AI寫得好不好而在于你讓它開工之前有沒有把“你們家的代碼長什么樣、有什么規(guī)矩”告訴它。1.2 AI并不是不聰明而是沒有你頭腦里的“框架心智”大模型在訓練時看過海量代碼它對通用編碼風格非常熟悉包括公開教程里最常見的直接new driver、time.sleep、find_element_by_xpath那一套。但它不知道的是你們團隊的BasePage封裝了什么、用例層能做什么不能做什么、失敗截圖是誰負責處理的、測試數(shù)據(jù)從哪里讀。這些信息不會出現(xiàn)在任何公開代碼庫里而是你所在工程多年迭代沉淀下來的隱性約定。我把這些約定稱為“框架心智”。老測試開發(fā)在寫用例時腦子里會下意識地調用這些約定就像老司機開車不需要思考檔位和剎車。但AI默認沒有這套心智你不主動喂給它它就只能按通用套路來而通用套路和團隊標準之間隔著一大段代碼評審的距離。所以“讓AI在你的框架里寫”這句話字面上就是第一步要做的把項目結構、核心接口、參考用例、運行方式、禁用項整理成一份它能直接讀取的上下文。這一步做扎實了后面才有“直接合入”的可能性。2. 把“框架上下文”整理成提示詞是合入的第一步2.1 上下文包的五類材料我試過很多種喂AI的方式最后收斂下來一份高質量的上下文包只需要包含五類材料。不需要把整個倉庫塞給它也不需要寫幾百行的框架源碼重點是讓它知道“怎么寫才像我們自己人”。第一類是目錄結構節(jié)選。不需要完整列出只展示用例相關的三層核心層級就夠了比如project/ ├── pages/ # Page Object頁面元素與操作封裝在這里 ├── cases/ # 測試用例只負責業(yè)務流程與斷言 ├── utils/ # 公共工具比如數(shù)據(jù)生成、配置讀取 └── runner.py # 執(zhí)行入口第二類是核心基類接口。把頁面對象和用例基類里常用的方法簽名給出來AI才知道哪些動作是現(xiàn)成的不需要自己造輪子class BasePage: def click(self, locator: tuple) - None def input_text(self, locator: tuple, text: str) - None def wait_until_visible(self, locator: tuple, timeout: int 10) - WebElement def get_text(self, locator: tuple) - str class BaseCase: def login(self, username: str, password: str) - HomePage第三類是2到3條已經(jīng)合入的參考用例。最好挑典型的表單填寫、列表校驗、按鈕跳轉各一條。AI很擅長模仿給它一個高質量樣例它會照著風格寫比給它一堆抽象規(guī)則更有用。第四類是運行方式與測試數(shù)據(jù)約定。比如命令行入口是什么、測試數(shù)據(jù)放在哪個目錄、測試結束是否需要自動清理。這些不屬于代碼語法但決定生成出來的用例能不能直接接進執(zhí)行鏈路。第五類是明確禁用項。這條最重要。把你們歷史上踩過的典型坑直接寫成“禁止”比如禁止time.sleep、禁止絕對XPath、禁止在用例層直接寫locator、禁止調用未封裝的外部資源。AI是概率模型它的“默認行為”來自海量訓練數(shù)據(jù)只有用明確的負面清單才能壓過那些默認行為。2.2 一套可以直接抄的Prompt框架材料準備好之后每次生成用例時我會用下面這個提示詞框架它把剛才說的內容都壓縮成一段結構化的約束你是我團隊的測試開發(fā)工程師。請按照當前工程約定編寫一條UI自動化測試用例。 目標場景{具體操作步驟與業(yè)務預期} 工程結構 {pages/ 與 cases/ 目錄結構節(jié)選} 核心接口 {BasePage 與 BaseCase 方法簽名} 參考用例 {一條已合入標準的用例代碼} 運行方式 python runner.py --case {case_name} 硬性約束 1. 頁面元素定位必須寫在 pages/ 下對應的Page類中cases/ 里只允許調用Page對象方法 2. 禁止使用 time.sleep等待統(tǒng)一調用 wait_until_visible 或 wait_until_clickable 3. 禁止使用絕對XPath元素定位優(yōu)先使用專屬 test-id 或相對定位策略 4. 不要打印日志、不要直接截圖日志與截圖由框架統(tǒng)一處理 5. 輸出必須是完整可運行的代碼不要額外解釋 請給出 cases/ 下用例文件路徑與完整代碼。這個Prompt的核心是“場景描述 框架約束 參考樣式”。場景描述要具體到“進入列表頁點擊第一行的編輯按鈕修改狀態(tài)為啟用保存后斷言提示成功”而不是“測一下編輯功能”。約束越具體AI越不會自由發(fā)揮。2.3 上下文不需要“全量源碼”給接口和約定就夠了剛開始有同事會把整個項目代碼打包成一個文件喂給AI覺得信息越全越準。實際效果恰恰相反。上下文太長時模型注意力會被大量無關實現(xiàn)稀釋最后產(chǎn)出的代碼反而偏離約束。你只需要給“支撐這一個用例的最小上下文”——它要調用的接口、要遵循的寫法、要模仿的樣例。這就像新員工入職不需要讀全公司代碼庫只需要先了解自己崗位涉及的模塊和相關規(guī)范干幾天活自然就上手了。這個思路也直接決定了真實成本。大模型按token計費動不動喂全量源碼既貴又慢。用精簡上下文單次生成消耗很小而且迭代反饋時也能快速調整不會因為每次都帶一大堆歷史代碼而拖慢速度。我們后來甚至把上下文包按模塊拆成好幾個版本登錄測試用登錄上下文訂單測試用訂單上下文準確率比一個“全量包”高出一截。3. 從AI輸出到合入分支四道檢查一個都不能少3.1 自動檢查把“骨架一致性”交給腳本即使上下文包寫得很完善AI偶爾還是會漏掉一兩條約束。所以第一條質量閘門應該自動完成不要靠人肉review去盯“是否用了sleep”這種問題。我在團隊里做了一組靜態(tài)檢查腳本用AST解析AI生成的用例文件重點檢查是否 import 了 time、selenium 這類應該由框架統(tǒng)一管理的模塊用例類中是否直接出現(xiàn)定位元組或XPath字符串是否調用了 pages/ 下已經(jīng)存在的頁面對象方法是否在斷言前使用了框架要求的顯式等待。這些檢查規(guī)則不需要很復雜正則加AST就能搞定。檢查不通過時直接把報錯信息返回給AI讓它基于報錯再改一輪。我發(fā)現(xiàn)這一步能把“初版不經(jīng)用”的比例從七成以上降到四成以下效果立竿見影。3.2 框架內試運行先證明它能在你家的環(huán)境里跑靜態(tài)檢查過了不代表能跑。第二個閘門是把AI生成的用例真正放進你的執(zhí)行框架里跑一次。我們會把新生成的用例先放到cases/ai_pending/目錄標記為冒煙用例跑一個專門的快速冒煙任務。這個任務只覆蓋目標用例依賴的前置數(shù)據(jù)盡量控制在5分鐘內出結果。通過后腳本會自動把用例移動到正式cases/目錄失敗的話就把日志和錯誤信息回投給AI讓它自己修正。這個“生成—運行—回喂—再生成”的循環(huán)是整個執(zhí)行自動化鏈路里最值錢的部分。因為AI模型本身不具備執(zhí)行能力它無法感知“這段代碼在當前環(huán)境下能不能跑”但你的框架可以?？蚣茇撠焾?zhí)行和反饋AI負責根據(jù)反饋修改兩者配合才真正形成閉環(huán)。3.3 人工評審只看增量不給AI重寫試運行通過后才算輪到人工評審。這里最容易犯的錯誤是reviewer忍不住親自上手改代碼把AI寫的東西重寫一遍。一旦這樣做AI就變成只能生成“初稿”的工具效率提升非常有限。我的建議是人工評審只做語義審核給reviewer一張檢查清單業(yè)務斷言是否完備關鍵狀態(tài)有沒有校驗測試數(shù)據(jù)是否可復用會不會污染其他用例用例名稱與模塊劃分是否符合工程規(guī)劃有沒有把測試邏輯和業(yè)務邏輯混在一起只要不滿足就把意見描述清楚再交給AI去改。比如“這里只校驗了提交成功提示沒有校驗列表里新增數(shù)據(jù)的展示值”AI通常會很快補上。人工專注業(yè)務正確性語法和格式問題全部交給前面的自動檢查去管評審速度會快很多。3.4 合入之后在回歸集里觀察兩天合入分支不等于完事。執(zhí)行自動化最怕的就是用例剛合入時能跑過兩天就flaky。我們的做法是給新合入用例設置一個觀察期在CI報告里標記為new_case連續(xù)跑5次全量回歸全部通過后才轉成正式用例。觀察期內一旦出現(xiàn)偶發(fā)失敗先查定位符和等待邏輯不要簡單屏蔽。這個機制看著保守但能極大地減少“AI生成的用例污染回歸集”的風險。對“直接合入”這個目標來說前面三道閘門是讓代碼滿足工程規(guī)范第四道閘門是讓代碼滿足穩(wěn)定性要求。四道都過了AI產(chǎn)出才算真正進入資產(chǎn)池。4. 執(zhí)行自動化落地中真正毀掉“直接合入”的兩個隱藏殺手4.1 脆弱的定位符死在第一輪回歸執(zhí)行自動化里AI生成用例最常死在第一輪回歸的就是元素定位。你可以在提示詞里寫一百句“請使用穩(wěn)定的定位符”但如果沒給出可操作的標準AI還是很容易寫出/html/body/div[2]/div[3]/form/div/input或者帶隨機后綴的id。原因還是訓練數(shù)據(jù)大量公開腳本為了快速演示直接用絕對XPath和當前頁面結構。我們后來在上下文包和自動檢查里同時加了硬性規(guī)定優(yōu)先使用>