Load Test nello sviluppo mobile — definizione, scenari e come si esegue

Cos’è Load Test?

Load Test è un processo di verifica di come un sistema si comporta sotto un numero previsto di richieste o utenti simultanei. Nel contesto dello sviluppo mobile, Load Test viene applicato sia al backend (API, database, cache) che al client (elaborazione notifiche push, sincronizzazione dati). La differenza principale rispetto ai test di stress è che Load Test simula un carico reale, non estremo. Secondo AWS Well-Architected Framework (2024), i test di carico devono essere eseguiti utilizzando profili di carico basati su analisi di utilizzo reali.

Load Test può essere eseguito a livello di richieste HTTP all’API, connessioni WebSocket o transazioni del database. L’obiettivo è garantire che il tempo di risposta di ogni richiesta non superi una soglia specificata (di solito 500–1000 ms per l’API) e che la portata (RPS — richieste al secondo) soddisfi i requisiti. Google Cloud Armor (2024) definisce valori soglia basati su percentili: il tempo di risposta p95 non deve superare 2 secondi per gli endpoint critici.

Il test di carico di un backend mobile include la simulazione di scenari tipici: registrazione, autenticazione, caricamento feed, invio moduli. Gli scenari vengono registrati come file HAR (HTTP Archive) e riprodotti dallo strumento di test di carico. Secondo la documentazione k6 (2025), la conversione HAR può ridurre il tempo di preparazione del Load Test del 60%.

Obiettivi del test di carico

Il primo obiettivo di Load Test è confermare la portata del sistema. Se la specifica richiede l’elaborazione di 1000 RPS, il test di carico deve confermarlo con un margine del 20%. Secondo Netflix Tech Blog (2024), i test di carico in Netflix vengono eseguiti con un margine 2x rispetto al carico di picco: se sono previsti 10000 RPS, il test verifica 20000 RPS. Questo approccio garantisce stabilità durante picchi improvvisi di traffico.

Il secondo obiettivo è identificare i colli di bottiglia nell’architettura. I colli di bottiglia tipici nei backend mobili sono il database (query lente), la cache (strategia di invalidazione errata) e le API esterne (servizi di terze parti lenti). Il tracing distribuito (Jaeger, Zipkin) aiuta a localizzare il problema a livello di un servizio o di una richiesta specifica.

Il terzo obiettivo è determinare il punto di saturazione. Questo è il momento in cui aggiungere nuovi utenti non aumenta più la portata. Nelle applicazioni mobili, il punto di saturazione si verifica spesso al 70–80% del carico CPU sui server del database. L’auto-scaling deve attivarsi prima di raggiungere questo punto.

Scenari di test di carico

Test di picco (Spike Test) — simula un improvviso aumento di attività, come una campagna di notifiche push mattutina o il lancio di una campagna pubblicitaria. Secondo Grafana k6 (2025), Spike Test simula una crescita del carico da 100 a 10000 RPS in 30 secondi. Il sistema deve gestirlo senza perdere richieste e senza superare il tempo di risposta di oltre il 50%.

Test di resistenza (Endurance Test) — verifica la stabilità del sistema durante il funzionamento prolungato sotto carico. La durata tipica è di 1–4 ore. Endurance Test rivela perdite di memoria nelle applicazioni server, problemi con il pool di connessioni al database e degradazione delle prestazioni della cache. Il pool di connessioni PostgreSQL sotto carico prolungato senza una configurazione adeguata può esaurire le connessioni disponibili in 2–3 ore di funzionamento.

Test di carico graduale (Step Load Test) — aumento graduale del carico con incrementi del 10–20% ogni 2–5 minuti. Questo scenario aiuta a trovare il limite esatto dopo il quale il sistema si degrada. InfluxDB e Prometheus raccolgono metriche a ogni passo per costruire un grafico del tempo di risposta rispetto a RPS.

Metriche di Load Test

Tempo di risposta

Tempo di risposta è la metrica primaria di Load Test. Misurato in millisecondi e analizzato per percentili: p50 (mediana), p95 e p99. Google SRE (2024) raccomanda una soglia p95 non superiore a 1000 ms per API REST e non superiore a 200 ms per gRPC. I percentili sono più importanti delle medie perché mostrano il comportamento delle peggiori richieste, che gli utenti notano per primi. Apdex (Indice di performance dell’applicazione) è una metrica composita che considera la proporzione di utenti soddisfatti, tolleranti e frustrati.

Portata

Portata (Throughput) — il numero di richieste riuscite per unità di tempo. Misurata in RPS (richieste al secondo) o TPS (transazioni al secondo). Il grafico della portata nelle coordinate “tempo — RPS” deve essere lineare fino al punto di saturazione. Un calo netto della portata all’aumentare del carico è un segno del raggiungimento del limite del sistema. Apache Bench e wrk sono semplici strumenti CLI per controlli rapidi della portata durante lo sviluppo.

Tasso di errore

Tasso di errore (Error Rate) — la proporzione di risposte con stato HTTP 4xx o 5xx rispetto al totale delle richieste. La soglia accettabile è inferiore all’1%. Errori 429 (Troppe richieste) e 503 (Servizio non disponibile) sotto carico elevato indicano la necessità di configurare la limitazione della velocità e l’auto-scaling. Un limitatore di velocità sul lato API Gateway protegge il backend dal superamento del carico consentito. La politica di ripetizione con backoff esponenziale aiuta i client a gestire correttamente gli errori temporanei.

Strumenti per Load Test

k6 (Grafana)

k6 — il principale strumento Open Source di test di carico di Grafana. Gli script sono scritti in JavaScript, con supporto per scenari modulari, soglie (thresholds) e integrazione con Prometheus e InfluxDB. k6 può essere eseguito sia in CLI che nel cloud Grafana Cloud k6. Grafana Cloud costruisce automaticamente dashboard dai risultati di Load Test e li confronta con i dati storici. k6 supporta Protocol Buffers e gRPC tramite il modulo separato k6/net/grpc.

Apache JMeter

Apache JMeter — uno strumento classico di Load Test con interfaccia grafica. Supporta un’ampia gamma di protocolli: HTTP, JDBC, JMS, FTP e TCP. JMeter è più adatto per scenari complessi con molti tipi diversi di richieste ma richiede più configurazione manuale rispetto a k6. I plugin JMeter estendono le funzionalità per i test WebSocket e gRPC. Per l’esecuzione distribuita, JMeter utilizza un’architettura master-slave con un controllore.

Locust

Locust — uno strumento basato su Python che consente di descrivere scenari di carico nel codice. Locust è comodo per i team che usano Python come linguaggio di automazione principale. A differenza di k6 e JMeter, Locust supporta l’esecuzione distribuita nativamente: un nodo master coordina diversi nodi worker. L’esecuzione distribuita consente di generare carichi fino a 100000 RPS da più macchine. Locust supporta anche i test WebSocket tramite estensioni personalizzate.

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

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

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

Esempio di scrittura di Load Test in k6

Lo script k6 mostrato sopra dimostra una struttura tipica di test di carico. Options definisce il profilo di carico: ramp-up per 2 minuti fino a 100 utenti, poi 5 minuti di carico costante e un altro ramp-up fino a 200 utenti. Le soglie definiscono i criteri di superamento del test: tempo di richiesta p95 non superiore a 500 ms, tasso di errore inferiore all’1%. Se le soglie vengono superate, k6 termina con un codice diverso da zero — questo consente di integrare Load Test in CI/CD.

Nello sviluppo mobile, Load Test del backend è particolarmente importante quando si lanciano nuove funzionalità che creano carico aggiuntivo: like, commenti, streaming. Raccomandazione — esegui un Load Test su ogni staging prima del deploy in produzione. Creare un profilo di carico base durante la fase di progettazione dell’API aiuta a evitare problemi architetturali nelle fasi successive.