SAP-performancetesten: wat IT-leiders moeten weten

SAP-performancetesten bewijzen vóór de go-live dat kritieke transacties, achtergrondjobs en interfaces onder productievolumes de afgesproken responstijden halen. Begin in het ontwerp, voer volume- en belastingstests uit in Realize zodra de configuratie stabiel is, rond de cyclus af vóór de gebruikersacceptatietest (UAT) en maak van de resultaten een poort voor de cutover. Deze gids is voor CIO's, programmadirecteuren en testleads van S/4HANA-programma's, inclusief RISE with SAP. Hij behandelt wat u test, wie het in handen heeft, hoe u acceptatiecriteria opstelt en wat er in de cloud verandert. Begin bij de tabel met acceptatiecriteria: als u die niet kunt invullen, bent u nog niet klaar om te testen.

Performanceproblemen in SAP-programma's worden bijna altijd pas na de go-live gevonden. Fiori-tegels lopen op een time-out als 300 gebruikers bij ploegwissel inloggen. Z-rapporten lopen vast omdat iemand een onbegrensde boekjaarselectie losliet op een tabel met 50 miljoen records. Achtergrondjobs overlappen tijdens de maandafsluiting en de boekingsrun breekt af.

Performanceproblemen in SAP-programma's komen zelden als een verrassing. De meeste waren voorspelbaar, er was alleen geen rekening mee gehouden. Het gebruikelijke patroon: het functioneel testen was grondig. Het volumetesten was gepland en werd daarna doorgeschoven toen de planning krap werd. De gevolgen kwamen in de eerste weken van het live gebruik.

Dit zijn geen randgevallen. Ze zijn voorspelbaar. De enige vraag is of het programma erop heeft getest, of dat de business ze ontdekt terwijl er echte orders draaien.

Performancetesten door SAP Activate heen

1. 01

   Explore

   Identificeer performancerisico's in het ontwerp. Architectuur en rapportopzet bepalen de uitkomst voordat er code is geschreven.

2. 02

   Realize

   Voer volume- en belastingstests uit naarmate de configuratie stabiliseert. Gedeeltelijke configuratie geeft misleidende resultaten.

3. 03

   Pre-UAT

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

4. 04

   Cutover

   Keur de cutover goed op basis van de vooraf afgesproken acceptatiecriteria, niet op basis van meningen.

5. 05

   Hypercare

   Volg de live KPI's gedurende 30 tot 60 dagen. De meeste achteruitgang komt aan het licht in de eerste afsluitcyclus.

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

Op S/4HANA, met Fiori-front-ends, uitbreidingen op SAP BTP en integratie via SAP Cloud Integration (CPI), 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 het niet. Het hele pad testen wel.

1. 01Tegel startenInlogpieken bij de start van de dienst
2. 02OData-aanroepGateway-time-outs, services die niet zijn gebouwd op gelijktijdigheid
3. 03ABAP-verwerkingLanglopende ABAP-aanroepen
4. 04DatabaselezingOnbegrensde selecties op grote tabellen
5. 05WeergavePlus netwerklatentie voor verre locaties

Eén responstijd, end-to-end gemeten

Integratiestromen brengen hun eigen risico mee. Stromen die in ontwikkeling en QA werkten met losse testberichten, kunnen bij productievolumes oplopen in een wachtrij of ongemerkt falen. Als berichtenwachtrijen niet zijn gedimensioneerd voor de echte belasting, lopen vertragingen op. De symptomen lijken op iets anders: onregelmatige orderfouten, afwijkende facturen, data die in het ene systeem aanwezig is en in het andere ontbreekt.

1. Belastingstests controleren het gedrag onder het verwachte volume. Het sleutelwoord is verwacht. U hebt echte transactievolumes, gebruikersaantallen en gelijktijdige sessies nodig. Veel belastingstests mislukken omdat ze volumeschattingen gebruikten waarvan iedereen al wist dat ze optimistisch waren.
2. Stresstests gaan voorbij de ontwerpgrenzen om te vinden waar het systeem breekt. Als de volumes over achttien maanden verdubbelen, vertellen ze u of de architectuur het aankan en of de dimensionering een probleem wordt vóór de volgende infrastructuurreview.
3. Soaktests draaien lange tijd een constante belasting om problemen bloot te leggen die zich in de loop van de tijd opbouwen: geheugenlekken, fragmentatie en conflicten tussen jobketens bij herhaalde runs. Het is de test die het vaakst wordt overgeslagen, en de test die de hieronder beschreven fout bij de maandafsluiting had opgemerkt.
4. End-to-end testen volgt het volledige pad dat een gebruiker aflegt: tegel starten, OData-aanroep, ABAP-verwerking, databaselezing, weergave. Het is de enige manier om problemen te vinden die onzichtbaar zijn wanneer elke laag afzonderlijk wordt getest.

Ploegwissel en piekmomenten bij het inloggen. Als 200 gebruikers om 8 uur 's ochtends de Fiori-launchpad openen, pieken authenticatie en het opbouwen van de launchpad. Een systeem dat buiten de piek prima draait, kan in dat tijdvak onbruikbaar zijn als gelijktijdig inloggen nooit is getest. In productie, retail en de financiële sector veroorzaken inlogpieken de meest zichtbare klachten op dag één.

Maand- en jaarafsluiting. Het scenario met het hoogste risico bij de meeste programma's: boekingen in groot volume, jobketens met een strikte volgorde en een financeteam dat tegen een vaste deadline werkt. Laat de jobketens van de afsluiting end-to-end draaien met de volumes van de afsluitperiode, niet met gemiddelde dagaantallen.

Batchjobs worden meestal afzonderlijk getest, wat de werkelijkheid niet weerspiegelt. Bij de maandafsluiting piekt de achtergrondverwerking en draaien veel programma's parallel op dezelfde resources. Eén slecht geoptimaliseerde job kan er vijf blokkeren, en de afsluiting loopt door buiten het afgesproken venster.

Conversie van ECC naar S/4HANA. Stabiele ECC-code gedraagt zich anders op HANA. Veel programma's worden veel sneller; sommige vertonen onverwachte profielen bij bepaalde datapatronen. Conversiespecifieke regressietests zijn niet optioneel. Mijn gids voor de migratie van ECC naar S/4HANA laat zien waar dit in het conversieplan past.

Gebruikers in meerdere regio's. Netwerklatentie raakt elke transactie. Een verkooporder die in het hostingland twee seconden duurt, kan 3.000 mijl verderop kapot aanvoelen als niemand van daaruit heeft getest. 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.

Spreek de criteria af met de business in de Prepare-fase, vóór er een test draait. Elk criterium noemt de transactie of job, de belasting en de drempel. Deze voorbeelden laten de vorm zien; bepaal uw eigen getallen vanuit de operationele behoeften:

Onderdeel	Belasting	Slaagdrempel	Eigenaar
Verkooporder aanmaken (VA01 of Fiori-app)	150 gelijktijdige gebruikers die orders invoeren	Binnen 3 seconden voor 95% van de transacties	Procesowner order-to-cash
Eerste keer laden van de Fiori-launchpad bij start van de dienst	Piek aan gelijktijdige logins voor de grootste ploeg	Binnen 5 seconden voor 95% van de gebruikers	Lead IT-operatie
Jobketen maandafsluiting	Volumes van de afsluitperiode, volledige reeks	Rondt af binnen het afgesproken afsluitvenster zonder afbrekingen	Financieel controller
Interface voor inkomende orders	Piekvolume aan berichten per uur	Geen wachtrijachterstand ouder dan 15 minuten	Integratielead
Maatwerkrapport met hoog volume	Volledig productievolume, gebruikelijke selectie	Binnen 60 seconden; onbegrensde selecties geblokkeerd	Rapporteigenaar

“Het systeem moet snel genoeg zijn voor de bedrijfsvoering” kan niet worden getest of geaccepteerd. Criteria wijzigen nadat de resultaten binnen zijn, ondermijnt het doel van criteria.

Vraag bij naam om elk van deze punten:

Verwachting	Wat er moet worden opgeleverd	Waarom het ertoe doet
Performance-servicelevels	Drempels per transactie, interface en job, met slagen en falen	Voorkomt dat meningen in de UAT de overhand krijgen op het bewijs
Risicogebaseerde scope	Prioritering op basis van gebruikersvolume, integratiepunten en data-afhankelijkheid	Zet testcycli in op de werklasten die ertoe doen
Deelname vanuit alle teams	Basis, infrastructuur, functioneel, security en integratie aanwezig tijdens de runs	Voorkomt schuld afschuiven wanneer er gaten opduiken
Tools en omgevingen gereed	Belastinggeneratoren (OpenText LoadRunner, Tricentis NeoLoad, Apache JMeter), monitoring en datarefreshes zijn geregeld voordat de cycli beginnen	Maakt de simulatie realistisch
Realistische testdata	Stamgegevens in productievolume, echte interface-aanroepen, een representatieve transactiemix	Zorgt dat resultaten het gedrag bij de go-live voorspellen
Performancerapportage	Belastingsmix, responstijden, CPU en geheugen, jobruntimes, foutpercentages	Geeft de goedkeuring van de cutover een bewijsbasis
Monitoringplan na de go-live	KPI's om de eerste 30 tot 60 dagen te volgen	Bevestigt dat het live systeem binnen de geteste grenzen blijft

Vier fouten komen het vaakst voor, zelfs bij grote ondernemingen met volwassen deliverymodellen.

Functioneel testen behandelen als performancetesten. Functionele tests bewijzen dat een transactie het juiste resultaat geeft. Ze zeggen niets over 150 mensen die hem tegelijk draaien.

Testen met kleine datavolumes. Een klant met 200.000 openstaande orderregels gedraagt zich anders dan een klant met 5.000. Filters die in test direct antwoorden, lopen in productie op een time-out. Vul de risicovolle gebieden met realistisch volume.

Performance overlaten aan Basis. Basis is verantwoordelijk voor dimensionering en jobplanning. Het is niet verantwoordelijk voor rapportontwerp, de architectuur van OData-services of het ontwerp van integratiestromen, en juist die bepalen de applicatieperformance.

Het eigenaarschap alleen bij QA leggen. QA voert tests uit en rapporteert resultaten. De beslissingen die performanceproblemen veroorzaken, worden in het ontwerp genomen door functionele, technische en Basis-teams. Een testlead of architect op programmaniveau heeft de bevoegdheid nodig om die beslissingen vroeg te betwisten, en de RACI moet zeggen wie de go-live op grond van performance kan blokkeren.

RISE verdeelt de verantwoordelijkheid

Onder RISE with SAP is SAP verantwoordelijk voor de infrastructuur: dimensionering, hyperscaler-regio, netwerk en beschikbaarheid van het platform. De klant en de partner zijn verantwoordelijk voor de applicatielaag. Het document met rollen en verantwoordelijkheden voor RISE van SAP zegt het ronduit: het opsporen en tunen van dure SQL-statements blijft bij de klant, tenzij u de aanvullende applicatieservices van SAP afneemt.

Een veelvoorkomende fout bij RISE-programma's is de aanname dat SAP performanceproblemen vangt omdat het de infrastructuur beheert. SAP vangt infrastructuurproblemen. SAP vangt geen slecht ontworpen OData-service, geen inefficiënte ABAP-job en geen integratiestroom die niet schaalt. Leg de verdeling vast in het charter en het testplan:

1. SAP: beschikbaarheid van de infrastructuur en responstijd op platformniveau
2. Partner: applicatieperformance onder de gedefinieerde belasting, inclusief uitbreidingen en integratiestromen
3. Klant: resultaten op procesniveau, zoals de looptijd van de afsluiting en de doorvoer van orders, en het acceptatiebesluit

Public Edition en GROW verkleinen de scope

Bij S/4HANA Cloud Public Edition, meestal afgenomen via GROW with SAP, voert SAP performancetests uit op zijn multi-tenantplatform als onderdeel van zijn eigen productstandaard en verwacht het niet dat klanten het gedeelde systeem aan belastingstests onderwerpen. Uw testwerk verschuift naar wat van u is: maatwerkintegraties, uitbreidingen, rapporten en analytics met hoog volume, de afsluit- en consolidatiereeks en het netwerkpad vanaf uw locaties. Performanceproblemen op het platform zelf gaan naar de SAP-support.

AI helpt bij scripts, niet bij architectuur

Leveranciers van belastingstesttools voegen AI toe voor scriptonderhoud en analyse van resultaten, wat helpt bij programma's waar de applicatie tussen de cycli verandert. Toets de beweringen op uw eigen landschap voordat u ervoor betaalt. SAP Cloud ALM kan helpen testcases en requirements te genereren, en AI-assistenten kunnen scenario-schetsen opstellen op basis van procesbeschrijvingen.

Niets daarvan lost architectuur op. AI zal u niet vertellen dat de OData-service anders had moeten worden ontworpen, of dat een rapport te zwaar is voor zijn volumes. Die afwegingen maken nog steeds mensen, in het ontwerp, voordat er een test draait.

De meeste programma's met performanceproblemen in productie hebben niet alle tests overgeslagen. Ze testten zonder afgesproken criteria, of ze testten en accepteerden de tekortkomingen daarna als bekende issues onder tijdsdruk. De discipline zit in de criteria en in het afdwingen ervan, niet in de tool. Voor de plek van performance tussen andere testsoorten, zie mijn vergelijking van SAP-test- en validatietools en mijn gids over SAP quality gates.

Wat is SAP-performancetesten en waarom is het belangrijk?

Het controleert hoe SAP zich gedraagt onder realistische belasting: responstijden van gebruikerstransacties, looptijden van achtergrondjobs, doorvoer van interfaces en resourcegebruik bij gelijktijdig werk.

Functionele juistheid en performance zijn verschillende eigenschappen. Een transactie die voor één gebruiker correct werkt, kan voor 200 gebruikers op een time-out lopen. Een job die op testdata in tien minuten draait, kan op productievolumes uren duren. Dat na de go-live ontdekken verstoort de bedrijfsvoering, dwingt tot noodwijzigingen en schaadt het vertrouwen van gebruikers op het moment dat de adoptie het kwetsbaarst is.

Wanneer moet performancetesten beginnen in een SAP-programma?

Risico-identificatie begint in Explore, omdat architectuurkeuzes de performance bepalen. Actief testen begint in Realize, zodra de configuratie stabiel genoeg is om resultaten betekenis te geven. Gedeeltelijke configuratie geeft misleidende cijfers.

Rond de laatste cyclus af vóór de UAT, niet tijdens de UAT. Performancedefecten die in de UAT opduiken, persen de resterende planning samen en creëren druk om ze als bekende issues te accepteren.

Wie moet eigenaar zijn van SAP-performancetesten?

Het programma, niet alleen QA. QA voert uit en rapporteert, maar de beslissingen die performance bepalen, worden in het ontwerp genomen door functionele, technische en Basis-teams. Een centrale architect of testlead op programmaniveau heeft de bevoegdheid nodig om die beslissingen vroeg te betwisten.

Leg het expliciet vast in de RACI: wie de acceptatiecriteria goedkeurt, wie verantwoordelijk is voor herstel wanneer criteria niet worden gehaald en wie de go-live kan blokkeren op grond van performance.

Hoe verandert RISE with SAP de verantwoordelijkheid voor performancetesten?

SAP is verantwoordelijk voor de infrastructuur: dimensionering, regio, netwerk en beschikbaarheid van het platform. De klant en de partner zijn verantwoordelijk voor de applicatieperformance: configuratie, uitbreidingen, OData- en Fiori-ontwerp, integratiestromen en proces-KPI's. In het document van SAP met rollen en verantwoordelijkheden voor RISE blijft SQL-tuning bij de klant, tenzij aanvullende SAP-services worden afgenomen.

Leg de verdeling vast in de acceptatiecriteria, zodat elke drempel een eigenaar heeft.

Wat zijn de meest voorkomende performanceproblemen met SAP Fiori?

Vier patronen dekken de meeste gevallen. Inlogpieken bij de start van de dienst, wanneer authenticatie en het opbouwen van de launchpad pieken. OData-services die grote resultaatsets teruggeven of per interactie meerdere back-end-aanroepen doen. De gatewaylaag die zelf een knelpunt wordt, en daarom tijdens tests moet worden gemonitord. En maatwerk- of sterk aangepaste apps, waar standaardaannames over performance niet gelden.

Hoe bepaalt u performance-acceptatiecriteria voor SAP?

Noem de transactie, de belasting en de drempel. Bijvoorbeeld: “Het aanmaken van een order is bij 95% van de transacties binnen 3 seconden klaar met 150 gelijktijdige gebruikers in de rol orderinvoer.” Dat is testbaar.

“Het systeem moet snel genoeg zijn” is dat niet. Spreek criteria af met de business in de Prepare-fase, op basis van echte operationele behoeften, en wijzig ze niet nadat de resultaten binnen zijn.

Wat gebeurt er als performancetesten wordt overgeslagen of ingekort?

Problemen komen in productie aan het licht: jobs die hun venster overschrijden en andere blokkeren, Fiori-apps die op piekmomenten op een time-out lopen, een maandafsluiting die twee keer zo lang duurt en rapportagedeadlines mist, interfacewachtrijen die oplopen.

Gebruikers die in hun eerste weken performanceproblemen tegenkomen, vormen een negatief beeld van het systeem dat moeilijk om te keren is. En noodherstel tijdens live gebruik kost meer dan het testen had gekost, omdat wat in Realize een ontwerpbeslissing was, een urgente architectuurwijziging wordt.