寫到這裡你可能已經發現,同樣是請 AI 寫測試,有時一次到位,有時來回五趟還不對。差別多半不在 AI 心情,在指令的精準度。這篇把好指令拆開來看,你會發現它的骨架就是你寫了多年的測試案例。

同一個需求的三種說法

圖 1:模糊指令與清楚指令的對照

最模糊的說法:「幫我測登入功能」。AI 只能猜:測哪個網址?用什麼帳號?成功的定義是什麼?它會產出一個看起來像登入測試的東西,但驗證的多半不是你在意的點。

升一級:「測 /login 頁的登入,成功要能進系統」。有網址了,但「進系統」還是驗不動,AI 只好隨便挑個依據。

再升一級:「到 /login 頁,用 demo@test.com / Pass123 登入,成功後應導向 /dashboard 且右上角顯示使用者名稱」。動作明確、驗證點明確,一次就接近可用。

三種說法的差距裡,沒有一分是程式知識,全部是需求描述的精準度。也就是說,你在這裡的優勢,是現成的。

測試案例的欄位,就是指令的骨架

圖 2:測試案例欄位對應到指令要素

逐項展開,每項配一個句型:

• 前置條件。AI 不知道你的系統,要先到什麼狀態要講明。句型:「前提:使用者已登入,購物車裡已有一件商品」。沒講,它就從首頁開始瞎逛。
• 測試資料。給具體的值。句型:「用 demo@test.com / Pass123」。說「用一組帳號」它會自己編一組不存在的;說「隨便填」它就真的隨便,而隨便填出來的測試沒有可重複性。
• 操作步驟。一步一動,照順序。句型:「1. 點右上角購物車圖示 2. 點『前往結帳』 3. 選貨到付款」。你寫重現步驟的功力直接搬過來,連編號習慣都能沿用。
• 預期結果。最關鍵的一項,它會直接變成程式裡的斷言。句型:「應導向 /orders/complete,頁面顯示訂單編號(ORD- 開頭)與『訂購成功』字樣」。

預期結果要記得多說兩句。上一篇講過,測試的靈魂是 expect,而 expect 驗什麼,完全來自你描述的預期結果。一個實用的自我檢查:你寫的預期結果,能不能拍張截圖圈出來?「登入成功」圈不出來;「右上角顯示 Demo User」圈得出來。圈得出來的,斷言就寫得出來。這也是為什麼「功能正常運作」是最糟的預期寫法,它沒有給斷言任何著力點。

四個立刻可用的習慣

(1) 先給角色和限制
開場說「我是測試人員,不太會寫程式,解釋時請用白話」,AI 的回應方式會整個不同:少用術語,動手前也更願意先說明和解釋。這句話值得放進每個新對話的開頭。之後可以寫進專案的 CLAUDE.md,一個給 AI 看的團隊規範檔。

(2) 一次一個場景
不要在同一句話裡要五個測試。一個做完、確認對了,再做下一個。這不是 AI 的限制,是審查的限制:一次收到五個測試,你多半只會粗略掃過, 關鍵的地方可能就沒有列到。

(3) 要求它先講計畫
指令結尾加一句「先告訴我你打算怎麼做,我確認後再動手」。誤解在程式產出前就攔下來,成本遠低於事後重寫。

(4) 給範例或反例
當你對「要什麼」說不清、但對「不要什麼」很有感時,可以使用反例:「不要只驗證訊息有出現,我被『訊息說成功、資料其實沒存』的 bug 咬過」。AI 對反例的理解力很好,而反例裡裝的正是你過往的實戰經驗。

你可以這樣對 Claude Code 說:

我是測試人員,不太會寫程式。
我想測:
到 /login 頁面,用 demo@test.com / Pass123 登入,預期導向 /dashboard 且右上角顯示「Demo User」。
注意:
不要只驗證網址,使用者名稱那個驗證一定要有。先告訴我你打算怎麼做,我確認後再動手。

第一版不滿意,怎麼追問

再好的指令也常需要第二輪,追問有技巧。

只想改一個地方,就點名那個地方:「斷言的部分,把驗證網址改成驗證使用者名稱,其他不動」。不要重新描述整個需求,重講一遍容易引入新的歧義,也會讓它整份重寫,把你已經確認過的部分又動掉。

方向整個錯了,就明確喊重來:「這個方向不對,我們重新開始」。別在錯的版本上修修補補,跟 AI 協作,沉沒成本一樣會騙人。

雞同鴨講時,問題多半出在這三處

• 預期結果不可觀察。「體驗要流暢」「功能正常」,請改成畫面上圈得出來的具體現象。
• 隱含知識沒說出口。你腦中的系統常識(哪個環境、哪個角色、什麼前置狀態)AI 都不知道。判斷標準:一個第一天到職的新同事聽了會不會問「等等,哪個環境?」會問,就是漏了。
• 一句話塞太多任務。拆開,一次一件。

你的第一批指令模板

五個模板,直接抄去改:

• 產測試:「我要測【功能】。前提:【前置】。步驟:【一步一動】。預期:【可截圖圈出的現象】。先講計畫再動手。」
• 解釋:「逐行用白話解釋【檔名】,假設我不會寫程式。」
• 除錯:「我執行了【指令】,出現以下錯誤:【整段貼上】。在這之前我改過【什麼】。」
• 修改:「【檔名】裡【哪個部分】改成【怎樣】,其他不動,改完先給我看差異。」
• 質疑:「這個測試的斷言驗證什麼?如果功能壞了它還是綠的,可能是什麼情況?」這是把關神器,之後每篇都用得上。

套用模板來練習:拿官網的搜尋功能填一次

模板是空格,填一次才會用。拿第一個模板(產測試),套在 playwright.dev 的站內搜尋上——這是官方網站,打開就能練,填完直接可跑:

你可以這樣對 Claude Code 說:

我要測 playwright.dev 的站內搜尋。
前提:
無,直接打開 https://playwright.dev。
步驟:
1. 點右上角的搜尋(Search)
2. 輸入 locator 
3. 等搜尋結果出現。
預期:
結果清單至少 1 筆,且第一筆的文字包含 locator;點下第一筆後,應離開搜尋框、進入一個標題含 Locator 的文件頁。先講計畫再動手。

對照模板逐格看,幾個填法上的小心思:

• 前提寫「無」也要寫出來。空著,AI 會猜你是不是漏了;明講「無」,它就知道從首頁開始。
• 步驟一步一動,連「等搜尋結果出現」都算一步。你覺得理所當然的等待,對程式是一個明確的狀態。
• 預期全部是圈得出來的現象:至少 1 筆、文字包含 locator、標題含 Locator。沒有一句「搜尋功能正常」。

把這段丟給 Claude Code,看它先回的計畫合不合你的意,確認後讓它跑。綠燈之後,做第 4 篇教的那件事:找出 expect 那幾行,對照你寫的三個預期,一一點名。三個都對得上,這次的模板套用就及格了。

💡** 把好指令存起來**
遇到一次就成功的指令,存進一個「指令範本」文件,從上面五個開始長。兩三週後你會累積出一套自己領域專用的版本。這份文件本身,就是團隊導入 AI 測試時最有價值的資產之一。