Test di performance SAP: cosa devono sapere i leader IT

Il test di performance SAP dimostra, prima del go-live, che le transazioni critiche, i job in background e le interfacce rispettano i tempi di risposta concordati con i volumi di produzione. Lo si avvia in fase di progettazione, si eseguono i test di volume e di carico in Realize quando la configurazione è stabile, si chiude il ciclo prima del test di accettazione utente (UAT) e si fa dei risultati un gate di cutover. Questa guida è per CIO, direttori di programma e responsabili dei test nei programmi S/4HANA, compreso RISE with SAP. Spiega che cosa testare, chi ne è responsabile, come scrivere i criteri di accettazione e che cosa cambia nel cloud. Parta dalla tabella dei criteri di accettazione: se non riesce a compilarla, il programma non è pronto per testare.

I problemi di performance nei programmi SAP vengono quasi sempre scoperti dopo il go-live. Le tile Fiori vanno in timeout quando 300 utenti fanno il login al cambio turno. I report Z si bloccano perché qualcuno ha lanciato una query sull'intero esercizio, senza limiti di selezione, su una tabella con 50 milioni di record. I job in background si sovrappongono durante la chiusura mensile e il run di contabilizzazione si interrompe.

I problemi di performance nei programmi SAP raramente arrivano di sorpresa. Quasi tutti erano prevedibili, semplicemente non erano stati pianificati. Lo schema è il solito: i test funzionali erano accurati. Il test di volume era pianificato, poi è stato rimandato quando il calendario si è compresso. Le conseguenze sono arrivate nelle prime settimane di esercizio in produzione.

Non sono casi limite. Sono prevedibili. L'unica domanda è se il programma li ha testati o se il business li scopre con gli ordini veri in corso.

Test di performance lungo SAP Activate

1. 01

   Explore

   Individuare i rischi di performance nella progettazione. Architettura e struttura dei report decidono l'esito prima che venga scritto il codice.

2. 02

   Realize

   Eseguire i test di volume e di carico man mano che la configurazione si stabilizza. Una configurazione parziale produce risultati fuorvianti.

3. 03

   Pre-UAT

   Completare l'intero ciclo di performance prima dell'UAT, non durante.

4. 04

   Cutover

   Approvare il cutover in base ai criteri di accettazione concordati in anticipo, non in base alle opinioni.

5. 05

   Hypercare

   Monitorare i KPI in produzione per 30-60 giorni. La maggior parte delle regressioni emerge nel primo ciclo di chiusura.

In un sistema ECC su un database tradizionale, fare il test di performance significava sottoporre a test di carico l'application server e il database: runtime ABAP, performance SQL, schedulazione dei job. Il front end era SAP GUI, che raramente riservava sorprese.

Su S/4HANA, con front end Fiori, estensioni su SAP BTP e integrazione tramite SAP Cloud Integration (CPI), le performance dipendono da più livelli contemporaneamente. Una tile Fiori lenta può essere una chiamata ABAP lunga, un timeout del gateway, un servizio OData non progettato per richieste concorrenti o la latenza di rete in un'architettura ibrida. Testare solo il back end non la troverà. Testare l'intero percorso sì.

1. 01Avvio della tilePicchi di login all'inizio del turno
2. 02Chiamata ODataTimeout del gateway, servizi non progettati per la concorrenza
3. 03Elaborazione ABAPChiamate ABAP di lunga durata
4. 04Lettura dal databaseSelezioni senza limiti su tabelle grandi
5. 05RenderingPiù la latenza di rete per le sedi lontane

Un unico tempo di risposta, misurato end to end

I flussi di integrazione aggiungono un rischio proprio. Flussi che funzionavano in sviluppo e in QA con singoli messaggi di test possono accodarsi o fallire in silenzio ai volumi di produzione. Se le code di messaggi non sono dimensionate per il carico reale, i ritardi si accumulano. I sintomi sembrano altro: errori intermittenti sugli ordini, fatture che non quadrano, dati presenti in un sistema e assenti in un altro.

1. Il test di carico verifica il comportamento al volume atteso. La parola chiave è atteso. Servono volumi reali di transazioni, numeri reali di utenti e di sessioni concorrenti. Molti test di carico falliscono perché hanno usato stime di volume che tutti sapevano già essere ottimistiche.
2. Lo stress test spinge oltre i limiti di progetto per scoprire dove il sistema cede. Se i volumi raddoppieranno in diciotto mesi, dice se l'architettura reggerà e se il dimensionamento diventerà un problema prima della prossima revisione dell'infrastruttura.
3. Il soak test applica un carico costante per un periodo prolungato per far emergere i problemi che si accumulano nel tempo: memory leak, frammentazione e contesa tra catene di job su esecuzioni ripetute. È il test saltato più spesso, e quello che avrebbe intercettato il guasto di fine mese descritto più sotto.
4. Il test end-to-end segue l'intero percorso di un utente: avvio della tile, chiamata OData, elaborazione ABAP, lettura dal database, rendering. È l'unico modo per trovare i problemi che restano invisibili quando ogni livello viene testato da solo.

Cambio turno e picco di login. Quando 200 utenti aprono il launchpad Fiori alle 8 del mattino, il carico su autenticazione e rendering del launchpad si impenna. Un sistema che va bene fuori dai picchi può diventare inutilizzabile in quella finestra se i login concorrenti non sono mai stati testati. Nel manifatturiero, nel retail e nei servizi finanziari, i picchi di login producono le lamentele più visibili del primo giorno.

Chiusura mensile e di fine anno. Lo scenario a più alto rischio nella maggior parte dei programmi: contabilizzazioni ad alto volume, catene di job con sequenze rigide e un team finance in corsa contro una scadenza fissa. Esegua le catene di job di chiusura end to end con i volumi del periodo di chiusura, non con i conteggi medi giornalieri.

I job batch di solito vengono testati in isolamento, il che non rispecchia la realtà. A fine mese l'elaborazione in background tocca il picco e molti programmi girano in parallelo sulle stesse risorse. Un solo job ottimizzato male può bloccarne altri cinque, e la chiusura sfora la sua finestra.

Conversione da ECC a S/4HANA. Il codice ECC stabile si comporta in modo diverso su HANA. Molti programmi diventano molto più veloci; alcuni producono profili inattesi con particolari schemi di dati. I test di regressione specifici per la conversione non sono facoltativi. La mia guida alla migrazione da ECC a S/4HANA spiega dove si colloca questo passaggio nel piano di conversione.

Utenti in più regioni. La latenza di rete incide su ogni transazione. Un ordine di vendita che richiede due secondi nel paese di hosting può sembrare rotto a 3.000 miglia di distanza se nessuno ha testato da lì. RISE sposta l'hosting a SAP, ma la latenza dipende comunque dalla regione scelta e dall'instradamento verso i suoi utenti.

Concordi i criteri con il business nella fase Prepare, prima che parta qualsiasi test. Ciascuno indica la transazione o il job, il carico e la soglia. Questi esempi mostrano la forma; definisca i suoi numeri in base alle esigenze operative:

Elemento	Condizione di carico	Soglia di superamento	Responsabile
Creazione dell'ordine di vendita (VA01 o app Fiori)	150 utenti concorrenti per l'inserimento ordini	Meno di 3 secondi per il 95% delle transazioni	Process owner order-to-cash
Primo caricamento del launchpad Fiori all'inizio del turno	Picco di login concorrenti per il turno più numeroso	Meno di 5 secondi per il 95% degli utenti	Responsabile IT operations
Catena di job della chiusura mensile	Volumi del periodo di chiusura, sequenza completa	Si completa entro la finestra di chiusura concordata, senza interruzioni	Financial controller
Interfaccia ordini in ingresso	Picco orario di volume dei messaggi	Nessun arretrato in coda più vecchio di 15 minuti	Responsabile integrazione
Report custom ad alto volume	Volume completo dei dati di produzione, selezione tipica	Meno di 60 secondi; selezioni senza limiti bloccate	Responsabile del report

«Il sistema deve essere abbastanza veloce per le operazioni di business» non si può testare né accettare. Cambiare i criteri dopo l'arrivo dei risultati vanifica lo scopo di averli.

Chieda ciascuno di questi elementi per nome:

Aspettativa	Che cosa va consegnato	Perché conta
Livelli di servizio sulle performance	Soglie per transazione, interfaccia e job, con criteri di superamento e di fallimento	Impedisce che le opinioni dell'UAT prevalgano sulle evidenze
Perimetro basato sul rischio	Priorità in base al numero di utenti, ai punti di integrazione e alla dipendenza dai dati	Concentra i cicli di test sui carichi di lavoro che contano
Partecipazione di più team	Basis, infrastruttura, funzionale, sicurezza e integrazione presenti durante le esecuzioni	Evita lo scaricabarile quando emergono lacune
Strumenti e ambienti pronti	Generatori di carico (OpenText LoadRunner, Tricentis NeoLoad, Apache JMeter), monitoraggio e aggiornamenti dei dati predisposti prima dell'inizio dei cicli	Rende realistica la simulazione
Dati di test realistici	Dati anagrafici con volumi di produzione, chiamate reali alle interfacce, mix di transazioni rappresentativo	Fa sì che i risultati prevedano il comportamento al go-live
Reportistica sulle performance	Mix di carico, tempi di risposta, CPU e memoria, tempi di esecuzione dei job, tassi di errore	Dà all'approvazione del cutover una base di evidenze
Piano di monitoraggio post go-live	KPI da tenere sotto controllo nei primi 30-60 giorni	Conferma che il sistema in produzione resta entro i limiti testati

Quattro errori ricorrono più spesso, anche nelle grandi aziende con modelli di delivery maturi.

Trattare i test funzionali come test di performance. I test funzionali dimostrano che una transazione dà il risultato giusto. Non dicono nulla su 150 persone che la eseguono contemporaneamente.

Testare con volumi di dati ridotti. Un cliente con 200.000 righe d'ordine aperte si comporta in modo diverso da uno con 5.000. Filtri che in test rispondono all'istante vanno in timeout in produzione. Generi volumi di dati per le aree ad alto rischio.

Lasciare le performance al team Basis. Il Basis è responsabile di dimensionamento e schedulazione dei job. Non è responsabile del design dei report, dell'architettura dei servizi OData né della progettazione dei flussi di integrazione, e sono questi a determinare le performance dell'applicazione.

Affidare la responsabilità al solo QA. Il QA esegue i test e riporta i risultati. Le decisioni che causano i problemi di performance vengono prese in fase di progettazione dai team funzionale, tecnico e Basis. Un responsabile dei test o un architetto a livello di programma ha bisogno dell'autorità di mettere in discussione quelle decisioni fin dall'inizio, e la matrice RACI dovrebbe dire chi può bloccare il go-live per motivi di performance.

RISE divide la responsabilità

Con RISE with SAP, SAP è responsabile dell'infrastruttura: dimensionamento, regione dell'hyperscaler, rete e disponibilità della piattaforma. Cliente e partner sono responsabili del livello applicativo. Il documento di SAP su ruoli e responsabilità in RISE lo dice con chiarezza: individuare e ottimizzare le istruzioni SQL onerose resta a carico del cliente, a meno che non acquisti i servizi applicativi aggiuntivi di SAP.

Un errore frequente nei programmi RISE è dare per scontato che SAP individuerà i problemi di performance perché gestisce l'infrastruttura. Individuerà i problemi di infrastruttura. Non individuerà un servizio OData progettato male, un job ABAP inefficiente o un flusso di integrazione che non scala. Scriva questa ripartizione nel charter e nel piano di test:

1. SAP: disponibilità dell'infrastruttura e tempi di risposta a livello di piattaforma
2. Partner: performance dell'applicazione sotto il carico definito, comprese estensioni e flussi di integrazione
3. Cliente: risultati a livello di processo, come il tempo di chiusura e il throughput degli ordini, e la decisione di accettazione

Public Edition e GROW restringono il perimetro

Su S/4HANA Cloud Public Edition, di solito acquistata tramite GROW with SAP, SAP esegue i test di performance sulla propria piattaforma multi-tenant come parte dello standard di prodotto e non si aspetta che i clienti sottopongano a test di carico il sistema condiviso. I suoi test si spostano su ciò che è suo: integrazioni custom, estensioni, report e analytics ad alto volume, la sequenza di chiusura e di consolidamento e il percorso di rete dalle sue sedi. I problemi di performance della piattaforma stessa vanno al supporto SAP.

L'AI aiuta con gli script, non con l'architettura

I fornitori di strumenti per i test di carico stanno aggiungendo l'AI per la manutenzione degli script e l'analisi dei risultati, il che aiuta nei programmi in cui l'applicazione cambia da un ciclo all'altro. Verifichi queste promesse sul suo ambiente prima di pagarle. SAP Cloud ALM può aiutare a generare casi di test e requisiti, e gli assistenti AI possono abbozzare scenari a partire dalle descrizioni di processo.

Nulla di tutto questo corregge l'architettura. L'AI non le dirà che il servizio OData andava progettato in modo diverso, né che un report è troppo pesante per i suoi volumi. Queste decisioni le prendono ancora le persone, in fase di progettazione, prima che parta qualsiasi test.

La maggior parte dei programmi con problemi di performance in produzione non ha saltato del tutto i test. Ha testato senza criteri concordati, oppure ha testato e poi ha accettato le lacune come problemi noti sotto la pressione del calendario. La disciplina sta nei criteri e nel farli rispettare, non nello strumento. Per capire dove si collocano le performance tra gli altri tipi di test, veda il mio confronto tra gli strumenti SAP di test e validazione e la mia guida ai quality gate SAP.

Che cos'è il test di performance SAP e perché è importante?

Verifica come si comporta SAP sotto un carico realistico: tempi di risposta delle transazioni utente, tempi di esecuzione dei job in background, throughput delle interfacce e uso delle risorse con lavoro concorrente.

La correttezza funzionale e le performance sono proprietà diverse. Una transazione corretta per un utente può andare in timeout per 200. Un job che gira in dieci minuti sui dati di test può impiegare ore con i volumi di produzione. Scoprirlo dopo il go-live manda in crisi le operazioni, impone modifiche d'emergenza e danneggia la fiducia degli utenti quando l'adozione è più fragile.

Quando deve iniziare il test di performance in un programma SAP?

L'individuazione dei rischi parte in Explore, perché le scelte di architettura determinano le performance. I test veri e propri partono in Realize, quando la configurazione è abbastanza stabile da rendere significativi i risultati. Una configurazione parziale dà numeri fuorvianti.

L'ultimo ciclo va chiuso prima dell'UAT, non durante. I difetti di performance trovati in UAT comprimono il calendario residuo e spingono ad accettarli come problemi noti.

Chi deve essere responsabile del test di performance SAP?

Il programma, non il solo QA. Il QA esegue e riporta, ma le decisioni che determinano le performance vengono prese in fase di progettazione tra i team funzionale, tecnico e Basis. Un architetto centrale o un responsabile dei test di programma ha bisogno dell'autorità di mettere in discussione quelle decisioni fin dall'inizio.

Lo espliciti nella matrice RACI: chi approva i criteri di accettazione, chi è responsabile della correzione quando i criteri non vengono rispettati e chi può bloccare il go-live per motivi di performance.

Come cambia con RISE with SAP la responsabilità del test di performance?

SAP è responsabile dell'infrastruttura: dimensionamento, regione, rete e disponibilità della piattaforma. Cliente e partner sono responsabili delle performance applicative: configurazione, estensioni, design di OData e Fiori, flussi di integrazione e KPI di processo. Il documento di SAP su ruoli e responsabilità in RISE lascia l'ottimizzazione SQL al cliente, a meno che non vengano acquistati servizi SAP aggiuntivi.

Scriva questa ripartizione nei criteri di accettazione, così che ogni soglia abbia un responsabile.

Quali sono i problemi di performance più comuni in SAP Fiori?

Quattro schemi ne coprono la maggior parte. I picchi di login all'inizio del turno, quando il carico su autenticazione e rendering del launchpad si impenna. I servizi OData che restituiscono grandi insiemi di risultati o fanno più chiamate al back end per ogni interazione. Il livello gateway che diventa un collo di bottiglia a sé stante, e che quindi va monitorato durante i test. E le app custom o molto modificate, dove le ipotesi di performance standard non valgono.

Come si definiscono i criteri di accettazione delle performance in SAP?

Si indicano la transazione, il carico e la soglia. Per esempio: «La creazione dell'ordine si completa in meno di 3 secondi per il 95% delle transazioni con 150 utenti concorrenti nel ruolo di inserimento ordini.» Questo è testabile.

«Il sistema deve essere abbastanza veloce» no. Si concordano i criteri con il business nella fase Prepare, in base a esigenze operative reali, e non si cambiano dopo l'arrivo dei risultati.

Che cosa succede se il test di performance viene saltato o compresso?

I problemi emergono in produzione: job che sforano le proprie finestre e ne bloccano altri, app Fiori che vanno in timeout nei picchi, la chiusura mensile che richiede il doppio del tempo e manca le scadenze di reporting, code delle interfacce che si accumulano.

Gli utenti che incontrano problemi di performance nelle prime settimane si fanno un'opinione negativa del sistema, difficile da ribaltare. E la correzione d'emergenza a sistema in produzione costa più dei test, perché ciò che in Realize era una decisione di progettazione diventa una modifica architetturale urgente.