S/4HANA 測試策略：測試週期、準則與角色

S/4HANA 測試策略決定您要執行哪些測試週期、依什麼順序、各由誰負責，以及需要什麼證據才能從一個週期進入下一個。在我的專案中，它涵蓋分輪進行的系統整合測試（SIT）、分輪進行的使用者驗收測試（UAT）與迴歸測試，每一項都有書面的進入與退出準則，以及具名的簽核人。

在我規劃的 S/4HANA 專案中，測試約占專案工作量的 35%，所以測試策略值得和建置計畫一樣用心。

各種測試類型本身，請參閱我的 SAP 測試全解析 指南。本文談的是策略層面：測試週期、準則、角色與文件大綱。

SAP Activate 把大部分測試放在 Realize 階段。SAP 自己的 S/4HANA Cloud Private Edition 測試策略教材 將單元測試與串接測試視為非正式測試。完整業務流程測試、整合測試、資料移轉測試與使用者驗收測試則是正式測試，必須留下文件紀錄。

以下是我在 S/4HANA 專案中規劃的順序：

S/4HANA 測試週期

1. 01

   單元與串接測試

   顧問在建置時測試每一項設定好的功能與短流程串接。

2. 02

   SIT 各輪

   跨模組、介面與移轉資料的完整流程串接。

3. 03

   UAT 各輪

   業務使用者一輪一輪證明系統能執行他們的流程。

4. 04

   迴歸測試

   在修正、傳輸與版本更新後，重新測試已通過的項目。

5. 05

   模擬轉換與演練

   依照檢核清單，以正式切換當晚的方式執行切換。

6. 06

   上線

   只有在議定的切換檢核清單全部完成時才上線。

單元測試與串接測試

顧問與開發人員在建置時，測試每一個設定項目與每一項開發。串接測試把幾個步驟連在一起，例如從銷售訂單一路到交貨。

以 SAP 的說法是非正式測試，但並非可有可無。

分輪進行的系統整合測試

SIT 測試跨模組、介面，以及轉換或載入資料的完整業務流程。我把它規劃成多輪，而不是一次性的活動，讓上一輪修正的缺陷能在下一輪重新測試。

我沒有固定的 SIT 輪數。輪數取決於範圍內的流程、介面與法人實體數量，測試策略應該寫明要跑幾輪以及原因。

分輪進行的使用者驗收測試

UAT 是業務單位用自己的人與貼近真實的資料，確認系統能執行其流程的地方。和 SIT 一樣，我把它規劃成多輪，讓上一輪的修正能在下一輪重新測試。

UAT 至少需要 6 到 8 週。業務測試人員是在正常工作之外做這件事，而且需要足夠時間進行不只一輪。我的 SAP 使用者驗收測試 指南詳細說明測試腳本、輪次與簽核。

迴歸測試

每一次修正、傳輸與版本更新，都可能弄壞已經通過的項目。迴歸測試會在每次變更後重新執行重要流程，在專案期間與上線後都是如此。

SAP 的教材主要把迴歸測試放在 Run 階段、版本升級之後，但專案更早就需要它。做法、影響分析與環境設定，請參閱我的 SAP 迴歸測試 指南。

模擬轉換與切換演練

在 brownfield 轉換專案中，我會在正式切換前規劃三次模擬轉換。每一次都要測試轉換本身、時程與對帳，而不只是流程。

最後一次演練應該像真正的切換當晚一樣執行：同樣的順序、同樣的人、同樣的檢核清單。我的 S/4HANA 移轉時程與專案計畫 說明了這些演練在計畫中的位置。

最重要的單一負責歸屬決定：使用者驗收測試由業務單位負責。不是系統整合商，也不是 IT。

整合商可以準備腳本與修正缺陷。但只有負責您月結、訂單到收款或工廠運作的人，才能確認這些流程可行。

SAP 自己的指引也指向同一方向。由夥伴的設定專家建立測試案例，由客戶的業務部門專家執行 UAT 並記錄結果。

以下是我在各週期中分配負責歸屬的方式：

週期	負責人	執行者	簽核人
單元與串接測試	建置團隊主管	顧問與開發人員	功能主管與技術主管
SIT 各輪	測試經理	顧問，關鍵使用者於後幾輪加入	測試經理與流程負責人
UAT 各輪	業務單位，透過具名的流程負責人	關鍵使用者與業務測試人員	流程負責人，再由專案發起人簽核
迴歸測試	測試經理	測試團隊，數量值得時採用自動化	測試經理與變更委員會
模擬轉換與演練	切換主管	技術、資料與功能團隊	切換主管、資料主管與專案發起人

在測試策略中寫上人名，而不是角色。「財務流程負責人」是一個角色；一位已同意簽核的具名人士，才是負責人。

進入準則避免週期在尚未具備成功條件時就開始。退出準則則避免週期只因為行事曆到了就結束。

在 Realize 開始前、還沒有人承受時程壓力時，就把兩者都寫好。我的 SAP 品質關卡 指南說明這些準則如何成為正式關卡，並由一位能說「尚未就緒」的負責人把關。

下表是可調整的指引，而不是照抄的標準。請與專案發起人一起設定百分比與缺陷上限，並記錄在測試策略中：

週期	進入準則	退出準則
單元與串接測試	設計已簽核；受測項目的設定與開發已完成	所有項目已測試並留下文件；缺陷已修正，或已登錄至 SIT 處理
SIT 一輪	範圍內流程的單元測試已完成；測試環境已建置且介面已連接；測試資料已載入；腳本已審閱	議定比例的腳本已執行並通過；沒有未結的重大缺陷；未結的較低等級缺陷各有負責人與修正日期
UAT 一輪	已達 SIT 退出準則；業務測試人員已指名並從日常工作中抽出時間；腳本已由流程負責人審閱；測試系統的教育訓練已完成	每一個範圍內流程都已由業務使用者執行；沒有未結的重大缺陷；流程負責人已簽核各自的流程
迴歸測試	一項變更、一批修正或一個版本已準備移轉；受影響流程的迴歸測試包已議定	迴歸測試包已通過；任何失敗都在變更繼續推進前修正並重新測試
模擬轉換或演練	已有正式環境複本；切換檢核清單與執行手冊已起草；對帳規則已議定	轉換或載入在規劃的時間窗內完成；對帳已由資料主管簽核；檢核清單已依經驗教訓更新
上線	先前所有退出準則都已達成；切換檢核清單已事先議定	檢核清單每一項都已完成並簽核；專案發起人已記錄 go/no-go 決定

讓這張表發揮作用的規則有兩條。每一項準則都能給出是或否的答案，每一個退出都有具名的簽核人。

如果某個週期未達退出準則，業務單位仍想繼續推進，就把它變成書面決策。寫明承擔風險的人，以及帶到下一階段的缺陷。

測試策略由測試經理在 Prepare 或 Explore 初期撰寫，再由專案發起人核准。篇幅要短到流程負責人願意讀。

以下是我期望看到的章節：

1. 範圍與目標。 哪些流程、法人實體、介面與報表要測試，哪些明確排除在外。
2. 測試類型與週期。 單元、串接、SIT 各輪、UAT 各輪、迴歸、效能、資料移轉測試與模擬轉換，並寫明輪數與理由。
3. 時程與工作量。 每個週期在 SAP Activate 計畫中的日期，UAT 至少給 6 到 8 週，工作量以約 35% 的測試占比編列預算。
4. 角色與負責歸屬。 上面的負責歸屬表，並填上人名。
5. 進入與退出準則。 每個週期一組，並寫明各自的簽核人。
6. 環境。 哪個週期使用哪些系統、如何更新，以及如何讓專案變更與正式環境維運變更保持分離。
7. 測試資料。 資料從哪裡來、如何遮罩，以及各輪之間如何更新。我的 SAP 測試資料管理 指南有深入說明。
8. 缺陷管理。 嚴重度定義、分類檢討的頻率、由誰決定優先順序，以及各嚴重度的目標修正時間。
9. 工具。 測試案例、結果、缺陷與簽核存放在哪裡，以單一系統作為正式紀錄。
10. 自動化做法。 哪些測試自動化、哪些維持手動，以及原因。
11. 報告。 每週測試報告要呈現什麼、由誰接收。
12. 切換與上線準則。 切換檢核清單、證明其可行的演練，以及由誰做出 go/no-go 決定。
13. 風險與假設。 測試人員的可用性、環境日期、資料就緒程度，以及對第三方的依賴。

在工具方面，SAP Cloud ALM 是新專案的預設選擇。SAP 表示 SAP Cloud ALM 不需要另外的授權：它包含在 Enterprise Support 之中，其測試管理應用程式負責保存正式的測試案例、執行紀錄與結果。

許多專案仍在使用 SAP Solution Manager 7.2，但它的 主流維護將於 2027 年底結束。在自動化方面，SAP 銷售可與 Cloud ALM 搭配使用的 SAP Test Automation by Tricentis；更廣泛的選擇請參閱我的 SAP 測試工具比較。

我最常看到的測試失敗，是 UAT 與 SIT 的測試量不足。

常見的機制是：建置延誤，上線日期不動，於是時間從測試週期裡扣掉，因為它們排在計畫的最後面。

以下是造成這種情況的模式，以及各自的對策：

1. 單元測試尚未完成就開始 SIT。 第一輪 SIT 變成了單元測試。請守住進入準則。
2. UAT 只規劃兩三週。 業務使用者在這段時間內，無法一邊做日常工作一邊好好測試。至少規劃 6 到 8 週，並讓測試人員抽出時間。
3. 整合商替業務單位執行 UAT。 腳本都通過了，業務單位卻在上線後才發現缺口。讓 UAT 的負責歸屬留在流程負責人身上。
4. 測試只被編列為一個小預算項目。 測試約占工作量的 35%，只編列其中一小部分預算的測試，會最先被砍。
5. 退出準則在週期進行中才寫。 結果準則會變成團隊已達成的任何狀態。請在 Realize 之前寫好。
6. 上線是依信心決定，而不是依檢核清單。 沒有人能拿出當初議定的內容，也就沒有人能說出還缺什麼。

最後一點是我堅持的。我的上線準則是一份詳盡的切換檢核清單，事先與業務單位、IT 與整合商議定。

它涵蓋技術步驟、資料載入、對帳、業務驗證、介面切換、使用者權限與 go/no-go 決策點。只要有任何一項尚未完成並簽核，不論日期怎麼說，專案都還沒準備好。

在 Realize 開始前，向您的測試經理索取測試策略文件，並對照上面的大綱檢查。如果文件裡沒有具名的 UAT 負責人、給 UAT 的時間少於 6 到 8 週，或沒有每個週期的進入與退出準則，請先修正這些問題。

如果您想對測試策略或上線檢核清單取得獨立的審查，我可以協助您的組織。您可以 在這裡與我聯絡。

什麼是 S/4HANA 測試策略？

它是一份計畫，決定要執行哪些測試週期、依什麼順序、各由誰負責與簽核，以及需要什麼證據才能讓專案從一個週期進入下一個。在 S/4HANA 專案中，它通常涵蓋單元與串接測試、SIT 各輪、UAT 各輪、迴歸測試、資料移轉測試與切換演練。

測試占 S/4HANA 專案多少比例？

在我規劃的專案中，測試約占專案工作量的 35%。從一開始就以這個水準編列預算，因為建置延誤時，資金不足的測試總是最先被砍。

S/4HANA 專案的 UAT 應該花多久時間？

至少 6 到 8 週。業務測試人員是在正常工作之外執行 UAT，而且需要足夠時間進行不只一輪，讓第一輪的修正能重新測試。

SAP 使用者驗收測試應由誰負責？

業務單位，透過具名的流程負責人。系統整合商可以準備腳本、管理環境與修正缺陷，但只有實際執行流程的人，才能確認系統適合他們。

SAP 測試中的進入準則與退出準則是什麼？

進入準則是一個週期開始前需要具備的條件，例如單元測試已完成、環境已建置、測試資料已載入。退出準則是週期結束前必須達成的條件，例如腳本已執行、沒有未結的重大缺陷，以及流程負責人已簽核。每一項都應能給出是或否的答案，並有具名的簽核人。

S/4HANA 上線檢核清單應包含什麼？

技術切換步驟、資料載入與對帳、業務驗證、介面切換、使用者權限，以及 go/no-go 決策點。事先議定這份清單，在模擬轉換或總彩排中演練，並且只有在每一項都完成並簽核時才上線。