用戶驗收測試流程圖
用戶驗收測試範本，涵蓋範圍、業務情境、受保護測試數據、環境準備、執行證據、問題分級、重新測試及簽署。
甚麼是用戶驗收測試流程
用戶驗收測試是由業務判斷發布版本能否支援議定工作及成效，不是把技術測試再做一次。流程先界定範圍、結束準則、測試人員及有權簽署的人。業務測試人員根據需求及風險草擬端對端情境；環境及數據支援準備具代表性並受保護的數據；交付團隊則證明已部署版本可以測試。執行時會記錄預期及實際結果並附上證據；產品負責人再按業務影響評定問題，不會把每項差異視為同一嚴重程度。
本圖刻意比 /yue/templates/企業軟件實施流程 的完整生命週期更窄。系統、整合、效能及保安測試應在驗收測試前建立技術信心；本流程只集中業務情境、阻礙驗收的嚴重程度、針對性修正、回歸重測及問責簽署。不阻礙驗收的問題，只可透過機構指定的剩餘風險路徑，由具名負責人連同行動接受。請以發布版本獲批的需求、數據處理規則及決策權，取代圖中的範例準則，不要假設一種嚴重程度模型適合所有系統。
本流程圖涵蓋的內容
本範本包含
- 八個階段，由範圍及情境設計，經測試數據、環境準備、執行、問題分流及重測，到簽署確認
- 由業務擁有並連到需求及風險的情境，讓涵蓋範圍反映真實工作而不只系統功能
- 具代表性的測試數據，以及在測試人員取得存取權前完成授權、遮蔽或重新產生的循環
- 收集證據並按嚴重程度分流，分開阻礙驗收的問題及需要明確處置的非阻礙問題
- 修正、部署及回歸重測循環，最後由贊助人簽署，或退回收集更多證據
何時使用本範本
- 發布版本在部署至正式環境或達到合約里程碑前，需要正式業務驗收
- 測試人員收到測試步驟時，沒有具代表性數據、穩定存取權或與議定需求的追溯關係
- 問題討論停滯，因為嚴重程度、業務影響及接受剩餘風險的權限未有界定
- 目前只以非正式訊息簽署確認，沒有證據套件、未解決問題紀錄或具名審批人
運作方式
界定範圍及簽署權限
列出驗收測試包括的流程、用戶群、需求及風險，以及明確排除的內容。指明審批人及該角色接受或拒絕發布所需的證據。
編寫業務情境
圍繞真實工作、決策、例外及交接建立端對端案例，而不是逐個畫面測試。把每項情境連到需求及優先風險，讓涵蓋範圍審閱可以找出有意義的缺口。
準備安全而具代表性的數據
列明測試正常及例外路徑所需的數據組合、由誰批准使用，以及如何遮蔽或合成敏感值。確認資料受保護後仍保留真實的參照關係及邊界情況。
設定嚴重程度及重測規則
以業務用語界定阻礙及非阻礙影響、由誰評級、哪些修正需要重測受影響案例，以及新版本要做多少回歸測試。執行前先列明爭議分級的處理路徑。
建立簽署紀錄
收集已執行案例、實際結果、證據、環境及版本識別碼、問題、重測結果及獲接受的剩餘行動。把批准、拒絕及要求更多證據記成有日期及問責角色的清晰決定。
常見問題
用戶驗收測試有甚麼目的？
驗收測試為問責的業務負責人提供證據，證明發布版本支援議定真實情境，並可供營運使用。它測試業務適用程度，而不是證明所有技術屬性。結果應是一項有記錄的驗收決定，包括已知問題及剩餘行動的處置，而不只是一個通過案例數目。
誰應執行及批准用戶驗收測試？
具代表性的業務用戶應執行情境，因為他們理解工作、例外及後果。驗收測試主管協調範圍、數據、環境及證據；產品負責人支援分流；交付團隊修正問題。最終批准應由有權接受營運影響及剩餘風險的業務贊助人或獲授權審批人作出，而不應只由建立版本的團隊決定。
應如何排列驗收測試問題的優先次序？
按書面定義評定業務影響，包括關鍵工作是否無法完成、數據或管控有沒有受損、是否有安全替代方法，以及影響多少用戶或交易。技術複雜程度可影響修正計劃，但不應降低業務嚴重程度。非阻礙問題仍要有記錄決定，在簽署前修正，或連同負責人及到期行動接受。
用戶驗收簽署應包括甚麼證據？
紀錄應識別測試版本及環境、獲批範圍及結束準則、已執行情境、預期及實際結果、佐證、問題嚴重程度及狀態、重測結果、任何有負責人的剩餘問題，以及審批人有日期的決定。保留足夠背景，毋須依賴個人收件箱或記憶也能重組業務接受了甚麼。
此流程所處的位置
在大多數機構中，此流程緊接數據遷移流程圖：由評估到切換之後，並交接給放行與否決策流程：推出就緒決策樹。
它是數碼轉型中的其中一個步驟。
第 1 步: 數碼轉型流程圖
第 2 步: 數碼計劃優先次序流程
第 3 步: 項目治理流程圖
第 4 步: 企業軟件實施流程
第 5 步: 數據遷移流程圖：由評估到切換
數據遷移流程範本，涵蓋範圍評估、欄位對照、清理、模擬載入、核對、業務核實、切換檢查及受控回復。
第 6 步: 用戶驗收測試流程圖 當前位置
用戶驗收測試範本，涵蓋範圍、業務情境、受保護測試數據、環境準備、執行證據、問題分級、重新測試及簽署。