SAP-performancetesten: load, concurrency en tools

SAP-performancetesten bewijst vóór de go-live dat kritieke transacties, achtergrondjobs en interfaces de afgesproken responstijden halen als veel gebruikers en jobs tegelijk draaien. In mijn ervaring zijn de concurrencytests de tests die tellen, uitgevoerd op gemaskeerde data met productievolume, tegen criteria voor geslaagd en mislukt die de business vóór de eerste run heeft afgesproken.

Deze gids is voor CIO's, programmadirecteuren en testleads in S/4HANA-programma's, inclusief RISE with SAP. Hij behandelt wat u test, welke data u nodig hebt, hoe u acceptatiecriteria schrijft, welke tools het werk doen en wie waarvoor verantwoordelijk is. Waar performance tussen de andere testsoorten staat, leest u in mijn overzicht SAP-testen uitgelegd.

Performanceproblemen in SAP-programma's zijn zelden een verrassing.

Fiori-tegels geven een time-out als honderden gebruikers aan het begin van een dienst inloggen. Een maatwerkrapport bevriest omdat iemand een selectie op een volledig boekjaar zonder grenzen draaide tegen een zeer grote tabel. Achtergrondjobs overlappen bij de maandafsluiting en de boekingsrun breekt af.

Dit is voorspelbaar. De enige vraag is of het programma erop heeft getest, of dat de business het ontdekt terwijl er echte orders lopen.

Performancetesten binnen SAP Activate

1. 01

   Explore

   Breng performancerisico's in het ontwerp in kaart. Architectuur en de opzet van rapporten bepalen de uitkomst voordat er code is geschreven.

2. 02

   Realize

   Voer volume- en loadtests uit zodra de configuratie stabiliseert. Gedeeltelijke configuratie geeft misleidende resultaten.

3. 03

   Vóór UAT

   Rond de volledige performancecyclus af vóór UAT, niet als onderdeel ervan.

4. 04

   Cutover

   Keur de cutover goed tegen de vooraf afgesproken acceptatiecriteria, niet op basis van een mening.

5. 05

   Hypercare

   Volg de live KPI's 30 tot 60 dagen. De meeste regressies komen boven in de eerste afsluitcyclus.

In een ECC-systeem op een traditionele database betekende performancetesten het load-testen van de applicatieserver en de database: ABAP-runtime, SQL-performance en jobplanning. De front-end was SAP GUI, en die verraste zelden iemand.

Op S/4HANA, met Fiori-front-ends, extensies op SAP BTP en integratie via SAP Cloud Integration, hangt performance van meerdere lagen tegelijk af. Een trage Fiori-tegel kan een lange ABAP-aanroep zijn, een gateway-time-out, een OData-service die niet is ontworpen voor gelijktijdige verzoeken of netwerklatentie in een hybride opzet. Alleen de back-end testen vindt dat niet.

1. 01Tegel openenInlogpieken bij het begin van een dienst
2. 02OData-aanroepGateway-time-outs, services niet gebouwd voor concurrency
3. 03ABAP-verwerkingLanglopende ABAP-aanroepen
4. 04Database lezenSelecties zonder grenzen op grote tabellen
5. 05WeergavePlus netwerklatentie voor verre vestigingen

Eén responstijd, van begin tot eind gemeten

Performancetesten op SAP HANA heeft bij een conversie een eigen wending. Stabiele ECC-code gedraagt zich anders op een in-memorydatabase. Veel programma's worden veel sneller, terwijl sommige bij bepaalde datapatronen onverwachte profielen laten zien, dus conversiespecifieke regressie van de zware maatwerkcode is niet optioneel.

Integratiestromen brengen hun eigen risico. Stromen die in ontwikkeling met losse testberichten werkten, kunnen bij productievolumes in de wachtrij blijven hangen of stil falen. De symptomen lijken op iets anders: orders die af en toe mislukken, facturen die niet aansluiten, data die in het ene systeem staat en in het andere ontbreekt.

Performancetesten moet vóór de go-live gebeuren. De tests die ik als de belangrijke beschouw, zijn de concurrencytests: veel gebruikers en jobs die op hetzelfde moment dezelfde transacties, tabellen en services raken.

Eén gebruiker die een verkooporder in twee seconden aanmaakt, bewijst bijna niets. Dezelfde order terwijl 150 mensen orders invoeren, er op de achtergrond een leveringsrun draait en een interface inkomende berichten boekt, is de test die dag één voorspelt.

Deze tabel laat zien wat elk type test bewijst en wanneer u het uitvoert:

Test	Wat het bewijst	Wanneer uitvoeren	Wat het meestal vindt
Concurrency	Veel gebruikers en jobs kunnen tegelijk op dezelfde objecten werken	Realize, zodra de configuratie stabiel is, en opnieuw vóór UAT	Lock-wachttijden, inlogpieken, gateway-knelpunten
Load	Het systeem haalt de responstijden bij het verwachte piekvolume	Realize, nadat de concurrencyscripts werken	Trage OData-services, zware maatwerkrapporten
Stress	Waar het systeem breekt boven de ontwerpgrenzen	Vóór UAT, als groei wordt verwacht	Gaten in de sizing, wachtrijlimieten
Soak	Het systeem houdt urenlang een gelijkmatige belasting vol	Vóór UAT, bij voorkeur over een gesimuleerde afsluiting	Groeiend geheugengebruik, conflicten in jobketens bij herhaalde runs
End-to-end	Het volledige pad waarop een gebruiker wacht, haalt het doel	Naast de loadtests	Problemen die onzichtbaar zijn als elke laag apart wordt getest

Het sleutelwoord bij loadtesten is verwacht. U hebt echte transactievolumes, gebruikersaantallen en sessiepatronen nodig. Een loadtest die is gebouwd op volume-inschattingen waarvan iedereen al wist dat ze optimistisch waren, levert een geslaagd resultaat op dat niets betekent.

Soaktesten wordt het vaakst overgeslagen. Volumetesten in het algemeen is de shortcut die programma's het vaakst nemen als de planning wordt samengeperst, en waar ze het meest spijt van krijgen.

Script deze eerst. Ze dekken de meeste fouten die productie bereiken.

1. Dienstwissel en piek in inloggen. Als een paar honderd gebruikers tegelijk het Fiori-launchpad openen, pieken de authenticatie en de weergave van het launchpad. Een systeem dat buiten de piek prima werkt, kan in dat venster onbruikbaar zijn als gelijktijdige logins nooit zijn getest.
2. Maand- en jaarafsluiting. Hoge boekingsvolumes, jobketens met een strikte volgorde en een financieel team dat tegen een vaste deadline racet. Draai de jobketens van de afsluiting van begin tot eind tegen de volumes van de afsluitperiode, niet tegen gemiddelde dagelijkse aantallen.
3. Overlappende achtergrondjobs. Batchjobs worden meestal één voor één getest, en dat weerspiegelt de werkelijkheid niet. Eén slecht geoptimaliseerde job kan verschillende andere blokkeren, en de afsluiting loopt over haar venster heen.
4. Maatwerkrapporten zonder selectiegrenzen. Een rapport dat op testdata direct resultaat geeft, kan op een volledig boekjaar minuten draaien. Test typische selecties en het slechtste geval, en blokkeer de selecties zonder grenzen.
5. Gebruikers in meerdere regio's. Netwerklatentie raakt elke transactie. RISE verplaatst de hosting naar SAP, maar de latentie hangt nog steeds af van de regio die u kiest en de routering naar uw gebruikers, dus test vanaf de vestigingen die het verst weg liggen.

Mijn gids voor de migratie van ECC naar S/4HANA beschrijft waar conversietesten in het bredere plan past.

Testdata op productieniveau

De data bepaalt of dit alles iets betekent. Ik sta op gemaskeerde data op productieniveau: productievolume en productierealisme, met persoonsgegevens en gevoelige velden gemaskeerd.

Een klant met 200.000 openstaande orderregels gedraagt zich anders dan een klant met 5.000. Filters die in een dunne testclient direct resultaat geven, lopen in productie in een time-out. Vul het volume aan voor de risicovolle gebieden, gebruik een representatieve mix van transacties en doe waar mogelijk echte interface-aanroepen.

Hoe u die data veilig krijgt, via kopieën, tools voor selectieve testdata en maskering, staat in mijn gids over SAP-testdatamanagement. Plan de verversing vóór de eerste performancecyclus, want die duurt langer dan de meeste testplannen aannemen.

Spreek de criteria in de Prepare-fase af met de business, voordat er een test draait. Elk criterium noemt de transactie of job, de belasting en de drempel.

Deze voorbeelden laten de vorm zien. Stel uw eigen getallen vast op basis van operationele behoeften:

Item	Belastingsconditie	Drempel voor geslaagd	Eigenaar
Verkooporder aanmaken (VA01 of Fiori-app)	150 gelijktijdige gebruikers voor orderinvoer	Onder 3 seconden voor 95% van de transacties	Proceseigenaar order-to-cash
Eerste keer laden van het Fiori-launchpad bij het begin van een dienst	Piek in gelijktijdige logins voor de grootste dienst	Onder 5 seconden voor 95% van de gebruikers	Lead IT-operations
Jobketen van de maandafsluiting	Volumes van de afsluitperiode, volledige volgorde	Afgerond binnen het afgesproken afsluitvenster, zonder afbrekingen	Financial controller
Interface voor inkomende orders	Piekvolume aan berichten per uur	Geen achterstand in de wachtrij ouder dan 15 minuten	Integratielead
Maatwerkrapport met hoog volume	Volledig productievolume, typische selectie	Onder 60 seconden; selecties zonder grenzen geblokkeerd	Rapporteigenaar

"Het systeem moet snel genoeg zijn voor de bedrijfsvoering" kan niet worden getest of geaccepteerd. Criteria wijzigen nadat de resultaten binnen zijn, maakt het hebben ervan zinloos.

Als het systeem slaagde omdat UAT-gebruikers zeiden dat het snel aanvoelde, hebt u een mening, geen acceptatiecriterium. Maak de resultaten een formele gate vóór de cutover, zoals mijn gids over SAP-quality gates beschrijft. Het totale cyclusplan, met instap- en exitcriteria voor elke testfase, hoort in uw S/4HANA-teststrategie.

Tools voor SAP-performancetesten

Een performancetest heeft drie dingen nodig: een loadgenerator die SAP-protocollen kan aansturen, monitoring aan de SAP-kant en een plek om testgevallen en resultaten te beheren. LoadRunner is de loadtool die ik teams heb laten gebruiken in SAP-programma's. Noem de tool vroeg in het testplan, want licenties, loadgenerators en scriptvaardigheden kosten allemaal tijd om te regelen.

De belangrijkste opties in 2026:

Tool	Rol	Wat u moet weten
OpenText Professional Performance Engineering	Loadgeneratie	Het product dat voorheen LoadRunner Professional heette. De protocolbundels dekken SAP, SAP GUI en SAP Web
Tricentis NeoLoad	Loadgeneratie	Tricentis noemt ondersteuning voor SAP GUI, Fiori, RFC en IDoc, en het kan assets van Tricentis Tosca hergebruiken
Apache JMeter	Loadgeneratie	Open source. Stuurt HTTP-verkeer aan, zoals Fiori- en OData-aanroepen
SAP Cloud ALM	Testmanagement	Bereidt handmatige en geautomatiseerde testgevallen voor, voert ze uit en volgt defecten. Genereert zelf geen belasting
SAP Solution Manager	Testmanagement	De mainstream maintenance eindigt op 31 december 2027, dus plan nieuw werk in Cloud ALM

Voor een breder beeld van functionele tools en automatiseringstools, zie mijn vergelijking van SAP-tools voor testen en validatie. De tool doet er minder toe dan de scripts, de data en de criteria.

RISE with SAP verdeelt de verantwoordelijkheid

Onder RISE with SAP is SAP verantwoordelijk voor de infrastructuur: sizing, hyperscalerregio, netwerk en beschikbaarheid van het platform. De klant en de partner zijn verantwoordelijk voor de applicatielaag.

Het RISE-document over rollen en verantwoordelijkheden van SAP is daar duidelijk over. Het uitvoeren van loadtests en het tunen van dure SQL-statements zijn SAP Cloud Application Services tegen meerprijs. Neemt u die niet af, dan doet de klant het werk.

Een veelvoorkomende fout in RISE-programma's is de aanname dat SAP performanceproblemen wel opvangt omdat SAP de infrastructuur beheert. SAP vangt infrastructuurproblemen op. Leg de verdeling vast in het charter en het testplan:

1. SAP: beschikbaarheid van de infrastructuur en respons op platformniveau
2. Partner: applicatieperformance onder de gedefinieerde belasting, inclusief extensies en integratiestromen
3. Klant: uitkomsten op procesniveau, zoals de looptijd van de afsluiting en de orderdoorvoer, en het acceptatiebesluit

Public cloud versmalt de scope

Op de public edition van de cloud-ERP van SAP draait het systeem op een gedeeld platform dat SAP beheert. Vraag SAP schriftelijk of een loadtest tegen een tenant is toegestaan en welke aankondiging nodig is, voordat u er een plant.

Uw testen verschuift dan naar wat van u is: eigen integraties, extensies, rapporten met hoog volume, de volgorde van de afsluiting en het netwerkpad vanaf uw vestigingen. Performanceproblemen van het platform gaan naar SAP-support.

Veelgemaakte fouten

1. Functioneel testen behandelen als performancetesten. Functionele tests bewijzen dat een transactie het juiste resultaat geeft. Ze zeggen niets over 150 mensen die haar tegelijk uitvoeren.
2. Performance overlaten aan Basis. Basis is verantwoordelijk voor sizing en jobplanning. Basis is niet verantwoordelijk voor het ontwerp van rapporten, de architectuur van OData-services of het ontwerp van integratiestromen, en die bepalen de applicatieperformance.
3. Het eigenaarschap alleen bij QA leggen. QA voert tests uit en rapporteert resultaten, maar de beslissingen die performanceproblemen veroorzaken, worden in het ontwerp genomen. Een testlead of architect op programmaniveau heeft de bevoegdheid nodig om die vroeg te betwisten, en de RACI moet zeggen wie de go-live op grond van performance kan tegenhouden.
4. Gaten accepteren als bekende problemen. De meeste programma's met performanceproblemen in productie hebben het testen niet overgeslagen. Ze testten zonder afgesproken criteria, of ze testten en accepteerden de fouten daarna onder druk van de planning.

Schrijf de vijf of zes acceptatiecriteria voor uw risicovolste transacties en jobs, met een eigenaar met naam voor elk. Kunt u de tabel hierboven niet invullen, dan bent u niet klaar om te testen, en hebt u het eerste gat gevonden.

Controleer daarna twee dingen: dat er een verversing met gemaskeerde data op productievolume in het plan staat, en dat de concurrencycyclus klaar is voordat UAT begint.

Wilt u een onafhankelijke blik op een plan voor performancetesten of een go-livebesluit, dan help ik organisaties daarbij. U kunt hier contact met mij opnemen.

Wat is SAP-performancetesten?

Het controleert hoe SAP zich gedraagt onder realistische belasting: responstijden voor gebruikerstransacties, looptijden van achtergrondjobs, doorvoer van interfaces en gebruik van resources als veel mensen tegelijk werken. Het moet vóór de go-live gebeuren.

Functionele juistheid en performance zijn verschillende eigenschappen. Een transactie die voor één gebruiker correct is, kan voor 200 gebruikers een time-out geven.

Wanneer moet performancetesten beginnen in een SAP-programma?

Het in kaart brengen van risico's begint in Explore, omdat architectuurkeuzes de performance-uitkomsten bepalen. Het actieve testen begint in Realize, zodra de configuratie stabiel genoeg is dat de resultaten iets betekenen.

Rond de laatste cyclus af vóór UAT, niet tijdens. Performancedefecten die in UAT worden gevonden, persen de planning samen en zetten druk om ze als bekende problemen te accepteren.

Wat is het verschil tussen loadtesten en concurrencytesten in SAP?

Loadtesten controleert de responstijden bij het verwachte piekvolume. Concurrencytesten controleert wat er gebeurt als veel gebruikers en jobs op hetzelfde moment op dezelfde transacties, tabellen en services werken. Daar komen lock-wachttijden, inlogpieken en gateway-knelpunten boven.

In mijn ervaring zijn de concurrencytests de belangrijke. Voer ze eerst uit en bouw daar de volledige loadtest bovenop.

Welke testdata moet SAP-performancetesten gebruiken?

Gemaskeerde data op productieniveau. Dat betekent productievolume en productierealisme, met persoonsgegevens en gevoelige velden gemaskeerd. Dunne testdata verbergt de trage filters, zware rapporten en lange looptijden van jobs die op dag één opduiken.

Welke tools worden gebruikt voor SAP-performancetesten?

Loadgenerators zoals OpenText Professional Performance Engineering (voorheen LoadRunner Professional), Tricentis NeoLoad en Apache JMeter genereren de belasting. SAP Cloud ALM of SAP Solution Manager beheren de testgevallen en resultaten, en monitoring aan de SAP-kant laat zien wat het systeem onder belasting deed.

Wie is verantwoordelijk voor performancetesten bij RISE with SAP?

SAP is verantwoordelijk voor de infrastructuur: sizing, regio, netwerk en beschikbaarheid van het platform. Het RISE-document over rollen en verantwoordelijkheden van SAP laat het uitvoeren van loadtests en het tunen van dure SQL-statements bij de klant, tenzij SAP Cloud Application Services tegen meerprijs worden afgenomen.

De klant en de partner zijn verantwoordelijk voor de applicatieperformance en het acceptatiebesluit. Leg de verdeling vast in de acceptatiecriteria, zodat elke drempel een eigenaar heeft.