Stress Test nello sviluppo mobile: definizione, obiettivi e come si esegue

Cos’è lo Stress Test?

Lo Stress Test è un processo di valutazione della capacità del sistema di funzionare in condizioni che superano i valori calcolati. Per un’applicazione mobile, ciò può significare 10000 notifiche push simultanee con una norma di 1000, per il backend — 50000 RPS contro 5000 previsti. La differenza principale tra Stress Test e Load Test è che l’obiettivo non è confermare le prestazioni, ma studiare il comportamento del sistema oltre la sua capacità nominale. Netflix Engineering (2024) definisce lo Stress Test come “verifica dell’ipotesi che il sistema si guasterà in modo prevedibile”.

Lo stress test comprende due fasi obbligatorie: carico fino al guasto e osservazione del recupero. Il recupero (recovery) è la capacità del sistema di tornare al funzionamento normale dopo la rimozione del sovraccarico. Un sistema che non si riprende senza riavvio è considerato fragile, anche se sopporta un sovraccarico di breve durata. Secondo AWS Well-Architected Framework (2024), il tempo di recupero dopo uno Stress Test non deve superare i 5 minuti.

Per i client mobili, lo Stress Test include la verifica del funzionamento in caso di terminazione forzata dei processi, disconnessione di rete ed esaurimento della RAM. Android Low Memory Killer può terminare un processo in background in caso di RAM insufficiente — lo stress test deve verificare che l’applicazione ripristini correttamente lo stato dopo tale terminazione. Apple UIKit (2024) raccomanda di testare scenari di avviso di memoria su ogni schermata dell’applicazione.

Obiettivi dello stress test

Determinazione del punto di rottura

Il primo obiettivo dello Stress Test è la determinazione del punto di rottura (breaking point). È il momento in cui uno degli indicatori chiave delle prestazioni supera una soglia critica: il tempo di risposta p95 supera 10 secondi, la percentuale di errori HTTP 5XX supera il 5% o la velocità effettiva scende al di sotto del 50% del riferimento. La registrazione del punto di rottura consente al team di conoscere in anticipo il limite di scalabilità del sistema. La pianificazione della capacità si basa proprio sui dati dello Stress Test, non del Load Test, poiché il Load Test non verifica le condizioni limite.

Verifica dei meccanismi di recupero

Il secondo obiettivo è la verifica dei meccanismi di recupero. Dopo che il carico è stato ridotto a un livello normale, il sistema deve tornare agli indicatori standard. Se il pool di connessioni al database non viene liberato o la cache non viene invalidata, lo Stress Test individuerà questo problema. Il circuit breaker (Hystrix, Resilience4j) deve attivarsi in caso di sovraccarico e ripristinare automaticamente la connessione dopo la stabilizzazione. Gli endpoint Health check aiutano a monitorare lo stato di ogni servizio durante il test.

Validazione dell’auto-scaling

Il terzo obiettivo è la validazione dell’auto-scaling. Se l’infrastruttura utilizza Kubernetes o AWS Auto Scaling, lo Stress Test verifica che nuovi pod o istanze vengano creati abbastanza rapidamente. Secondo Google Kubernetes Engine (2024), il tempo di distribuzione di un nuovo pod non deve superare i 30 secondi dall’attivazione della metrica HPA (Horizontal Pod Autoscaler). HPA deve scalare in base a CPU, memoria e metriche personalizzate. Cluster Autoscaler aggiunge nuovi nodi se quelli correnti non possono ospitare i pod.

Metodologia dello Stress Test

Aumento graduale del carico (Ramp-up Stress Test) — lo scenario più comune. Il carico iniziale è impostato al 50% del carico previsto, poi aumentato del 10% ogni 2 minuti fino al guasto del sistema. Questo scenario consente di trovare il limite esatto di resilienza. Grafana Cloud k6 (2025) raccomanda un incremento non superiore al 10% per ottenere un grafico fluido del tempo di risposta.

Picco improvviso di carico (Spike Stress Test) — il carico passa dal 10% al 500% in 10–30 secondi. Questo scenario simula situazioni come la diffusione virale di contenuti o un attacco DDoS. Lo Spike Stress Test verifica non tanto le prestazioni quanto la sopravvivenza del sistema: la capacità di non crollare completamente e di riprendere il funzionamento dopo la stabilizzazione. Il gateway API deve configurare la limitazione della velocità per proteggere il backend da picchi improvvisi.

Mantenimento prolungato del sovraccarico (Sustained Stress Test) — il sistema viene mantenuto in stato di sovraccarico per 30–60 minuti. Questo scenario rivela perdite di risorse che non si manifestano durante test di breve durata. Le perdite di memoria nelle applicazioni Java/Kotlin si accumulano durante 20–40 minuti di funzionamento intensivo e solo il Sustained Stress Test le rileva.

Analisi del punto di rottura e recupero

Il punto di rottura è determinato secondo tre criteri: tempo di risposta, percentuale di errori e velocità effettiva. Di solito, la soglia del tempo di risposta viene superata per prima — le richieste iniziano a richiedere più tempo del limite stabilito. Poi aumenta la percentuale di errori: il server non riesce a elaborare le richieste e restituisce 503. Infine, il Throughput diminuisce — il sistema smette di gestire anche il carico minimo. La metrica del punto di rottura viene registrata nel profilo di carico per la pianificazione della capacità.

L’analisi del recupero comprende tre fasi: reazione immediata (primi 30 secondi dopo la rimozione del carico), stabilizzazione (1–5 minuti) e recupero completo (5–30 minuti). Nella fase di reazione immediata, il tempo di risposta deve scendere al di sotto del riferimento — il sistema si libera dalle code. Se ciò non accade, il problema non è il carico ma lo stato accumulato. Il graceful degradation — capacità del sistema di mantenere una funzionalità parziale in caso di sovraccarico — è un indicatore chiave della maturità dell’architettura.

Chaos Engineering integra lo Stress Test introducendo intenzionalmente guasti: arresto del server di database, latenza di rete, arresto di un microservizio. Chaos Monkey di Netflix (2024) termina casualmente i processi in produzione, verificando la resilienza del sistema. Per le applicazioni mobili, Chaos Engineering significa testare scenari: assenza di rete, indisponibilità dell’API, risposta vuota del server.

Strumenti per lo Stress Test

k6 con ramping-arrival-rate

k6 supporta lo Stress Test tramite il modulo `execution` con configurazione ramping-arrival-rate. Questa modalità aumenta il numero di richieste al secondo indipendentemente dal tempo di esecuzione di ogni richiesta. Rispetto al Load Test, lo Stress Test in k6 richiede la configurazione di soglie più aggressive e la disattivazione di gracefull-stop per simulare un guasto improvviso. Grafana Cloud rileva automaticamente il punto di rottura dalla flessione del grafico del tempo di risposta. k6-operator per Kubernetes consente di eseguire Stress Test distribuiti dal cluster.

JMeter con Ultimate Thread Group

JMeter consente di configurare lo Stress Test tramite Ultimate Thread Group — un plugin che definisce il profilo di carico in forma di tabella: numero di thread, tempo di riscaldamento, tempo di mantenimento, tempo di raffreddamento. Ultimate Thread Group è utile per scenari multifase complessi. JMeter Backend Listener invia metriche a InfluxDB per costruire grafici del punto di rottura. Per lo Stress Test, si consiglia di disabilitare i timeout di connessione in JMeter per misurare più accuratamente il comportamento in sovraccarico.

Gremlin per Chaos Engineering

Gremlin è una piattaforma di Chaos Engineering per lo Stress Test dell’infrastruttura. Gremlin consente di disconnettere la rete, caricare la CPU, riempire il disco e terminare processi a livello di singoli pod Kubernetes. I team SRE utilizzano Gremlin insieme a k6 per uno Stress Test completo: k6 genera carico, Gremlin introduce guasti. Game Day — sessioni regolari di Stress Test con Gremlin, documentate in un “chaos report” per analizzare la resilienza del sistema.

Esempio di Stress Test su k6

Lo script k6 seguente mostra uno Stress Test con aumento graduale del carico fino al guasto. Ramping-arrival-rate aumenta il numero di richieste al secondo indipendentemente dal tempo di esecuzione. Le soglie sono configurate per il rilevamento aggressivo del degrado: p95 non superiore a 2000 ms, tasso di errore non superiore al 5%. Al superamento delle soglie, k6 termina il test con codice di errore, consentendo di integrare lo Stress Test nella pipeline CI/CD.

import http from 'k6/http'
import check from 'k6'

export const options = {
    scenarios: {
        stress: {
            executor: 'ramping-arrival-rate',
            startRate: 50,
            timeUnit: '1s',
            stages: [
                { duration: '2m', target: 200 },
                { duration: '5m', target: 500 },
                { duration: '2m', target: 1000 },
            ],
            preAllocatedVUs: 50,
            maxVUs: 200,
        },
    },
    thresholds: {
        http_req_duration: ['p(95)<2000'],
        http_req_failed: ['rate<0.05'],
    },
}

export default function() {
    const res = http.get('https://api.example.com/health')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
}

Migliori pratiche dello stress test

Iniziare lo Stress Test sullo staging — lo stress test in produzione richiede monitoraggio avanzato e un piano di rollback. Google SRE (2024) raccomanda di eseguire lo Stress Test in un ambiente isolato al 100% che replichi la produzione per architettura e capacità. Dopo un test riuscito sullo staging, si può passare alla produzione sotto la supervisione della SRE. Il feature flag per disabilitare funzionalità in caso di sovraccarico è un elemento obbligatorio.

Automatizzare lo Stress Test nel CI/CD per l’analisi di regressione del punto di rottura. Se una nuova versione dell’applicazione ha un punto di rottura inferiore del 20% rispetto alla precedente, si tratta di una regressione da correggere prima del rilascio. Il punto di rottura di riferimento è memorizzato nelle metriche e automaticamente confrontato con il risultato di ogni Stress Test. Un avviso scatta se il punto di rottura diminuisce del 10%.

Documentare ogni Stress Test: profilo di carico, punto di rottura, comportamento di recupero e elenco dei problemi scoperti. Netflix Engineering (2024) organizza “Game Day” — sessioni regolari di Stress Test i cui risultati sono documentati in un “chaos report”. Il rapporto di stress test deve contenere un grafico “RPS — tempo di risposta” con il punto di rottura evidenziato.