在介紹完後 Gherkin 和前面那些開立範例的測試手法，接下來我們來聊聊如何使用 GenAI 工具來輔助我們開立範例。

很多人認為GenAI 可以開出不錯的範例，並且又快又好，但真的是這樣嗎？就讓我們來看看會有什麼結果。這邊我們使用台灣高鐵訂票系統網頁版來當對象：
高鐵系統網站： https://irs.thsrc.com.tw/IMINT/?locale=tw

練習一 簡單地請 ChatGPT 開立範例

A. Prompt
請開立出台灣高鐵訂票系統中分票功能的 AC，高鐵系統 https://irs.thsrc.com.tw/IMINT/?locale=tw

B. ChatGPT 的回答
Scenario 1: 分票人成功分票給同行者
Scenario: 分票人成功分票給同行者
Given 分票人已完成訂票並成功取票
And 分票人選擇「本手機取票及分票」方式
When 分票人於 T Express App 中選擇欲分票的車票
And 選擇通訊方式（如：LINE、簡訊、Email）傳送分票連結與驗證碼
Then 同行者應收到分票連結與驗證碼
And 分票人手機顯示該筆訂位紀錄狀態為「已分票」

Scenario 2: 同行者成功取得分票
Scenario: 同行者成功取得分票
Given 同行者已安裝最新版 T Express App
And 已收到分票連結與驗證碼
When 同行者點擊分票連結並輸入驗證碼
Then 系統應將對應車票載入同行者的 T Express App 中
And 該車票顯示於「我的車票」列表

Scenario 3: 分票後限制其他取票方式
Scenario: 分票後限制其他取票方式
Given 一筆訂位紀錄已執行分票
When 同行者嘗試透過非 T Express App 的方式（如：自動售票機、車站窗口）取票
Then 系統應提示「此訂位僅限使用智慧型手機取票及乘車，無法使用其他通路開票」

Scenario 4: 同行者未安裝 T Express App
Scenario: 同行者未安裝 T Express App
Given 同行者尚未安裝 T Express App
When 同行者點擊分票連結
Then 系統應引導同行者前往 App Store 或 Google Play 下載並安裝 T Express App

Scenario 5: 分票後退票處理
Scenario: 分票後退票處理
Given 分票人已將車票分票給同行者
And 同行者尚未取票
When 分票人嘗試辦理退票
Then 系統應允許分票人辦理退票
And 退票款項退回原付款帳戶

Scenario 6: 同行者已取票後退票處理
Scenario: 同行者已取票後退票處理
Given 同行者已成功取票
When 同行者嘗試辦理退票
Then 系統應允許同行者辦理退票
And 退票款項退回原付款帳戶

Scenario 7: 分票功能僅適用多人訂位
Scenario: 分票功能僅適用多人訂位
Given 訂位紀錄僅包含一張車票
When 使用者嘗試執行分票功能
Then 系統應提示「單人訂位無需分票，可直接取票乘車」

練習二 使用 Use Case Testing 開立範例

A. Prompt
用 Use Case Testing 為「台灣高鐵分票功能」開立 AC

B. ChatGPT的回答
Use Case 簡述
使用者希望把訂購的車票，分送給其他同行者，各自用手機取票。

主成功流程（Happy Path）
Scenario 1: 成功分票給同行者
Scenario: 成功分票給同行者
Given 使用者已完成訂位並付款
And 選擇「分票功能」並成功傳送分票連結與驗證碼給同行者
When 同行者使用分票連結並輸入正確驗證碼
Then 同行者的 App 成功載入該車票
And 分票人車票狀態變更為「已分票」

例外流程（Alternative / Exception Flows）
Scenario 2: 驗證碼輸入錯誤
Scenario: 驗證碼輸入錯誤
Given 同行者點擊分票連結
When 輸入錯誤的驗證碼
Then 系統應提示「驗證碼錯誤，請重新輸入」

Scenario 3: 分票連結過期或失效
Scenario: 分票連結過期或失效
Given 分票人已傳送分票連結
When 同行者於有效期限外點擊連結
Then 系統應提示「分票連結已失效，請聯絡分票人重新分票」

Scenario 4: 未安裝 App 無法領取分票
Scenario: 未安裝 App 無法領取分票
Given 同行者尚未安裝 T-Express App
When 點擊分票連結
Then 系統應引導至 App Store/Google Play 下載 App

Scenario 5: 分票已經完成，不可重複領取
Scenario: 分票已經完成，不可重複領取
Given 同行者已經成功領取過分票
When 再次點擊同一分票連結
Then 系統應提示「此票券已領取完成」

Scenario 6: 分票過程中取消分票
Scenario: 分票過程中取消分票
Given 分票人開始分票流程
When 分票人中途取消操作
Then 系統應保留票券在分票人帳戶中
And 狀態維持「未分票」

練習三 使用 Decision Table Testing 開立範例

A. Prompt
用 Decision Table Testing 為「台灣高鐵分票功能」開立 AC

B. ChatGPT 的回答

• 條件（Conditions）
  

• 動作（Actions）
  

• Decision Table（簡化版）
  

*:表示此條件不影響結果。

 從 Decision Table 推導出 AC
Scenario 1: 成功分票
Scenario: 成功分票
Given 分票人已完成訂位並取票
And 分票人選擇分票功能
And 同行者已安裝 T-EX App
And 驗證碼輸入正確
And 分票連結有效
When 同行者完成分票流程
Then 車票成功轉移到同行者帳戶

Scenario 2: 同行者未安裝 App
Scenario: 同行者未安裝 T-EX App
Given 分票人已選擇分票功能
When 同行者點擊分票連結但未安裝 T-EX App
Then 系統應引導使用者下載並安裝 T-EX App

Scenario 3: 驗證碼錯誤
Scenario: 驗證碼錯誤
Given 同行者收到分票連結
When 輸入錯誤的驗證碼
Then 系統應提示「驗證碼錯誤，請重新輸入」

Scenario 4: 分票連結過期
Scenario: 分票連結過期
Given 分票人已傳送分票連結
When 同行者於有效期限後點擊分票連結
Then 系統應提示「分票連結已失效」

Scenario 5: 尚未訂票或取票
Scenario: 尚未訂位或取票，無法分票
Given 分票人尚未完成訂位或取票
When 嘗試啟動分票功能
Then 系統應提示「尚未完成訂位或取票，無法進行分票」
And 保持票券在原帳戶中

你可以發現到：直接開 vs 用 Use Case vs 用 Decision Table，有明顯層次上的差異。

• 沒有方法 ➔ 容易漏掉很多情境，尤其是異常流程與邊界條件。
• 用 Use Case ➔ 流程連貫、體驗思維好，但對條件交互覆蓋有限。
• 用 Decision Table ➔ 條件組合嚴密、邊界條件完整，但缺少故事感。

因此，比較好的做法是：

• 先用 Use Case 建立故事骨架 ➔ 再用 Decision Table 補強條件組合 ➔ 最後人工審核業務邏輯與重點。
• 而 GenAI 在這個流程中很適合擔任「快速展開」和「幫忙列條件組合」的角色，但真正的業務關鍵仍需人腦把關。

此外，由上面的三種做法可以知道，為什麼沒有測試知識，只靠 GenAI，還是難開出好範例。

(1) GenAI 本身不會測試，只是語言模型
GenAI 只是在模仿大量看到的句子結構（例如：Given-When-Then）。它不知道「邏輯漏洞」、「需求矛盾」、「場景是否符合業務背景」。它只會根據文字表面合理性去生成內容，不會真正檢查需求完整性或風險。

例如：你問：「請幫我產生高鐵訂票系統的異常流程」
它可能會生出「當票價為負數時訂票成功」，這在業務上根本不可能，但表面看起來很合理。

(2) 沒有測試知識，使用者不知道要問對的問題
測試設計的關鍵，不只是寫出一句句 AC，更是問對問題。例如：

• 邊界條件是什麼？
• 什麼是重要異常？
• 行為和狀態之間有什麼交互影響？
• 成功定義是什麼？失敗定義是什麼？
  如果自己不知道該去問這些問題，GenAI 自然也不會「主動幫你想到」。

例如：上面「請產生分票功能的 AC」做法，如果沒有加問「異常流程有哪些？分票連結過期要怎麼處理？同行者未裝App怎麼辦？」GenAI通常只會給你一條主流程，異常與邊界情境或許會有，但不見得在你的商業規則中。

沒有測試設計知識的人，就算有GenAI，也只是用得很像「高級填空機」。
真正好的 AC、好的範例，必須要有人類掌握背後的測試技巧和邏輯判斷，GenAI只是加速器，不是思考者。