Cosa misuriamo
Un test di carico che restituisce solo 'ha retto' o 'non ha retto' non serve a decidere. Raccogliamo metriche che dicono dove intervenire e con che priorità.
- Tempo di risposta su percentili (p95 e p99), non solo la media
- Throughput: quante richieste al secondo il sistema serve davvero
- Error rate al crescere del carico, distinto per tipo di errore
- Saturazione delle risorse: CPU, memoria, connessioni al database
- Punto di degrado e punto di rottura, con il valore di carico corrispondente
I tipi di test e quando servono
Performance testing non è una singola attività. Scegliamo il tipo di test in base alla domanda a cui devi rispondere.
- Load test: il sistema rispetta i tempi attesi al carico previsto?
- Stress test: oltre quale soglia si rompe e come si rompe, in modo graduale o improvviso?
- Spike test: regge un picco improvviso, tipo apertura vendite o campagna che parte?
- Soak test: sotto carico costante per ore emergono memory leak o degradi progressivi?
Strumenti
Lavoriamo principalmente con Gatling e Locust: scenari scritti in codice, versionabili in repository ed eseguibili in pipeline, senza licenze da rinnovare.
Se il tuo team ha già script k6 o JMeter, partiamo da quelli invece di riscrivere tutto da zero.
Come funziona la prima settimana
Il primo intervento copre due flussi critici sotto carico. È abbastanza per avere numeri reali su cui decidere, senza aprire un progetto lungo prima di sapere se il problema esiste.
- Giorno 1: scegliamo i due flussi e definiamo i profili di carico attesi
- Giorni 2-3: scriviamo gli scenari e prepariamo dati e ambiente di staging
- Giorno 4: esecuzione dei test, raccolta metriche e monitoraggio delle risorse
- Giorno 5: report con soglie, colli di bottiglia prioritizzati e walkthrough con il team
Dal test singolo al controllo continuo
Una misurazione una tantum invecchia in fretta: basta un rilascio per cambiare le carte in tavola. Quando serve, integriamo un test di performance ridotto nella pipeline CI/CD come gate automatico.
Gira in pochi minuti su ogni merge request e confronta i tempi di risposta con la baseline: se una modifica peggiora le prestazioni oltre la soglia concordata, il deploy si ferma prima di arrivare in produzione.
Cosa ricevi
- Script dei flussi critici, versionati nel tuo repository
- Report con curve di carico, percentili ed error rate per ogni scenario
- Elenco dei colli di bottiglia individuati, ordinati per impatto
- Soglie di riferimento da usare come baseline nei rilasci successivi
- Walkthrough dei risultati con il team di sviluppo
- Opzionale: integrazione del test come gate nella pipeline CI/CD