Risposta.

Storicamente, le prestazioni del software venivano verificate dopo la parte funzionale principale: gli sviluppatori eseguivano manualmente gli script o raccoglievano metriche utilizzando strumenti come JMeter. Con il passaggio massiccio a DevOps e CI/CD, è emersa la necessità di automatizzare questi processi e ottenere metriche in ogni fase della consegna.

Il problema è complicato dal fatto che l'automazione del carico non è solo l'esecuzione di test già pronti, ma una fine regolazione degli scenari di carico, riproducibilità del profilo degli utenti, emulazione di reti reali, considerazione della latenza, limitatezza dell'hardware di test.

La soluzione moderna è l'implementazione di strumenti specializzati (ad esempio, Gatling, Locust, k6), creazione di scenari con parametrizzazione del profilo degli utenti, integrazione dei test delle prestazioni nei pipeline CI, automazione della raccolta e analisi delle metriche, allerta in caso di deterioramento delle prestazioni.

Caratteristiche chiave:

Corretto settaggio degli scenari di carico (ripetibilità e maggiore realismo).
Analisi delle metriche (separazione del benchmarking, stress, long interval) e automazione della loro raccolta.
Valutazione dell'impatto dei risultati dei test sulla qualità complessiva della consegna e rispetto degli SLA.

Domande trabocchetto.

È corretto dire che l'automazione dei "load tests" è consentita solo in produzione?

No. I test automatici di prestazioni e stress possono essere eseguiti su un'applicazione/stend dedicato in fase di staging, per non violare gli SLA. Automatizzarli è, al contrario, preferibile prima del rilascio in produzione.

Se i test automatici di carico passano, si può essere sicuri dell'esperienza reale dell'utente?

No, i test automatici forniscono solo un quadro medio. Il comportamento degli utenti reali può differire a causa delle condizioni di rete, delle piattaforme utilizzate e di altri fattori che sono difficili da emulare alla lettera.

Dovremmo basarci solo sui valori medi dei tempi di risposta (response time)?

No. È estremamente importante considerare il percentil (ad esempio, il 95°, il 99°), poiché le medie possono essere distorte da outlier, e i valori estremi influiscono maggiormente sull'UX.

Errori comuni e antipattern

Focalizzarsi solo su scenari semplici "login/logout", senza emulare operazioni aziendali.
Ignorare l'analisi degli scenari peggiori (tail latency).
Analisi insufficiente delle dipendenze (ad esempio, servizi di terze parti non disabilitati e rate limits).

Esempio dalla vita reale

Caso negativo

L'azienda ha implementato test automatici delle prestazioni solo per l'accesso al sistema: gli script eseguivano 1000 login, analizzavano il tempo medio di risposta e pensavano che il problema fosse risolto. Al primo avvio reale ci sono stati timeout massivi: si è scoperto che le "pesanti" operazioni aziendali parallele non erano state considerate, l'API è crollata sotto carico.

Vantaggi:

Conferma rapida della funzionalità dei semplici scenari.

Svantaggi:

L'ignoranza delle catene utente più importanti ha portato a un incidente.
Falsa percezione di stabilità.

Caso positivo

In un'altra squadra, l'intero profilo di carico è stato composto sulla base del monitoraggio della produzione, alcuni script emulavano picchi di attività da dispositivi e reti diverse. Tutti i risultati venivano automaticamente confrontati con un benchmark, deviazioni superiori al 5% generavano un alert e una sospensione del rilascio.