SAP 測試全解析：類型、階段與負責人

SAP 測試的工作，是證明一套設定好的 SAP 系統，能用您的資料、在您的業務量下正確執行業務流程，不論是上線之前，還是上線後每一次變更。在 S/4HANA 專案中，它涵蓋六種測試：單元測試、系統整合測試（SIT）、使用者驗收測試（UAT）、迴歸測試、效能測試與切換演練。

每一種測試回答的問題都不同，彼此無法互相取代。依我的經驗，測試約占專案工作量的 35%，所以它應該有自己的計畫、預算與負責人，而不是在建置尾聲擠出幾週。

本頁是總覽。每種測試都有自己的指南，連結放在下方各節。

SAP 系統是設定、主檔資料、客製程式與介面共同運作的結果。一個地方的變更，可能讓別處的流程出錯，而且常常發生在沒人動過的模組。

因此 SAP 測試是以業務流程為單位來安排，而不是以畫面為單位。訂單到收款、採購到付款、記錄到報告都橫跨多個模組，只測到單一交易就停下來，證明不了多少事。

測試也不會在上線時結束。維運變更、SAP 版本更新與新的推展都會改變系統，所以同樣的紀律會延續到 Run 階段。

以下是我在 S/4HANA 專案中規劃的六種測試。下表列出每一種要證明什麼、何時執行，以及應由誰負責。

測試類型	要證明什麼	在 SAP Activate 中的位置	負責人
單元測試	每個設定項目、程式或增強功能本身都能正常運作	Realize，在每個建置衝刺之內	功能顧問與技術顧問
系統整合測試（SIT）	完整流程能以貼近真實的資料，跨模組與介面順利執行	Realize，建置穩定後分輪進行	專案測試主管，搭配流程負責人
使用者驗收測試（UAT）	業務單位能在系統上執行真實情境	Realize 後段，Deploy 之前	業務單位
迴歸測試	變更之後，原本正常的功能依然正常	Realize 起，之後 Run 階段的每次版本更新	測試主管，在數量值得時搭配自動化
效能測試	系統在大量使用者同時操作、正式環境資料量下仍撐得住	Realize，上線前完成	專案層級效能負責人，搭配 Basis
切換演練	上線步驟順序、資料載入與時程能完整跑通	Deploy	切換經理

SAP 測試在 SAP Activate 各階段的安排

1. 01

   Prepare

   建立測試工具、團隊與測試環境。

2. 02

   Explore

   在進行 Fit-to-Standard 決策的同時撰寫測試策略，讓需求可以被測試。

3. 03

   Realize

   在衝刺中做單元測試，建置穩定後進行 SIT 各輪、效能測試與 UAT。

4. 04

   Deploy

   依照事先議定的檢核清單進行切換演練，再做出上線決策。

5. 05

   Run

   每一次維運變更、升級與版本更新都做迴歸測試。

單元測試

單元測試由建置該項目的人執行。功能顧問檢查定價條件，開發人員檢查增強功能或介面對應。

它是必要的，但不夠。單元測試通過，並不能告訴您這個項目接上流程其他部分之後會發生什麼事。

系統整合測試

SIT 是專案確認設計到底可不可行的地方。一張銷售訂單必須順利流向交貨、開票、會計與報表，沿途每一個介面都要正確過帳。

我把 SIT 分成好幾輪，而不是只跑一次。第一輪找到的缺陷修正後，下一輪要證明這些修正沒有弄壞其他東西。各輪測試、進入準則與退出準則如何搭配，請參考我的 S/4HANA 測試策略指南。

使用者驗收測試

UAT 是業務單位確認系統能支援上線後的工作方式。它屬於業務單位，而不是系統整合商，因為只有業務單位能夠驗收系統。

UAT 至少需要 6 到 8 週。為了配合延誤的建置而壓縮它，您得到的會是紙上的簽核和正式環境裡的問題。我的 SAP 使用者驗收測試 指南涵蓋測試腳本、角色與簽核。

迴歸測試

迴歸測試是在變更之後重新執行已驗證過的測試，抓出變更弄壞的地方。在長期專案中，正式環境的維運修正與專案變更會同時在系統中流動。

我的做法是維持兩套獨立的環境，一套給專案，一套給日常維運（BAU）。這樣正式環境的維運變更與專案變更可以分開測試，任何一邊都不會掩蓋另一邊的缺陷。我的 SAP 迴歸測試 指南涵蓋雙環境做法、升級與影響分析。

效能測試

效能測試必須在上線前完成。最重要的是並行測試，也就是讓大量使用者在同一時間執行交易。

一筆對單一使用者完全正確的交易，換成兩百位使用者時可能逾時。功能測試永遠不會讓您看到這一點。我寫給 IT 主管的 SAP 效能測試 指南涵蓋負載、壓力與長時間穩定性測試，以及如何撰寫驗收準則。

切換演練

切換演練測試的是上線本身：技術步驟的順序、資料載入、對帳與簽核，以及各步驟的時間。在 brownfield 轉換專案中，我會在正式切換前規劃三次模擬轉換。

我堅持的上線準則，是一份事先議定的詳盡切換檢核清單。如果檢核清單是在切換週末才寫出來，那之前的演練就稱不上真正的演練。

依我的經驗，測試約占專案工作量的 35%。這個數字常讓專案發起人吃驚，因為他們以為測試只是建置與上線之間的一小段空檔。

這些工作分散在很多人身上。顧問執行單元測試，測試團隊準備並執行 SIT，業務使用者執行 UAT，Basis 與整合團隊則支援效能測試與切換演練。

資料移轉與測試並行，本身就占 30% 到 40% 的工作量。兩者高度重疊，因為每一輪測試都需要看起來像正式環境的移轉資料。

我最常看到的測試失敗，就只是 SIT 與 UAT 的測試量不足。建置延誤時，測試輪次被砍，上線日期卻原地不動。在我主導或救援過的 21 個 SAP 專案中，最大的錯誤仍是一開始沒有好好規劃，而測試通常是這個問題最先浮現的地方。

測試的品質取決於它所用的資料。我的原則是使用經過遮罩、但達到正式環境等級的資料：正式環境規模的資料量與貼近真實的紀錄，個人與敏感欄位則加以遮罩。

又少又乾淨的測試資料，會把真正重要的問題藏起來。一份在幾千筆紀錄上幾秒就跑完的報表，換成一整年的過帳資料可能要跑好幾個小時。

環境和資料一樣重要。在 Prepare 階段就規劃測試環境，決定各輪之間如何更新，並讓專案變更與 BAU 變更保持分離。我的 SAP 測試資料管理 指南涵蓋系統複製、資料遮罩與選擇性測試資料。

我對自動化的原則很簡單。當測試案例數量很多，而且需要大量重複測試時，就自動化。低於這個程度，手動測試就夠了。

迴歸測試通常是自動化最先回本的地方，因為每次變更後都要跑同一批測試。UAT 大多維持手動，因為它的目的是業務使用者的判斷，而不是腳本的判斷。

及早決定還有一個實際的理由。自動化測試需要時間建置與維護，只有執行很多次才划得來。我的 SAP 測試自動化指南 涵蓋從哪裡開始，以及何時能回本。

這些工具分成三類：測試管理、功能自動化與效能測試。我主導或合作過的團隊用過 Tricentis Tosca、Worksoft、Panaya、SAP Cloud ALM、SAP Solution Manager、UiPath 與 LoadRunner。

以下是每一類工具的用途，以及其中的產品：

工具類別	用途	團隊常用的產品
測試管理	測試計畫、測試案例、執行紀錄、缺陷，以及與需求的追溯關係	SAP Cloud ALM、SAP Solution Manager、Panaya
功能測試自動化	在 SAP 與非 SAP 應用程式上執行腳本式或模型式測試	Tricentis Tosca、SAP Test Automation by Tricentis、Worksoft、UiPath
效能測試	模擬大量並行使用者與正式環境資料量	OpenText LoadRunner，現以 OpenText Professional Performance Engineering 名稱銷售

在選擇之前，有幾項產品事實值得先了解。

1. SAP Cloud ALM 已包含在 SAP Enterprise Support 客戶，或含 Enterprise Support, cloud editions 的雲端訂閱之中（SAP Support）。它的測試管理涵蓋測試準備、測試計畫與執行，包括 UAT 用的手動測試案例（SAP Learning）。
2. SAP Solution Manager 7.2 的主流維護將於 2027 年底結束，部分功能（包括測試套件）可選擇延長維護至 2030 年底（SAP Support）。
3. SAP Test Automation by Tricentis 是 SAP 轉售的自動化產品，與 SAP Cloud ALM 整合，專為 SAP 與第三方系統打造（SAP）。
4. LoadRunner 是 OpenText 的產品。LoadRunner Professional 現在稱為 OpenText Professional Performance Engineering，支援 SAP GUI 與 SAP Web 協定（OpenText）。

如果您正要啟動新專案，請規劃在 Cloud ALM 而不是 Solution Manager 中管理測試。更深入的比較，請參閱我的 SAP 測試工具 指南。

在 SAP Cloud ERP public edition（S/4HANA Cloud Public Edition）上，SAP 會依照自己的時程為每位客戶升級。SAP Learning 說明升級每六個月一次，目前在 2 月與 8 月，中間則每月提供新功能（SAP Learning）。

升級日期不由您決定，所以迴歸測試會變成固定的行事曆項目，而不是一個專案。這正是在公有雲系統上及早將迴歸測試自動化的最有力理由。

在私有雲與地端環境，升級時間由您掌控。不過每一次升級，仍需要依變更所影響的流程規模，安排一輪迴歸測試。

首先，把測試以獨立工作流的形式放進專案計畫，配置自己的負責人與預算，規模約為整體工作量的三分之一。接著指定 UAT 的業務負責人，現在就在行事曆上保留 6 到 8 週，別等建置把它擠掉。

用可衡量的退出準則，把測試結果與 go/no-go 決策綁在一起。我的 SAP 品質關卡 指南說明了做法。如果您的專案已經陷入困境，我的 SAP 專案救援 筆記說明了應該先修正什麼。

如果您想對測試策略或上線決策取得獨立的看法，我可以協助您的組織。您可以 在這裡與我聯絡。

什麼是 SAP 測試？

SAP 測試是證明設定好的 SAP 系統，能用您的資料、在您的業務量下正確執行業務流程。在 S/4HANA 專案中，它包括單元測試、系統整合測試、使用者驗收測試、迴歸測試、效能測試與切換演練。上線後，每一次維運變更與版本更新都會持續進行。

SAP 測試有哪些類型？

六種主要類型是單元測試、系統整合測試（SIT）、使用者驗收測試（UAT）、迴歸測試、效能測試與切換演練。單元測試檢查單一項目，SIT 檢查跨模組與介面的完整流程，UAT 則是業務單位驗收系統。迴歸測試、效能測試與切換演練分別防範變更、負載與上線本身帶來的風險。

SAP 使用者驗收測試需要多久？

UAT 至少要規劃 6 到 8 週。應由業務單位負責，執行真實情境並完成簽核。UAT 與 SIT 的測試量不足，是我最常看到的測試失敗。

測試占 SAP 專案多少比例？

依我的經驗，測試約占專案工作量的 35%。這包括準備與執行單元測試、SIT 各輪、UAT、迴歸測試、效能測試與切換演練。資料移轉與測試並行，每一輪測試都需要貼近正式環境的資料。

SAP 測試應該自動化嗎？

當測試案例數量很多、需要大量重複測試時就自動化，這通常指的是迴歸測試。低於這個程度，手動測試就夠了。UAT 大多維持手動，因為它的目的是業務單位的判斷。

SAP 測試要用哪一種工具？

大多數專案會把測試管理工具、自動化工具與效能測試工具搭配使用。常見的選擇是以 SAP Cloud ALM 或 Solution Manager 做測試管理，以 Tricentis Tosca、SAP Test Automation by Tricentis、Worksoft 或 UiPath 做自動化，並以 OpenText LoadRunner 做效能測試。新專案應以 Cloud ALM 為規劃基礎，因為 Solution Manager 的主流維護將於 2027 年結束。