SAP-Performancetests: Last, Parallelität und Tools

SAP-Performancetests belegen vor dem Go-live, dass kritische Transaktionen, Hintergrundjobs und Schnittstellen die vereinbarten Antwortzeiten einhalten, wenn viele Anwender und Jobs gleichzeitig laufen. Nach meiner Erfahrung sind die Parallelitätstests die, auf die es ankommt, ausgeführt auf maskierten Daten mit Produktionsvolumen und gegen Kriterien für bestanden und nicht bestanden, die der Fachbereich vor dem ersten Lauf vereinbart hat.

Dieser Leitfaden richtet sich an CIOs, Programmdirektoren und Testleiter in S/4HANA-Programmen, einschließlich RISE with SAP. Er behandelt, was Sie testen, welche Daten Sie brauchen, wie Sie Abnahmekriterien formulieren, welche Tools die Arbeit leisten und wer wofür zuständig ist. Wo Performancetests unter den anderen Testarten stehen, zeigt mein Überblick SAP-Tests erklärt.

Performanceprobleme in SAP-Programmen sind selten eine Überraschung.

Fiori-Kacheln laufen in einen Timeout, wenn sich Hunderte von Anwendern zu Schichtbeginn anmelden. Ein Z-Bericht friert ein, weil jemand eine offene Selektion über ein ganzes Geschäftsjahr gegen eine sehr große Tabelle gestartet hat. Hintergrundjobs überschneiden sich zum Monatsende, und der Buchungslauf bricht ab.

Das ist vorhersehbar. Die einzige Frage ist, ob das Programm darauf getestet hat oder ob der Fachbereich es bei laufenden echten Aufträgen entdeckt.

Performancetests über SAP Activate hinweg

1. 01

   Explore

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

2. 02

   Realize

   Volumen- und Lasttests durchführen, sobald sich die Konfiguration stabilisiert. Eine unvollständige Konfiguration 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 gegen die vorab vereinbarten Abnahmekriterien freigeben, nicht nach Meinung.

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 hieß Performancetest, den Applikationsserver und die Datenbank unter Last zu testen: ABAP-Laufzeit, SQL-Performance und Jobsteuerung. Das Frontend war SAP GUI, und das überraschte selten jemanden.

Bei S/4HANA mit Fiori-Frontends, Erweiterungen auf SAP BTP und Integration über SAP Cloud Integration hängt die Performance von mehreren Ebenen gleichzeitig ab. Eine langsame Fiori-Kachel kann ein langer ABAP-Aufruf sein, ein Gateway-Timeout, ein OData-Service, der nicht für parallele Anfragen ausgelegt ist, oder Netzwerklatenz in einem hybriden Aufbau. Wer nur das Backend testet, findet das nicht.

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

Eine Antwortzeit, durchgängig gemessen

Performancetests auf SAP HANA haben bei einer Konvertierung ihre eigene Besonderheit. Stabiler ECC-Code verhält sich auf einer In-Memory-Datenbank anders. Viele Programme werden deutlich schneller, während manche bei bestimmten Datenmustern unerwartete Profile zeigen, also ist ein konvertierungsspezifischer Regressionstest der schweren Eigenentwicklungen nicht optional.

Integrationsabläufe bringen ihr eigenes Risiko mit. Abläufe, die in der Entwicklung mit einzelnen Testnachrichten funktioniert haben, können sich bei Produktionsvolumen stauen oder still fehlschlagen. Die Symptome sehen nach etwas anderem aus: sporadische Auftragsfehler, nicht passende Rechnungen, Daten, die in einem System vorhanden sind und im anderen fehlen.

Performancetests müssen vor dem Go-live stattfinden. Als die wichtigen Tests betrachte ich die Parallelitätstests: viele Anwender und Jobs, die gleichzeitig auf dieselben Transaktionen, Tabellen und Services zugreifen.

Ein einzelner Anwender, der einen Kundenauftrag in zwei Sekunden anlegt, beweist fast nichts. Derselbe Auftrag, während 150 Leute Aufträge erfassen, im Hintergrund ein Lieferlauf läuft und eine Schnittstelle eingehende Nachrichten bucht, ist der Test, der den ersten Tag vorhersagt.

Diese Tabelle zeigt, was jede Testart belegt und wann Sie sie durchführen:

Test	Was er belegt	Wann er läuft	Was er meist findet
Parallelität	Viele Anwender und Jobs können gleichzeitig an denselben Objekten arbeiten	Realize, sobald die Konfiguration stabil ist, und erneut vor dem UAT	Sperrwartezeiten, Anmeldewellen, Gateway-Engpässe
Last	Das System hält die Antwortzeiten bei der erwarteten Spitzenlast ein	Realize, wenn die Parallelitätsskripte funktionieren	Langsame OData-Services, schwere Z-Berichte
Stress	Wo das System oberhalb der Auslegungsgrenzen bricht	Vor dem UAT, wenn Wachstum erwartet wird	Lücken in der Dimensionierung, Grenzen von Warteschlangen
Dauer	Das System hält über Stunden eine gleichmäßige Last	Vor dem UAT, idealerweise über einen simulierten Abschluss	Wachsender Speicherverbrauch, Konkurrenz in Jobketten bei wiederholten Läufen
Durchgängig	Der ganze Weg, auf den ein Anwender wartet, erreicht das Ziel	Parallel zu den Lasttests	Probleme, die unsichtbar sind, wenn jede Ebene allein getestet wird

Das entscheidende Wort beim Lasttest ist erwartet. Sie brauchen echte Transaktionsvolumen, Anwenderzahlen und Sitzungsmuster. Ein Lasttest, der auf Volumenschätzungen beruht, von denen alle schon wussten, dass sie optimistisch sind, liefert ein Bestanden, das nichts bedeutet.

Der Dauertest wird am häufigsten ausgelassen. Volumentests insgesamt sind die Abkürzung, die Programme am häufigsten nehmen, wenn der Zeitplan schrumpft, und am meisten bereuen.

Skripten Sie diese zuerst. Sie decken die meisten Ausfälle ab, die bis in die Produktion gelangen.

1. Schichtwechsel und Anmeldespitze. Wenn einige hundert Anwender gleichzeitig das Fiori Launchpad öffnen, schnellen Authentifizierung und Aufbau des Launchpads in die Höhe. Ein System, das außerhalb der Spitze gut läuft, kann in diesem Zeitfenster unbenutzbar sein, wenn parallele Anmeldungen nie getestet wurden.
2. Monats- und Jahresabschluss. Buchungen in hohem Volumen, Jobketten mit strikter Reihenfolge und ein Finanzteam, das gegen eine feste Frist arbeitet. Lassen Sie die Jobketten des Abschlusses durchgängig mit den Volumen der Abschlussperiode laufen, nicht mit durchschnittlichen Tageswerten.
3. Sich überschneidende Hintergrundjobs. Batchjobs werden meist einzeln getestet, und das entspricht nicht der Realität. Ein schlecht optimierter Job kann mehrere andere blockieren, und der Abschluss läuft über sein Zeitfenster hinaus.
4. Offene Z-Berichte. Ein Bericht, der auf Testdaten sofort Ergebnisse liefert, kann auf einem vollen Geschäftsjahr minutenlang laufen. Testen Sie typische und ungünstigste Selektionen, und sperren Sie die offenen.
5. Anwender in mehreren Regionen. Netzwerklatenz wirkt sich auf jede Transaktion aus. RISE verlagert das Hosting zu SAP, aber die Latenz hängt weiterhin von der gewählten Region und dem Routing zu Ihren Anwendern ab, also testen Sie von den am weitesten entfernten Standorten aus.

Mein Leitfaden zur Migration von ECC auf S/4HANA zeigt, wo Konvertierungstests in den Gesamtplan passen.

Testdaten auf Produktionsniveau

Die Daten entscheiden, ob irgendetwas davon aussagekräftig ist. Ich bestehe auf maskierten Daten auf Produktionsniveau: Produktionsvolumen und Realitätsnähe wie in der Produktion, mit maskierten personenbezogenen und sensiblen Feldern.

Ein Kunde mit 200.000 offenen Auftragspositionen verhält sich anders als einer mit 5.000. Filter, die in einem dünnen Testmandanten sofort Ergebnisse liefern, laufen in der Produktion in einen Timeout. Befüllen Sie die Hochrisikobereiche mit Volumen, nutzen Sie einen repräsentativen Transaktionsmix und rufen Sie echte Schnittstellen auf, wo Sie können.

Wie Sie diese Daten sicher bekommen, über Kopien, selektive Testdatentools und Maskierung, behandelt mein Leitfaden zum SAP-Testdatenmanagement. Planen Sie die Auffrischung vor dem ersten Performancezyklus, denn sie dauert länger, als die meisten Testpläne annehmen.

Vereinbaren Sie die Kriterien mit dem Fachbereich in der Prepare-Phase, bevor irgendein Test läuft. Jedes nennt die Transaktion oder den Job, die Last und die Schwelle.

Diese Beispiele zeigen die Form. Legen Sie Ihre eigenen Zahlen nach den betrieblichen Anforderungen fest:

Element	Lastbedingung	Schwelle für bestanden	Verantwortlich
Anlage von Kundenaufträgen (VA01 oder Fiori-App)	150 gleichzeitige Anwender in der Auftragserfassung	Unter 3 Sekunden für 95 % der Transaktionen	Prozessverantwortlicher Order-to-Cash
Erster Aufruf des Fiori Launchpad zu Schichtbeginn	Spitze paralleler Anmeldungen für die größte Schicht	Unter 5 Sekunden für 95 % der Anwender	Leiter IT-Betrieb
Jobkette zum Monatsabschluss	Volumen der Abschlussperiode, vollständige Abfolge	Wird im vereinbarten Abschlussfenster ohne Abbrüche abgeschlossen	Leiter Controlling
Eingehende Auftragsschnittstelle	Spitzenvolumen an Nachrichten pro Stunde	Kein Rückstau in der Warteschlange, der älter als 15 Minuten ist	Integrationsverantwortlicher
Z-Bericht mit hohem Volumen	Volles Produktionsdatenvolumen, typische Selektion	Unter 60 Sekunden; offene Selektionen gesperrt	Verantwortlicher für den Bericht

„Das System sollte für den Geschäftsbetrieb schnell genug sein“ lässt sich weder testen noch abnehmen. Wer Kriterien ändert, nachdem die Ergebnisse vorliegen, macht ihren Zweck zunichte.

Wenn das System bestanden hat, weil Anwender im UAT sagten, es fühle sich schnell an, haben Sie eine Meinung, kein Abnahmekriterium. Machen Sie die Ergebnisse zu einem formalen Gate vor dem Cutover, so wie es mein Leitfaden zu SAP Quality Gates beschreibt. Der Gesamtplan der Zyklen, mit Eingangs- und Ausgangskriterien für jede Testphase, gehört in Ihre S/4HANA-Teststrategie.

Tools für SAP-Performancetests

Ein Performancetest braucht drei Dinge: einen Lastgenerator, der SAP-Protokolle bedienen kann, Monitoring auf der SAP-Seite und einen Ort, an dem Testfälle und Ergebnisse verwaltet werden. LoadRunner ist das Lasttool, das meine Teams in SAP-Programmen eingesetzt haben. Benennen Sie das Tool früh im Testplan, denn Lizenzen, Lastgeneratoren und Skripting-Kenntnisse brauchen alle Zeit in der Beschaffung.

Die wichtigsten Optionen 2026:

Tool	Rolle	Was Sie wissen sollten
OpenText Professional Performance Engineering	Lasterzeugung	Das Produkt, das früher LoadRunner Professional hieß. Seine Protokollpakete decken SAP, SAP GUI und SAP Web ab
Tricentis NeoLoad	Lasterzeugung	Tricentis nennt Unterstützung für SAP GUI, Fiori, RFC und IDoc, und es kann Tricentis-Tosca-Bausteine wiederverwenden
Apache JMeter	Lasterzeugung	Open Source. Erzeugt HTTP-Verkehr wie Fiori- und OData-Aufrufe
SAP Cloud ALM	Testmanagement	Bereitet manuelle und automatisierte Testfälle vor, führt sie aus und verfolgt Fehler. Last erzeugt es nicht selbst
SAP Solution Manager	Testmanagement	Die Mainstream-Wartung endet am 31. Dezember 2027, also planen Sie neue Arbeit in Cloud ALM

Einen breiteren Blick auf funktionale Tools und Automatisierungstools bietet mein Vergleich von SAP-Test- und Validierungstools. Das Tool zählt weniger als die Skripte, die Daten und die Kriterien.

RISE with SAP teilt die Verantwortung auf

Unter RISE with SAP verantwortet SAP die Infrastruktur: Dimensionierung, Hyperscaler-Region, Netzwerk und Verfügbarkeit der Plattform. Kunde und Partner verantworten die Anwendungsebene.

Das Dokument von SAP zu Rollen und Verantwortlichkeiten bei RISE ist da eindeutig. Die Durchführung von Lasttests und das Tuning teurer SQL-Anweisungen sind kostenpflichtige SAP Cloud Application Services. Kaufen Sie sie nicht, erledigt der Kunde die Arbeit.

Ein häufiger Fehler in RISE-Programmen ist die Annahme, SAP werde Performanceprobleme abfangen, weil SAP die Infrastruktur betreibt. SAP fängt Infrastrukturprobleme ab. Schreiben Sie die Aufteilung in die Projektcharta und den Testplan:

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

Die Public Cloud engt den Umfang ein

In der Public Edition des Cloud-ERP von SAP läuft das System auf einer gemeinsam genutzten, von SAP betriebenen Plattform. Bevor Sie einen Lasttest gegen einen Tenant planen, fragen Sie SAP schriftlich, ob er erlaubt ist und welche Vorlaufzeit SAP braucht.

Ihr Testen verlagert sich dann auf das, was Ihnen gehört: eigene Integrationen, Erweiterungen, Berichte mit hohem Volumen, die Abschlussabfolge und den Netzwerkweg von Ihren Standorten. Performanceprobleme der Plattform gehen an den SAP-Support.

Häufige Fehler

1. Funktionale Tests als Performancetests behandeln. Funktionale Tests belegen, dass eine Transaktion das richtige Ergebnis liefert. Über 150 Leute, die sie gleichzeitig ausführen, sagen sie nichts.
2. Performance der Basis überlassen. Die Basis verantwortet Dimensionierung und Jobsteuerung. Sie verantwortet nicht das Design der Berichte, die Architektur der OData-Services oder das Design der Integrationsabläufe, und genau die bestimmen die Anwendungsperformance.
3. Die Verantwortung allein der Qualitätssicherung geben. Die Qualitätssicherung führt Tests durch und berichtet Ergebnisse, aber die Entscheidungen, die Performanceprobleme verursachen, fallen im Design. Ein Testleiter oder Architekt auf Programmebene braucht die Befugnis, sie früh zu hinterfragen, und die RACI-Matrix sollte festlegen, wer den Go-live aus Performancegründen stoppen kann.
4. Lücken als bekannte Probleme akzeptieren. Die meisten Programme mit Performanceproblemen in der Produktion haben das Testen nicht ausgelassen. Sie haben ohne vereinbarte Kriterien getestet oder getestet und die Ausfälle dann unter Termindruck akzeptiert.

Schreiben Sie die fünf oder sechs Abnahmekriterien für Ihre riskantesten Transaktionen und Jobs, jeweils mit einem namentlich benannten Verantwortlichen. Wenn Sie die Tabelle oben nicht ausfüllen können, sind Sie nicht testbereit, und Sie haben die erste Lücke gefunden.

Prüfen Sie dann zwei Dinge: dass eine Auffrischung mit maskierten Daten in Produktionsvolumen im Plan steht und dass der Parallelitätszyklus abgeschlossen ist, bevor der UAT beginnt.

Wenn Sie eine unabhängige Sicht auf einen Performancetestplan oder eine Go-live-Entscheidung möchten: Dabei unterstütze ich Organisationen. Sie können mich hier kontaktieren.

Was sind SAP-Performancetests?

Sie prüfen, wie sich SAP unter realistischer Last verhält: Antwortzeiten für Anwendertransaktionen, Laufzeiten für Hintergrundjobs, Durchsatz für Schnittstellen und Ressourcenverbrauch, wenn viele Leute gleichzeitig arbeiten. Sie müssen vor dem Go-live erfolgen.

Funktionale Korrektheit und Performance sind unterschiedliche Eigenschaften. Eine Transaktion, die für einen Anwender korrekt ist, kann bei 200 in einen Timeout laufen.

Wann sollten Performancetests in einem SAP-Programm beginnen?

Die Risikoerkennung beginnt in Explore, denn Architekturentscheidungen legen die Performance fest. Das aktive Testen beginnt in Realize, sobald die Konfiguration stabil genug ist, dass die Ergebnisse etwas aussagen.

Schließen Sie den letzten Zyklus vor dem UAT ab, nicht währenddessen. Performancefehler, die im UAT gefunden werden, drücken den Zeitplan zusammen und erzeugen Druck, sie als bekannte Probleme zu akzeptieren.

Was ist der Unterschied zwischen Lasttest und Parallelitätstest in SAP?

Der Lasttest prüft die Antwortzeiten bei der erwarteten Spitzenlast. Der Parallelitätstest prüft, was passiert, wenn viele Anwender und Jobs im selben Moment an denselben Transaktionen, Tabellen und Services arbeiten. Dort zeigen sich Sperrwartezeiten, Anmeldewellen und Gateway-Engpässe.

Nach meiner Erfahrung sind die Parallelitätstests die wichtigen. Führen Sie sie zuerst durch und bauen Sie dann den vollständigen Lasttest darauf auf.

Welche Testdaten sollten SAP-Performancetests verwenden?

Maskierte Daten auf Produktionsniveau. Das heißt Produktionsvolumen und Realitätsnähe, mit maskierten personenbezogenen und sensiblen Feldern. Dünne Testdaten verbergen die langsamen Filter, schweren Berichte und langen Joblaufzeiten, die am ersten Tag auftauchen.

Welche Tools werden für SAP-Performancetests verwendet?

Lastgeneratoren wie OpenText Professional Performance Engineering (früher LoadRunner Professional), Tricentis NeoLoad und Apache JMeter erzeugen die Last. SAP Cloud ALM oder SAP Solution Manager verwalten Testfälle und Ergebnisse, und das Monitoring auf der SAP-Seite zeigt, was das System unter Last getan hat.

Wer ist bei RISE with SAP für Performancetests zuständig?

SAP verantwortet die Infrastruktur: Dimensionierung, Region, Netzwerk und Verfügbarkeit der Plattform. Das Dokument von SAP zu Rollen und Verantwortlichkeiten bei RISE belässt die Durchführung von Lasttests und das Tuning teurer SQL-Anweisungen beim Kunden, es sei denn, SAP Cloud Application Services werden gegen Aufpreis gekauft.

Kunde und Partner verantworten die Anwendungsperformance und die Abnahmeentscheidung. Schreiben Sie die Aufteilung in die Abnahmekriterien, damit jede Schwelle einen Verantwortlichen hat.