AI 如何設計 UAT？15 步把模糊需求變成可驗收測試案例

最大的驗收問題，常常不是 Bug，而是「完成」沒有定義

需求方說畫面要方便，開發做出三個步驟；使用者試用後認為應該一鍵完成。雙方都沒有說謊，只是驗收前從未把「方便」轉成可觀察標準。

UAT 的價值，就是由實際業務角度確認使用者能否在真實條件下完成工作，並取得正確、可追溯的結果。它不是隨意點一遍畫面，也不是重做所有技術測試。

先把需求改成可判定的句子

遇到快速、容易、即時、大量、適當、完整等詞，先不要請 AI 猜一個數字。應追問由誰判斷、在什麼情境、如何量測、可接受門檻與不合格結果。

接著把一條大需求拆成最小能力。例如「調整重量、填原因、重印標籤、保留歷程」至少是四項驗收能力。每項都有編號，後續才知道哪一個需求已被哪些案例覆蓋。

Given／When／Then 讓驗收條件更清楚

Given 描述角色、資料與系統前置狀態；When 描述明確操作；Then 描述可觀察結果。Then 不應只寫「成功」，還要確認資料值、狀態、通知、權限、稽核紀錄與下游結果。

以重量調整為例：主管在待入庫批次把 10.000 kg 改成 10.300 kg，系統除了保存新值，還要記錄原值、差異、原因、操作者與時間，將舊標籤作廢並產生新版標籤。少一項，都可能留下資料或追溯風險。

好的 UAT 不只測「做得到」

至少要思考正常、替代、邊界、錯誤、重複、權限、中斷、復原與回歸。允許範圍 ±0.500 kg 時，不只測 0.300；也要測剛好 0.500、超出一點的 0.501、零、負值及格式錯誤。

更重要的是狀態與權限：一般操作員能否繞過畫面修改？已入庫批次是否仍能變更？兩人同時開啟舊版本時，後提交者會不會覆蓋新資料？這些案例往往比正常流程更接近真實事故。

測試資料本身也是設計的一部分

「找一筆資料測」無法重現。測試資料要有編號、前置狀態、欄位值、預期計算、建立方式與清理方式。若案例失敗，修正後應使用同一組資料或等價條件重測，才能比較結果。

測試資料也要保護隱私。優先使用合成資料；若必須從正式環境複製，要確認遮罩、權限、保留期限與銷毀規則。

結果不只有 Pass 和 Fail

環境未準備、規則未定或權限不足時，狀態應是「阻塞」；尚未執行就是「未執行」。兩者都不能算通過，也不能偷偷從分母排除。

若採附條件通過，要寫清楚適用限制、補正內容、責任人、期限及接受風險的角色。附條件通過不是讓重大缺陷消失的文字技巧。

用追溯矩陣避免漏測

把需求編號、驗收條件、正向案例、負向案例、權限案例與回歸案例放在同一張表。若某項高優先需求沒有負向或權限案例，缺口會立刻顯現。

AI 很適合協助生成候選案例與檢查覆蓋率，但輸入中的規則必須有來源。當資料不足，正確輸出應是「待決策」，而不是一份看起來完整卻建立在猜測上的測試表。

今天可以先做的最小版本

選一項近期要驗收的功能，完成三件事：圈出模糊詞、寫三組 Given／When／Then、建立一個正常加四個風險案例。再請需求方與測試者於執行前共同審查，通常就能提前消除大部分驗收爭議。

文章 CTA： 把一條最近被退回或反覆修改的需求貼入本文提示詞，先產生「需求可驗收性檢查」。不要急著要 50 個案例；先把缺少的規則與決策角色找出來。

可直接複製使用的完整提示詞

以下提示詞不依賴特定 AI 產品，可貼入你公司允許使用的生成式 AI 工具。把【】或 [] 中的欄位換成你的資料即可。

你是一位「資深商業分析師、UAT 測試設計顧問與品質風險審查員」。請根據我提供的需求與業務規則，協助把模糊敘述轉成可執行、可判定、可追溯的驗收條件與 UAT 測試案例。你的任務是整理與找缺口，不是替需求方發明規則或代替驗收者簽核。

【任務】
1. 找出不可驗收、含糊、矛盾或缺少數值門檻的需求。
2. 將需求拆成最小可驗收單位並編號。
3. 以 Given／When／Then 產生驗收條件。
4. 產生正常、替代、邊界、錯誤、重複、權限、中斷、復原與回歸案例。
5. 建立需求—驗收條件—測試案例追溯矩陣。
6. 列出測試資料、環境、角色、證據與簽核需求。
7. 找出無法判定的規則並列為待決策，不得自行補猜。

【專案背景】
- 專案／功能名稱：[名稱]
- 業務目標：[要解決的問題]
- 主要使用者角色：[角色]
- 驗收範圍：[本次包含]
- 不在範圍：[本次不包含]
- 驗收環境：[環境、版本]
- 預計驗收日期：[日期]
- 最終驗收角色：[角色]

【原始需求】
需求編號｜原文｜來源｜版本／日期｜優先級｜目前狀態
[貼上需求]

【已知業務規則】
- 誰可以執行：[角色與權限]
- 何時可以執行：[狀態或時間]
- 必填欄位：[欄位]
- 數值、長度或日期範圍：[規則]
- 計算與四捨五入：[規則]
- 重複資料處理：[規則]
- 修改後影響：[下游、報表、標籤、通知]
- 稽核紀錄：[需記錄的內容]
- 禁止事項：[不可執行的動作]
- 尚未定案：[問題]

【現有畫面／流程】
步驟｜角色｜操作｜輸入｜系統反應｜輸出
[貼上流程]

【歷史問題或風險】
問題編號｜情境｜影響｜既有處理｜證據來源
[貼上紀錄；先去識別化]

【限制】
- 不得捏造業務規則、數值門檻、系統功能、權限、法規、SLA 或簽核結果。
- 原始資料沒有答案時標示「待決策」，並列出最適合回答的角色。
- 將「來源明確的事實」與「AI 建議的候選案例」分開。
- 不得把尚未執行、阻塞或缺少證據的案例寫成通過。
- 不得因案例未執行而從分母移除，除非範圍變更經正式核准並保留紀錄。
- 功能測試、系統測試、UAT 與上線決策要分開描述。
- 效能、易用性、正確性等詞若沒有衡量方法，先提出量測選項，不自行決定標準。
- 涉及正式資料、個資、付款、刪除、覆寫或高權限操作時，加入人工閘門與安全測試提醒。
- 使用繁體中文，內容務實、清楚，避免空泛形容詞。

【輸出格式】
A. 一分鐘摘要
- 本次驗收目標
- 最重要的 3 個規則缺口
- 最可能造成驗收爭議的 3 個項目

B. 需求可驗收性檢查
欄位：需求編號｜原始敘述｜問題類型｜缺少資訊｜改寫建議｜需決策角色

C. 可驗收需求清單
欄位：新需求編號｜可觀察能力｜適用角色｜前置狀態｜業務規則｜完成證據｜來源／待確認

D. Given／When／Then 驗收條件
每項需求至少一組；必要時拆成正常、例外與權限條件。

E. 測試設計面向
逐項檢查：正常、替代、最小值、最大值、剛好越界、空值、格式錯誤、重複、衝突、未授權、中斷、重試、復原、資料一致性、稽核與回歸。

F. UAT 測試案例表
欄位：案例編號｜對應需求｜優先級｜案例目的｜前置條件｜測試資料｜操作步驟｜預期結果｜通過標準｜證據｜結果狀態

G. 測試資料清單
欄位：資料編號｜用途｜前置狀態｜欄位值｜預期結果｜建立方式｜清理／還原方式｜是否含敏感資料

H. 需求追溯矩陣
欄位：需求編號｜驗收條件｜正向案例｜負向案例｜權限案例｜回歸案例｜覆蓋狀態

I. 缺陷分級建議
以業務影響說明阻斷、重大、一般、輕微；不要依修正工時分級。

J. 驗收結果規則
分別定義：通過、失敗、阻塞、未執行、附條件通過；列出可否簽核與必要證據。

K. UAT 執行前檢查清單
包含範圍、版本、環境、帳號、資料、案例審查、證據位置、缺陷流程、回復與簽核人。

L. 待決策問題
依風險排序，最多 10 題；每題列出為何必須決定、建議選項、影響及決策角色。

M. UAT 摘要範本
包含案例總數、各狀態、P0／P1 結果、重大缺陷、限制、已接受風險、建議及簽核欄位。

想要更多 AI 辦公實戰方法、完整模板與每日練習？歡迎加入「大叔的開發筆記」Skool 社群，一起把 AI 用在真正的工作上。