一個測試案例之所以真正有用,不是因為它存在於測試管理系統中,或是包含一串步驟。更重要的問題是:一個案例需要具備什麼,才稱得上「可執行」? 一個有力的答案是:另一位 QA 工程師——一個沒有撰寫這個案例、對這個功能也沒有任何歷史背景的人——應該能夠獨立執行它,並得出相同的結論。

這暴露了成熟 QA 團隊一個常見的弱點。有些測試案例之所以看起來完整,只是因為某位資深同事記得所有沒被寫下來的事:該用哪個帳號、必須啟用哪個功能開關(feature flag)、需要事先準備哪些資料、正確的回應應該包含什麼,或哪些紀錄事後必須刪除。文件與資深同事的記憶,實際上共同構成了一個測試系統。一旦那個人不在,缺口立刻浮現。

因此,目標不一定是寫更多測試案例,而是讓既有的案例具備獨立可執行性。

一張好的 QA 票據需要什麼

一個可執行的案例,始於明確的前置條件(preconditions)。與其說「登入並測試優惠券」,它應該指明所需的帳號、權限、功能開關、環境與起始資料狀態。前置條件精確界定測試從哪裡開始。

接著,步驟必須描述讀者可以一步一步執行的動作。「測試優惠券疊加」是一個調查指令,不是可執行的步驟。「套用優惠券 CODE10,再加優惠券 SAVE200,然後前往結帳」才是給測試者的一段可重現序列。

最重要的是,預期結果必須是可判定的。「正常運作」「回應恰當」「頁面看起來正常」這類敘述,會逼測試者自己發明成功的定義。更好的預期是陳述可觀察的事實:「訂單總額為 880,只套用一項折扣,被拒絕的優惠券有留下紀錄。」測試者應該能夠拿實際行為與預期行為比對,做出明確的判斷。

在測試 AI 時,這一點尤其重要。假設一個 AI 助理應該要能解釋為什麼無法退款。如果預期結果只寫「AI 給出良好的回應」,兩位測試者完全可以合理地得出不同結論。這個測試需要可衡量的要求:回應必須說明適用的條件、不得宣稱退款已發生、並且必須提供核准的升級(escalation)管道。如果團隊連這些要求都無法達成共識,那麼測試案例可能不是真正的問題——規格本身從來就沒有被定清楚。一個模糊的預期結果,可以暴露一個模糊的產品需求。

測試資料也必須是有意安排的。案例應該指明這些值從哪裡來、由誰建立,而不是依賴環境裡碰巧存在的任何東西。同樣地,清理(cleanup)是執行的一部分,不是雜務。優惠券、訂單、紀錄、工作階段(session)與其他被修改的狀態,無論案例通過或失敗,都應該被恢復到所需的起始條件。否則,一個測試可能悄悄污染另一個測試。

由此得出另一個重要原則:不留隱性假設。一個案例不應該依賴「CART-001 已經在 CART-002 之前執行過」,除非這個依賴是被明確設計出來的。它也不應該要求測試者「本來就知道」業務規則。獨立的案例更容易重現、更容易自動化、更容易在測試者之間分配,也更容易在失敗時調查。拿掉其中任何一個要素,這個案例就會越來越只對撰寫它的那個人有用。

連測試案例名稱也影響可執行性。一個有用的名稱應該可被搜尋,並傳達意圖。「退款測試 3」在幾個月後幾乎什麼都說不明白;而「拒絕不符合資格的已出貨訂單之退款」能在打開案例之前,就告訴另一位工程師這裡驗證的是什麼行為。當迴歸測試套件從數十個成長到數千個測試時,好的命名價值越來越高。

Aurora Shop:把需求變成可執行的案例

這張表展示了這些原則如何應用在 Aurora Shop——一個帶有結帳規則與 AI 客服助理的電商平台。CART-001 定義了確切的起始購物車、優惠券、動作、預期總額、帳號與清理;CART-002 更進一步,驗證的是優惠券疊加的業務規則,而不只是檢查結帳是否成功;CART-003 刻意測試 499 與 500 之間的運費邊界,讓預期行為可以被客觀衡量。AI 案例則把同樣的紀律套用到不那麼確定性的行為上:AI-001 確保助理只談論正確的訂單;AI-002 定義了一個合格的拒絕「必須」與「不得」宣稱什麼;AI-003 則把抗提示詞注入能力轉化為可觀察的標準,要求助理拒絕未經授權的退款指令。在每一個案例中,測試者都知道起始狀態、動作、預期結果、所需資料與清理方式。知識被儲存在案例本身,而不是儲存在當初設計這個功能的人的記憶裡。

歸根結底,好的測試文件應該活得比它的作者更久。一個實用的標準很簡單:把案例交給一位從沒見過這個功能的、有能力的 QA 工程師。如果對方能完成設定、執行、判定結果、事後清理,並在不需要追問作者「到底是什麼意思」的情況下重現出相同結論,那麼這個測試案例才算真正可執行。