從2小時到15分鐘：AI大模型驅(qū)動測試用例生成全流程實戰(zhàn)

傳統(tǒng)寫用例的方式越來越跑不動了？

做測試的朋友都懂，寫用例這活，看著簡單，真做起來全是坑。

• 第一個坑：太依賴人。一個老員工離職，新人接手，同樣的模塊寫出來的用例天差地別。老手能想到的各種異常分支、邊界情況，新人根本意識不到。最后線上出故障，一查全是邊緣場景沒覆蓋。
• 第二個坑：復(fù)雜業(yè)務(wù)拆不動。尤其是電商訂單、金融交易這種多狀態(tài)流轉(zhuǎn)的業(yè)務(wù)——訂單有已支付、未支付、退款中、已關(guān)閉好幾種狀態(tài)，每種狀態(tài)下能做什么操作、不能做什么操作，還得考慮狀態(tài)之間怎么跳轉(zhuǎn)。人工梳理一遍，腦子都得炸，更別說寫全了。
• 第三個坑：迭代一次，痛苦一次。產(chǎn)品每周發(fā)版，功能變一點，舊用例就廢一片。到底是刪還是改還是留著？全靠人工篩，工作量巨大。
• 第四個坑：標準不統(tǒng)一。團隊里每個人寫法不一樣，有的人寫得特別細，操作步驟恨不得一步步截圖；有的人就寫一句話“驗證功能正常”。資產(chǎn)沉淀不下來，后面想復(fù)用都沒法用。

AI大模型能幫上忙嗎？

很多人一聽說用AI寫用例，第一反應(yīng)就是：哦，就是讓ChatGPT幫我寫幾條用例唄，省得我打字了。如果只是這么想，那格局就小了。

大模型真正有價值的地方，不是幫你省掉“敲鍵盤”這個動作，而是把整個用例設(shè)計流程重構(gòu)成自動化的——從需求解析、場景拆解、用例生成、自我校驗，到迭代更新、批量落地，全鏈路跑通。

說白了，以前是一個人去想、去寫、去改；現(xiàn)在是你定好規(guī)則和邊界，AI幫你把80%的重復(fù)勞動干了，你只需要做最后的把關(guān)和調(diào)優(yōu)。

六步走，跑通全流程（附案例）

拿一個電商退款功能來舉例，這個場景大家比較熟悉，容易理解。

• 第一步：先把需求“洗”干凈

很多測試同學(xué)的習(xí)慣是，拿到PRD就直接讓AI生成用例。這樣做的結(jié)果就是AI瞎編一堆你業(yè)務(wù)里根本沒有的場景，或者漏掉關(guān)鍵的業(yè)務(wù)約束。

??正確做法是：先讓AI幫你把需求里的關(guān)鍵約束提煉出來。

比如退款這個需求，原始文檔可能寫了三四頁，又是流程圖又是表格的。但真正影響用例設(shè)計的核心約束其實就幾條：

• 只有“待支付”和“已支付未發(fā)貨”兩種狀態(tài)的訂單才能發(fā)起退款
• 退款金額不能超過實付金額
• 發(fā)起退款后30分鐘沒處理，自動取消
• 已經(jīng)開票的訂單，必須先沖紅發(fā)票才能退

把這四條擺出來，AI后面生成用例的邊界就清晰了，不會亂發(fā)揮。

• 第二步：拆場景，別一上來就寫用例

復(fù)雜業(yè)務(wù)最怕的就是直接寫用例，寫著寫著就亂了。

我的做法是分層拆：

• 正向場景：正常流程能走通的
• 異常場景：各種參數(shù)不對、狀態(tài)不對、權(quán)限不夠的情況
• 邊界場景：金額臨界值、時間臨界點、次數(shù)上限
• 聯(lián)動場景：退款的時候同時有其他操作，比如同時下單、同時改地址

每一層單獨拆成測試點，確認覆蓋全了，再進入下一步。

• 第三步：批量生成，統(tǒng)一格式

拆好場景之后，讓AI按你的格式要求一次性生成所有用例。

格式要提前定好，比如我常用的：用例ID、模塊、前置條件、操作步驟、預(yù)期結(jié)果、優(yōu)先級、類型。格式統(tǒng)一了，后面才好管理。

這一步AI跑得飛快，一百多條用例十幾分鐘就出來了。

• 第四步：讓AI自己先檢查一遍

大模型有個毛病叫“幻覺”——它會很自信地輸出一些錯誤的東西。

所以在生成用例之后，再加一輪自檢提示詞，讓AI自己復(fù)查：

• 有沒有用例違反了業(yè)務(wù)約束？（比如在“已關(guān)閉”狀態(tài)下還能退款）
• 有沒有兩條用例實際上測的是同一個東西？
• 有沒有邏輯上說不通的步驟？
• 有沒有編造出來但業(yè)務(wù)里根本不存在的場景？

這一步能篩掉大量低級錯誤，減少人工返工。

• 第五步：人工做精細化調(diào)整

AI自檢完，你拿到的用例基本能用了。但肯定還有一些需要微調(diào)的地方——比如某些公司特有的合規(guī)要求、歷史線上故障沉淀下來的特殊場景，這些AI不知道，需要你手動補上。

關(guān)鍵動作：把這些調(diào)整記錄下來，回頭去優(yōu)化你的提示詞模板。下次再生成同類用例時，問題就不會重復(fù)出現(xiàn)。

• 第六步：入庫，形成資產(chǎn)

優(yōu)化完的用例，批量導(dǎo)入TestRail、禪道這類管理平臺，跟需求、版本、自動化腳本關(guān)聯(lián)起來。以后每次迭代只需要增量更新，不用重寫。

復(fù)雜業(yè)務(wù)怎么寫？

前面說的是通用流程，但真正讓人頭疼的是那種多狀態(tài)流轉(zhuǎn)的復(fù)雜業(yè)務(wù)。

比如一個訂單有6種狀態(tài)：待支付、支付中、已支付、退款中、已退款、已關(guān)閉。不同狀態(tài)下能做的操作不一樣，狀態(tài)之間跳轉(zhuǎn)有規(guī)則有例外，組合起來幾十個分支。

這種業(yè)務(wù)怎么用AI搞定？

• ：讓AI先把狀態(tài)流轉(zhuǎn)圖畫出來——哪些狀態(tài)之間可以跳轉(zhuǎn)，哪些是禁止的。
• ：基于這張圖，讓AI逐個狀態(tài)推導(dǎo)——這個狀態(tài)下能做什么操作？哪些操作會報錯？邊界值是什么？
• 第三步：專門跑一輪“疊加異常”——比如“退款中的訂單能不能支付？”“已關(guān)閉的訂單能不能發(fā)起退款？”這些交叉場景是人工最容易漏的。

這套打法跑下來，原來需要人工干2小時的復(fù)雜鏈路，AI 10分鐘覆蓋全，分支基本不漏。

邊緣場景怎么挖？AI的強項

線上故障大部分來自邊緣場景，而邊緣場景恰恰是人工測試最容易忽略的。AI擅長做一件事：按維度窮舉。

常用的四個維度：

• 數(shù)值邊界：最大值、最小值、0、空、負數(shù)、超長字符串
• 時間邊界：超時臨界點、跨天跨月、并發(fā)瞬時
• 狀態(tài)邊界：狀態(tài)切換那一刻、異常中斷后狀態(tài)殘留
• 環(huán)境邊界：弱網(wǎng)、斷網(wǎng)、低電量、資源耗盡的極端情況

舉個實際例子：測Serverless接口超時。人工一般就想到“網(wǎng)絡(luò)超時”這一種。但讓AI按這四個維度拆一遍，它能多給你8種：冷啟動超時、并發(fā)限流超時、內(nèi)存配額超了導(dǎo)致的超時、觸發(fā)器延遲……全是Serverless架構(gòu)特有的盲區(qū)。

AI生成用例常見問題，這樣處理

AI不是萬能的，生成出來的用例經(jīng)常有四個問題

• 問題一：重復(fù)用例太多。AI喜歡換著說法描述同一個場景，導(dǎo)致用例列表里一堆長得像但實際測的東西一樣的。治法是加一句提示詞：“自動識別并合并同質(zhì)場景，相似場景只保留最優(yōu)的一條，差異化場景單獨保留。”——就這么一句話，能砍掉60%以上的冗余。
• 問題二：瞎編場景。AI自由發(fā)揮起來很可怕，能給你編出業(yè)務(wù)里根本不存在的功能。治法是明確告訴它：“所有用例嚴格基于給定的需求文檔生成，禁止延伸擴展未提及的功能。”把它的想象力鎖住。
• 問題三：顆粒度忽粗忽細。有的用例寫得特別籠統(tǒng)，有的又拆到每一步點擊哪個按鈕。治法是先給它看你們公司的標準用例樣例（Few-Shot），讓它照著這個顆粒度來。
• 問題四：版本變了用例跟不上。每次迭代如果都全量重寫，那AI的效率優(yōu)勢就沒了。正確的做法是增量更新：“基于舊版本用例，結(jié)合本次變更點，新增需要覆蓋的新場景、刪掉失效的、修改邏輯變了的。”這樣每次只需要改一小部分。

給新手轉(zhuǎn)行AI測試的3條建議

第一，別等“完全準備好”再開始。今天就用DeepSeek或通義千問，把你的下一個需求文檔丟進去，讓它生成一批用例——看輸出、找問題、改提示詞，這是最快的學(xué)習(xí)路徑。在AI時代，動手比觀望重要一萬倍。

第二，掌握提示詞工程是核心杠桿。AI測試不是“問一句就行”，而是需要結(jié)構(gòu)化輸入、分層拆解、持續(xù)迭代。學(xué)會寫精準的提示詞，你的產(chǎn)出效率會是別人的3-5倍。

第三，人機協(xié)同是終局思維。AI負責(zé)標準化量產(chǎn)和全覆蓋拆解，你負責(zé)業(yè)務(wù)規(guī)則校驗和特殊場景適配。未來的高價值測試工程師，不是被AI替代的人，而是會用AI的人。

??想了解更多漲薪技能提升方法

??可以到公主號【Atstudy技術(shù)社區(qū)】,即可加入領(lǐng)取 ??????

??轉(zhuǎn)行、入門、提升、需要的各種干貨資料

??內(nèi)含AI測試、 車載測試、AI大模型開發(fā)、BI數(shù)據(jù)分析、銀行測試、游戲測試、AIGC