SAP-Testdaten in S/4HANA: fünf Wege im Vergleich

Fünf Wege zu SAP-Testdaten im Überblick

Gute Testdaten decken Fehler auf, bevor sie in der Produktion auftreten, und schaffen dabei keine neuen Risiken. Fünf Kriterien entscheiden: Wie viel Aufwand kostet die Bereitstellung? Wie aussagekräftig sind die Tests, also wie nah an der Produktion, mit Sonderfällen und vollständigen Belegketten? Wie viel Hauptspeicher belegen die Daten in SAP HANA? Wie viele personenbezogene Daten landen im Testsystem? Und wie aktuell bleiben sie?

Weg	Aufwand	Aussagekraft	HANA-Speicher	Datenschutz	Aktualität
Systemkopie	Hoch: Das ganze Zielsystem wird überschrieben, umfangreiche Nacharbeiten	Maximal: alle Daten, alle Sonderfälle, echte Mengen	Wie in der Produktion	Alle Personendaten im Klartext, solange nicht maskiert wird	Stand der Kopie, Refresh selten, weil aufwendig
Mandantenkopie (Standard)	Mittel bis hoch: Laufzeit wächst mit der Historie, dazu Nacharbeiten	Hoch: komplette Historie des Mandanten mit allen Belegketten	Nahe am Produktions-Sizing	Wie bei der Systemkopie, für den kopierten Mandanten	Stand der Kopie, veraltet bis zum nächsten Refresh
Teilkopie per Zeitscheibe	Werkzeug und Einrichtung nötig, danach wiederholbar	Hoch für den Zeitraum, wenn alle abhängigen Objekte mitkommen	Nur Zeitraum plus Abhängigkeiten	Weniger Personendaten, Maskierung trotzdem nötig	Häufigere Refreshs möglich, weil kleiner und schneller
Manuell oder per Testautomatisierung angelegt	Hoch je Testfall, Pflege bei jeder Prozessänderung	Genau die geplanten Fälle, keine unbekannten Sonderfälle	Gering	Unkritisch, solange keine echten Daten verwendet werden	Jederzeit neu erzeugbar, unabhängig von der Produktion
Synthetisch erzeugt	Hoch: Regeln oder Modell für das SAP-Datenmodell aufbauen	So gut wie das Modell, Mengen gut skalierbar	Frei wählbar	Günstig, bei Ableitung aus Produktivdaten Rückschlüsse prüfen	Unabhängig von der Produktion, Modell muss nachgezogen werden

Vereinfachte Einordnung. Im Einzelfall hängt die Bewertung von Systemgröße, Werkzeugen und Testzielen ab.

Vollkopien: Systemkopie und Mandantenkopie

Die Systemkopie überträgt die gesamte Datenbank: alle Mandanten, das Repository und die mandantenübergreifenden Daten. Das Zielsystem ist danach ein Abbild der Produktion, einschließlich des Entwicklungsstands. Wie sie abläuft, beschreibt der Artikel SAP-Systemkopie: Methoden, Ablauf und Nacharbeiten.

Die Standard-Mandantenkopie überträgt die mandantenabhängigen Daten eines Mandanten. Mit dem Profil SAP_ALL kommen Customizing, Anwendungsdaten und Benutzerstämme mit. Die Kopierprofile wählen Datenarten aus, aber keinen Zeitraum.

Beide liefern das Maximum an Realität: echte Belegketten über Module hinweg, gewachsene Stammdaten und Sonderfälle, an die beim Testfalldesign niemand gedacht hat. Deshalb sind sie für Integrations- und Abnahmetests beliebt. Der Preis zeigt sich an drei Stellen:

Speicher: SAP HANA hält die Daten im Hauptspeicher. Jede Vollkopie braucht fast so viel RAM wie die Produktion, und der wird gerade deutlich teurer.
Dauer: Kopie, BDLS-Lauf, Schnittstellen, Jobs und Benutzer. Bei großen Systemen ist ein Refresh schnell ein Wochenendprojekt.
Datenschutz: Jede Vollkopie bringt alle personenbezogenen Daten der Produktion in ein System, in dem meist mehr Menschen mit breiteren Rechten arbeiten.

Das BSI führt Tests mit Produktivdaten im IT-Grundschutz ausdrücklich als Gefährdung. Enthalten die Testdaten personenbezogene Informationen, verlangt der Baustein OPS.1.1.6 als Basis-Anforderung, sie mindestens zu pseudonymisieren. Mehr dazu im Artikel Personenbezogene Daten in SAP-Testsystemen. Was der Hauptspeicher kostet, zeigt der Artikel RAM-Preise und S/4HANA.

Systemkopie

Überschreibt die ganze Datenbank

Mandantenkopie

Überschreibt einen Mandanten mit kompletter Historie

Mandantenkopie mit Zeitscheibe

Überschreibt einen Mandanten mit einem Zeitraum, z. B. 90 Tagen, plus abhängigen Objekten

Die Systemkopie ersetzt alles, die Mandantenkopie einen Mandanten mit der ganzen Historie, die Zeitscheibe nur den benötigten Zeitraum. Schematische Darstellung.

Teilkopie per Zeitscheibe

Eine Teilkopie überträgt nur einen Ausschnitt der Produktion, meist einen Zeitraum: zum Beispiel die Belege der letzten 90 Tage. Damit das Zielsystem fachlich funktioniert, müssen alle Objekte mitkommen, auf die diese Belege verweisen. Dazu gehören Stammdaten, Vorgängerbelege und offene Posten, auch wenn sie Jahre älter sind. Fehlt ein Glied der Belegkette, scheitern Tests an fehlenden Daten statt an Fehlern im Programm.

Richtig umgesetzt verbindet die Teilkopie die Aussagekraft der Vollkopie mit einem Bruchteil des Speichers. Die Grenze: Sonderfälle, die nur in älteren Daten stecken und im Zeitraum nicht vorkommen, fehlen. Für Tests rund um den Jahresabschluss wählen Sie den Zeitraum deshalb passend zum Geschäftsjahr.

Die Standard-Mandantenkopie kennt keinen Zeitraum. Eine Notlösung ist, nach einer Vollkopie im Zielsystem zu löschen oder zu archivieren. Das spart Speicher aber erst hinterher und verlängert den Refresh. In ECC-Landschaften wurde für Teilkopien oft SAP TDMS eingesetzt, das für ECC entwickelt wurde. Laut SAP-Hinweis 2696183 wird TDMS im S/4HANA-Kontext nicht unterstützt. Was das für den Umstieg bedeutet, steht auf der Seite Alternative zu SAP TDMS für S/4HANA.

SAP-Testdaten generieren: manuell, automatisiert, synthetisch

Statt Daten aus der Produktion zu holen, können Sie sie im Testsystem selbst anlegen. Drei Varianten sind üblich:

Manuell: Key User oder Tester legen Stammdaten und Belege über die Anwendung an. Das kostet Zeit, liefert aber Daten, die genau zum Testfall passen.
Per Testautomatisierung: Testskripte legen ihre Daten selbst an, bevor sie den eigentlichen Test ausführen. In eCATT etwa liegen Testdaten getrennt von den Skripten in Testdatencontainern und lassen sich wiederverwenden.
Synthetisch: Generatoren erzeugen Daten nach Regeln oder nach einem statistischen Modell, auch in großen Mengen, etwa für Lasttests.

In SAP gilt dabei eine Grundregel: Daten über die Anwendungslogik anlegen, also über Transaktionen, Fiori-Apps, BAPIs oder freigegebene APIs, nicht direkt in Tabellen. Ein Kundenauftrag schreibt in viele Tabellen, vergibt Nummern, setzt Status und baut den Belegfluss auf. Spätestens die Faktura bucht in die Finanzbuchhaltung. Wer an der Anwendung vorbei schreibt, erzeugt inkonsistente Daten.

Die Grenze aller selbst erzeugten Daten: Sie enthalten nur, was jemand vorhergesehen hat. Gewachsene Stammdaten, Altlasten aus der Migration und seltene Prozessvarianten fehlen. Für Entwicklung, Schulung und automatisierte Regressionstests ist das ein Vorteil, für Integrations- und Abnahmetests ein Risiko. Werden synthetische Daten aus Produktivdaten abgeleitet, etwa über ein trainiertes Modell, klären Sie mit Ihrem Datenschutz, ob sie Rückschlüsse auf echte Personen zulassen.

Testdatenmanagement in S/4HANA: welcher Weg wofür

Testdatenmanagement heißt, für jedes Testsystem festzulegen, welche Daten es braucht, woher sie kommen, wie oft sie erneuert und wie sie geschützt werden. Es ergänzt das Testmanagement, das Testfälle, Testpläne und Testläufe organisiert, in SAP-Landschaften etwa mit SAP Cloud ALM. Den Ausschlag gibt der Zweck des Systems:

Entwicklung: Customizing und wenige gezielte Daten genügen meist. Diese legen Entwickler manuell oder per Skript an, Produktivdaten sind hier selten nötig.
QS und Integrationstest: Produktionsnahe Daten mit vollständigen Belegketten über Module und Schnittstellen. Passend sind eine Teilkopie per Zeitscheibe oder eine Mandantenkopie, jeweils maskiert.
Regressionstest: Eine reproduzierbare Ausgangslage. Automatisierte Tests legen ihre Daten selbst an oder wählen sie zur Laufzeit aus. So überstehen sie auch den nächsten Refresh.
Support und Fehleranalyse: Möglichst aktuelle Daten, um Fehler aus der Produktion nachzustellen. Hier zählt, wie schnell und wie oft sich das System auffrischen lässt.
Schulung: Stabile, verständliche Beispieldaten ohne echte Personen. Praktisch ist ein Vorlagemandant, aus dem der Schulungsmandant vor jedem Kurs per lokaler Mandantenkopie neu aufgesetzt wird.
Performancetest: Realistische Datenmengen. Dafür ist meist eine Systemkopie nötig. Synthetische Daten helfen, wenn künftiges Wachstum simuliert werden soll.

Für das SAP-HANA-Testsystem folgt daraus auch die Größe. Weil HANA die Daten im Hauptspeicher hält, bestimmt die Datenmenge den Bedarf an RAM. Wer QS, Test und Sandbox nach Zweck befüllt statt per Vollkopie, kann sie auch nach Zweck dimensionieren. Mehr zum HANA-Speicher in Non-Prod

Produktionsnah und schlank: Zeitscheibe mit Maskierung

Für QS-, Test- und Support-Systeme ist die Teilkopie oft der beste Kompromiss: echte Belegketten, weniger Speicher, kürzere Refreshs. Hier setzt der Data Refresh Operator (DRO) an. Er kopiert eine Zeitscheibe, zum Beispiel die letzten 90 Tage, und ergänzt alle abhängigen Objekte aus älteren Jahren, aufgelöst bis zum Fixpunkt. So fehlt nachweisbar nichts. Die Maskierung ist integriert: Regeln werden zentral im Control-System gepflegt und beim Export oder Import angewendet. Logische Systemnamen ersetzt DRO beim Import, ein nachträglicher BDLS-Lauf entfällt.

–75 %: HANA-RAM in Non-Prod
–60 %: Storage & Backup

Richtwerte aus Referenzszenarien. Die tatsächlichen Effekte hängen von Systemgröße, Historie und Refresh-Zyklen ab.

DRO läuft ab SAP S/4HANA 2023 und ersetzt die Mandantenkopie, nicht die Systemkopie. Für Performancetests mit vollem Datenvolumen bleibt die Systemkopie der richtige Weg. Wann welches Verfahren passt, zeigt der Vergleich von Mandantenkopie, Systemkopie und Zeitscheibe. Welche Testdaten Ihre Systeme wirklich brauchen, besprechen wir gern mit Ihnen: Vorstellungstermin vereinbaren.

Quellen

SAP-Hinweis 2696183: TDMS-Komponenten bei Installation und Upgrade von S/4HANA 1809/1909 (SAP-Support-Portal, Anmeldung nötig)
BSI, IT-Grundschutz-Kompendium Edition 2023: Baustein OPS.1.1.6 Software-Tests und -Freigaben
SAP-Hilfe: Organizing Test Data in eCATT (SAP NetWeaver 7.3)
SAP Support: SAP Cloud ALM for Implementation: Test Management
dsgvo-gesetz.de: Art. 5 DSGVO: Grundsätze für die Verarbeitung personenbezogener Daten

Testdaten für S/4HANA: Kopie, Teilkopie oder Generierung?