Cos'è il test di scalabilità? Impara con l'esempio
Tommaso Hamilton
⚡ Riepilogo intelligente
I test di scalabilità misurano il comportamento di un'applicazione quando il carico degli utenti, il volume dei dati o la frequenza delle transazioni aumentano o diminuiscono, rivelando il punto esatto in cui le prestazioni smettono di scalare e identificando il collo di bottiglia responsabile.
Che cosa sono i test di scalabilità?
Test di scalabilità Il test di scalabilità è un metodo di test non funzionale che misura le prestazioni di un sistema o di una rete quando il numero di richieste degli utenti viene aumentato o diminuito. Lo scopo del test di scalabilità è garantire che il sistema sia in grado di gestire un aumento previsto del traffico utenti, del volume dei dati e della frequenza delle transazioni. Verifica la capacità del sistema di soddisfare la crescente domanda.
Il test di scalabilità è un sottotipo di test delle prestazioni, quindi si concentra sul comportamento di un'applicazione quando viene distribuita su un sistema più ampio o utilizzata sotto carico eccessivo. In Software EngineeringI test di scalabilità misurano il punto in cui un'applicazione smette di scalare e ne identificano la causa.
Perché eseguire test di scalabilità?
I problemi di capacità raramente emergono durante i test funzionali. Si manifestano nel giorno di maggiore attività commerciale dell'anno, quando viene lanciata una campagna di marketing o quando un set di dati cresciuto silenziosamente per due anni inizia a rallentare ogni query. I test di scalabilità mettono in luce questi limiti in un ambiente controllato. Nello specifico, ti aiutano a:
- Determinare come l'applicazione si adatta all'aumento del carico di lavoro e dove tale curva si appiattisce.
- Determinare il limite di utenti simultanei per l'applicazione web prima che i tempi di risposta diventino inaccettabili.
- Determinare il degrado delle prestazioni lato client e l'esperienza dell'utente finale sotto carico, ad esempio il rallentamento del rendering dello schermo.
- Determinare la robustezza e il degrado del lato server, inclusi la saturazione della CPU, le perdite di memoria e l'esaurimento del pool di connessioni.
La relazione si può visualizzare più facilmente come una curva: la velocità di elaborazione aumenta con l'aumento del carico fino a quando una risorsa si satura, dopodiché l'aggiunta di utenti non fa altro che allungare la coda.
Tipi di test di scalabilità
La scalabilità non è una singola proprietà, quindi un piano di test di solito copre più di una dimensione. I quattro tipi seguenti sono quelli che la maggior parte dei team misura, e i primi due determinano la struttura stessa dell'ambiente di test.
| Tipo | Che cosa è scalato? | Cosa dimostra il test |
|---|---|---|
| Scalabilità verticale (ampliamento) | CPU, memoria o spazio di archiviazione aggiunti a un singolo server | Quanto carico aggiuntivo assorbe una macchina aggiornata e dove si trova il limite massimo per un singolo nodo. |
| Scalabilità orizzontale (ridurre l'ingrandimento) | Server, container o nodi aggiuntivi dietro un bilanciatore di carico | Se la velocità di trasmissione aumenta approssimativamente in proporzione ai nodi aggiunti o se le risorse condivise la limitano |
| Scalabilità funzionale | Nuove funzionalità, moduli o servizi | Se le funzionalità aggiuntive possono essere integrate senza compromettere le transazioni esistenti. |
| Scalabilità amministrativa | Utenti, tenant, team o ambienti da gestire | Se l'onboarding, le autorizzazioni e il monitoraggio rimangono funzionali con la crescita dell'organizzazione |
La scalabilità verticale è più semplice perché l'architettura cambia raramente, ma una singola macchina ha sempre un limite massimo. La scalabilità orizzontale elimina questo limite e migliora la tolleranza ai guasti, a scapito della latenza di rete, della coerenza dei dati e del sovraccarico di coordinamento, tutti aspetti che il test deve misurare anziché presumere.
Cosa testare nei test di scalabilità
La scalabilità si valuta in base alle misurazioni, non alle impressioni. Registra i seguenti attributi a ogni fase di caricamento, in modo che sia visibile l'andamento e non solo il valore finale.
| Attributo | Cosa ti dice |
|---|---|
| Tempo di risposta | Tempo tra una richiesta dell'utente e la risposta del sistema; dovrebbe rimanere costante all'aumentare della concorrenza |
| Transizione dello schermo | Quanto velocemente una pagina o una visualizzazione lascia il posto alla successiva sotto carico |
| Throughput | Volume di richieste elaborate per unità di tempo; un plateau segna il limite di scalabilità |
| Misurazioni del tempo | Tempo di sessione, tempo di riavvio, tempo di stampa, tempo di transazione e tempo di esecuzione dell'attività |
| Prestazioni in rapporto al numero di utenti | Come si muove ciascuna metrica all'aumentare degli utenti simultanei. |
| Tariffe di richiesta | Richieste al secondo, transazioni al secondo e accessi al secondo |
| Utilizzo della rete | Larghezza di banda consumata e latenza dei pacchetti tra i livelli |
| Utilizzo della CPU e della memoria | Costo delle risorse per transazione; una cifra in costante aumento spesso segnala una perdita |
| Contatori del server web | Richieste e risposte al secondo, profondità della coda e connessioni rifiutate |
| Prestazioni sotto carico | Comportamento combinato una volta che ogni metrica viene letta insieme al picco |
Strategia di test per la scalabilità
La strategia di test per il test di scalabilità varia a seconda del tipo di applicazione in fase di test. Se un'applicazione accede a un banca datiI parametri di test includeranno la dimensione del database in relazione al numero di utenti e così via.
Prerequisiti per il test di scalabilità
- Capacità di distribuzione del carico — Verificare se lo strumento di prova di carico consente di generare il carico da più macchine e di controllarlo da un punto centrale.
- Operasistema di ting — Controlla cosa sistemi operativi gli agenti di generazione del carico e il master del test di carico vengono eseguiti sotto.
- Processore — Verificare il tipo di CPU richiesto per l'agente utente virtuale e il master del test di carico.
- Memorie — Verifica quanta memoria sarebbe sufficiente per l'agente utente virtuale e il master del test di carico.
- Ambiente di test — Controlla che il ambiente di test rispecchia la produzione in modo sufficientemente fedele da permettere il trasferimento dei risultati.
Come eseguire test di scalabilità
- Definire un processo ripetibile per l'esecuzione di test di scalabilità durante l'intero ciclo di vita dell'applicazione.
- Determinare i criteri per la scalabilità
- Elenca gli strumenti software necessari per eseguire il test di carico
- Imposta l'ambiente di test e configura l'hardware richiesto per eseguire test di scalabilità
- Pianifica gli scenari di test e i test di scalabilità.
- Creare e verificare lo script dell'utente virtuale
- Creare e verificare gli scenari dei test di carico
- Eseguire i test
- Valuta i risultati
- Genera i report richiesti
Piano di test di scalabilità
Prima di creare effettivamente i test, sviluppate un piano di test dettagliato. Si tratta di un passaggio importante per garantire che il test sia conforme ai requisiti dell'applicazione.
Di seguito sono riportati gli attributi per la creazione di un ben definito Piano di test per i test di scalabilità.
- Passaggi per gli scriptLo script di test dovrebbe contenere passaggi dettagliati che determinino le azioni esatte che un utente dovrebbe eseguire.
- Dati di esecuzioneIl piano di test dovrebbe determinare tutti i dati di runtime necessari per interagire con l'applicazione.
- Test guidati dai datiSe gli script necessitano di dati variabili in fase di esecuzione, è necessario comprendere tutti i campi che richiedono tali dati.
Esempio di test di scalabilità
Consideriamo un negozio online che prevede 2,000 acquirenti contemporanei durante i saldi stagionali. Il team concorda innanzitutto su un criterio di successo: la transazione di pagamento deve completarsi in meno di tre secondi per il 95% degli utenti, con un tasso di errore inferiore all'1%.
Il test esegue quindi lo stesso script di navigazione, ricerca, carrello e pagamento con 250, 500, 1,000, 1,500 e 2,000 utenti virtuali. Il tempo di risposta si mantiene intorno ai due secondi fino a 1,000 utenti, scende a 2.8 secondi a 1,500 e raggiunge i nove secondi a 2,000, mentre l'utilizzo della CPU del database si attesta al 98%. Il limite di scalabilità è quindi di circa 1,500 utenti e il collo di bottiglia è rappresentato dal livello del database, non dai server applicativi che il team aveva previsto di aggiungere.
Strumenti per i test di scalabilità
Per i test di scalabilità è necessario uno strumento in grado di generare carico da più macchine contemporaneamente e di centralizzare i risultati. La scelta di solito dipende dal linguaggio di programmazione principale del team e dai protocolli da testare.
| Chiavetta | Scripting | più adatto a |
|---|---|---|
| Apache JMeter | Piani di test GUI e XML, Java basato | Ampia copertura dei protocolli, inclusi JDBC, JMS, LDAP e SOAP. |
| Grafana k6 | JavaScrittura o TypeScript | Test di API e microservizi integrati in una pipeline CI/CD |
| Gatling | Java, Kotlin o Scala DSL | Elevato numero di utenti virtuali per iniettore con report HTML dettagliati |
| Locusta | pianura Python | Python team che necessitano di estendere il client oltre HTTP |
| LoadRunner | Script simili al linguaggio C registrati in VuGen | Grandi infrastrutture aziendali con applicazioni legacy e pacchettizzate |
Runner ospitati nel cloud come BlazeMeterLoadView e Gatling Enterprise si basano su diversi di questi motori e vale la pena considerarli quando un test richiede decine di migliaia di utenti virtuali o traffico da più regioni geografiche. Una panoramica più ampia della categoria è disponibile nella guida a strumenti di test delle prestazioni.
Sfide e migliori pratiche nei test di scalabilità
Risultati di scalabilità più deludenti tracTorniamo alla configurazione di test anziché all'applicazione. Questi sono i problemi che si ripresentano e le abitudini che li prevengono.
Sfide comuni
- Ambienti di dimensioni ridotte — Un banco di prova con metà della memoria di produzione segnala un collo di bottiglia che non esiste in produzione.
- Modelli di carico di lavoro irrealistici — Gli script senza tempo di elaborazione o variazione dei dati accedono a cache che gli utenti reali non riuscirebbero a raggiungere.
- Risultati rumorosi — L'auto-scaling, la raccolta dei rifiuti e l'hardware cloud condiviso fanno sì che due esecuzioni identiche presentino risultati diversi.
- Osservabilità sottile — Senza metriche lato server, un risultato lento indica che qualcosa si è rotto, ma non cosa.
- Costo — Generare un numero molto elevato di richieste simultanee richiede una flotta dedicata di generatori di carico, il che può facilmente comportare un budget inferiore al previsto.
migliori pratiche
- Definire i criteri di superamento, come ad esempio una percentuale del tempo di risposta e un limite massimo per il tasso di errore, prima della prima esecuzione.
- Aumenta il carico gradualmente, secondo un piano prestabilito, e mantieni ogni livello per un tempo sufficiente a permettere al sistema di stabilizzarsi.
- Variare i dati di test per ciascun utente virtuale in modo che la memorizzazione nella cache non alteri i risultati.
- Raccogli metriche relative ad applicazioni, database e infrastruttura, oltre ai dati lato client.
- Archivia gli script di test nel sistema di controllo versione ed esegui un breve controllo di scalabilità su ogni build, quindi un test completo prima del rilascio.
- Confronta le tendenze tra le diverse build anziché valutare un singolo report isolatamente.
Test di scalabilità vs. test di carico
I due vengono spesso confusi perché entrambi applicano un carico. La differenza sta nella domanda a cui ognuno risponde: il test di scalabilità chiede fino a che punto il sistema può crescere, mentre test di carico chiede se è in grado di gestire il carico già previsto.
| Base | Test di scalabilità | Caricare i test |
|---|---|---|
| Focus | Si concentra sulle prestazioni di siti web, software, hardware e applicazioni quando vengono apportate modifiche alle dimensioni o al volume del sistema per soddisfare un'esigenza crescente. | Il test di carico si concentra sulla verifica di un'applicazione sotto carichi elevati, al fine di determinare a quale punto il tempo di risposta del sistema non è più adeguato. |
| Modello di carico | Il carico viene aumentato gradualmente e tra una fase e l'altra è possibile aggiungere risorse. | Il carico viene mantenuto al valore massimo previsto per una durata fissa. |
| Domanda con risposta | Fino a che punto può espandersi questo sistema e quali sono i suoi limiti? | Questo sistema raggiunge oggi gli obiettivi prefissati? |
| Uscita tipica | Un limite di scalabilità, un collo di bottiglia e un piano di capacità | Risultato positivo o negativo rispetto agli obiettivi di tempo di risposta e di produttività. |
Entrambi siedono sotto il test non funzionali ombrello accanto stress test, test di picco, prova di resistenza and test di volumee una strategia di performance matura di solito ne esegue diverse sugli stessi script.
