本文整理自QCon北京《蔡明哲 - 透過Agent Skill、MCP再到Pre 的全鏈路智能化流程與實踐方案》通過AI音視頻總結(jié)工具Ai好記視頻轉(zhuǎn)文字轉(zhuǎn)錄整理以下為精煉整理后的會議筆記內(nèi)容。先拋一個和每個測試團隊都相關(guān)的問題AI 對 QA 來說幫助更多還是威脅更多作者用 Shopify 的 CTO 在 GitHub 上的 commit 數(shù)量做了個對比團隊開發(fā)速度被 AI 明顯拉快了如果 QA 跟不上開發(fā)的節(jié)奏整個迭代就會卡在測試這個環(huán)節(jié)。這篇文章講的就是一個 QA 團隊如何透過 Agent Skills、MCP 和 Playwright 這些技術(shù)把從需求分析到測試執(zhí)行的整個鏈路智能化讓 QA 從執(zhí)行者轉(zhuǎn)向架構(gòu)師。用 AI 的幾類典型問題團隊在日常中發(fā)現(xiàn)大家用 AI 很容易踩幾個坑。一是不知道工具怎么用把 AI 該做的重復(fù)工作留給人做把需要人判斷的留給 AI。二是對 AI 過度信任或不信任有人堅信自己寫的代碼比 AI 強有人則 AI 出什么就發(fā)什么。三是工具孤島測試管理平臺、缺陷平臺、AI 工具、文檔平臺各自獨立數(shù)據(jù)沒法串接。四是用錯工具典型例子是打開通用的 AI 網(wǎng)頁說「你是一位資深測試工程師請幫我寫測試用例」結(jié)果是通用模型不懂業(yè)務(wù)領(lǐng)域知識生成出一堆不可用的用例于是得出 AI 不可靠的結(jié)論。五是工具效能沒釋放會用的藏著掖著大家重復(fù)造輪子。從日常流程切入找 AI 能介入的點作者強調(diào)不要為了做而做而是先梳理日常測試流程STLC 環(huán)節(jié)、每個 sprint 怎么跟其他團隊協(xié)作找出耗時最長、最值得改進的地方再針對性地讓 AI 介入。最終確定了四個方向測試用例生成、測試腳本生成、產(chǎn)品業(yè)務(wù)知識提取、用戶反饋 log 分析。Agent Skills 的核心實踐測試用例生成新需求的用例生成主要通過 Agent Skills 來做好處是漸進式披露、結(jié)構(gòu)化輸出和執(zhí)行步驟。流程是理解需求文檔、識別測試場景、按定義結(jié)構(gòu)產(chǎn)生輸出。作者分享了幾個經(jīng)驗QA 的基礎(chǔ)認知決定了 Skill 質(zhì)量負責創(chuàng)建 Skill 的人如果對業(yè)務(wù)邏輯和 QA 方法論不清晰生成結(jié)果會有遺漏邊界值過寬松、用戶路徑輸出不好。拆分測試類型不要指望一個 Skill 同時做壓測和普通用例每個 Skill 專注一件事。規(guī)范結(jié)構(gòu)清楚定義輸出格式。一個策略調(diào)整由于通用大模型不懂業(yè)務(wù)邏輯且產(chǎn)品迭代快兩周可能改一次頁面他們不生成完整測試案例而是先生成測試點test point即什么時間點做什么事、預(yù)期結(jié)果是什么采納率比生成完整案例高很多。成對組合測試Pairwise系統(tǒng)測試步驟參數(shù)很多時比如交易系統(tǒng)的交易類型、卡片類型、賬戶類型排列組合能到 1 萬 9 千多種組合。Pairwise 的目標是用最少的用例達到最高覆蓋作者發(fā)現(xiàn)兩兩成對的組合是中最高效的能把整體用例壓縮到 30 個以內(nèi)。過去靠跑腳本生成現(xiàn)在封裝成 SkillAgent 可以自動提取關(guān)鍵參數(shù)、執(zhí)行腳本并生成用例。基于代碼變更的智能化測試有幾千上萬個測試用例回歸時不可能全部執(zhí)行。這個流程會先給大模型 GitHub 的 PR 或 tag通過 GitHub 的 MCP 抓取代碼變更、提交人、PR 評論定位文件改動和相關(guān)點再抓取關(guān)聯(lián)的 Jira 需求文檔理解改動背景同時補充產(chǎn)品知識后做分析判斷影響哪個板塊、風險最高再通過 MCP 把相關(guān)測試用例抓回來挑選輸出最后在測試管理平臺自動創(chuàng)建 test plan。這里有個處理產(chǎn)品大文本的踩坑經(jīng)歷code 里的 RAG 方式先提取關(guān)鍵字再全文檢索但文檔中英混合時效率結(jié)果不理想換更大 token 的模型讓多 agent 各讀檔案再總結(jié)token 消耗大又慢最終改成先把技術(shù)文檔做語義相似度提取去重、精簡既省 token 又快。產(chǎn)品業(yè)務(wù)知識提取不用傳統(tǒng) RAG團隊最早嘗試建傳統(tǒng)的 RAG 系統(tǒng)用向量化工具或向量庫結(jié)果遇到三個問題技術(shù)落地門檻高QA 工程師需要背景知識圖片、表格、長文本文檔臟數(shù)據(jù)清洗和向量化是大工程做不好匹配率低知識更新成本高產(chǎn)品迭代快要不停清理向量庫。最終改用新的思路做意圖分層先判斷問題屬于哪個業(yè)務(wù)場景再動態(tài)加載對應(yīng)技術(shù)文檔按長短文本分別處理。這樣維護的只是背后的知識文檔不用跑整套 RAG pipeline。MCP 打通工具孤島團隊大量的工具底層打通都靠 MCP。當開源或官方 MCP 不符合使用情境時會借助 AI 力量做一個貼近自己使用場景的 MCP。MCP 和 Agent Skills 是可混搭的很多 Skill 在運行時會再去調(diào)用別的 MCP。Playwright Agent 生成測試腳本Playwright Agent 內(nèi)部有三個 AgentPlanner Agent 像資深 QA 一樣起一個瀏覽器判斷測試意圖Generator Agent 針對測試案例生成腳本代碼Repair Agent 做自動修復(fù)基于無障礙accessibility tree的方式讀取頁面比傳統(tǒng) DOM 解析效率更高、意圖識別更準。一個很實用的能力是同時生成 UI 和 API 測試在 Agent 執(zhí)行 UI 操作時通過 hook 記錄下觸發(fā)的所有網(wǎng)絡(luò)請求最終把 UI 操作步驟和捕獲的 API 請求一起輸出同一個測試用例下同時產(chǎn)出 UI 自動化和 API 自動化腳本。當 Playwright Agent 只支持 JavaScript 時可以創(chuàng)建一個 Skill 把 JS 腳本轉(zhuǎn)成 pytest告訴它 JS 用法映射到 pytest 哪個 API、項目架構(gòu)、編碼規(guī)范。構(gòu)建好 Agent Skills 的四個準則邏輯確定性能用 Python 或腳本執(zhí)行的盡量用代碼執(zhí)行降模型幻覺輸出更可控。顯性激勵約束在 prompt 里明確品質(zhì)優(yōu)先同時告訴模型不該做什么限定邊界。權(quán)重分配最不希望或最希望做的放 markdown 文本上方用強調(diào)方式保證模型注意力。避免超大 Skill拆成多個小 Skill 互相調(diào)用。幾個使用技巧善用 IDE 的 prompt 功能艾特文件、斜杠命令先把意圖定義清楚搭配 agent 模式和 bug 模式增強輸出處理彈窗、下拉這類影響 AI 執(zhí)行的特殊交互先在頁面初始化時剔除最后模型能力直接決定成效差一點的模型輸出確實不行能直上就直上。用戶反饋 log 分析研發(fā)排查問題時不斷和 AI 對話定位后讓 AI 把整個排查過程壓縮成一個 Skill 上傳到平臺其他團隊上傳 log 時自動匹配這些 Skill 做分析并反饋。這樣讓大家一起參與 Skill 維護更快地分析問題。未來展望一是通過代碼知識圖譜實現(xiàn)更精準的測試用例篩選解析代碼、抽象語法樹知道每個函數(shù)、變量之間的關(guān)聯(lián)某個函數(shù)改動時能拉出上下游調(diào)用鏈路的函數(shù)一起分析回歸測試更準。二是預(yù)先冒煙機制在 PR 階段讓 AI 作為公正的第三方針對本次新功能變更生成測試用例、用 Playwright 自動執(zhí)行輸出 pass 或 fail生成的腳本沉淀回自動化倉庫提交 PR實現(xiàn)「新功能提交時已經(jīng)讓 AI 做過冒煙測試」的閉環(huán)。回到開頭的問題作者認為現(xiàn)階段 AI 對 QA 是幫助更多。真正受威脅的是還不太會用 AI 的人。就像汽車問世后養(yǎng)馬人、車夫消失但出現(xiàn)的是修車人和汽車工人QA 的價值會從專注執(zhí)行測試轉(zhuǎn)向測試架構(gòu)師回歸本質(zhì)把產(chǎn)品品質(zhì)做好。衡量的標準是測得更深、更廣、更快。以上內(nèi)容由 Ai好記 轉(zhuǎn)錄整理。Ai好記是一款支持音視頻轉(zhuǎn)圖文筆記的AI知識庫工具支持B站、小紅書、抖音、小宇宙等平臺鏈接及本地音視頻文件視頻轉(zhuǎn)文字后自動生成精華速覽、思維導(dǎo)圖和結(jié)構(gòu)化圖文筆記幫助你把幾小時的視頻內(nèi)容變成可搜索、可復(fù)習的圖文筆記。