SAP 使用者驗收測試：由誰負責，如何執行

SAP 使用者驗收測試（UAT）是業務使用者在設定好的系統中執行自己的流程，並在上線前正式驗收系統的階段。它由業務單位負責，IT 與導入夥伴提供支援；在 S/4HANA 專案中，我會為它規劃至少 6 到 8 週。

我最常看到的測試失敗很單純：UAT 與系統整合測試（SIT）的測試量不足。時程一延誤，這兩個階段就被壓縮，缺口改在上線後才浮現。

以下說明誰負責什麼、準備工作、測試腳本、缺陷分類處理，以及有實質意義的簽核。若想了解 UAT 在其他測試類型中的位置，請先閱讀我的總覽 SAP 測試全解析。

使用者驗收測試由業務單位負責。這是我的立場，而且不該因為時程吃緊就改變。

理由就在名稱裡。驗收是一項業務決策，判斷系統能否支撐業務運作，所以只有經營業務的人才能做出這個決定。如果 UAT 由 IT 或夥伴簽核，那就等於沒有人驗收任何東西。

SAP 自己的方法論也這麼說。它的 S/4HANA Cloud Private Edition 測試策略指引 把 UAT 放在 Realize 階段。由夥伴的設定專家建立手動測試案例，再由客戶的業務部門專家執行並記錄結果。

可行的工作分配如下：

角色	在 UAT 中負責	不負責
業務流程負責人	情境範圍、驗收準則、其流程的最終簽核	修正設定或程式碼
關鍵使用者與測試人員	執行腳本、記錄結果與佐證、提出發現	獨自判定某項缺陷「不是缺陷」
UAT 主管（業務端）	每日計畫、進度、主持分類會議、向專案發起人提交就緒報告	技術修正
導入夥伴	起草腳本、測試系統就緒、修正缺陷、支援重新測試	驗收
內部 IT	環境、權限、與其他系統的介面、傳輸	驗收
資料團隊	載入與更新測試資料、支援對帳	業務情境設計

UAT 主管應該來自業務單位，而不是夥伴。由夥伴主導的 UAT，會逐漸偏向證明建置成果可行，而這和業務單位能否靠它運作是兩個不同的問題。

UAT 至少需要 6 到 8 週。少於這個時間，業務單位只會把正常流程測一次，沒有時間重新測試修正，也永遠碰不到真正問題所在的例外情況。

這幾週只有在 UAT 從穩定的系統開始時才有效。SAP 的指引是，業務流程要在整合設定完成、該流程的資料也已移轉之後才測試。這代表 SIT 必須依議定的退出準則先完成，而我的 S/4HANA 測試策略 指南說明了這些週期如何銜接。

在第一位測試人員登入之前，以下項目都應該到位：

1. 已簽核的流程設計。 腳本是依據它們撰寫的，設計未簽核，腳本就無法定案。
2. 進入準則已達成並留下紀錄。 SIT 已完成、沒有未結的重大缺陷，且除了受控的修正之外，測試系統已凍結。
3. 與正式環境相似的測試系統。 設定、介面、角色與權限都和上線時一致。
4. 貼近真實的測試資料。 經過遮罩、達到正式環境等級，在測試開始前完成載入與對帳。我的 SAP 測試資料管理 指南說明了做法。
5. 測試人員從日常工作中抽出時間。 指名測試人員，與他們的主管議定投入時數，並以書面記錄。
6. 測試人員已接受新系統的教育訓練。 在 UAT 之前（而不是期間）簡短導覽他們將使用的 Fiori 應用程式與交易。
7. 單一測試管理工具。 腳本、結果、佐證與缺陷集中在同一處，而不是分散在多份平行的試算表中。

第 5 項是 UAT 通常悄悄失敗的地方。被要求在月結之餘擠出時間做 UAT 的測試人員，會優先處理月結，而他們這樣做是對的。

UAT 腳本是一個業務情境，而不是一份交易清單。「建立銷售訂單」測試的是一個畫面。「接一張信用凍結中新客戶的訂單，解除凍結、出貨並開立發票」測試的才是業務。

依已簽核的流程設計建立腳本，並為每一個腳本訂出以業務用語表達的明確預期結果。測試人員應該不必問顧問，就能判斷通過或失敗。

涵蓋四種情境：

1. 核心流程。 維持業務運作的日常流程，例如訂單到收款、採購到付款與記錄到報告。
2. 例外情況。 退貨、信用凍結、部分交貨、價格變動、沖銷，以及被駁回的核准。
3. 期末作業。 財務團隊實際執行的月結與年結步驟，並依他們實際執行的順序。
4. 角色檢查。 每位測試人員都以上線後將擁有的角色執行測試，讓權限缺口現在就浮現。

讓夥伴起草腳本，再請關鍵使用者用他們自己的語言改寫。如果業務單位沒有人協助就看不懂腳本，那這份腳本就是寫給建置團隊看的。

在 SAP Cloud ALM 中，手動測試案例從流程開始建立，測試計畫則把它們分組成週期。測試人員將每個步驟設為通過或失敗、記錄實際結果，並直接從測試執行中提出缺陷，讓腳本與缺陷之間保持連結。

對於仍以 SAP Solution Manager 7.2 管理測試的專案，請注意它的主流維護將於 2027 年底結束（SAP Support）。新專案請以 Cloud ALM 規劃。

不是每一項 UAT 發現都是缺陷。全部當成缺陷會淹沒夥伴，全部當成變更需求則會掩蓋真正的失敗。

UAT 期間每天都要開分類會議。由業務端的 UAT 主管主持，夥伴的功能主管與一位 IT 代表出席，每一項新發現離開會議室時都要有類型、嚴重度與負責人。

一套簡單的分類就能涵蓋大多數發現：

發現類型	意義	由誰處理	對簽核的影響
缺陷	系統沒有做到已簽核設計所描述的內容	夥伴修正，測試人員重新測試	重大與高等級缺陷會阻擋簽核
變更需求	設計已達成，但業務單位現在想要不同的東西	設計主管機關依成本與時程決定	不會阻擋，除非業務單位表示沒有它流程就無法運作
資料問題	主檔資料或交易資料錯誤或缺漏	資料團隊修正，測試人員重新測試	如果同樣的資料將會上線，就會阻擋
教育訓練或使用問題	系統正常，但測試人員不知道如何使用	教育訓練主管更新教材	不會阻擋，但會納入教育訓練計畫
權限問題	角色缺少權限，或權限過多	資安團隊調整角色	會阻擋受影響的角色

在 UAT 開始前，以業務用語議定嚴重度定義。重大缺陷會讓流程停擺且沒有替代做法。高等級缺陷有替代做法，但業務單位無法在大量業務下長期維持。

留意變更需求這一欄。UAT 中出現一長串變更需求，通常代表業務單位在設計階段沒有充分參與，這是下一波推展前必須解決的問題。

SAP 的 Activate 訓練教材指出，使用者驗收測試完成並簽核後，Realize 階段才算完成。讓這份簽核成為一份文件，而不是一串電子郵件。

每位業務流程負責人為自己的流程簽核。簽核應記錄：

1. 測試了什麼。 執行、通過與失敗的情境，佐證保存在測試工具中。
2. 還有什麼未結。 每一項未結缺陷，以及其嚴重度、負責人與目標日期。
3. 哪些以替代做法接受。 逐項列出，並寫明業務單位同意採用的替代做法。
4. 誰在何時簽核。 每個流程一位具名人士，而不是一個委員會。

在 UAT 開始前寫好退出準則，結果出來時也不要更改。如果業務單位在仍有缺口的情況下還是想上線，就把它記錄為一項經簽署的決策。我的 SAP 品質關卡 指南說明這道關卡如何對應各階段的轉換。

UAT 簽核不是上線決策。它是上線決策的依據之一。

我堅持的上線準則，是一份事先議定的詳盡切換檢核清單。UAT 簽核只是其中一行，旁邊還有資料對帳、教育訓練與切換演練。

簽核之後，要保護已驗收的成果。從現在到上線的每一次修正與傳輸都需要重新測試，我的 SAP 迴歸測試 指南說明如何控管這件事。

您不需要一份冗長的文件。您需要的是一份每次都回答同樣問題的計畫，在 UAT 開始前寫好，並由業務單位簽署。

一份簡單的大綱就夠了：

章節	內容	負責人
範圍	範圍內的流程、組織單位與角色，以及明確排除的項目	業務流程負責人
時程	開始與結束日期、週期、重新測試的時間窗、期末作業執行	UAT 主管
團隊	依流程分配的測試人員、其從日常工作中抽出的時間、夥伴與 IT 支援聯絡人	UAT 主管與直屬主管
進入準則	已達 SIT 退出準則、測試系統已凍結、資料已載入並對帳、測試人員已受訓	UAT 主管與專案經理
環境與資料	測試系統、範圍內的介面、經遮罩且達正式環境等級的資料、更新計畫	IT 與資料團隊
腳本	每個流程的情境清單、預期結果、與流程設計的連結	夥伴起草，關鍵使用者核准
缺陷流程	發現類型、嚴重度定義、每日分類會議、重新測試規則	UAT 主管主持分類會議
報告	每日進度、依嚴重度統計的未結缺陷、向專案發起人回報的阻礙	UAT 主管
退出準則	各嚴重度未結缺陷的門檻、通過的情境、議定的替代做法	業務流程負責人
簽核	每位流程負責人的簽核欄、已接受的替代做法清單	業務流程負責人與專案發起人

在各推展波次中沿用同一份範本。第二次推展應該重複使用第一波的腳本與經驗教訓，而不是從頭開始。

這個月就從業務單位指派您的 UAT 主管，並請每位流程負責人提名能抽出時間的測試人員。接著在計畫中把 6 到 8 週的 UAT 放在 SIT 之後，並在時程吃緊時守住它。

如果您的 UAT 是由夥伴在執行，或一再被壓縮，我可以協助專案把這件事建立好。您可以 在這裡與我聯絡。

SAP 中的使用者驗收測試是什麼？

它是業務使用者依照真實流程測試設定好的 SAP 系統，並在上線前正式驗收的階段。在 SAP Activate 中，它發生在 Realize 階段、整合測試之後。關鍵使用者執行情境腳本、記錄結果並提出發現，再由流程負責人簽核。

SAP 專案中的 UAT 由誰負責？

業務單位：流程負責人決定範圍並簽核，關鍵使用者執行測試。導入夥伴起草腳本並修正缺陷，內部 IT 提供環境、權限與介面。IT 與夥伴都不應代替業務單位驗收系統。

SAP UAT 應該花多久時間？

在 S/4HANA 專案中至少規劃 6 到 8 週。這樣才有時間執行核心流程、例外情況與期末作業步驟，再重新測試修正。比這更短的 UAT，通常只把正常流程測一次，其餘問題都在上線後才發現。

SAP 中的 SIT 與 UAT 有什麼不同？

系統整合測試（SIT）檢查流程與介面能否跨模組與系統協同運作，主要由專案團隊執行。UAT 檢查業務單位能否在系統上執行其流程，由業務使用者執行。SIT 應在 UAT 開始前完成。

UAT 簽核應包含什麼？

已測試的情境及其結果、每一項未結缺陷及其負責人與日期、業務單位已接受的替代做法，以及每位流程負責人的具名簽署。在 UAT 開始前議定退出準則。帶有缺口的簽核，應該是一項有紀錄的業務決策。

SAP Cloud ALM 可以用於 UAT 嗎？

可以。SAP Cloud ALM 支援從流程建立的手動測試案例、每個週期的測試計畫、逐步記錄通過或失敗，以及從測試執行中提出缺陷。依 SAP 的指引，由夥伴專家建立測試案例，再由客戶的業務專家在其中執行並記錄結果。