登錄功能大概是測試圈里最看不起、又最寫不完的功能。你說簡單吧賬號密碼輸對點一下登錄就完事了但真要讓一個同學把用例寫到能過評審往往要憋一整天——正常流程、異常流程、密碼錯誤、賬號鎖定、驗證碼過期、多次失敗、異地登錄、弱密碼、SQL注入、XSS攻擊……列到后面自己都想吐。我前陣子接了一個登錄模塊優(yōu)化的需求當天下午就要用例評審實在不想從空白Excel開始敲就試著用文心一言跑了一遍結果5分鐘拿到一份60多條用例的初稿再審一遍補上業(yè)務規(guī)則半小時內直接交出去。這篇文章就把這套AI測試實操方法完整拆給你提示詞怎么設計、AI生成結果怎么審、Excel模板怎么落地以及那些我踩過之后才知道的坑。不管你用的是文心一言還是其他大模型思路都是通用的。適合正在做功能測試的同學也適合想用AI給團隊提效的測試負責人。1. 為什么寫登錄用例這種小事也要用AI1.1 你真的了解登錄用例要覆蓋多少維度嗎很多人對登錄用例的認知停留在輸入賬號密碼點登錄但真正上線過的項目都知道一個登錄框背后牽扯的測試維度遠超想象。功能層面要覆蓋正常登錄、密碼錯誤、賬號不存在、賬號鎖定、驗證碼失效、記住密碼、退出登錄、Session過期安全層面要覆蓋暴力破解、SQL注入、XSS腳本、密碼傳輸加密、驗證碼繞過兼容層面要覆蓋不同瀏覽器、不同操作系統(tǒng)、不同分辨率性能層面要考慮并發(fā)登錄、接口響應時間。再加上現(xiàn)在的系統(tǒng)普遍支持掃碼登錄、短信驗證碼登錄、第三方OAuth登錄登錄這個小功能真正展開寫一百條用例一點都不夸張。我在實際項目里見過太多以為寫完了上線就出事故的情況。比如驗證碼邏輯沒覆蓋、多次失敗鎖定策略沒驗證、找回密碼后舊Session沒有失效這些問題一旦漏到生產環(huán)境輕則被安全團隊通報重則影響用戶賬號安全。所以登錄用例不是不需要寫全而是太容易靠個人經(jīng)驗漏寫。AI在這里最大的價值就是像一個讀過幾百個登錄模塊用例的助手幫你把通用維度先鋪滿剩下的才是你基于項目實際情況去調整的部分。1.2 AI寫用例的本質檢索與組織而不是創(chuàng)造我剛開始嘗試AI寫用例的時候也犯過一個理解錯誤——以為AI能完全替代測試工程師的思考把需求丟進去就能產出可直接執(zhí)行的交付物。用了幾次之后才想明白AI在寫用例這件事上干的活本質上是檢索與組織不是創(chuàng)造。它做的是把你給出的功能需求映射到一個龐大的、經(jīng)過訓練的測試用例知識庫上然后按照你要求的格式把相關內容組織出來。這跟搜索引擎有點像只不過它是用自然語言跟你對話輸出的是結構化的可用文本。這意味著兩件事第一你給的信息越具體AI輸出越可用——你只寫測試登錄它就只能給你一堆教科書式的通用用例你寫清楚系統(tǒng)有哪些登錄方式、鎖定規(guī)則、驗證碼策略它就能按你的業(yè)務規(guī)則生成有針對性的用例。第二AI沒有你是否漏了需求的判斷力——需求文檔里沒提的東西它不會幫你強行補上它只會按你喂的料去鋪。想明白這一點之后我不再把AI當獨立測試設計師而是當初稿生成器靈感補充器。人工負責業(yè)務規(guī)則梳理和最終驗收AI負責把那些大家都會測、但又特別耗時的基礎場景快速鋪出來。這種分工方式讓我實際寫用例的時間壓縮了至少一半而且漏測率反而降了因為AI鋪底的覆蓋面比單靠個人記憶更穩(wěn)定。1.3 為什么選文心一言而不是其他工具市面上的大模型產品很多我之所以在實操里用文心一言來演示不是因為別的模型不行而是它在做中文測試用例生成這件事上有幾個讓我覺得順手的點。第一是中文理解穩(wěn)定。測試用例里經(jīng)常出現(xiàn)請輸入11位手機號密碼由8-20位字母和數(shù)字組成這類描述文心一言對中文語境的解析能力比較扎實生成出來的用例描述基本不需要大改。第二是低門檻注冊就能用不需要考慮網(wǎng)絡、部署這些問題對絕大多數(shù)測試同學來說是最快能上手體驗AI提效的路徑。第三是支持多輪對話修改。我先讓它生成一版然后繼續(xù)追問把移動端的場景補上優(yōu)先級重新調一下把用例編號改成LOGIN_CN這種格式它都能基于上文繼續(xù)優(yōu)化而不是每次重新生成。當然如果你團隊已經(jīng)在用其他大模型的API或者公司要求數(shù)據(jù)不能出內網(wǎng)那用私有化部署的模型也是可以的。核心思路是一樣的區(qū)別只在工具本身。這篇文章里的提示詞模板、審查方法、Excel模板都可以直接平移到任何大模型產品上使用。2. 5分鐘搞定提示詞怎么設計才能讓AI輸出可用用例2.1 一個能開箱即用的登錄用例提示詞模板直接來干貨。這個模板是我在實際項目里反復調整過好幾版之后定下來的把它復制到文心一言對話框里把被測功能需求部分替換成你自己系統(tǒng)的真實規(guī)則回車就能得到一份可以直接進入人工審查的用例初稿。你是一位有10年經(jīng)驗的資深測試工程師擅長Web端和App端功能測試。 現(xiàn)在需要為【登錄模塊】編寫一份完整的測試用例集被測系統(tǒng)的登錄功能需求如下 1. 用戶使用已注冊的郵箱/手機號和密碼登錄。 2. 登錄成功后跳轉到首頁右上角顯示用戶名。 3. 密碼錯誤時提示用戶名或密碼錯誤連續(xù)5次錯誤鎖定賬號30分鐘。 4. 支持記住密碼勾選后下次自動填充。 5. 支持短信驗證碼登錄驗證碼有效期5分鐘60秒后可重新發(fā)送。 6. 未注冊的賬號登錄時提示賬號不存在請先注冊。 請基于以上需求編寫一份覆蓋完整的登錄功能測試用例集并滿足以下要求 1. 覆蓋正常流程、異常流程、邊界值、安全、兼容性、易用性幾個維度。 2. 輸出格式為Markdown表格字段包含用例編號、用例名稱、前置條件、測試步驟、測試數(shù)據(jù)、預期結果、優(yōu)先級、用例類型。 3. 用例編號使用LOGIN_CN、LOGIN_EX、LOGIN_SEC等前綴。 4. 對高風險、高優(yōu)先級用例用高標注。 5. 如果需求描述不足以覆蓋某個場景請基于通用登錄系統(tǒng)的常見做法做合理補充并在該用例備注欄說明AI補充。這個模板看起來不復雜但我見過很多人寫提示詞只寫一句幫我寫登錄功能的測試用例然后抱怨AI輸出太水。區(qū)別就在于后面那一大段關于角色、需求、輸出格式、編號規(guī)則、兜底策略的約束才是讓AI從教科書模式切換到可交付模式的關鍵。2.2 為什么提示詞要這樣寫五個要素逐個拆先看角色定義。我給AI設定了一個有10年經(jīng)驗的資深測試工程師的角色。這個設置不是玄學而是因為大模型在訓練時見過海量不同身份視角的表達給它一個明確的角色相當于幫它鎖定輸出的語氣、深度和關注點。你讓它以資深測試工程師身份寫用例它輸出時會更關注邊界、異常、安全維度你讓它以產品經(jīng)理身份寫它可能會更關注用戶場景和流程合理性。這個差異化在使用中是非常明顯的。功能需求要素是整個提示詞的核心。我建議把需求逐條編號列出來而不是用一大段文字描述。編號的好處有三點第一AI更容易逐條對齊不會漏掉某一條第二你后續(xù)追問第3條那種場景再多補幾個用例時AI能準確知道你指的是哪一條第三強制你自己先把需求梳理清楚——這一步的價值后面還會提到。覆蓋維度和輸出字段兩個要素解決的是格式問題。我見過太多AI生成結果沒有編號、沒有優(yōu)先級、預期結果寫得含糊其辭直接導致后期還要人工返工。你在一開始就把字段名定死把維度點齊AI輸出就能直接進入表格流程省掉大量整理時間。最后說兜底策略。這一條是我自己加的也是我覺得最實用的一條。AI在處理信息不完整的需求時有一種默認傾向是會停下來反問請?zhí)峁└嘈畔?。但如果真讓它反問你就得一輪一輪對?分鐘根本搞不定。所以我在提示詞里明確告訴它信息不足時基于通用做法做合理補充并在備注欄說明AI補充。這樣它既能給出完整輸出又保留了標記讓你后面審查時能快速識別哪些內容是需要特別核對的。3. 實操演示文心一言生成登錄用例的全過程拆解3.1 現(xiàn)場操作從提出需求到拿到60條用例把上面那段提示詞復制進文心一言的輸入框點擊發(fā)送之后你會看到它開始逐字生成Markdown表格。整個過程大概在30秒到1分鐘之間取決于當前服務的繁忙程度。生成完之后我找到了頁面上復制Markdown的按鈕直接把結果粘到了本地一個.md文件里然后通過Excel的數(shù)據(jù)-從文本/CSV導入功能快速把Markdown表格轉成了真正的Excel表。這一步很多人不知道實際上比手動復制粘貼每一個單元格要快非常多。第一版生成出來的用例大約有60條我數(shù)了一下覆蓋了賬號密碼登錄、驗證碼登錄、記住密碼、密碼找回、鎖定與解鎖、Session會話、兼容性、安全性等八大類。從覆蓋面上看AI做得確實比多數(shù)新人更全面比如它自動補了密碼使用弱口令時系統(tǒng)是否攔截鎖定時間到期后能否正常登錄清除瀏覽器緩存后記住密碼是否失效這類我個人都未必第一時間想到的場景。但這個初稿也不是完美無缺。仔細看你會發(fā)現(xiàn)部分預期結果寫得比較籠統(tǒng)比如有一句系統(tǒng)應正確校驗驗證碼這種描述放到Excel里是沒法直接執(zhí)行的必須改寫成系統(tǒng)應在驗證碼錯誤時提示驗證碼錯誤并清空驗證碼輸入框。還有一部分AI補充的測試數(shù)據(jù)是編造的比如用戶名為A123456的賬號實際測試環(huán)境里根本沒有這個賬號需要替換成真實數(shù)據(jù)。這些就需要進入下一步人工審查去處理。3.2 人工審查把80分的AI初稿改成95分拿到AI初稿之后我一般會做一輪15分鐘左右的人工審查分三步走。第一步是逐條對照核心業(yè)務規(guī)則。我會把需求文檔里的每一條關鍵規(guī)則拿出來跟AI生成的用例逐一比對。比對的目的是找出AI理解偏差的地方比如需求里寫的是密碼錯誤5次鎖定賬號但AI生成了密碼錯誤5次后賬號永久鎖定雖然只是兩個字的差異測試結果會完全不同。這一步必須要人工來做因為AI并不知道你系統(tǒng)的真實行為到底是什么。第二步是把測試數(shù)據(jù)從AI編造的換成真實可用的。這一步容易被忽視但直接影響用例能否被執(zhí)行。我會把用戶名:test001、密碼:Test12345這類占位數(shù)據(jù)替換成測試環(huán)境里真實存在的賬號并且把賬號類型標注清楚比如已注冊普通用戶已鎖定用戶未注冊手機號。很多測試同學在寫用例時也會忽略這一點結果執(zhí)行的時候才發(fā)現(xiàn)賬號不存在又得臨時找人創(chuàng)建效率非常低。第三步是重新排優(yōu)先級。AI給出的優(yōu)先級判斷往往偏通用它會把所有安全相關用例都標成高但實際項目中登錄接口的防暴力破解可能比注冊流程的邊界值更緊急這個輕重緩急只有了解當前迭代重點和線上風險的人才判斷得了。我會把當前版本重點改造的功能相關用例全部提升優(yōu)先級把AI默認高但實際影響面小的用例降為中或低保證回歸測試時先跑最關鍵的部分。這一輪審查做完AI初稿基本就從看起來全變成了真正能執(zhí)行。我自己算過一筆賬同樣一份登錄用例以前從空白Excel開始寫加上整理格式怎么也要3個小時現(xiàn)在這套流程AI生成5分鐘人工審查15分鐘總計不到半個小時而且覆蓋面更全、格式更規(guī)范。4. 把AI結果落到Excel模板字段、下拉、高亮一次配齊4.1 測試用例Excel模板的字段設計AI生成的是Markdown表格要落到團隊協(xié)作用的Excel里字段還需要再擴展一下。我自己的模板里會放這些列字段名填寫說明示例用例編號模塊前綴_類型_三位序號LOGIN_CN_001所屬模塊被測功能模塊登錄用例名稱一句話描述驗證點正確賬號密碼登錄成功前置條件用例執(zhí)行前需要滿足的狀態(tài)賬號test已注冊且未被鎖定測試步驟數(shù)字編號列出操作步驟1.進入登錄頁 2.輸入賬號 3.點擊登錄測試數(shù)據(jù)步驟中使用的輸入值郵箱:testexample.com 密碼:Test12345預期結果可斷言的系統(tǒng)表現(xiàn)登錄成功跳轉首頁右上角顯示用戶名優(yōu)先級高/中/低控制執(zhí)行順序高用例類型功能/UI/安全/性能/兼容性功能執(zhí)行結果未執(zhí)行/通過/失敗/阻塞通過執(zhí)行人實際執(zhí)行用例的人張三備注補充說明或關聯(lián)缺陷ID關聯(lián)BUG-1024字段設計有幾個細節(jié)值得注意。首先是預期結果這列我在模板里明確要求填寫可斷言的描述也就是能明確判斷成功還是失敗而不是系統(tǒng)應正確處理這種廢話。其次是所屬模塊和用例編號要分開因為后續(xù)做用例統(tǒng)計和篩選時按模塊分組看用例分布是非常高頻的需求。最后是執(zhí)行結果狀態(tài)建議和團隊的測試管理系統(tǒng)保持一致不要自己發(fā)明一套名詞否則后續(xù)統(tǒng)計口徑對不上。4.2 幾個能提升填表效率的Excel小技巧模板字段定好了再說幾個我實際用下來覺得特別好用的Excel功能能讓這套模板從表格變成半自動化工件。第一個是數(shù)據(jù)驗證下拉菜單。選中優(yōu)先級列整列點擊數(shù)據(jù)驗證允許條件選序列來源填高,中,低確定。這樣填表時直接點下拉選擇不用每次手敲。同理用例類型列來源填功能,UI,安全,性能,兼容性,異常執(zhí)行結果列來源填未執(zhí)行,通過,失敗,阻塞。這個操作一分鐘就能完成但能讓全組的人填表口徑保持統(tǒng)一不會出現(xiàn)高優(yōu)先級高混著寫的情況。第二個是條件格式高亮。點擊開始-條件格式-新建規(guī)則選擇使用公式確定要設置格式的單元格公式填$J2失敗然后設置一個淺紅色填充。這里的$J2假設執(zhí)行結果在J列如果你的模板列順序不同需要按實際列號改。設置完之后失敗的行會自動標紅整個測試周期的通過情況一眼就能掃出來。我再加了一個規(guī)則$J2阻塞標黃色失敗和阻塞在視覺上直接分開。第三個是凍結首行加自動篩選。視圖-凍結窗格-凍結首行然后CtrlShiftL開啟自動篩選。做完整理的時候我會按優(yōu)先級篩選出所有高優(yōu)先級用例再按用例類型篩出安全維度單獨拉出來做一輪專項確認非常方便。第四個是關于用例編號的一個小技巧。如果用例數(shù)量一多手動改編號很容易出錯?？梢栽谟美幪柫惺褂霉紺ONCAT(LOGIN_CN_,TEXT(ROW()-1,000))這樣往下填充的時候編號會自動生成。第一行表頭占了一行所以ROW()要減1。當前面的行被刪除時編號也會自動更新不會再出現(xiàn)斷號的情況。需要批量導入禪道或其他管理系統(tǒng)時直接把這一列復制成值再導出即可。5. 翻車現(xiàn)場匯總AI生成用例最常見的6個坑5.1 六大高頻翻車場景與排查方案我自己前前后后用AI寫了十幾個模塊的測試用例踩過的坑不少。這里整理一個速查表按現(xiàn)象-根因-解決方案的方式列出來你對照著就能避坑?，F(xiàn)象根因解決方案生成的用例太泛泛像教科書模板提示詞沒有提供具體業(yè)務規(guī)則把需求逐條編號寫進提示詞越具體越好漏了短信驗證碼/圖形驗證碼場景AI不知道你的登錄包含驗證碼在功能需求描述里單獨列出包含驗證碼登錄測試數(shù)據(jù)是編造的AI沒有真實環(huán)境數(shù)據(jù)人工替換為真實賬號并標注賬號類型預期結果描述含糊無法執(zhí)行提示詞沒要求可斷言追加預期結果必須可判斷成功或失敗業(yè)務規(guī)則理解錯誤規(guī)則本身復雜且描述不清抽取核心規(guī)則用必須強調單獨成段多輪對話后忘掉之前的約束上下文被后續(xù)內容干擾重要約束在每次追加問題時重復發(fā)送一遍展開說幾個我印象最深的。測試數(shù)據(jù)是編造的這個坑第一次用AI生成用例時最容易踩。AI生成的測試數(shù)據(jù)看起來有模有樣比如用戶名:zhangsan、密碼:Abc123456但等你真正執(zhí)行的時候才發(fā)現(xiàn)測試環(huán)境里根本沒有這個賬號還得去找開發(fā)創(chuàng)建數(shù)據(jù)白白浪費半天?，F(xiàn)在我收到AI輸出后會第一時間掃一遍測試數(shù)據(jù)列凡是編造的數(shù)據(jù)全部替換成測試環(huán)境真實存在的賬號或者統(tǒng)一寫成預置賬號:test_01然后單獨在旁邊標注。預期結果含糊也是個高頻問題。AI初稿里經(jīng)常出現(xiàn)系統(tǒng)應正確反饋或者頁面表現(xiàn)正常這類描述這種用例發(fā)到測試執(zhí)行人手里根本沒法判斷到底算通過還是失敗。我試過在提示詞里直接加一句預期結果必須是可以明確判斷成功或失敗的客觀描述禁止使用正確正常等模糊詞匯加了這句話之后輸出質量明顯提升了一個檔次。多輪對話后忘掉約束是我在讓AI補用例時遇到的。我先讓它生成了一版然后讓它再補充移動端場景的用例結果它補充的用例里用例編號格式、優(yōu)先級標注方式全都變了跟第一版完全對不上。后來我每次追加需求都會把用例編號格式仍然使用LOGIN_CN這種前綴這類關鍵約束重新發(fā)一遍問題就解決了。5.2 AI生成內容進入評審前的檢查清單結合這些翻車經(jīng)驗我總結了一份AI生成用例評審前檢查清單每次用AI生成完用例后我都會過一遍保證交到評審會上的內容經(jīng)得起問。第一項逐條比對核心業(yè)務規(guī)則。這塊強調的是需求里明確的規(guī)則用例里必須有對應覆蓋比如連續(xù)5次錯誤鎖定賬號30分鐘這條必須能看到對應的成功路徑和失敗路徑用例甚至鎖定時長邊界值也算上。第二項檢查AI補充標記的用例是否合理。我在提示詞里要求AI把自己補充的內容打上標記拿到結果后我會重點看這些標記。如果內容是通用的業(yè)界實踐比如登錄接口應使用HTTPS傳輸我就保留如果明顯不符合我們系統(tǒng)的設計比如支持指紋登錄而我們根本沒做指紋登錄我會直接刪掉或改寫。第三項確認測試數(shù)據(jù)和預期結果都可執(zhí)行。這一點前面提過但值得再強調因為評審會上被問最多的就是這條用例怎么執(zhí)行預期結果是什么標準。把這兩列打磨清楚用例評審通過率會高很多。第四項檢查編號和格式是否統(tǒng)一。批量生成的用例編號前綴、優(yōu)先級大小寫、用例類型用詞都要保持全表一致否則后面做統(tǒng)計和追溯時非常痛苦。6. 登錄只是一個開始AI測試還能怎么玩6.1 從用例生成到自動化腳本AI測試的進階玩法登錄用例的AI生成其實只是AI測試這件事很小的一塊。我嘗試下來覺得下面幾個方向同樣值得測試團隊關注。第一個是AI輔助生成自動化測試腳本。既然Excel里已經(jīng)有了步驟明確的測試用例那能不能讓AI把這些自然語言步驟直接翻譯成自動化腳本我試驗過把一條1.進入登錄頁 2.輸入用戶名 3.輸入密碼 4.點擊登錄 5.驗證跳轉首頁的用例丟給AI讓它生成一段Selenium腳本它能給出一個八九不離十的版本你只需要把元素定位符改成自己項目里的真實選擇器。對于剛上手自動化測試的團隊這個能力能顯著降低寫腳本的啟動成本?，F(xiàn)在很多AI自動化測試工具也在做錄制自然語言操作生成腳本的路子方向基本一致。第二個是AI輔助缺陷分析。測試執(zhí)行過程中失敗用例會留下一堆日志和截圖。我把日志關鍵信息和界面截圖描述喂給AI讓它基于經(jīng)驗給出失敗可能的原因它往往能指出一些我忽略的線索比如接口返回500之前有一個超時重試的日志懷疑是服務端連接池配置問題這類推測。雖然它不能替代真正的開發(fā)排查但能幫我縮小定位范圍節(jié)省不少時間。第三個是AI變異測試。這個方向偏研究一些核心思路是讓AI對被測代碼做小改動生成一堆變異體然后跑一遍現(xiàn)有測試集看測試用例能不能把這些變異體測出來。如果某個變異體沒被測試用例殺死說明測試集存在漏洞。這個玩法評估的是你的測試用例本身的質量跟AI生成用例配合起來能比較科學地衡量測試覆蓋率到底夠不夠。第四個是AI在安全測試領域的應用比如輔助滲透測試和漏洞探測。AI可以根據(jù)你描述的系統(tǒng)類型和接口信息生成探測用的輸入樣例、構造異常請求、甚至給出攻擊鏈路建議。它在這個領域的定位是輔助而不是全自動因為安全測試的誤報率本來就高最終判斷還是需要專業(yè)的測試人員來做。6.2 測試工程師和AI協(xié)作的邊界在哪里說到最后我特別想說一說我對AI會取代測試工程師嗎這個問題的看法。我自己用了大半年AI輔助測試最直觀的感受是AI改變的不是要不要做測試而是怎么做測試。那些重復的、規(guī)則清晰的、依賴知識面鋪底的測試工作AI確實能干得又快又多。比如登錄用例生成、基礎回歸用例整理、通用格式的格式化輸出這些都是AI的優(yōu)勢區(qū)間。但真正涉及復雜業(yè)務流程的鏈路設計、需要結合用戶場景做主觀體驗判斷、需要在多個需求之間權衡測試優(yōu)先級、需要跟開發(fā)產品溝通確認需求意圖的事情AI目前還遠遠替代不了人。它沒有對業(yè)務的理解沒有對用戶痛點的感知更沒有這個功能上線出問題影響有多大的風險判斷力。所以我的建議是測試工程師不妨把AI當成一個永遠精力充沛、知識面很廣但不懂業(yè)務的小助手。你負責告訴它業(yè)務規(guī)則和重點它負責快速鋪底和查漏補缺你來做最終的決策和收口。這種協(xié)作方式下你花在基礎工作上的時間會大大減少省下來的精力正好可以投入到更高價值的業(yè)務測試設計和質量策略上。對個人發(fā)展來說這反而是個提升空間更大的機會窗口。我個人現(xiàn)在的工作習慣是接到任何測試任務第一步不是打開Excel而是先花5到10分鐘把業(yè)務規(guī)則梳理成一條條可驗證的描述然后丟給AI生成初稿。這個過程本身就會倒逼我把需求想清楚——如果我自己都說不清規(guī)則AI生出來的東西一定沒法用。所以別把AI當成偷懶神器把它當成一面強制你想清楚需求的鏡子效果會好得多。