化測試的“假通過”怎么治？)
關(guān)注 霍格沃茲軟件測試開發(fā) 公眾號(hào)回復(fù)「資料」, 領(lǐng)取人工智能測試開發(fā)技術(shù)合集上周幫一個(gè)團(tuán)隊(duì)看 AI 生成的 UI 自動(dòng)化腳本。腳本跑得很漂亮打開頁面、填表、點(diǎn)擊提交最后頁面彈出“提交成功”報(bào)告里一片綠色。但測試同學(xué)順手去后臺(tái)查了一下——這筆申請根本沒有創(chuàng)建成功。原因并不復(fù)雜前端 Toast 提示先出來了接口實(shí)際返回異常而 AI 生成的腳本把“看見成功提示”當(dāng)成了唯一斷言。這類問題在研發(fā)團(tuán)隊(duì)接入 Coding Agent、AI 自動(dòng)化之后會(huì)越來越常見。AI 很會(huì)“把流程跑完”但不天然知道頁面完成一次點(diǎn)擊和業(yè)務(wù)真正成功不是一回事。01 AI 寫出了腳本為什么還會(huì)出現(xiàn)假通過現(xiàn)在用 Codex、Claude Code 這類工具補(bǔ)一條 Playwright 腳本已經(jīng)很方便。給它一個(gè)頁面、一段需求描述通常幾十秒就能生成這樣的代碼def test_apply_refund(page): page.goto(https://test.example.com/refund/apply) page.get_by_label(訂單號(hào)).fill(A20260831001) page.get_by_label(退款原因).select_option(重復(fù)下單) page.get_by_role(button, name提交申請).click() expect(page.get_by_text(提交成功)).to_be_visible()它的問題在于這段代碼只驗(yàn)證了頁面說自己成功了。但在真實(shí)業(yè)務(wù)中至少還可能出現(xiàn)幾種情況點(diǎn)擊后前端樂觀更新接口其實(shí)返回 500接口返回成功但退款單沒有正確落庫落庫成功但狀態(tài)機(jī)流轉(zhuǎn)錯(cuò)誤例如本應(yīng)是PENDING卻直接進(jìn)入了CLOSED測試環(huán)境里殘留舊數(shù)據(jù)頁面展示的是上一輪的結(jié)果。所以AI 自動(dòng)化最危險(xiǎn)的不是“腳本不會(huì)寫”。而是腳本把錯(cuò)誤的結(jié)果當(dāng)成了正確的驗(yàn)證標(biāo)準(zhǔn)。02 給 AI 一個(gè)“UI—接口—業(yè)務(wù)狀態(tài)一致性”Skill解決這件事不是每次都重新提醒 AI“不要只斷言頁面提示還要校驗(yàn)接口和數(shù)據(jù)?！备玫淖龇ㄊ前堰@條測試原則固化成一個(gè)項(xiàng)目級Skill。例如在倉庫里放一個(gè)ui-api-consistency/SKILL.md--- name: ui-api-consistency description: 用于涉及創(chuàng)建、提交、支付、審批等關(guān)鍵業(yè)務(wù)操作的 UI 自動(dòng)化測試 --- ## 測試規(guī)則 1. 不允許只用 Toast、彈窗或按鈕狀態(tài)作為成功斷言。 2. 必須捕獲關(guān)鍵請求并校驗(yàn) HTTP 狀態(tài)碼和響應(yīng)體關(guān)鍵字段。 3. 對創(chuàng)建類操作必須通過業(yè)務(wù)查詢接口驗(yàn)證最終狀態(tài)。 4. 斷言應(yīng)覆蓋請求參數(shù)、接口響應(yīng)、業(yè)務(wù)實(shí)體狀態(tài)。 5. 測試失敗時(shí)輸出 requestId、響應(yīng)體和頁面截圖便于定位。它的價(jià)值不在于多寫了一個(gè) Markdown 文件。而在于以后無論是 Codex、Claude Code還是團(tuán)隊(duì)里其他人調(diào)用 Agent 補(bǔ)腳本都能沿用同一套質(zhì)量規(guī)則。Prompt 是一次性對話。 Skill 是可復(fù)用、可審查、可跟隨項(xiàng)目演進(jìn)的測試經(jīng)驗(yàn)。03 Playwright 負(fù)責(zé)操作MCP 負(fù)責(zé)讓 Agent 看見真實(shí)系統(tǒng)有了規(guī)則還要讓 Agent 真正拿到驗(yàn)證業(yè)務(wù)結(jié)果的能力。這時(shí)可以把能力拆開能力在測試中的作用Playwright操作頁面、監(jiān)聽網(wǎng)絡(luò)請求、獲取頁面狀態(tài)MCP連接 Swagger、測試數(shù)據(jù)服務(wù)、缺陷平臺(tái)、業(yè)務(wù)查詢接口等工具Skills固化什么時(shí)候必須做多層校驗(yàn)、失敗后輸出什么信息Coding Agent理解任務(wù)并組合調(diào)用這些能力生成或維護(hù)測試代碼下面把剛才那條“假通過”腳本改成真正能校驗(yàn)退款申請狀態(tài)的版本import pytest from playwright.sync_api import expect pytest.mark.e2e def test_apply_refund_should_create_pending_refund(page, api_client): order_no A20260831001 page.goto(https://test.example.com/refund/apply) page.get_by_label(訂單號(hào)).fill(order_no) page.get_by_label(退款原因).select_option(重復(fù)下單) # 1. 點(diǎn)擊動(dòng)作和關(guān)鍵接口請求必須綁定 with page.expect_response( lambda response: /api/refunds in response.url and response.request.method POST ) as response_info: page.get_by_role(button, name提交申請).click() response response_info.value # 2. 校驗(yàn)接口真正成功而不是只看頁面提示 assert response.status 201 payload response.json() refund_id payload[data][refundId] assert payload[data][status] PENDING # 3. 通過業(yè)務(wù)查詢接口確認(rèn)最終狀態(tài) refund api_client.get(f/api/refunds/{refund_id}).json()[data] assert refund[orderNo] order_no assert refund[status] PENDING # 4. 頁面反饋只作為體驗(yàn)層補(bǔ)充校驗(yàn) expect(page.get_by_text(退款申請已提交)).to_be_visible()這段代碼的核心不是“多寫了幾個(gè)斷言”。而是把一次業(yè)務(wù)提交拆成了三個(gè)層次頁面層用戶是否完成操作接口層服務(wù)是否真正成功處理請求業(yè)務(wù)層最終數(shù)據(jù)和狀態(tài)是否符合規(guī)則。這才是 AI 自動(dòng)化在關(guān)鍵鏈路上應(yīng)該有的測試思維。04 這類 Skill恰恰是團(tuán)隊(duì)接入 AI 后最該先沉淀的很多團(tuán)隊(duì)一上來就讓 AI 做“自動(dòng)生成測試用例”“自動(dòng)寫腳本”。真正跑一段時(shí)間才發(fā)現(xiàn)難的不是生成而是控制生成結(jié)果的質(zhì)量。建議優(yōu)先沉淀這幾類測試 Skills關(guān)鍵鏈路一致性 SkillUI、接口、數(shù)據(jù)庫或業(yè)務(wù)狀態(tài)的聯(lián)合校驗(yàn)失敗歸因 Skill自動(dòng)收集請求響應(yīng)、日志、截圖和 Trace輔助區(qū)分產(chǎn)品 Bug、環(huán)境問題、腳本問題測試數(shù)據(jù) Skill生成數(shù)據(jù)、清理數(shù)據(jù)、避免測試之間互相污染需求風(fēng)險(xiǎn)分析 Skill讀取 PRD、歷史缺陷和接口文檔輸出高風(fēng)險(xiǎn)測試點(diǎn)回歸報(bào)告 Skill按團(tuán)隊(duì)規(guī)范匯總通過率、失敗原因、風(fēng)險(xiǎn)項(xiàng)和發(fā)布建議。Skills 不是替代測試工程師判斷。它做的是把那些反復(fù)驗(yàn)證過的判斷標(biāo)準(zhǔn)先交給 AI 嚴(yán)格執(zhí)行。當(dāng)團(tuán)隊(duì)把這些規(guī)則逐步沉淀下來AI 才不會(huì)只是“跑得很快的腳本生成器”而會(huì)開始成為真正可控的質(zhì)量協(xié)作對象。如果你現(xiàn)在正在接觸 Codex、Claude Code、Skills、MCP 或 Playwright不妨先問自己一個(gè)問題AI 幫我把測試跑完了它驗(yàn)證的是頁面表象還是業(yè)務(wù)事實(shí)這兩者之間往往就是一條 Skill 的距離。我們近期也會(huì)圍繞 Agent、MCP、Skills、RAG 和 AI 自動(dòng)化測試持續(xù)拆解能夠放進(jìn)真實(shí)研發(fā)流程的測試場景。本文部分內(nèi)容參考了霍格沃茲測試開發(fā)學(xué)社整理的相關(guān)技術(shù)資料主要涉及軟件測試、自動(dòng)化測試、測試開發(fā)及 AI 測試等內(nèi)容側(cè)重測試實(shí)踐、工具應(yīng)用與工程經(jīng)驗(yàn)整理。 Skills + MCP + Playwright：AI 自動(dòng)化測試的“假通過”怎么治？
關(guān)注 霍格沃茲軟件測試開發(fā) 公眾號(hào)回復(fù)「資料」, 領(lǐng)取人工智能測試開發(fā)技術(shù)合集上周幫一個(gè)團(tuán)隊(duì)看 AI 生成的 UI 自動(dòng)化腳本。腳本跑得很漂亮打開頁面、填表、點(diǎn)擊提交最后頁面彈出“提交成功”報(bào)告里一片綠色。但測試同學(xué)順手去后臺(tái)查了一下——這筆申請根本沒有創(chuàng)建成功。原因并不復(fù)雜前端 Toast 提示先出來了接口實(shí)際返回異常而 AI 生成的腳本把“看見成功提示”當(dāng)成了唯一斷言。這類問題在研發(fā)團(tuán)隊(duì)接入 Coding Agent、AI 自動(dòng)化之后會(huì)越來越常見。AI 很會(huì)“把流程跑完”但不天然知道頁面完成一次點(diǎn)擊和業(yè)務(wù)真正成功不是一回事。01 AI 寫出了腳本為什么還會(huì)出現(xiàn)假通過現(xiàn)在用 Codex、Claude Code 這類工具補(bǔ)一條 Playwright 腳本已經(jīng)很方便。給它一個(gè)頁面、一段需求描述通常幾十秒就能生成這樣的代碼def test_apply_refund(page): page.goto(https://test.example.com/refund/apply) page.get_by_label(訂單號(hào)).fill(A20260831001) page.get_by_label(退款原因).select_option(重復(fù)下單) page.get_by_role(button, name提交申請).click() expect(page.get_by_text(提交成功)).to_be_visible()它的問題在于這段代碼只驗(yàn)證了頁面說自己成功了。但在真實(shí)業(yè)務(wù)中至少還可能出現(xiàn)幾種情況點(diǎn)擊后前端樂觀更新接口其實(shí)返回 500接口返回成功但退款單沒有正確落庫落庫成功但狀態(tài)機(jī)流轉(zhuǎn)錯(cuò)誤例如本應(yīng)是PENDING卻直接進(jìn)入了CLOSED測試環(huán)境里殘留舊數(shù)據(jù)頁面展示的是上一輪的結(jié)果。所以AI 自動(dòng)化最危險(xiǎn)的不是“腳本不會(huì)寫”。而是腳本把錯(cuò)誤的結(jié)果當(dāng)成了正確的驗(yàn)證標(biāo)準(zhǔn)。02 給 AI 一個(gè)“UI—接口—業(yè)務(wù)狀態(tài)一致性”Skill解決這件事不是每次都重新提醒 AI“不要只斷言頁面提示還要校驗(yàn)接口和數(shù)據(jù)?！备玫淖龇ㄊ前堰@條測試原則固化成一個(gè)項(xiàng)目級Skill。例如在倉庫里放一個(gè)ui-api-consistency/SKILL.md--- name: ui-api-consistency description: 用于涉及創(chuàng)建、提交、支付、審批等關(guān)鍵業(yè)務(wù)操作的 UI 自動(dòng)化測試 --- ## 測試規(guī)則 1. 不允許只用 Toast、彈窗或按鈕狀態(tài)作為成功斷言。 2. 必須捕獲關(guān)鍵請求并校驗(yàn) HTTP 狀態(tài)碼和響應(yīng)體關(guān)鍵字段。 3. 對創(chuàng)建類操作必須通過業(yè)務(wù)查詢接口驗(yàn)證最終狀態(tài)。 4. 斷言應(yīng)覆蓋請求參數(shù)、接口響應(yīng)、業(yè)務(wù)實(shí)體狀態(tài)。 5. 測試失敗時(shí)輸出 requestId、響應(yīng)體和頁面截圖便于定位。它的價(jià)值不在于多寫了一個(gè) Markdown 文件。而在于以后無論是 Codex、Claude Code還是團(tuán)隊(duì)里其他人調(diào)用 Agent 補(bǔ)腳本都能沿用同一套質(zhì)量規(guī)則。Prompt 是一次性對話。 Skill 是可復(fù)用、可審查、可跟隨項(xiàng)目演進(jìn)的測試經(jīng)驗(yàn)。03 Playwright 負(fù)責(zé)操作MCP 負(fù)責(zé)讓 Agent 看見真實(shí)系統(tǒng)有了規(guī)則還要讓 Agent 真正拿到驗(yàn)證業(yè)務(wù)結(jié)果的能力。這時(shí)可以把能力拆開能力在測試中的作用Playwright操作頁面、監(jiān)聽網(wǎng)絡(luò)請求、獲取頁面狀態(tài)MCP連接 Swagger、測試數(shù)據(jù)服務(wù)、缺陷平臺(tái)、業(yè)務(wù)查詢接口等工具Skills固化什么時(shí)候必須做多層校驗(yàn)、失敗后輸出什么信息Coding Agent理解任務(wù)并組合調(diào)用這些能力生成或維護(hù)測試代碼下面把剛才那條“假通過”腳本改成真正能校驗(yàn)退款申請狀態(tài)的版本import pytest from playwright.sync_api import expect pytest.mark.e2e def test_apply_refund_should_create_pending_refund(page, api_client): order_no A20260831001 page.goto(https://test.example.com/refund/apply) page.get_by_label(訂單號(hào)).fill(order_no) page.get_by_label(退款原因).select_option(重復(fù)下單) # 1. 點(diǎn)擊動(dòng)作和關(guān)鍵接口請求必須綁定 with page.expect_response( lambda response: /api/refunds in response.url and response.request.method POST ) as response_info: page.get_by_role(button, name提交申請).click() response response_info.value # 2. 校驗(yàn)接口真正成功而不是只看頁面提示 assert response.status 201 payload response.json() refund_id payload[data][refundId] assert payload[data][status] PENDING # 3. 通過業(yè)務(wù)查詢接口確認(rèn)最終狀態(tài) refund api_client.get(f/api/refunds/{refund_id}).json()[data] assert refund[orderNo] order_no assert refund[status] PENDING # 4. 頁面反饋只作為體驗(yàn)層補(bǔ)充校驗(yàn) expect(page.get_by_text(退款申請已提交)).to_be_visible()這段代碼的核心不是“多寫了幾個(gè)斷言”。而是把一次業(yè)務(wù)提交拆成了三個(gè)層次頁面層用戶是否完成操作接口層服務(wù)是否真正成功處理請求業(yè)務(wù)層最終數(shù)據(jù)和狀態(tài)是否符合規(guī)則。這才是 AI 自動(dòng)化在關(guān)鍵鏈路上應(yīng)該有的測試思維。04 這類 Skill恰恰是團(tuán)隊(duì)接入 AI 后最該先沉淀的很多團(tuán)隊(duì)一上來就讓 AI 做“自動(dòng)生成測試用例”“自動(dòng)寫腳本”。真正跑一段時(shí)間才發(fā)現(xiàn)難的不是生成而是控制生成結(jié)果的質(zhì)量。建議優(yōu)先沉淀這幾類測試 Skills關(guān)鍵鏈路一致性 SkillUI、接口、數(shù)據(jù)庫或業(yè)務(wù)狀態(tài)的聯(lián)合校驗(yàn)失敗歸因 Skill自動(dòng)收集請求響應(yīng)、日志、截圖和 Trace輔助區(qū)分產(chǎn)品 Bug、環(huán)境問題、腳本問題測試數(shù)據(jù) Skill生成數(shù)據(jù)、清理數(shù)據(jù)、避免測試之間互相污染需求風(fēng)險(xiǎn)分析 Skill讀取 PRD、歷史缺陷和接口文檔輸出高風(fēng)險(xiǎn)測試點(diǎn)回歸報(bào)告 Skill按團(tuán)隊(duì)規(guī)范匯總通過率、失敗原因、風(fēng)險(xiǎn)項(xiàng)和發(fā)布建議。Skills 不是替代測試工程師判斷。它做的是把那些反復(fù)驗(yàn)證過的判斷標(biāo)準(zhǔn)先交給 AI 嚴(yán)格執(zhí)行。當(dāng)團(tuán)隊(duì)把這些規(guī)則逐步沉淀下來AI 才不會(huì)只是“跑得很快的腳本生成器”而會(huì)開始成為真正可控的質(zhì)量協(xié)作對象。如果你現(xiàn)在正在接觸 Codex、Claude Code、Skills、MCP 或 Playwright不妨先問自己一個(gè)問題AI 幫我把測試跑完了它驗(yàn)證的是頁面表象還是業(yè)務(wù)事實(shí)這兩者之間往往就是一條 Skill 的距離。我們近期也會(huì)圍繞 Agent、MCP、Skills、RAG 和 AI 自動(dòng)化測試持續(xù)拆解能夠放進(jìn)真實(shí)研發(fā)流程的測試場景。本文部分內(nèi)容參考了霍格沃茲測試開發(fā)學(xué)社整理的相關(guān)技術(shù)資料主要涉及軟件測試、自動(dòng)化測試、測試開發(fā)及 AI 測試等內(nèi)容側(cè)重測試實(shí)踐、工具應(yīng)用與工程經(jīng)驗(yàn)整理。