SAP-Performancetests: was IT-Verantwortliche wissen müssen

SAP-Performancetests belegen vor dem Go-live, dass kritische Transaktionen, Hintergrundjobs und Schnittstellen unter Produktivvolumen die vereinbarten Antwortzeiten einhalten. Beginnen Sie im Design, führen Sie Volumen- und Lasttests in der Phase Realize durch, sobald die Konfiguration stabil ist, schließen Sie den Zyklus vor dem Benutzerabnahmetest (UAT) ab und machen Sie die Ergebnisse zu einem Kriterium für den Cutover. Dieser Leitfaden richtet sich an CIOs, Programmleiter und Testleiter in S/4HANA-Programmen, auch mit RISE with SAP. Er behandelt, was Sie testen, wer dafür verantwortlich ist, wie Sie Abnahmekriterien formulieren und was sich in der Cloud ändert. Beginnen Sie mit der Tabelle der Abnahmekriterien: Wenn Sie sie nicht ausfüllen können, sind Sie noch nicht bereit zu testen.

Performanceprobleme in SAP-Programmen werden fast immer erst nach dem Go-live gefunden. Fiori-Kacheln laufen in einen Timeout, wenn sich beim Schichtwechsel 300 Anwender anmelden. Z-Berichte frieren ein, weil jemand eine unbegrenzte Geschäftsjahresabfrage auf eine Tabelle mit 50 Millionen Datensätzen abgesetzt hat. Hintergrundjobs überschneiden sich beim Monatsabschluss, und der Buchungslauf bricht ab.

Performanceprobleme in SAP-Programmen kommen selten überraschend. Die meisten waren vorhersehbar, es hat nur niemand dafür geplant. Das übliche Muster: Der Funktionstest war gründlich. Der Volumentest war geplant und wurde dann verschoben, als der Zeitplan knapp wurde. Die Folgen kamen in den ersten Wochen des Echtbetriebs.

Das sind keine Randfälle. Sie sind vorhersehbar. Die einzige Frage ist, ob das Programm darauf getestet hat oder ob das Business sie findet, während echte Aufträge laufen.

Performancetests entlang von SAP Activate

1. 01

   Explore

   Performancerisiken im Design erkennen. Architektur und Berichtsaufbau entscheiden über das Ergebnis, bevor Code geschrieben wird.

2. 02

   Realize

   Volumen- und Lasttests durchführen, sobald sich die Konfiguration stabilisiert. Teilkonfiguration liefert irreführende Ergebnisse.

3. 03

   Vor dem UAT

   Den vollständigen Performancezyklus vor dem UAT abschließen, nicht als Teil davon.

4. 04

   Cutover

   Den Cutover anhand der vorab vereinbarten Abnahmekriterien freigeben, nicht anhand von Meinungen.

5. 05

   Hypercare

   Die Live-Kennzahlen 30 bis 60 Tage beobachten. Die meisten Verschlechterungen zeigen sich im ersten Abschlusszyklus.

In einem ECC-System auf einer klassischen Datenbank bedeutete Performancetesten, Anwendungsserver und Datenbank unter Last zu testen: ABAP-Laufzeit, SQL-Performance, Jobplanung. Das Frontend war SAP GUI, das selten jemanden überraschte.

Auf S/4HANA mit Fiori-Frontends, Erweiterungen auf SAP BTP und Integration über SAP Cloud Integration (CPI) hängt die Performance von mehreren Schichten gleichzeitig ab. Eine langsame Fiori-Kachel kann an einem langen ABAP-Aufruf liegen, an einem Gateway-Timeout, an einem OData-Service, der nicht für gleichzeitige Anfragen ausgelegt ist, oder an Netzwerklatenz in einem hybriden Aufbau. Wer nur das Backend testet, findet das nicht. Wer den gesamten Pfad testet, schon.

1. 01KachelstartAnmeldewellen zu Schichtbeginn
2. 02OData-AufrufGateway-Timeouts, Services ohne Auslegung für Parallelität
3. 03ABAP-VerarbeitungLang laufende ABAP-Aufrufe
4. 04DatenbanklesezugriffOffene Selektionen auf großen Tabellen
5. 05DarstellungDazu Netzwerklatenz bei entfernten Standorten

Eine Antwortzeit, Ende zu Ende gemessen

Integrationsflüsse bringen ein eigenes Risiko mit. Flüsse, die in Entwicklung und QA mit einzelnen Testnachrichten funktionierten, können sich bei Produktivvolumen stauen oder stillschweigend ausfallen. Sind die Nachrichtenwarteschlangen nicht für die reale Last dimensioniert, bauen sich Verzögerungen auf. Die Symptome sehen nach etwas anderem aus: sporadisch fehlschlagende Aufträge, abweichende Rechnungen, Daten, die in einem System vorhanden sind und im anderen fehlen.

1. Lasttests prüfen das Verhalten unter dem erwarteten Volumen. Das Schlüsselwort ist erwartet. Sie brauchen reale Transaktionsvolumen, Anwenderzahlen und gleichzeitige Sitzungen. Viele Lasttests scheitern, weil sie Volumenschätzungen verwendeten, von denen alle schon wussten, dass sie zu optimistisch waren.
2. Stresstests gehen über die Auslegungsgrenzen hinaus, um zu finden, wo das System bricht. Wenn sich die Volumen in achtzehn Monaten verdoppeln, zeigen sie Ihnen, ob die Architektur das verkraftet und ob die Dimensionierung zum Problem wird, noch vor der nächsten Überprüfung der Infrastruktur.
3. Dauerlasttests (Soak-Tests) fahren über längere Zeit eine gleichmäßige Last, um Probleme aufzudecken, die sich mit der Zeit aufbauen: Speicherlecks, Fragmentierung und Konkurrenz zwischen Jobketten über wiederholte Läufe. Es ist der am häufigsten übersprungene Test, und er hätte den unten beschriebenen Ausfall zum Monatsabschluss entdeckt.
4. Ende-zu-Ende-Tests folgen dem gesamten Pfad eines Anwenders: Kachelstart, OData-Aufruf, ABAP-Verarbeitung, Datenbanklesezugriff, Darstellung. Nur so finden Sie Probleme, die unsichtbar bleiben, wenn jede Schicht für sich getestet wird.

Schichtwechsel und Anmeldespitzen. Wenn um 8 Uhr 200 Anwender das Fiori Launchpad öffnen, schnellen Authentifizierung und Launchpad-Darstellung in die Höhe. Ein System, das außerhalb der Spitzen einwandfrei läuft, kann in diesem Zeitfenster unbrauchbar sein, wenn gleichzeitige Anmeldungen nie getestet wurden. In Fertigung, Handel und Finanzdienstleistungen verursachen Anmeldewellen die sichtbarsten Beschwerden am ersten Tag.

Monats- und Jahresabschluss. Das riskanteste Szenario in den meisten Programmen: Buchungen in hohem Volumen, Jobketten mit strenger Reihenfolge und ein Finanzteam, das gegen eine feste Frist arbeitet. Fahren Sie die Abschlussjobketten durchgängig mit den Volumen der Abschlussperiode, nicht mit durchschnittlichen Tageswerten.

Batchjobs werden meist isoliert getestet, was die Realität nicht abbildet. Zum Monatsende erreicht die Hintergrundverarbeitung ihre Spitze, und viele Programme laufen parallel auf denselben Ressourcen. Ein schlecht optimierter Job kann fünf andere blockieren, und der Abschluss läuft über sein Zeitfenster hinaus.

Konvertierung von ECC zu S/4HANA. Stabiler ECC-Code verhält sich auf HANA anders. Viele Programme werden deutlich schneller, manche zeigen bei bestimmten Datenmustern unerwartete Laufzeitprofile. Konvertierungsspezifische Regressionstests sind nicht optional. Mein Leitfaden zur Migration von ECC zu S/4HANA zeigt, wo sich das in den Konvertierungsplan einfügt.

Anwender in mehreren Regionen. Netzwerklatenz wirkt auf jede Transaktion. Ein Kundenauftrag, der im Hosting-Land zwei Sekunden dauert, kann sich 3.000 Meilen entfernt kaputt anfühlen, wenn niemand von dort getestet hat. RISE verlagert das Hosting zu SAP, aber die Latenz hängt weiter von der gewählten Region und dem Routing zu Ihren Anwendern ab.

Vereinbaren Sie die Kriterien in der Prepare-Phase mit dem Business, bevor irgendein Test läuft. Jedes nennt die Transaktion oder den Job, die Last und den Schwellenwert. Diese Beispiele zeigen die Form; legen Sie Ihre eigenen Zahlen anhand der betrieblichen Anforderungen fest:

Gegenstand	Lastbedingung	Schwellenwert zum Bestehen	Verantwortlich
Anlegen von Kundenaufträgen (VA01 oder Fiori-App)	150 gleichzeitige Anwender bei der Auftragserfassung	Unter 3 Sekunden bei 95 % der Transaktionen	Prozessverantwortlicher Order-to-Cash
Erstes Laden des Fiori Launchpads zu Schichtbeginn	Spitze gleichzeitiger Anmeldungen der größten Schicht	Unter 5 Sekunden bei 95 % der Anwender	Leiter IT-Betrieb
Jobkette des Monatsabschlusses	Volumen der Abschlussperiode, vollständige Abfolge	Läuft ohne Abbrüche im vereinbarten Abschlussfenster durch	Financial Controller
Eingehende Auftragsschnittstelle	Spitzenvolumen an Nachrichten pro Stunde	Kein Rückstau in der Warteschlange, der älter ist als 15 Minuten	Integrationsleiter
Eigenentwickelter Bericht mit hohem Volumen	Volles Produktivdatenvolumen, typische Selektion	Unter 60 Sekunden; offene Selektionen gesperrt	Berichtsverantwortlicher

„Das System sollte schnell genug für den Geschäftsbetrieb sein“ lässt sich weder testen noch abnehmen. Kriterien zu ändern, nachdem die Ergebnisse vorliegen, nimmt ihnen jeden Sinn.

Fordern Sie jeden dieser Punkte ausdrücklich ein:

Erwartung	Was geliefert werden sollte	Warum es wichtig ist
Performance-Service-Levels	Schwellenwerte je Transaktion, Schnittstelle und Job, mit Bestanden und Nicht bestanden	Verhindert, dass Meinungen aus dem UAT Belege übertrumpfen
Risikobasierter Umfang	Priorisierung nach Anwenderzahl, Integrationspunkten und Datenabhängigkeit	Richtet die Testzyklen auf die Lasten, auf die es ankommt
Teamübergreifende Beteiligung	Basis, Infrastruktur, Fachseite, Security und Integration sind bei den Läufen dabei	Verhindert Schuldzuweisungen, wenn Lücken auftreten
Werkzeuge und Umgebungen bereit	Lastgeneratoren (OpenText LoadRunner, Tricentis NeoLoad, Apache JMeter), Monitoring und Datenaktualisierungen stehen, bevor die Zyklen beginnen	Macht die Simulation realistisch
Realistische Testdaten	Stammdaten in Produktivvolumen, echte Schnittstellenaufrufe, repräsentativer Transaktionsmix	Macht die Ergebnisse zu einer Prognose für das Verhalten nach dem Go-live
Performance-Reporting	Lastmix, Antwortzeiten, CPU und Arbeitsspeicher, Joblaufzeiten, Fehlerraten	Gibt der Cutover-Freigabe eine Beweisgrundlage
Monitoringplan nach dem Go-live	Kennzahlen, die in den ersten 30 bis 60 Tagen zu beobachten sind	Bestätigt, dass das Livesystem innerhalb der getesteten Grenzen bleibt

Vier Fehler tauchen am häufigsten auf, selbst in großen Unternehmen mit ausgereiften Liefermodellen.

Funktionstests mit Performancetests verwechseln. Funktionstests belegen, dass eine Transaktion das richtige Ergebnis liefert. Über 150 Personen, die sie gleichzeitig ausführen, sagen sie nichts.

Mit kleinen Datenmengen testen. Ein Kunde mit 200.000 offenen Auftragspositionen verhält sich anders als einer mit 5.000. Filter, die im Test sofort antworten, laufen in der Produktion in den Timeout. Legen Sie für die Hochrisikobereiche Volumen an.

Performance der Basis überlassen. Die Basis verantwortet Dimensionierung und Jobplanung. Berichtsdesign, OData-Service-Architektur und das Design der Integrationsflüsse verantwortet sie nicht, und genau diese bestimmen die Anwendungsperformance.

Die Verantwortung allein der QA geben. Die QA führt Tests durch und berichtet Ergebnisse. Die Entscheidungen, die Performanceprobleme verursachen, treffen Fach-, Technik- und Basis-Teams im Design. Ein Testleiter oder Architekt auf Programmebene braucht die Befugnis, diese Entscheidungen früh zu hinterfragen, und die RACI-Matrix sollte festhalten, wer das Go-live aus Performancegründen stoppen darf.

RISE teilt die Verantwortung

Bei RISE with SAP verantwortet SAP die Infrastruktur: Dimensionierung, Hyperscaler-Region, Netzwerk und Plattformverfügbarkeit. Kunde und Partner verantworten die Anwendungsschicht. Das Dokument zu Rollen und Verantwortlichkeiten bei RISE von SAP sagt es deutlich: Das Finden und Optimieren aufwendiger SQL-Anweisungen bleibt beim Kunden, solange Sie die zusätzlichen Anwendungsservices von SAP nicht hinzukaufen.

Ein häufiger Fehler in RISE-Programmen ist die Annahme, SAP werde Performanceprobleme finden, weil es die Infrastruktur betreibt. Infrastrukturprobleme findet SAP. Einen schlecht gestalteten OData-Service, einen ineffizienten ABAP-Job oder einen Integrationsflow, der nicht skaliert, findet es nicht. Schreiben Sie die Aufteilung in die Programm-Charter und den Testplan:

1. SAP: Verfügbarkeit der Infrastruktur und Antwortverhalten auf Plattformebene
2. Partner: Anwendungsperformance unter der definierten Last, einschließlich Erweiterungen und Integrationsflüssen
3. Kunde: Ergebnisse auf Prozessebene wie die Laufzeit des Abschlusses und der Auftragsdurchsatz sowie die Abnahmeentscheidung

Public Edition und GROW grenzen den Umfang ein

Bei S/4HANA Cloud Public Edition, meist über GROW with SAP bezogen, führt SAP Performancetests auf seiner Multi-Tenant-Plattform im Rahmen des eigenen Produktstandards durch und erwartet nicht, dass Kunden das gemeinsam genutzte System unter Last testen. Ihr Testen verlagert sich auf das, was Ihnen gehört: eigene Integrationen, Erweiterungen, Berichte und Analysen mit hohem Volumen, die Abfolge von Abschluss und Konsolidierung sowie den Netzwerkpfad von Ihren Standorten. Performanceprobleme auf der Plattform selbst gehören zum SAP-Support.

KI hilft bei Skripten, nicht bei der Architektur

Anbieter von Lasttestwerkzeugen ergänzen KI für die Skriptpflege und die Ergebnisanalyse, was in Programmen hilft, in denen sich die Anwendung zwischen den Zyklen ändert. Prüfen Sie die Versprechen in Ihrer eigenen Landschaft, bevor Sie dafür zahlen. SAP Cloud ALM kann bei der Erzeugung von Testfällen und Anforderungen helfen, und KI-Assistenten können aus Prozessbeschreibungen Szenarioentwürfe erstellen.

Nichts davon repariert Architektur. KI sagt Ihnen nicht, dass der OData-Service anders hätte gestaltet werden müssen oder dass ein Bericht für seine Volumen zu schwer ist. Diese Entscheidungen treffen weiterhin Menschen, im Design, bevor irgendein Test läuft.

Die meisten Programme mit Performanceproblemen in der Produktion haben das Testen nicht komplett ausgelassen. Sie haben ohne vereinbarte Kriterien getestet oder getestet und die Lücken dann unter Termindruck als bekannte Probleme akzeptiert. Die Disziplin liegt in den Kriterien und in ihrer Durchsetzung, nicht im Werkzeug. Wo Performancetests im Verhältnis zu anderen Testarten stehen, zeigen mein Vergleich von SAP-Test- und Validierungswerkzeugen und mein Leitfaden zu SAP Quality Gates.

Was sind SAP-Performancetests und warum sind sie wichtig?

Sie prüfen, wie sich SAP unter realistischer Last verhält: Antwortzeiten für Anwendertransaktionen, Laufzeiten von Hintergrundjobs, Durchsatz von Schnittstellen und Ressourcenverbrauch bei paralleler Arbeit.

Funktionale Korrektheit und Performance sind verschiedene Eigenschaften. Eine Transaktion, die für einen Anwender korrekt ist, kann für 200 in den Timeout laufen. Ein Job, der mit Testdaten zehn Minuten braucht, kann mit Produktivvolumen Stunden laufen. Wer das erst nach dem Go-live findet, stört den Betrieb, erzwingt Notfalländerungen und beschädigt das Vertrauen der Anwender, wenn die Akzeptanz am fragilsten ist.

Wann sollten Performancetests in einem SAP-Programm beginnen?

Die Risikoidentifikation beginnt in Explore, weil Architekturentscheidungen die Performance festlegen. Das aktive Testen beginnt in Realize, sobald die Konfiguration stabil genug ist, dass Ergebnisse etwas aussagen. Teilkonfiguration liefert irreführende Zahlen.

Schließen Sie den letzten Zyklus vor dem UAT ab, nicht währenddessen. Performancefehler, die im UAT auftauchen, drücken auf den verbleibenden Zeitplan und erzeugen Druck, sie als bekannte Probleme hinzunehmen.

Wer sollte SAP-Performancetests verantworten?

Das Programm, nicht die QA allein. Die QA führt aus und berichtet, aber die Entscheidungen, die die Performance bestimmen, fallen im Design in den Fach-, Technik- und Basis-Teams. Ein zentraler Architekt oder Testleiter auf Programmebene braucht die Befugnis, diese Entscheidungen früh zu hinterfragen.

Halten Sie es in der RACI-Matrix ausdrücklich fest: wer die Abnahmekriterien freigibt, wer für die Behebung zuständig ist, wenn Kriterien nicht erfüllt werden, und wer das Go-live aus Performancegründen stoppen darf.

Wie verändert RISE with SAP die Verantwortung für Performancetests?

SAP verantwortet die Infrastruktur: Dimensionierung, Region, Netzwerk und Plattformverfügbarkeit. Kunde und Partner verantworten die Anwendungsperformance: Konfiguration, Erweiterungen, OData- und Fiori-Design, Integrationsflüsse und Prozesskennzahlen. Das Dokument von SAP zu Rollen und Verantwortlichkeiten bei RISE lässt das SQL-Tuning beim Kunden, sofern keine zusätzlichen SAP-Services hinzugekauft werden.

Schreiben Sie die Aufteilung in die Abnahmekriterien, damit jeder Schwellenwert einen Verantwortlichen hat.

Was sind die häufigsten Performanceprobleme bei SAP Fiori?

Vier Muster decken die meisten ab. Anmeldewellen zu Schichtbeginn, wenn Authentifizierung und Launchpad-Darstellung in die Höhe schnellen. OData-Services, die große Ergebnismengen zurückgeben oder pro Interaktion mehrere Backend-Aufrufe auslösen. Die Gateway-Schicht, die selbst zum Engpass wird und deshalb während der Tests überwacht werden muss. Und eigenentwickelte oder stark veränderte Apps, in denen die Standardannahmen zur Performance nicht gelten.

Wie legen Sie Abnahmekriterien für die SAP-Performance fest?

Nennen Sie die Transaktion, die Last und den Schwellenwert. Zum Beispiel: „Das Anlegen eines Auftrags dauert bei 95 % der Transaktionen unter 3 Sekunden, bei 150 gleichzeitigen Anwendern in der Rolle Auftragserfassung.“ Das ist testbar.

„Das System sollte schnell genug sein“ ist es nicht. Vereinbaren Sie die Kriterien in der Prepare-Phase mit dem Business, auf Basis realer betrieblicher Anforderungen, und ändern Sie sie nicht, nachdem die Ergebnisse vorliegen.

Was passiert, wenn Performancetests ausgelassen oder verkürzt werden?

Die Probleme zeigen sich in der Produktion: Jobs, die ihre Zeitfenster überschreiten und andere blockieren, Fiori-Apps, die in der Spitze in den Timeout laufen, ein Monatsabschluss, der doppelt so lange dauert und Berichtsfristen verfehlt, Schnittstellenwarteschlangen, die sich aufstauen.

Anwender, die in den ersten Wochen auf Performanceprobleme stoßen, bilden sich ein negatives Bild des Systems, das sich schwer umkehren lässt. Und die Notfallbehebung im laufenden Betrieb kostet mehr, als das Testen gekostet hätte, weil aus einer Designentscheidung in Realize eine dringende Architekturänderung wird.