SAP 測試資料管理：經過遮罩、達正式環境規模的資料

SAP 測試資料管理，是讓每一套測試系統都擁有表現得像正式環境的資料，同時不暴露真實人員的個人資料。我的原則很簡單：經過遮罩的資料，但在資料量與真實度上達到正式環境等級。

單薄、手工製作的資料會掩蓋真正重要的缺陷。未經遮罩的正式環境資料，則會把客戶、供應商與員工紀錄放進控管比正式環境寬鬆的系統中。

測試資料是更大測試計畫的一部分。我的 SAP 測試全解析 指南說明了各種測試類型、由誰負責，以及它們在 SAP Activate 中的位置。

測試只能發現它的資料能觸發的問題。一位有五筆未結項目的客戶，和一位有五萬筆的客戶，系統表現截然不同；一個沒有人在測試用戶端建立過的定價條件，在測試用戶端裡永遠不會出錯。

我看過最常見的測試失敗，是系統整合測試（SIT）與使用者驗收測試（UAT）的測試量不足。薄弱的測試資料，正是讓這種情況悄悄發生的途徑之一。測試案例跑完了，結果一片綠燈，而那些本來會出錯的案例，只是根本沒有資料可以讓它們出錯。

這就是我堅持使用正式環境等級資料的原因。它代表四件事：

1. 資料量。 資料表大小接近正式環境，讓報表、背景作業與搜尋都在貼近真實的資料筆數上執行。
2. 多樣性。 正式環境中真實存在的特殊紀錄：被凍結的供應商、部分交貨、貸項通知單、外幣、陳年的未結項目。
3. 歷史。 足夠的已關帳期間，讓帳齡分析、折舊與年結作業有意義。
4. 完整性。 複製與遮罩之後，單據之間跨模組的連結仍然正確。

資料量對效能最重要。效能測試必須在上線前完成，依我的經驗，並行測試（大量使用者同時作業）才是重要的那一種。

在幾乎空白的資料庫上做並行測試，證明不了多少事。我的 SAP 效能測試 指南說明如何建立這些測試。

測試系統中的正式環境資料，仍然是個人資料。測試系統與品質系統的存取範圍通常比正式環境更廣，而這正是資料遮罩要堵住的風險。

歐盟《一般資料保護規則》（GDPR）是大多數組織所依據的參考，許多國家的法規也採取類似的方向。GDPR 前言第 26 點提出了一項每個 SAP 團隊都應該知道的區分。

1. 假名化資料仍屬個人資料。 如果資料能藉由額外資訊（例如對照表）連回某個人，就仍適用該規則。
2. 匿名資料不在其適用範圍內。 無法再識別任何人的資料不受規範。

實際的結論是：大多數遮罩產生的是假名化資料，而不是匿名資料。經過遮罩的測試系統仍需要存取控管、使用目的與保存規則。請在第一次複製之前，就請您的個資保護長同意遮罩規則，而不是等稽核人員問起才處理。

常見的途徑有五種。大多數專案會使用不只一種，因為每個測試階段的需求都不同。

下表依據決定適用性的幾個重點加以比較。

方法	您會得到什麼	資料量	隱私處理	最適合
完整系統複製	正式環境的完整複本，包含每個用戶端與資料表	完整	遮罩必須在複製後、使用者取得權限前執行	效能測試、模擬轉換、切換演練
用戶端複製	在系統內或系統間複製一個用戶端；由複製設定檔決定是否一併複製主檔與交易資料	完整或僅含設定	複製應用資料時，與系統複製相同	建立新的測試或訓練用戶端、將用戶端重設為已知狀態
SAP Test Data Migration Server（TDMS）	依時間或組織單位挑選的精簡複本，並進行資料擾亂	精簡	由工具內的擾亂規則處理	已取得其授權的現有 SAP Business Suite 系統環境
夥伴的選擇性複製工具	依需求複製選定的業務物件或資料切片，傳輸過程中即完成遮罩	精簡、針對性	由工具內的遮罩規則在複製時套用	定期更新、迴歸測試資料、重現缺陷
自建或移轉的資料	由腳本、移轉載入或手動輸入產生的資料	取決於您建了多少	若從零建立，就沒有真實的個人資料	早期單元測試、上線前的 greenfield 專案

完整系統複製與用戶端複製

完整系統複製能給您最貼近真實的測試資料。它同時也複製了正式環境中所有的隱私風險。如果您使用它，系統必須鎖定，直到遮罩執行完畢並經過檢查為止。

用戶端複製是建立與重設用戶端的日常工具。複製設定檔是關鍵決定，因為它決定只移動設定，還是連同主檔與交易資料一起移動。

SAP Test Data Migration Server

SAP Test Data Migration Server（TDMS）以正式環境資料建立精簡的非正式環境系統，並對敏感欄位進行擾亂。它是在 SAP Business Suite 上發展起來的，SAP Help Portal 上目前的文件適用於 4.0 SP14 版。

我找不到 SAP 對 TDMS 支援目前 S/4HANA 版本的官方聲明，也找不到具名的後繼產品。如果您打算依賴它，請以書面向 SAP 確認它是否支援您的目標版本與部署模式，包括 RISE with SAP。

SAP Landscape Transformation 與殼層複製

SAP Landscape Transformation 是 SAP 在選擇性資料轉換中使用的一組分析與轉換工具。SAP Learning 將殼層轉換（shell conversion）描述為不含主檔與交易資料的正式系統複本，再轉換為 S/4HANA。

同樣的概念也適用於測試資料。殼層系統給您正式環境的儲存庫與設定，但沒有業務資料，接著您只填入測試所需的資料。

有幾項夥伴產品會將選定的業務資料複製到 SAP 測試系統，並在過程中完成遮罩。以下是我能在供應商自己網站上查證其說法的產品，排列不分先後。

1. EPI-USE Labs Data Sync Manager。 一套在 SAP ABAP 系統環境之間複製與遮罩資料的工具組，包括精簡用戶端、物件層級複製，以及依預先定義規則進行遮罩。EPI-USE Labs 表示 Data Sync Manager 已通過與 SAP S/4HANA 及 S/4HANA Cloud 整合的認證，並可搭配 RISE with SAP 使用。
2. SNP Kyano Test Data Organizer。 只擷取測試所需的資料，而不是整套系統，並在提供資料時遮罩敏感資料。SNP 將 Test Data Organizer 描述為相容於 RISE with SAP Private Cloud Edition。
3. Qlik Gold Client。 將選定的交易資料從正式環境複製並同步到非正式環境，對現有系統採用靜態遮罩，對傳輸中的資料採用動態遮罩。
4. Natuvion DCS Protect。 找出個人資料，並在測試、品質、開發與訓練系統中進行匿名化或假名化。Natuvion 將它定位於測試移轉與持續營運，該頁面並未提及 S/4HANA，因此請直接確認支援範圍。

購買之前，請每家供應商在您自己的系統上回答以下問題：

1. 它目前支援哪些 S/4HANA 版本與部署模式？
2. 它是在資料離開正式環境之前遮罩，還是在資料抵達目標系統之後遮罩？
3. 遮罩在相連系統之間是否保持一致，讓在 S/4HANA 中被遮罩的客戶，與您 CRM 或資料倉儲中的同一位客戶相符？
4. 在正式環境資料量下，更新一個公司代碼需要多久？
5. 新增客製資料表或欄位時，由誰維護遮罩規則？

每個測試階段需要資料的理由都不同。我在 S/4HANA 專案中規劃測試資料時，從這裡開始。

測試階段	資料必須做到什麼	常見來源
單元測試	讓開發人員證明單一物件可以運作	自建資料，或一小塊經遮罩的資料切片
系統整合測試各輪	跨模組與介面執行完整流程串接	經遮罩且達正式環境等級的複本，或選擇性複製
使用者驗收測試各輪	看起來像業務使用者自己的資料，讓他們認得自己的案例	經遮罩且達正式環境等級的資料，每一輪前更新
迴歸測試	保持穩定，讓每次執行的結果可以比較	固定且可重設的資料集，加上更新計畫
效能測試	符合正式環境資料量，讓並行測試結果有意義	完整的遮罩複本，或正式環境規模的資料量
模擬轉換與切換演練	以真實的資料樣貌證明移轉可行	正式環境的完整複本，若核心團隊以外的人有存取權則需遮罩

UAT 需要特別用心。使用者驗收測試應由業務單位負責，在我看來至少需要 6 到 8 週。

給使用者他們認得的資料：他們自己的客戶、物料與價格表，即使名稱經過遮罩也一樣。我的 SAP 使用者驗收測試 指南說明如何執行。

模擬轉換也遵循同樣的邏輯。在 brownfield 轉換專案中，我會規劃三次模擬轉換，每一次都應該在近期的正式環境複本上執行。

依我的經驗，資料移轉占專案工作量的 30% 到 40%，因此請與移轉團隊一起規劃這些執行所需的資料存取。我的文章 SAP 資料移轉為何失敗 說明各次模擬載入如何銜接。

兩套環境，兩份更新計畫

在專案期間，我會維持兩套獨立的環境：一套給專案，一套給日常維運（BAU）。這樣正式環境維運變更與專案變更就能分開測試。

每一套環境都需要自己的測試資料計畫。BAU 測試需要接近今天正式環境的資料，因為維運修正是在回應今天的問題。

專案測試需要符合新設計的資料，可能是轉換後的複本，也可能是選擇性載入。為兩者各自維持一份更新時程表，讓一邊的更新永遠不會抹掉另一邊仍需要的測試資料。

測試約占專案工作量的 35%。請在這份工作量之內規劃測試資料，而不是在 SIT 開始前一週才處理。

以下是我會遵循的順序：

1. 以書面議定原則。 經過遮罩且達正式環境等級的資料，由專案發起人、個資保護長與業務負責人簽核。
2. 找出個人與敏感資料。 客戶、供應商、員工、銀行資料、聯絡人、自由文字欄位、附件，以及任何存放這些資料的客製資料表。
3. 撰寫遮罩規則。 逐欄位決定要替換、保留或移除哪些內容，並在相連系統之間保持替換內容一致。
4. 將資料對應到各測試階段。 以上表為起點，並優先為效能與並行測試估算資料量。
5. 挑選複製方法與工具。 重視資料量時使用完整複製，重視速度與頻率時使用選擇性複製，並確認工具是否支援您的版本。
6. 訂定更新時程表。 每套環境一份計畫，在每一輪 SIT 與 UAT 以及每一次模擬轉換之前安排更新。
7. 在遮罩通過檢查之前鎖定存取。 新複本在遮罩檢查通過之前，核心技術團隊以外的任何人都不得登入。

接著把它變成一道關卡。各週期的策略、進入準則與退出準則，都在我的 S/4HANA 測試策略 指南中，而測試資料就緒程度應該列入每一輪的進入準則。

具體的下一步：列出目前所有存有正式環境資料複本的非正式環境系統，並檢查哪些已經過遮罩。

如果您想對 S/4HANA 專案的測試資料做法或測試計畫取得獨立的看法，您可以 在這裡與我聯絡。

什麼是 SAP 測試資料管理？

它是您如何規劃、建立、複製、遮罩與更新 SAP 測試系統中的資料。目標是讓資料在資料量與真實度上表現得像正式環境，同時不把真實的個人資料暴露給不該看到的人。

可以用正式環境資料做 SAP 測試嗎？

只有在遮罩之後才可以，而且即使如此也需要存取控管。依 GDPR，假名化資料仍屬個人資料，因此經過遮罩的複本仍需要使用目的、存取規則與保存規則。請在第一次複製之前，與您的個資保護長議定遮罩規則。

SAP TDMS 還能用於 S/4HANA 嗎？

SAP Help Portal 上目前的 TDMS 文件適用於 4.0 SP14 版，而 TDMS 是在 SAP Business Suite 上發展起來的。我找不到 SAP 對其支援目前 S/4HANA 版本的官方聲明。在以它為基礎進行規劃之前，請先以書面向 SAP 確認。

哪些工具能建立選擇性的 SAP 測試資料？

SAP Test Data Migration Server，以及 EPI-USE Labs Data Sync Manager、SNP Kyano Test Data Organizer 與 Qlik Gold Client 等夥伴產品。Natuvion DCS Protect 著重於在測試系統中將資料匿名化與假名化。請逐一確認它們是否支援您的 S/4HANA 版本與部署模式。

SAP 效能測試需要多少測試資料？

達到正式環境等級的資料量。效能問題會在真實的資料表大小與大量並行使用者下浮現，所以在單薄資料集上的測試證明不了多少事。正式環境的完整遮罩複本，是效能與並行測試的常見來源。