SAP 效能測試：負載、並行與工具

SAP 效能測試在上線前證明，當大量使用者與背景作業同時運作時，關鍵交易、背景作業與介面都能達到議定的回應時間。依我的經驗，最重要的是並行測試：在達到正式環境資料量的遮罩資料上執行，並依業務單位在第一次執行前議定的通過與失敗準則判定。

本指南寫給 S/4HANA 專案（包括 RISE with SAP）的 CIO、專案總監與測試主管。內容涵蓋要測試什麼、需要什麼資料、如何撰寫驗收準則、哪些工具能勝任，以及誰負責什麼。若想了解效能測試在其他測試類型中的位置，請先閱讀我的總覽 SAP 測試全解析。

SAP 專案中的效能問題，很少是出乎意料的。

輪班開始時數百位使用者同時登入，Fiori 動態磚就逾時。有人對一張非常大的資料表執行不設範圍的整個會計年度查詢，客製報表就卡住。月結時背景作業彼此重疊，過帳作業因此中止。

這些都是可預期的。唯一的問題是，專案有沒有針對它們做測試，還是要等業務單位在真實訂單進來時才發現。

SAP Activate 各階段的效能測試

1. 01

   Explore

   在設計中找出效能風險。在寫程式之前，架構與報表的形態就已經決定了結果。

2. 02

   Realize

   隨著設定趨於穩定，執行資料量與負載測試。設定不完整會產生誤導性的結果。

3. 03

   UAT 之前

   在 UAT 之前完成完整的效能測試週期，而不是把它當成 UAT 的一部分。

4. 04

   切換

   依照事先議定的驗收準則核准切換，而不是依照個人意見。

5. 05

   上線後支援期

   觀察上線後 30 到 60 天的關鍵指標。大多數效能退化會在第一次關帳週期中浮現。

在傳統資料庫上的 ECC 系統中，效能測試指的是對應用伺服器與資料庫做負載測試：ABAP 執行時間、SQL 效能與作業排程。前端是 SAP GUI，很少讓人意外。

在 S/4HANA 上，前端是 Fiori，擴充放在 SAP BTP，整合則透過 SAP Cloud Integration，效能同時取決於好幾個層次。一個緩慢的 Fiori 動態磚，可能是冗長的 ABAP 呼叫、閘道逾時、一個沒有為並行請求設計的 OData 服務，或混合架構下的網路延遲。只測試後端是找不到它的。

1. 01開啟動態磚輪班開始時的登入風暴
2. 02OData 呼叫閘道逾時、未為並行設計的服務
3. 03ABAP 處理長時間執行的 ABAP 呼叫
4. 04資料庫讀取對大型資料表不設範圍的查詢
5. 05畫面呈現再加上遠端據點的網路延遲

一個以端對端方式量測的回應時間

在轉換專案中，SAP HANA 效能測試有它自己的特殊之處。穩定的 ECC 程式碼在記憶體內資料庫上的表現會不同。許多程式會快很多，但有些程式在特定資料模式下會出現意料之外的效能特徵，因此針對大量客製程式碼的轉換專屬迴歸測試不是可有可無的。

整合流程也帶來自己的風險。在開發環境中以單一測試訊息運作正常的流程，到了正式環境資料量時可能大量排隊，或無聲無息地失敗。症狀看起來像別的問題：間歇性的訂單失敗、發票不符、資料出現在一個系統卻在另一個系統中消失。

效能測試必須在上線前完成。我視為重要的是並行測試：大量使用者與背景作業在同一時間衝擊相同的交易、資料表與服務。

單一使用者在兩秒內完成一張銷售訂單，幾乎證明不了任何事。同一張訂單在 150 人同時輸入訂單、背景正在執行交貨作業、介面正在過帳傳入訊息時的表現，才是能預測上線第一天的測試。

下表列出每一種測試要證明什麼，以及何時執行：

測試	要證明什麼	何時執行	通常會發現什麼
並行	大量使用者與背景作業能同時處理相同物件	Realize，設定穩定之後，並在 UAT 前再做一次	鎖定等待、登入風暴、閘道瓶頸
負載	系統在預期尖峰量下仍達到回應時間	Realize，並行測試腳本可運作之後	緩慢的 OData 服務、沉重的客製報表
壓力	系統在超出設計上限時會在哪裡崩潰	UAT 之前，若預期業務會成長	規模估算缺口、佇列上限
長時間穩定性	系統能在數小時內維持穩定負載	UAT 之前，最好橫跨一次模擬關帳	記憶體增長、重複執行時作業鏈之間的資源爭用
端對端	使用者等待的完整路徑達到目標	與負載測試同時進行	每一層單獨測試時看不見的問題

負載測試的關鍵字是「預期」。您需要真實的交易量、使用者數與工作階段模式。一個建立在大家早就知道過於樂觀之資料量估計上的負載測試，給出的通過毫無意義。

長時間穩定性測試是最常被跳過的一種。整體而言，資料量測試是時程被壓縮時專案最常走的捷徑，也是最常後悔的捷徑。

先為這些情境撰寫腳本。它們涵蓋了大多數會進入正式環境的失敗。

1. 換班與尖峰登入。 當幾百位使用者同時開啟 Fiori launchpad，驗證與 launchpad 畫面呈現的負載會急遽升高。一套在離峰時正常的系統，如果從未測試過並行登入，在那段時間內可能根本無法使用。
2. 月結與年結。 大量過帳、順序嚴格的作業鏈，以及在固定期限前趕工的財務團隊。以關帳期間的資料量（而不是平日平均筆數）端對端執行關帳作業鏈。
3. 重疊的背景作業。 批次作業通常一次只測一個，這並不反映現實。一個優化不良的作業可能卡住其他好幾個作業，讓關帳超出它的時間窗。
4. 不設範圍的客製報表。 一份在測試資料上瞬間返回結果的報表，在完整會計年度資料上可能要跑好幾分鐘。測試一般與最壞情況的查詢條件，並封鎖不設範圍的查詢。
5. 多區域使用者。 網路延遲影響每一筆交易。RISE 把主機代管移交給 SAP，但延遲仍取決於您選擇的區域與通往使用者的路由，所以要從距離最遠的據點進行測試。

我的 ECC 到 S/4HANA 移轉指南 說明了轉換測試在整體計畫中的位置。

達正式環境等級的測試資料

資料決定了這一切是否有意義。我堅持使用達正式環境等級的遮罩資料：正式環境的資料量與真實度，個人與敏感欄位則加以遮罩。

一位有 200,000 筆未結訂單明細的客戶，表現與只有 5,000 筆的客戶截然不同。在單薄測試用戶端中瞬間返回的篩選條件，在正式環境中會逾時。為高風險領域準備足夠的資料量，使用具代表性的交易組合，並盡可能進行真實的介面呼叫。

如何透過系統複製、選擇性測試資料工具與遮罩安全地取得這些資料，請參閱我的 SAP 測試資料管理 指南。在第一次效能測試週期之前就規劃好資料更新，因為它花的時間比大多數測試計畫預估的更長。

在 Prepare 階段、任何測試執行之前，就與業務單位議定準則。每一項準則都要寫明交易或背景作業、負載條件與門檻。

以下範例說明其形式。請依營運需求設定您自己的數字：

項目	負載條件	通過門檻	負責人
建立銷售訂單（VA01 或 Fiori 應用程式）	150 位並行訂單輸入使用者	95% 的交易低於 3 秒	訂單到收款流程負責人
輪班開始時 Fiori launchpad 首次載入	最大班次的尖峰並行登入	95% 的使用者低於 5 秒	IT 維運主管
月結作業鏈	關帳期間資料量，完整順序	在議定的關帳時間窗內完成，沒有中止	財務長室主管
傳入訂單介面	尖峰每小時訊息量	沒有超過 15 分鐘的佇列積壓	整合主管
大量資料的客製報表	完整正式環境資料量，一般查詢條件	低於 60 秒；封鎖不設範圍的查詢	報表負責人

「系統應該快到足以支撐業務運作」既無法測試，也無法驗收。結果出來後才更改準則，就失去了訂定準則的意義。

如果系統過關的理由是 UAT 使用者覺得它很快，那您得到的是意見，而不是驗收準則。請把結果變成切換前的正式關卡，就像我的 SAP 品質關卡 指南所說明的那樣。包含每個測試階段進入與退出準則的整體週期計畫，應該放在您的 S/4HANA 測試策略 中。

SAP 效能測試工具

一次效能測試需要三樣東西：能驅動 SAP 協定的負載產生器、SAP 端的監控，以及管理測試案例與結果的地方。LoadRunner 是我在 SAP 專案中讓團隊使用過的負載工具。請及早在測試計畫中確定工具，因為授權、負載產生器與腳本撰寫技能都需要時間安排。

2026 年的主要選擇：

工具	角色	須知
OpenText Professional Performance Engineering	負載產生	前身為 LoadRunner Professional 的產品。其協定套件涵蓋 SAP、SAP GUI 與 SAP Web
Tricentis NeoLoad	負載產生	Tricentis 列出支援 SAP GUI、Fiori、RFC 與 IDoc，並可重複使用 Tricentis Tosca 的資產
Apache JMeter	負載產生	開源工具。可驅動 Fiori 與 OData 呼叫等 HTTP 流量
SAP Cloud ALM	測試管理	準備與執行手動及自動化測試案例並追蹤缺陷。它本身不產生負載
SAP Solution Manager	測試管理	主流維護於 2027 年 12 月 31 日結束，因此新工作請在 Cloud ALM 中規劃

若想更全面了解功能測試與自動化工具，請參閱我的 SAP 測試與驗證工具比較。工具的重要性，不如腳本、資料與準則。

RISE with SAP 劃分了責任

在 RISE with SAP 下，SAP 負責基礎設施：規模估算、雲端服務商區域、網路與平台可用性。客戶與夥伴負責應用層。

SAP 的 RISE 角色與責任文件 寫得很明白。負載測試的執行與高成本 SQL 陳述式的調校，屬於需額外付費的 SAP Cloud Application Services。如果您沒有購買，這些工作就由客戶自己做。

RISE 專案中常見的失敗，是假設 SAP 既然負責基礎設施，就會抓出效能問題。它會抓出基礎設施問題。請把分工寫進專案章程與測試計畫：

1. SAP： 基礎設施可用性與平台層級的回應
2. 夥伴： 在定義的負載下的應用程式效能，包括擴充與整合流程
3. 客戶： 流程層級的成果，例如關帳執行時間與訂單處理量，以及驗收決策

公有雲縮小了範圍

在 SAP 雲端 ERP 的 public edition 上，系統運行在由 SAP 營運的共用平台上。在規劃任何針對租用戶的負載測試之前，請以書面詢問 SAP 是否允許，以及需要多少事前通知。

接著您的測試就轉向屬於您的部分：客製整合、擴充、大量資料報表、關帳順序，以及從您各據點出發的網路路徑。平台效能問題則交給 SAP 支援處理。

常見錯誤

1. 把功能測試當成效能測試。 功能測試證明一筆交易能得出正確結果。它無法說明 150 人同時執行時會怎樣。
2. 把效能交給 Basis。 Basis 負責規模估算與作業排程。它不負責報表設計、OData 服務架構或整合流程設計，而這些才是驅動應用程式效能的因素。
3. 只交給 QA 負責。 QA 執行測試並回報結果，但造成效能問題的決策是在設計階段做出的。專案層級的測試主管或架構師需要有權及早質疑這些決策，RACI 也應寫明誰能以效能為由阻擋上線。
4. 把缺口當成已知問題接受。 大多數在正式環境出現效能問題的專案，並沒有跳過測試。它們是在沒有議定準則的情況下測試，或是測試了之後，在時程壓力下接受了那些失敗。

為您風險最高的交易與背景作業寫下五到六項驗收準則，每一項都有具名負責人。如果您填不出上面那張表，您就還沒準備好測試，而您也已經找到第一個缺口。

接著檢查兩件事：計畫中是否已排入經遮罩且達正式環境資料量的資料更新，以及並行測試週期是否在 UAT 開始前完成。

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

什麼是 SAP 效能測試？

它檢查 SAP 在貼近真實的負載下表現如何：使用者交易的回應時間、背景作業的執行時間、介面的處理量，以及大量人員同時作業時的資源使用。它必須在上線前完成。

功能正確性與效能是不同的特性。一筆對單一使用者正確的交易，換成 200 位使用者時可能逾時。

SAP 專案中的效能測試應該何時開始？

風險辨識從 Explore 開始，因為架構選擇決定了效能結果。實際測試從 Realize 開始，等設定穩定到結果有意義時進行。

在 UAT 之前完成最後一個週期，而不是在 UAT 期間。在 UAT 中發現的效能缺陷會壓縮時程，並帶來把它們當成已知問題接受的壓力。

SAP 的負載測試與並行測試有什麼不同？

負載測試檢查在預期尖峰量下的回應時間。並行測試檢查大量使用者與背景作業在同一時刻處理相同交易、資料表與服務時會發生什麼事。鎖定等待、登入風暴與閘道瓶頸就是在這裡出現的。

依我的經驗，並行測試才是重要的那一種。先執行它們，再在其上建立完整的負載測試。

SAP 效能測試應該使用什麼測試資料？

達正式環境等級的遮罩資料。也就是正式環境的資料量與真實度，個人與敏感欄位則加以遮罩。單薄的測試資料會掩蓋上線第一天就會出現的緩慢篩選、沉重報表與冗長的作業執行時間。

SAP 效能測試使用哪些工具？

由 OpenText Professional Performance Engineering（前身為 LoadRunner Professional）、Tricentis NeoLoad 與 Apache JMeter 等負載產生器產生負載。SAP Cloud ALM 或 SAP Solution Manager 管理測試案例與結果，SAP 端的監控則顯示系統在負載下的表現。

在 RISE with SAP 下，效能測試由誰負責？

SAP 負責基礎設施：規模估算、區域、網路與平台可用性。SAP 的 RISE 角色與責任文件將負載測試的執行與高成本 SQL 調校留給客戶，除非客戶另外付費購買 SAP Cloud Application Services。

客戶與夥伴負責應用程式效能與驗收決策。請把分工寫進驗收準則，讓每一個門檻都有負責人。