SAP 效能測試：IT 主管必須知道的事

SAP 效能測試，是在上線前證明關鍵交易、背景作業與介面，在正式環境的資料量下，能符合議定的回應時間。在設計階段就開始，在配置穩定後的 Realize 階段進行資料量與負載測試，在使用者驗收測試（UAT）之前完成整個週期，並把結果訂為切換的關卡。本文寫給 S/4HANA 專案（包括 RISE with SAP）的 CIO、專案總監與測試負責人。內容涵蓋該測什麼、由誰負責、如何撰寫驗收標準，以及在雲端上有什麼不同。請先從驗收標準表開始：如果您填不出來，就表示還沒準備好測試。

SAP 專案中的效能問題，幾乎都是在上線後才被發現。300 位使用者在換班時登入，Fiori 磚就逾時。有人對一張有 5,000 萬筆紀錄的表，執行沒有條件限制的會計年度查詢，Z 報表就凍結。背景作業在月結期間重疊，過帳執行就中止。

SAP 專案中的效能問題，很少是突然降臨的。多數都能預見，只是沒有被規劃進去。常見的模式是：功能測試做得很徹底。資料量測試原本有排，後來時程壓縮就被往後推。後果在正式營運的最初幾週就到了。

這些不是邊緣案例。它們可以預見。唯一的問題是，專案有沒有為它們做過測試，還是要等業務端在真實訂單跑起來時才發現。

貫穿 SAP Activate 的效能測試

1. 01

   Explore

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

2. 02

   Realize

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

3. 03

   UAT 前

   在 UAT 之前完成整個效能週期，而不是把它放進 UAT 裡。

4. 04

   切換

   依據事先議定的驗收標準核准切換，而不是依據意見。

5. 05

   Hypercare

   觀察正式環境的 KPI 30 至 60 天。多數退步會在第一次結帳週期中浮現。

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

在 S/4HANA 上，搭配 Fiori 前端、SAP BTP 上的擴充，以及透過 SAP Cloud Integration（CPI）的整合，效能同時取決於好幾層。一個很慢的 Fiori 磚，可能是一個很長的 ABAP 呼叫、一次 Gateway 逾時、一個沒有為並行請求設計的 OData 服務，或是混合式架構中的網路延遲。只測後端找不到它。測整條路徑才找得到。

1. 01啟動磚換班開始時的登入尖峰
2. 02OData 呼叫Gateway 逾時，服務並非為並行而建
3. 03ABAP 處理執行很久的 ABAP 呼叫
4. 04資料庫讀取在大型資料表上沒有條件限制的選取
5. 05畫面呈現加上遠端據點的網路延遲

一個回應時間，端對端量測

整合流程自帶風險。在開發與 QA 中，以單一測試訊息運作良好的流程，在正式環境的資料量下，可能堵塞或悄悄失敗。如果訊息佇列沒有依真實負載規劃容量，延遲就會累積。症狀看起來像別的問題：間歇性的訂單失敗、發票不一致、資料在一個系統中有、在另一個系統中卻不見。

1. 負載測試檢查在預期資料量下的行為。關鍵字是預期。您需要真實的交易量、使用者數與並行工作階段。許多負載測試失敗，是因為採用了每個人都知道過於樂觀的資料量估計。
2. 壓力測試把系統推過設計極限，找出它在哪裡崩潰。如果資料量會在十八個月內翻倍，它能告訴您架構撐不撐得住，以及容量規劃會不會在下一次基礎架構檢視之前就成為問題。
3. **浸泡測試（soak testing）**以穩定負載長時間執行，暴露隨時間累積的問題：記憶體洩漏、碎片化，以及在反覆執行中作業鏈的資源競爭。這是最常被略過的測試，也是本可以抓出下文所述月結失敗的測試。
4. 端對端測試走完使用者所經過的完整路徑：啟動磚、OData 呼叫、ABAP 處理、資料庫讀取、畫面呈現。這是找出各層單獨測試時看不見的問題的唯一方法。

**換班與登入尖峰。**早上 8 點 200 位使用者打開 Fiori Launchpad 時，驗證與 Launchpad 的畫面呈現會暴增。一個在離峰時段沒問題的系統，如果從沒測過並行登入，在那個時段可能根本無法使用。在製造、零售與金融服務業，登入尖峰造成的上線第一天抱怨最為明顯。

**月結與年結。**這是多數專案中風險最高的情境：大量過帳、有嚴格順序的作業鏈，以及一個與固定期限賽跑的財務團隊。請以結帳期間的資料量，而不是平均每日筆數，完整跑過結帳作業鏈。

批次作業通常是單獨測試的，這不反映現實。到了月底，背景處理達到高峰，許多程式在同樣的資源上平行執行。一個沒有最佳化的作業可能擋住另外五個，結帳就會超出它的時間窗口。

**ECC 到 S/4HANA 的轉換。**穩定的 ECC 程式碼在 HANA 上的行為不同。許多程式會快很多；有些在特定資料型態下，會出現意料之外的效能表現。針對轉換的迴歸測試不是選配。我的 ECC 到 S/4HANA 移轉指南說明了這一塊在轉換計畫中的位置。

**多區域使用者。**網路延遲影響每一筆交易。一張在託管國家花兩秒的銷售訂單，在 3,000 英里外可能感覺像壞掉了，如果沒有人從那裡測過。RISE 把託管交給了 SAP，但延遲仍取決於您選擇的區域，以及通往您使用者的路由。

請在 Prepare 階段、在任何測試執行之前，與業務端議定標準。每一項都要指明交易或作業、負載與門檻。這些例子顯示的是格式；請依營運需求訂定您自己的數字：

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

「系統應該足夠快，能支援業務運作」這種說法無法測試，也無法驗收。結果出來後再更改標準，就失去了訂定標準的意義。

請逐項點名要求：

期待	應交付的成果	為什麼重要
效能服務水準	每個交易、介面與作業的門檻，並明訂通過與否	避免 UAT 的意見推翻證據
以風險為基礎的範疇	依使用者數量、整合點與資料相依性排定優先順序	把測試週期放在重要的工作負載上
跨團隊參與	執行期間，Basis、基礎架構、功能、資安與整合團隊都在場	出現缺口時避免互相推卸責任
工具與環境就緒	負載產生器（OpenText LoadRunner、Tricentis NeoLoad、Apache JMeter）、監控與資料更新，在週期開始前就位	讓模擬貼近現實
真實的測試資料	正式環境資料量的主檔資料、真實的介面呼叫、具代表性的交易組合	讓結果能預測上線後的行為
效能報告	負載組合、回應時間、CPU 與記憶體、作業執行時間、錯誤率	給切換核准一個證據基礎
上線後的監控計畫	前 30 至 60 天要觀察的 KPI	確認正式系統維持在已測試的範圍內

即使在擁有成熟交付模式的大型企業，這四種錯誤也最常出現。

**把功能測試當成效能測試。**功能測試證明一個交易給出正確的結果。它對 150 個人同時執行時的情況，什麼也沒說。

**用小資料量測試。**一位有 200,000 筆未結訂單行的客戶，行為與只有 5,000 筆的客戶不同。在測試中立即回傳的篩選，在正式環境會逾時。請為高風險領域預先建置足量的資料。

**把效能丟給 Basis。**Basis 負責容量規劃與作業排程。它不負責報表設計、OData 服務架構或整合流程設計，而這些才是驅動應用程式效能的因素。

**把責任只交給 QA。**QA 執行測試並回報結果。造成效能問題的決策，是功能、技術與 Basis 團隊在設計階段做出的。專案層級的測試負責人或架構師，需要有權限及早質疑那些決策，而 RACI 應該寫明，誰可以基於效能理由擋下上線。

RISE 把責任一分為二

在 RISE with SAP 之下，SAP 負責基礎架構：容量規劃、超大規模雲端服務商的區域、網路與平台可用性。客戶與合作夥伴負責應用層。SAP 的 RISE 角色與責任文件講得很明白：除非您購買 SAP 額外的應用程式服務，否則找出並調校耗用資源的 SQL 陳述式，仍屬客戶的責任。

RISE 專案常見的失敗，是假設 SAP 會抓出效能問題，因為基礎架構是它在運行。它會抓出基礎架構的問題。它不會抓出設計不良的 OData 服務、沒有效率的 ABAP 作業，或無法擴展的整合流程。請把這個劃分寫進章程與測試計畫：

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

Public Edition 與 GROW 縮小了範疇

在 S/4HANA Cloud Public Edition（通常透過 GROW with SAP 購買）上，SAP 在它的多租戶平台上執行效能測試，作為自身產品標準的一部分，不期待客戶對共用系統做負載測試。您的測試轉向屬於您的部分：客製整合、擴充、大量資料的報表與分析、結帳與合併的順序，以及從您各據點出發的網路路徑。平台本身的效能問題，則交給 SAP 支援。

AI 幫得上腳本，幫不上架構

負載測試廠商正在加入 AI，用於腳本維護與結果分析，這對應用程式在各週期之間會變動的專案很有幫助。在付錢之前，先在您自己的系統環境上驗證這些說法。SAP Cloud ALM 可以協助產生測試案例與需求，AI 助理也能依流程描述起草情境大綱。

但沒有一樣能解決架構問題。AI 不會告訴您 OData 服務本來應該用不同方式設計，或某份報表對它的資料量來說太重。那些判斷仍然是由人來做，在設計階段，在任何測試執行之前。

多數在正式環境出現效能問題的專案，並不是完全跳過了測試。它們是在沒有議定標準的情況下測試，或是測了之後，在時程壓力下把缺口當成已知問題接受下來。紀律在於標準，以及落實標準，而不在於工具。至於效能在其他測試類型中的位置，請參閱我的 SAP 測試與驗證工具比較與 SAP 品質關卡指南。

什麼是 SAP 效能測試？為什麼重要？

它檢查 SAP 在真實負載下的表現：使用者交易的回應時間、背景作業的執行時間、介面的吞吐量，以及並行工作下的資源使用。

功能正確與效能是不同的特質。對一位使用者正確的交易，對 200 位使用者可能逾時。一個在測試資料上跑十分鐘的作業，在正式資料量下可能跑上好幾個小時。在上線後才發現，會干擾營運、迫使緊急變更，並在採用最脆弱的時候損害使用者的信任。

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

風險辨識從 Explore 階段開始，因為架構選擇決定了效能結果。實際測試從 Realize 階段開始，也就是配置穩定到結果有意義的時候。不完整的配置會給出誤導的數字。

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

誰該負責 SAP 效能測試？

是專案，而不是只有 QA。QA 負責執行與回報，但驅動效能的決策，是在設計階段由功能、技術與 Basis 團隊做出的。一位中央的架構師或專案測試負責人，需要有權限及早質疑那些決策。

請在 RACI 中明確寫出：誰核准驗收標準、標準未達時由誰負責補救，以及誰可以基於效能理由擋下上線。

RISE with SAP 如何改變效能測試的責任？

SAP 負責基礎架構：容量規劃、區域、網路與平台可用性。客戶與合作夥伴負責應用程式的效能：配置、擴充、OData 與 Fiori 設計、整合流程與流程 KPI。SAP 的 RISE 角色與責任文件，把 SQL 調校留給客戶，除非另外購買 SAP 的服務。

請把這個劃分寫進驗收標準，讓每一個門檻都有負責人。

最常見的 SAP Fiori 效能問題有哪些？

四種模式涵蓋了大部分情況。換班開始時的登入尖峰，此時驗證與 Launchpad 的畫面呈現暴增。OData 服務回傳過大的結果集，或每次互動就呼叫好幾次後端。Gateway 層本身成為瓶頸，所以測試期間必須監控它。以及客製或大幅修改過的應用程式，標準的效能假設在那裡並不適用。

如何為 SAP 定義效能驗收標準？

指明交易、負載與門檻。例如：「在訂單輸入角色的 150 位並行使用者下，訂單建立在 3 秒內完成，涵蓋 95% 的交易。」這是可以測試的。

「系統應該夠快」則不行。請在 Prepare 階段，依據真實的營運需求與業務端議定標準，並且在結果出來之後不要更改。

如果跳過或壓縮效能測試，會發生什麼事？

問題會在正式環境浮現：作業超出時間窗口並擋住其他作業、Fiori 應用程式在尖峰時逾時、月結花兩倍時間而錯過報表期限、介面佇列積壓。

在最初幾週就遇到效能問題的使用者，會形成對系統的負面印象，而且很難扭轉。此外，在正式營運下做緊急補救，比測試本身更花錢，因為原本在 Realize 階段只是設計決策的事，變成了緊急的架構變更。