[圖片上傳失敗...(image-22ab32-1778291323683)]
前天面試了一個有著五年經(jīng)驗的測試工程師。
簡歷上寫得挺漂亮：熟練使用AI生成測試用例，用AI實現(xiàn)自動化測試。我心想，這哥們兒應(yīng)該有點東西，就拋了一個真實的項目問題過去。
沒想到，他的回答把我驚呆了。
題目是這樣的：
你用AI做測試，需求文檔是完整的電商訂單流程。AI生成了120條測試用例，3000 行UI自動化腳本，覆蓋了正向下單、支付、退款流程。結(jié)果上線后一小時，大量用戶反饋無法完成訂單支付。
排查發(fā)現(xiàn)兩個核心問題：
- AI生成的用例漏了訂單金額為0.01元的邊界值、支付時網(wǎng)絡(luò)中斷重試這兩個關(guān)鍵場景
- 自動化腳本只實現(xiàn)了點擊操作，沒有斷言支付成功后訂單狀態(tài)變?yōu)榇l(fā)貨，也沒有處理支付超時的異常場景，導(dǎo)致測試時沒發(fā)現(xiàn)問題，上線后直接引發(fā)生產(chǎn)故障。
我接著追問了三個問題，每一個都是面試必問：
第一，你在審核AI生成的訂單支付用例時，怎么判斷AI有沒有漏測邊界值異常場景？
第二，自動腳本跑通就代表沒問題嗎？你會具體檢查腳本的哪些細節(jié)，如何避免沒有斷言、沒有異常處理的情況。
第三，這次故障后，你會怎么優(yōu)化AI測試的流程，保證下次不再出現(xiàn)漏測腳本無效的問題？
沒想到，他張口就來：
"我就把AI生成的用例大致掃了一遍，看步驟完整、沒有明顯錯誤就夠了。"
"腳本能跑通就行，沒必要查那么細。"
"故障后……下次讓AI多生成幾條用例，再多看兩眼就好了。"
聽到這里，我心里嘆了口氣。
兄弟，你這根本不是懂AI測試，你就是拿AI當(dāng)甩手掌柜。AI一天能生成幾百條用例、幾萬行腳本，你粗略掃一眼，能發(fā)現(xiàn)藏在細節(jié)里的邊界漏洞、斷言缺失嗎？
他不知道該怎么回答了，面試到這里，基本也就結(jié)束了。
這道題為什么能篩掉大部分人？
說實話，這類題我面了不下二十幾個人，能答到點上的不超過三個。
很多人有個誤區(qū)：覺得會用AI生成幾條用例、讓Copilot寫幾行Selenium腳本，就叫"AI測試"了。
大家一定要明白一個核心真相，AI擅長批量生成模板化輸出，但永遠不懂隱性業(yè)務(wù)，不懂行業(yè)規(guī)則，不懂項目歷史問題。
AI最大的隱患不是寫不出用例，而是特別容易產(chǎn)出看起來專業(yè)，實際全是漏洞的內(nèi)容。
比如漏掉權(quán)限互斥場景、忽略流程依賴關(guān)系、邊界值只寫常規(guī)，不寫極值、異常場景只做表面覆蓋、自動化腳本缺少關(guān)鍵斷言、接口測試漏了參數(shù)加密和并發(fā)場景等。
比如，AI生成測試內(nèi)容的常見翻車點：
| 翻車類型 | 具體表現(xiàn) | 危害等級 |
|---|---|---|
| 邊界值漏測 | 只寫常規(guī)值，不寫極值（如0.01元、999999.99元） | ?? 高 |
| 異常場景表面化 | 寫了"網(wǎng)絡(luò)異常"，但沒寫異常后的狀態(tài)恢復(fù) | ?? 高 |
| 權(quán)限互斥缺失 | 沒覆蓋"同時操作沖突"（如退款+退貨并發(fā)） | ?? 高 |
| 斷言缺失 | 腳本只點不驗，跑通≠通過 | ?? 中 |
| 流程依賴斷裂 | 步驟A失敗后重試，步驟B的狀態(tài)沒同步校驗 | ?? 中 |
| 參數(shù)安全忽略 | 接口測試漏了加密、防篡改、并發(fā)場景 | ?? 中 |
| 重復(fù)冗余 | 同一個場景換說法生成多條，浪費執(zhí)行資源 | ?? 低 |
這也是初級測試和高級測試的核心分水嶺：前者只看 AI 產(chǎn)出的 “數(shù)量”，后者能看透背后的風(fēng)險，用系統(tǒng)化方法駕馭 AI。
真正玩轉(zhuǎn)AI測試，需要五層質(zhì)量管控體系
結(jié)合我多年的實戰(zhàn)經(jīng)驗，以及踩過的 AI 測試坑，我始終認為：想要真正用好 AI 測試，既發(fā)揮它的效率優(yōu)勢，又杜絕漏測、錯測、無效用例上線，絕不能 “甩手掌柜式” 用 AI，而是要建立一套完整的 AI 測試全流程質(zhì)量管控體系。
這不是簡單的 “讓 AI 多生成幾條用例、多看兩眼”，而是從需求到復(fù)盤的全鏈路把控，每一步都要融入人的專業(yè)判斷和業(yè)務(wù)經(jīng)驗。
我把這套體系，分為五個層級，每一層都是面試高頻考點，也是實際工作能落地的標準流程。
第一層：業(yè)務(wù)需求前置拆解，不給AI盲目發(fā)揮的機會
很多人用AI測試最大的誤區(qū)，就是直接把一份籠統(tǒng)的需求文檔丟給AI，讓它自由發(fā)揮生成測試用例。
這本身就是最大的風(fēng)險。
AI看不懂文字背后的隱性規(guī)則，也不知道你們項目過往的高頻缺陷點。
比如"支付功能"三個字，AI理解的就是"輸入金額→確認支付→扣款成功"。但它不會知道：
你們的支付通道有金額下限（0.01元）
網(wǎng)絡(luò)中斷后需要支持3次重試，每次間隔5秒
支付超時后訂單狀態(tài)要回滾為"待支付"，不能卡在"支付中"
同一筆訂單不能重復(fù)支付（冪等性）
正確的做法是先人工拆解需求，梳理出幾大模塊：
核心業(yè)務(wù)流程（主路徑必須100%覆蓋）
次要分支流程（異常分支、降級方案）
隱藏業(yè)務(wù)規(guī)則（風(fēng)控攔截、金額限制、時間窗口）
權(quán)限角色劃分（普通用戶/VIP/管理員的不同邏輯）
邊界極值清單（最小值、最大值、空值、超長值）
異常故障場景（網(wǎng)絡(luò)中斷、服務(wù)超時、數(shù)據(jù)不一致）
安全風(fēng)控要求（SQL注入、越權(quán)訪問、敏感信息脫敏）
把這幾大模塊的結(jié)構(gòu)化清單、歷史Bug案例、業(yè)務(wù)禁止規(guī)則，一起喂給AI，限定生成范圍，限定覆蓋維度。讓AI在你劃定的框架內(nèi)產(chǎn)出，而不是任由它隨意編造業(yè)務(wù)邏輯。
尤其是支付、訂單、用戶權(quán)限、數(shù)據(jù)隱私、資金流轉(zhuǎn)這類核心模塊，
必須提前做場景鎖定，強制 AI 全覆蓋，絕不讓它隨意編造業(yè)務(wù)邏輯。這一步的核心是 “人主導(dǎo)、AI 輔助”，用人工的業(yè)務(wù)理解彌補 AI 的認知盲區(qū)。
第二層：給 AI 產(chǎn)出 “做減法”，篩選有效內(nèi)容
AI產(chǎn)出的測試用例，從來不是全部可用的。而是要學(xué)會快速分類篩選：
第一類：標準正向用例
常規(guī)流程、基礎(chǔ)操作
AI基本不會出錯，可以直接保留
占比約60%-70%
第二類：待修改用例
邊界值不精準（如寫了"輸入負數(shù)"，但沒寫具體-1還是-0.01）
異常場景描述模糊（如"網(wǎng)絡(luò)異常"沒定義異常類型）
步驟順序錯亂
這類不用直接刪掉，人工微調(diào)后就能復(fù)用
第三類：直接廢棄用例
邏輯前后矛盾（如前置條件說"未登錄"，步驟里卻要求"點擊個人中心"）
編造不存在的業(yè)務(wù)功能（AI"幻覺"出來的菜單或按鈕）
重復(fù)冗余（同一個場景換說法寫了3遍）
完全脫離實際業(yè)務(wù)（如電商系統(tǒng)里出現(xiàn)"火箭發(fā)射"的測試步驟——別笑，我真見過）
這類必須直接剔除，絕對不能混入測試套件
同時還要檢查自動化腳本，看腳本是否只實現(xiàn)了頁面操作，缺少結(jié)果斷言，缺少異常捕獲，缺少環(huán)境兼容適配，這類腳本跑通也沒有任何測試意義，必須整改。
這一步的關(guān)鍵是 “不迷信 AI 產(chǎn)出”，用人工的專業(yè)判斷篩選出真正有價值的內(nèi)容，避免無效用例占用測試資源。
第三層：多維度量化校驗，不靠感覺，靠數(shù)據(jù)
判斷AI測試用例可不可靠，不能憑肉眼感覺，要有量化標準。
首先，核對需求覆蓋率，對照需求文檔每一個功能點，檢查有沒有遺漏、未覆蓋的模塊。
其次，統(tǒng)計反向用例、邊界用例、異常用例的占比。正常業(yè)務(wù)不能只有正向用例，沒有反向和異常兜底。然后排查重復(fù)用例率、邏輯錯誤率、高危場景遺漏率。
結(jié)合項目歷史缺陷庫，校驗AI有沒有覆蓋過往線上出過的同類bug
具體供參考：
| 校驗維度 | 具體做法 | 合格線 |
|---|---|---|
| 需求覆蓋率 | 對照需求文檔逐條映射，看每個功能點有沒有對應(yīng)用例 | ≥95% |
| 反向用例占比 | 反向/異常用例占總用例比例 | ≥30% |
| 邊界用例數(shù)量 | 每個數(shù)值型字段至少2個邊界值（最小、最大） | 100%覆蓋 |
| 重復(fù)用例率 | 語義重復(fù)的用例占比 | ≤10% |
| 邏輯錯誤率 | 業(yè)務(wù)邏輯錯誤或無法執(zhí)行的用例占比 | ≤5% |
| 高危場景遺漏率 | 權(quán)限/并發(fā)/弱網(wǎng)/非法輸入/參數(shù)篡改等場景 | 0% |
| 歷史缺陷覆蓋率 | 過去3個版本的線上Bug，AI用例能否覆蓋 | ≥80% |
除此之外，還要重點核對AI最容易忽略的高危場景，比如
權(quán)限互斥：越權(quán)訪問、角色切換后的權(quán)限殘留
并發(fā)場景：同一用戶多設(shè)備登錄、秒殺搶購
弱網(wǎng)環(huán)境：2G網(wǎng)絡(luò)、網(wǎng)絡(luò)切換、飛行模式
非法輸入：SQL注入、XSS、路徑遍歷、特殊字符
接口安全：參數(shù)加密、簽名驗證、重放攻擊
這些是 AI 最容易忽略，但最容易引發(fā)線上故障的點，用數(shù)據(jù)做校驗，才是專業(yè)測試的做事方式。
第四層：三級審核，用人工經(jīng)驗兜底，守住核心風(fēng)險
AI 永遠替代不了人的業(yè)務(wù)經(jīng)驗，核心場景必須層層把關(guān)，所以這里，我建議的做法是，建立 “初審 + 復(fù)核 + 終審” 的三級審核機制：
初審：用自動化工具批量過濾重復(fù)用例、格式錯誤、邏輯沖突的內(nèi)容，節(jié)省人工時間；
復(fù)核：由資深測試工程師負責(zé)，逐行校驗核心業(yè)務(wù)的邊界、極值、異常流程，尤其是支付、權(quán)限這類高危模塊，比如核對自動化腳本是否有斷言、異常捕獲、環(huán)境適配邏輯；
終審：由業(yè)務(wù)負責(zé)人或測試總監(jiān)確認，重點把關(guān)隱性需求和特殊業(yè)務(wù)規(guī)則，比如電商訂單的 “跨平臺退款規(guī)則”“節(jié)假日支付限額” 等 AI 無法理解的業(yè)務(wù)細節(jié)。
三道關(guān)卡層層過濾，能從根本上杜絕 AI 的錯漏內(nèi)容流入執(zhí)行階段，這也是規(guī)避線上故障的關(guān)鍵。
第五層：復(fù)盤沉淀，讓 AI 越用越 “懂” 業(yè)務(wù)，形成閉環(huán)
AI 測試不是一次性行為，一定要做長期沉淀優(yōu)化。
建議在每次項目結(jié)束后，記錄三類信息：
1、AI翻車案例庫
哪類場景AI容易漏測？
哪類業(yè)務(wù)AI容易編造規(guī)則？
哪類腳本容易出現(xiàn)斷言缺失？
2、優(yōu)質(zhì)模板庫
提示詞模板（不同業(yè)務(wù)類型的標準Prompt）
用例模板（正向/反向/邊界的標準格式）
腳本規(guī)范模板（斷言、異常處理、日志的代碼規(guī)范）
3、訓(xùn)練數(shù)據(jù)集
把歷史優(yōu)質(zhì)用例、業(yè)務(wù)規(guī)則、負面案例投喂給AI
讓AI越來越貼合團隊業(yè)務(wù)，生成內(nèi)容越來越精準
形成完整閉環(huán)：
需求拆解 → AI生成 → 分類篩選 → 量化校驗 → 三級審核 → 落地執(zhí)行 → 復(fù)盤沉淀 → 優(yōu)化提示詞 → 下一輪復(fù)用
[圖片上傳失敗...(image-9446e9-1778291323682)]
這才是成熟的AI測試工作模式。
為什么有人用AI效率翻倍，有人越用越漏測？
說到底，AI 測試的核心不是 “會不會用 AI 寫用例、出腳本”，而是 “能不能用人的專業(yè)能力約束 AI、校驗 AI、優(yōu)化 AI”，這也是前段時間AI 圈大火的Harness Engineering 所提倡的思想。
很多人覺得 AI 測試 “越用越坑”，本質(zhì)是把本該自己把控的質(zhì)量責(zé)任甩給了 AI；而真正能把 AI 用出效率的人，是把 AI 當(dāng)成 “高效的工具”，而非 “甩鍋的借口”。
最后想問問大家：你們在工作中用AI生成測試用例時，有沒有踩過類似的坑？AI有沒有漏過讓你后怕的邊界場景？歡迎在評論區(qū)交流，我盡量每條都回復(fù)。
