資料來源：Tricentis 2026 QA Trend Report、WeTest 2026 測試實踐文章

為什麼這個做法值得學？

WeTest 在 2026 年的測試實踐文章引用了 Tricentis 2026 QA Trend Report 的關鍵數據：超過 40% 的核心 QA 團隊已經採用「傳統測試方法 + AI 輔助」的混合流程。

這不是「AI 取代人類」的故事，而是業界成熟團隊摸索出來的分工：測試設計的骨幹還是人類，AI 是加速器。

同一份報告還揭露另一個讓人冒汗的數字：傳統測試腳本的平均月失敗率高達 25%，且維護成本佔總測試工作量的 60% 以上。換句話說，大家急著導入 AI 不是因為 AI 寫得多神，而是傳統方法的維護成本實在撐不下去了。

常見誤解 直接把需求丟給 AI 說「幫我生 test cases」，產出的東西通常很表面、覆蓋率低、邊界都漏，還會生出一堆無意義的重複案例。混合流程的精髓在於——人類負責策略層，AI 負責展開層。

接下來我用一個台灣人都熟的例子：高鐵早鳥票，手把手帶你走完整個流程。

核心心法：策略層 vs 展開層

圖一　混合流程的核心分工：人類做策略，AI 做展開

為什麼這樣分？因為 ISTQB 教了幾十年的那套測試設計技巧：等價類劃分、邊界值分析、決策表、狀態轉移，本質上是業務理解 + 邏輯抽象的工作，AI 還做不好。但「把抽象骨架翻譯成具體案例」這種有規則、會重複、需要耐心的工作，AI 比人類強太多。

實戰案例：台灣高鐵早鳥票訂票功能

我們用高鐵早鳥票作為被測系統。先把實際業務規則整理出來：

高鐵早鳥票業務規則（節錄） 折扣級別：依購票時間與配額提供 65 折 / 8 折 / 9 折三種，售完降階。 訂票區間：可訂乘車日（含）起算 29 天內，最晚於乘車日前 5 天截止。 車次限制：部分超尖峰車次不提供任何早鳥；部分尖峰車次只提供 9 折。 實名制：須輸入身分證字號或護照號碼，限本人搭乘。 變更規則：改車次或改座位即失去早鳥優惠，須補足全額差價。 退票：須於原列車發車前 30 分鐘完成。

光是這段需求，就有時間維度、車次屬性、會員身分、配額狀態、後續行為五個彼此糾纏的維度。如果直接丟給 AI 說「幫我生測試案例」，產出的東西保證漏一堆。我們來用混合流程處理。

Step 1：人類用傳統方法搭骨架（策略層）

重要提醒 這一步絕對不要叫 AI 做。這是你身為 QA 的核心價值，也是後面所有產出的源頭。骨架錯，AI 展開出來的東西全錯。

1-1. 等價類劃分（Equivalence Partitioning）

把每個輸入條件分成「有效」與「無效」的等價類：

• 訂票距乘車日：> 29 天（無效）／ 6 ~ 29 天（有效）／ 5 天（有效邊界）／ < 5 天（無效）／ 乘車當日（無效）
• 車次類型：一般車次（三種折扣全有）／ 部分尖峰（只有 9 折）／ 超尖峰（無早鳥）
• 配額狀態：65 折有剩 ／ 65 折售完 8 折有剩 ／ 僅剩 9 折 ／ 全部售完
• 乘客身分：本人持證 ／ 本人無證 ／ 非本人冒用
• 後續行為：照原票搭乘 ／ 改車次 ／ 改座位 ／ 越乘 ／ 退票

1-2. 邊界值分析（Boundary Value Analysis）

找出每個數值欄位的邊界——這是早鳥票最容易出 bug 的地方：

• 訂票時間邊界：T-30 天 23:59:59（無效）／ T-29 天 00:00:00（有效，剛開賣）
• 截止邊界：T-6 天 23:59:59（有效）／ T-5 天 23:59:59（有效，最後一刻）／ T-4 天 00:00:00（無效）
• 退票時間：發車前 31 分鐘（可退）／ 30 分鐘整（可退邊界）／ 29 分鐘（不可退）
• 週五跨日：週五 23:59:59 訂下下週五（有效）／ 週六 00:00:00 訂下下週五（無效）

為什麼這些邊界很重要 半夜整點開賣時的時區與秒數判定，是高鐵搶票最常出包的點。光是「下單瞬間」與「付款完成瞬間」分屬不同日期這種情境，就足以讓客服爆量。

1-3. 決策表（Decision Table）

把交織的業務規則畫成決策表：

條件	R1	R2	R3	R4	R5
在訂票區間內（6 ~ 29 天）	Y	Y	Y	Y	N
車次提供 65 折	Y	Y	N	N	–
65 折配額有剩	Y	N	–	–	–
8 折配額有剩	–	Y	–	–	–
9 折配額有剩	–	–	Y	N	–
預期結果	訂到 65 折	訂到 8 折	訂到 9 折	無早鳥可訂	無早鳥可訂

1-4. 狀態轉移圖（State Transition）

把折扣級別與生命週期視覺化：

圖二　高鐵早鳥票狀態轉移圖與容易出包的邊界情境

骨架到此就完成了。重點是：這個骨架反映了你對業務的理解，是後面所有 AI 工作的基礎。

Step 2：AI 進場做組合展開（展開層）

骨架定好之後，把它丟給 AI，讓 AI 做四件事。

任務一：自動展開組合矩陣

Prompt 範例：

我用等價類劃分定義了高鐵早鳥票的測試維度： – 訂票距乘車日：[>29天, 29天, 6~28天, 5天, <5天, 當日] – 車次類型：[一般, 部分尖峰, 超尖峰] – 配額狀態：[65折有剩, 8折有剩, 9折有剩, 全售完] – 乘客身分：[本人持證, 本人無證, 非本人] – 後續行為：[原票搭乘, 改車次, 改座位, 越乘, 退票]   請幫我： 1. 生成完整的笛卡兒積組合矩陣（共 6×3×4×3×5 = 1080 組） 2. 標記每組的預期結果（訂到什麼折扣 / 拒絕原因 / 違約金計算） 3. 用 pairwise 方法縮減到約 40~50 組高覆蓋率測試案例 4. 輸出成 Markdown 表格，含 case ID

人類定義 5 個維度，AI 就能秒生 1080 組組合並做 pairwise 縮減——這個工作如果手做，一天起跳。

任務二：提示「你可能漏了的邊界」

這個用法 90% 的人不知道，但價值極高。

這是我針對高鐵早鳥票的測試骨架：[貼上 Step 1 的內容]   請以資深 QA 角度檢視，列出我可能漏掉的邊界情境，特別關注： – 並發場景（搶票尖峰時兩人同時搶最後一張 65 折） – 時區與系統時間（伺服器時間與使用者裝置時間不一致時的開賣判定） – 連假特殊開賣規則（春節、清明預售規則與一般日不同） – 跨日邊界（週五 23:59 下單但付款完成已是週六 00:01） – 證件號碼格式（外籍護照、新式身分證、舊式 10 碼 vs 居留證） – 加購占位票（B1、B2 後綴）的邊界 – 退票手續費計算與遺失再購的退費邏輯 – 安全性（暴力試證號、機器人搶票）

關鍵心態 AI 的價值不在於替你想，而在於幫你檢查盲點。把它當成一個 24 小時待命的副審 QA。光是上面這些情境，每一個拿出來都可能是線上事故。

任務三：生成測試資料

請根據以下 schema 生成 30 筆早鳥票測試訂單資料（JSON 陣列）：   passengerId: 涵蓋三種格式   – 新式身分證（A123456789）   – 護照號碼（8~9 碼英數）   – 居留證號（兩英文 + 8 碼） seatExtra: null | “B1” | “B2″（加購占位） trainNo: 從附表中取（含一般、部分尖峰、超尖峰各 5 個車次） travelDate: 涵蓋   – 距今 30 天（剛超過開賣）   – 距今 29 天（剛開賣）   – 距今 6 天   – 距今 5 天（早鳥最後一日）   – 距今 4 天（早鳥已截止） fromStation / toStation: 從 12 個高鐵站取，需含南港、左營、桃園

任務四：把抽象 test case 翻成可執行 script

這是 AI 最擅長的工作。把任務一產出的測試案例，叫 AI 翻成 Playwright / Cypress / Pytest 等可執行腳本。

把這個測試案例： 「使用者於乘車日前 5 天 23:59:30 下單早鳥 9 折票， 車次為部分尖峰（不提供 65 折/8 折）， 完成付款時系統時間已經是 5 天前 00:00:10 → 預期：訂單仍應以 9 折成立，因下單瞬間在區間內」   翻成 Playwright（TypeScript）測試腳本，使用以下 Page Object： [貼上 BookingPage、PaymentPage 的方法簽章] 並請使用 page.clock.install() 模擬跨日邊界。

流程總覽

圖三　混合測試流程的三段式結構：策略 → 展開 → 覆核

三個常見踩雷

雷一：跳過 Step 1 直接叫 AI 生 test cases 你問 AI「幫我寫高鐵早鳥票的測試案例」，它會生一堆「使用者訂票成功」「使用者訂票失敗」這種空話，根本不會碰到「部分尖峰車次只給 9 折」這種業務細節。AI 不知道你的業務邏輯邊界在哪。

雷二：Step 2 任務四產出的腳本直接進 CI AI 生的 selector、等待邏輯、資料清理通常不夠穩。例如它可能用 page.click(“button”) 而非穩定的 data-testid，搶票尖峰時的延遲處理也不會考慮到。記得這只是「初稿」，人類必須過一輪。

雷三：忘了維護骨架 高鐵下個月把早鳥從三級改成兩級，你的決策表沒更新，AI 再展開出來的東西就全錯。混合流程的核心資產是那份骨架，不是 AI 產出的測試案例。骨架是源頭，測試案例只是衍生物。

結語

回到那個 25% 月失敗率與 60% 維護成本的數據——混合流程之所以在業界擴散，不是因為 AI 多厲害，而是因為它把人類的時間從「機械展開」中解放出來，重新投入到「策略思考」與「維護骨架」這些真正有槓桿的工作上。

下次要寫 test cases 之前，先問自己：這一步是策略還是展開？ 答案決定了你該自己做，還是丟給 AI。