Test di performance SAP: carico, concorrenza e strumenti

Il test di performance SAP dimostra, prima del go-live, che le transazioni critiche, i job in background e le interfacce rispettano tempi di risposta concordati quando molti utenti e job girano nello stesso momento. Nella mia esperienza i test che contano sono quelli di concorrenza, eseguiti su dati mascherati con volumi di produzione e rispetto a criteri di superamento e fallimento che il business ha concordato prima della prima esecuzione.

Questa guida è per CIO, program director e test lead dei programmi S/4HANA, compresi quelli RISE with SAP. Tratta che cosa testare, i dati necessari, come scrivere i criteri di accettazione, quali strumenti fanno il lavoro e chi è responsabile di che cosa. Per capire dove si colloca la performance tra gli altri tipi di test, parta dalla mia panoramica sui test SAP spiegati.

Nei programmi SAP i problemi di performance raramente sono una sorpresa.

I tile Fiori vanno in timeout quando centinaia di utenti accedono all'inizio di un turno. Un report custom si blocca perché qualcuno ha lanciato una selezione sull'intero esercizio, senza limiti, su una tabella molto grande. I job in background si sovrappongono a fine mese e l'elaborazione delle registrazioni si interrompe.

Sono problemi prevedibili. L'unica domanda è se il programma li ha testati, o se li scopre il business con gli ordini reali in corso.

Il test di performance lungo SAP Activate

1. 01

   Explore

   Individuare i rischi di performance nel disegno. Architettura e struttura dei report decidono i risultati prima che si scriva il codice.

2. 02

   Realize

   Eseguire 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 della UAT, non al suo interno.

4. 04

   Cutover

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

5. 05

   Hypercare

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

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

Su S/4HANA, con front end Fiori, estensioni su SAP BTP e integrazione tramite SAP Cloud Integration, la performance dipende da più livelli contemporaneamente. Un tile Fiori lento può essere una lunga chiamata ABAP, 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 lo farà emergere.

1. 01Avvio del tileOndate di accessi a inizio turno
2. 02Chiamata ODataTimeout del gateway, servizi non costruiti 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

Il test di performance su SAP HANA ha una sua particolarità in una conversione. Codice ECC stabile si comporta diversamente su un database in-memory. Molti programmi diventano molto più veloci, mentre alcuni producono profili inattesi su particolari distribuzioni di dati, quindi una regressione specifica per la conversione del codice custom più pesante non è facoltativa.

I flussi di integrazione aggiungono un rischio proprio. Flussi che in sviluppo funzionavano con singoli messaggi di test possono accodarsi o fallire in silenzio con i volumi di produzione. I sintomi sembrano altro: errori intermittenti sugli ordini, fatture che non quadrano, dati presenti in un sistema e assenti in un altro.

Il test di performance va fatto prima del go-live. I test che considero importanti sono quelli di concorrenza: molti utenti e job che agiscono sulle stesse transazioni, tabelle e servizi nello stesso momento.

Un singolo utente che crea un ordine di vendita in due secondi non dimostra quasi nulla. Lo stesso ordine con 150 persone che inseriscono ordini, un'elaborazione delle consegne in background e un'interfaccia che registra messaggi in entrata è il test che prevede il primo giorno.

Questa tabella mostra che cosa dimostra ciascun tipo di test e quando eseguirlo:

Test	Che cosa dimostra	Quando eseguirlo	Che cosa trova di solito
Concorrenza	Molti utenti e job possono lavorare sugli stessi oggetti contemporaneamente	Realize, una volta stabile la configurazione, e di nuovo prima della UAT	Attese sui lock, ondate di accessi, colli di bottiglia del gateway
Carico	Il sistema rispetta i tempi di risposta al volume di picco previsto	Realize, dopo che gli script di concorrenza funzionano	Servizi OData lenti, report custom pesanti
Stress	Dove il sistema si rompe oltre i limiti di progetto	Prima della UAT, se è prevista una crescita	Lacune di dimensionamento, limiti delle code
Soak	Il sistema regge un carico costante per ore	Prima della UAT, idealmente durante una chiusura simulata	Crescita della memoria, contesa tra catene di job su esecuzioni ripetute
End-to-end	L'intero percorso che l'utente attende rispetta l'obiettivo	Insieme ai test di carico	Problemi invisibili quando ogni livello è testato da solo

La parola chiave nel test di carico è previsto. Servono volumi di transazioni, numeri di utenti e schemi di sessione reali. Un test di carico costruito su stime di volume che tutti sapevano già ottimistiche dà un esito positivo che non significa nulla.

Il soak test è quello che si salta più spesso. Il test di volume in generale è la scorciatoia che i programmi prendono più spesso quando la timeline si comprime, e quella di cui si pentono di più.

Scripti per primi questi scenari. Coprono la maggior parte dei malfunzionamenti che arrivano in produzione.

1. Cambio turno e picco di accessi. Quando qualche centinaio di utenti apre il Fiori launchpad nello stesso momento, autenticazione e rendering del launchpad hanno un picco. Un sistema che va bene fuori picco può diventare inutilizzabile in quella finestra se gli accessi concorrenti non sono mai stati testati.
2. Chiusura mensile e annuale. Registrazioni ad alto volume, catene di job con sequenze rigide e un team finance che corre contro una scadenza fissa. Esegua le catene di job di chiusura dall'inizio alla fine con i volumi del periodo di chiusura, non con le medie giornaliere.
3. Job in background sovrapposti. I job batch di solito si testano uno alla volta, il che non riflette la realtà. Un job poco ottimizzato può bloccarne diversi altri, e la chiusura sfora la sua finestra.
4. Report custom senza limiti di selezione. Un report che risponde all'istante sui dati di test può girare per minuti su un intero esercizio. Testi selezioni tipiche e quelle nel caso peggiore, e blocchi quelle senza limiti.
5. Utenti in più regioni. La latenza di rete incide su ogni transazione. RISE sposta l'hosting presso SAP, ma la latenza dipende comunque dalla regione scelta e dall'instradamento verso i suoi utenti, quindi testi dalle sedi più lontane.

La mia guida alla migrazione da ECC a S/4HANA spiega dove si colloca il test della conversione nel piano complessivo.

Dati di test a livello di produzione

Sono i dati a decidere se tutto questo ha un senso. Insisto su dati mascherati a livello di produzione: volumi e realismo di produzione, con i campi personali e sensibili mascherati.

Un cliente con 200.000 righe d'ordine aperte si comporta diversamente da uno con 5.000. Filtri che rispondono all'istante in un mandante di test scarno vanno in timeout in produzione. Popoli i volumi per le aree ad alto rischio, usi un mix di transazioni rappresentativo ed effettui chiamate reali alle interfacce dove possibile.

Come ottenere quei dati in sicurezza, tramite copie, strumenti per dati di test selettivi e mascheramento, lo spiego nella mia guida alla gestione dei dati di test SAP. Pianifichi l'aggiornamento prima del primo ciclo di performance, perché richiede più tempo di quanto prevedano la maggior parte dei piani di test.

Concordi i criteri con il business nella fase Prepare, prima che giri qualsiasi test. Ognuno indica la transazione o il job, il carico e la soglia.

Questi esempi mostrano la forma. Fissi i suoi numeri in base alle esigenze operative:

Elemento	Condizione di carico	Soglia di superamento	Responsabile
Creazione ordine di vendita (VA01 o app Fiori)	150 utenti concorrenti di inserimento ordini	Meno di 3 secondi per il 95% delle transazioni	Process owner order to cash
Primo caricamento del Fiori launchpad a inizio turno	Picco di accessi concorrenti del turno più numeroso	Meno di 5 secondi per il 95% degli utenti	Responsabile delle IT operations
Catena di job della chiusura mensile	Volumi del periodo di chiusura, sequenza completa	Si conclude entro la finestra di chiusura concordata senza interruzioni	Financial controller
Interfaccia ordini in entrata	Volume orario di messaggi di picco	Nessun arretrato in coda più vecchio di 15 minuti	Responsabile dell'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 l'operatività aziendale» non si può né testare né accettare. Cambiare i criteri dopo l'arrivo dei risultati vanifica lo scopo di averli.

Se il sistema ha superato il test perché gli utenti della UAT hanno detto che sembrava veloce, lei ha un'opinione, non un criterio di accettazione. Trasformi i risultati in un gate formale prima del cutover, come descrive la mia guida ai quality gate SAP. Il piano complessivo dei cicli, con criteri di ingresso e di uscita per ogni fase di test, va inserito nella sua strategia di test S/4HANA.

Strumenti per il test di performance SAP

Un test di performance richiede tre cose: un generatore di carico in grado di gestire i protocolli SAP, il monitoraggio lato SAP e un luogo in cui gestire casi di test e risultati. LoadRunner è lo strumento di carico che ho fatto usare ai team nei programmi SAP. Indichi presto lo strumento nel piano di test, perché licenze, generatori di carico e competenze di scripting richiedono tutti tempo per essere predisposti.

Le opzioni principali nel 2026:

Strumento	Ruolo	Che cosa sapere
OpenText Professional Performance Engineering	Generazione del carico	Il prodotto che in precedenza si chiamava LoadRunner Professional. I suoi pacchetti di protocolli coprono SAP, SAP GUI e SAP Web
Tricentis NeoLoad	Generazione del carico	Tricentis indica il supporto di SAP GUI, Fiori, RFC e IDoc, e può riutilizzare gli asset di Tricentis Tosca
Apache JMeter	Generazione del carico	Open source. Genera traffico HTTP come le chiamate Fiori e OData
SAP Cloud ALM	Gestione dei test	Prepara ed esegue casi di test manuali e automatizzati e traccia i difetti. Non genera carico da sé
SAP Solution Manager	Gestione dei test	La manutenzione mainstream termina il 31 dicembre 2027, quindi pianifichi il nuovo lavoro in Cloud ALM

Per una visione più ampia degli strumenti funzionali e di automazione, consulti il mio confronto tra strumenti di test e convalida SAP. Lo strumento conta meno degli script, dei dati e dei criteri.

RISE with SAP ripartisce le 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 SAP su ruoli e responsabilità in RISE è chiaro in proposito. L'esecuzione dei load test e il tuning delle istruzioni SQL onerose sono SAP Cloud Application Services a pagamento aggiuntivo. Se non li acquista, il lavoro lo fa il cliente.

Un errore comune nei programmi RISE è dare per scontato che SAP intercetterà i problemi di performance perché gestisce l'infrastruttura. Intercetterà i problemi di infrastruttura. Scriva la ripartizione nel project charter e nel piano di test:

1. SAP: disponibilità dell'infrastruttura e risposta a livello di piattaforma
2. Partner: performance applicativa con il carico definito, comprese estensioni e flussi di integrazione
3. Cliente: risultati a livello di processo, come la durata della chiusura e il volume di ordini evasi, e la decisione di accettazione

Il public cloud restringe il perimetro

Sulla public edition del cloud ERP di SAP, il sistema gira su una piattaforma condivisa gestita da SAP. Prima di pianificare qualsiasi test di carico su un tenant, chieda a SAP per iscritto se è consentito e con quale preavviso.

Il suo test si sposta allora su ciò che è suo: integrazioni custom, estensioni, report ad alto volume, la sequenza di chiusura e il percorso di rete dalle sue sedi. I problemi di performance della piattaforma vanno al supporto SAP.

Errori comuni

1. Trattare il test funzionale 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.
2. Lasciare la performance al Basis. Il Basis è responsabile del dimensionamento e della schedulazione dei job. Non è responsabile del disegno dei report, dell'architettura dei servizi OData o del disegno dei flussi di integrazione, ed è questo che determina la performance applicativa.
3. Affidare la responsabilità al solo QA. Il QA esegue i test e riporta i risultati, ma le decisioni che causano i problemi di performance si prendono nel disegno. Un test lead o un architetto a livello di programma deve avere l'autorità per contestarle presto, e la matrice RACI deve indicare chi può bloccare il go-live per motivi di performance.
4. Accettare le lacune come problemi noti. La maggior parte dei programmi con problemi di performance in produzione non ha saltato i test. Ha testato senza criteri concordati, oppure ha testato e poi accettato i malfunzionamenti sotto la pressione del calendario.

Scriva i cinque o sei criteri di accettazione per le transazioni e i job più a rischio, con un responsabile nominato per ciascuno. Se non riesce a compilare la tabella qui sopra, non è pronto per testare, e ha trovato la prima lacuna.

Poi verifichi due cose: che nel piano ci sia un aggiornamento dei dati mascherato con volumi di produzione, e che il ciclo di concorrenza finisca prima che inizi la UAT.

Se desidera un parere indipendente su un piano di test di performance o su una decisione di go-live, aiuto le organizzazioni proprio su questo. Può contattarmi qui.

Che cos'è il test di performance SAP?

Verifica come si comporta SAP con un carico realistico: tempi di risposta delle transazioni utente, durata dei job in background, throughput delle interfacce e uso delle risorse quando molte persone lavorano contemporaneamente. Va fatto prima del go-live.

Correttezza funzionale e performance sono proprietà diverse. Una transazione corretta per un utente può andare in timeout con 200.

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

L'individuazione dei rischi inizia in Explore, perché le scelte di architettura determinano i risultati di performance. Il test vero e proprio inizia in Realize, quando la configurazione è abbastanza stabile da rendere significativi i risultati.

Concluda il ciclo finale prima della UAT, non durante. I difetti di performance trovati in UAT comprimono il calendario e creano pressione per accettarli come problemi noti.

Qual è la differenza tra test di carico e test di concorrenza in SAP?

Il test di carico verifica i tempi di risposta al volume di picco previsto. Il test di concorrenza verifica che cosa succede quando molti utenti e job lavorano sulle stesse transazioni, tabelle e servizi nello stesso momento. È lì che emergono attese sui lock, ondate di accessi e colli di bottiglia del gateway.

Nella mia esperienza i test di concorrenza sono quelli importanti. Li esegua per primi, poi costruisca sopra il test di carico completo.

Quali dati di test deve usare il test di performance SAP?

Dati mascherati a livello di produzione. Significa volumi e realismo di produzione, con i campi personali e sensibili mascherati. Dati di test scarni nascondono i filtri lenti, i report pesanti e le lunghe durate dei job che compaiono il primo giorno.

Quali strumenti si usano per il test di performance SAP?

Generatori di carico come OpenText Professional Performance Engineering (in precedenza LoadRunner Professional), Tricentis NeoLoad e Apache JMeter producono il carico. SAP Cloud ALM o SAP Solution Manager gestiscono casi di test e risultati, e il monitoraggio lato SAP mostra che cosa ha fatto il sistema sotto carico.

Chi è responsabile del test di performance in RISE with SAP?

SAP è responsabile dell'infrastruttura: dimensionamento, regione, rete e disponibilità della piattaforma. Il documento SAP su ruoli e responsabilità in RISE lascia al cliente l'esecuzione dei load test e il tuning delle istruzioni SQL onerose, a meno che non si acquistino SAP Cloud Application Services a pagamento aggiuntivo.

Cliente e partner sono responsabili della performance applicativa e della decisione di accettazione. Scriva la ripartizione nei criteri di accettazione, così ogni soglia ha un responsabile.