Cos'è il test del volume? Impara con gli esempi
Tommaso Hamilton
⚡ Riepilogo intelligente
Il Volume Testing sottopone un'applicazione a una quantità molto elevata di dati per verificare come si comportano lo storage, le query e i tempi di risposta al crescere del database. È anche chiamato flood testing e si basa sulla scalabilità dei dati anziché sul numero di utenti.
Cos'è il test del volume?
Test di volume è un tipo di test del software, in cui il software viene sottoposto a un enorme volume di dati. Viene anche indicato come test di inondazione. Il test del volume viene eseguito per analizzare le prestazioni del sistema aumentando il volume dei dati nel database.
Con l'aiuto del test del volume, è possibile studiare l'impatto sui tempi di risposta e sul comportamento del sistema quando esposto a un volume elevato di dati.
Ad esempio, un servizio di streaming musicale potrebbe essere testato con un catalogo di 50 milioni tracks e una tabella di cronologia di ascolto contenente miliardi di righe, per verificare se le query di ricerca e raccomandazione restituiscono ancora risultati in tempi accettabili.
Si noti la distinzione: il test di volume aumenta il quantità di dati il sistema regge. Aumentando il numero di utenti simultanei è un test di carico, che è un test diverso con un obiettivo diverso.
Vantaggi del test del volume
- L'individuazione tempestiva dei problemi di capacità produttiva consente di evitare i costi ben più elevati necessari per risolverli in fase di produzione.
- Aiuta ad avviare più rapidamente i piani di scalabilità
- Identificazione precoce dei colli di bottiglia
- Garantisce che il tuo sistema sia ora in grado di essere utilizzato nel mondo reale
Perché eseguire test di volume?
L'obiettivo dell'esecuzione del test del volume è quello di
- Controlla le prestazioni del sistema con l'aumento dei volumi di dati nel database
- Identificare i problemi che probabilmente si presenteranno quando il set di dati diventerà grande
- Per capire il punto in cui la stabilità del sistema degrada
- Il test del volume aiuterà a identificare la capacità del sistema o dell'applicazione: volume normale e pesante
Come eseguire il test del volume
Nei test di volume, è necessario testare le seguenti cose
- Test per verificare se c'è qualche perdita di dati
- Controllare il tempo di risposta del sistema
- Controlla se i dati sono memorizzati correttamente o meno
- Verificare se i dati vengono sovrascritti senza alcuna notifica
- Verifica che gli avvisi e i messaggi di errore vengano effettivamente visualizzati al raggiungimento di un limite di volume.
- Controlla se un volume elevato di dati influisce sulla velocità di elaborazione
- Verificare che il sistema disponga delle risorse di memoria e di archiviazione necessarie al volume.
- Verificare che il test di volume copra l'intero sistema e non un singolo componente.
- Esiste qualche rischio se il volume dei dati è maggiore di quanto specificato
- Verificare se esiste una garanzia che il volume dei dati non supererà il massimo specificato
Migliori pratiche per test ad alto volume
Molte delle pratiche descritte di seguito sono comuni ai test di carico, poiché entrambi vengono generalmente eseguiti nello stesso ambiente. Quelle specifiche per i test di volume riguardano il set di dati stesso:
- Arrestare tutti i server e controllare tutti i registri
- Prima del test di carico, eseguire manualmente lo scenario dell'applicazione
- Per ottenere risultati più utili, scaglionare il numero di utenti
- Per superare i vincoli di licenza, bilancia il tempo di riflessione
- Sii cauto con la nuova build
- Analizzare il caso d'uso per migliorarlo una volta stabilita una linea di base
- Una ripetizione di parti particolari del test del volume diventa inevitabile nel caso in cui si verifichi un collo di bottiglia nelle prestazioni
Test di volume vs test di carico
| Test di volume | Caricare i test |
|---|---|
|
|
|
|
Sfide nei test di volume
- Frammentazione della memoria difficile da generare
- Generazione dinamica delle chiavi
- Relazionale Integrity di dati generati
Come si confronta questo test con altri test di performance?
I test di prestazione sono una famiglia di test che si differenziano per la forma del carico applicato, motivo per cui sono così facilmente confusi.
| Tipo di test | Cosa aumenta? | Domanda a cui risponde |
|---|---|---|
| Test di carico | Utenti simultanei, fino al picco previsto | Raggiunge gli obiettivi prefissati in condizioni di traffico di punta normali? |
| Test volumetrico | Dati contenuti nel database | Riesce a gestire la crescita del set di dati? |
| Test da sforzo | Caricare oltre la capacità, fino al cedimento | Dove si rompe e in che modo? |
| Test delle punte | Carica, istantaneamente ed estremamente | Riesce a sopravvivere e a riprendersi da uno shock? |
| Test di resistenza | Durata, a carico normale | Le prestazioni si degradano nel tempo? |
| Test di immersione | Durata, risorse di visualizzazione | Sono presenti perdite di memoria o di handle? |
| Test di stabilità | Condizioni variabili | Rimane affidabile al variare delle condizioni? |
La distinzione che conta di più qui è: I test di volume scalano i dati, i test di carico scalano il numero di utenti. Un report che impiega due secondi per elaborare diecimila righe e due minuti per elaborarne dieci milioni presenta un problema di volume, non di carico, e nessuna quantità di capacità aggiuntiva del server potrà risolverlo.
Come generare dati di test per i test di volume
La sezione dedicata alle sfide evidenzia che la generazione di dati realistici è la parte più difficile dei test di volume. In pratica si utilizzano quattro approcci, ognuno dei quali comporta un compromesso.
| Approccio | Realismo | Svantaggio principale |
|---|---|---|
| Copia dei dati di produzione | Massimo | Rischi legati alla privacy e alla conformità normativa |
| Copia di produzione mascherata | Alto | La mascheratura può compromettere l'integrità referenziale |
| generazione sintetica | Medio | Le distribuzioni potrebbero non corrispondere alla realtà |
| Traffico di produzione riprodotto | Alto | Richiede un'infrastruttura di acquisizione |
Qualunque percorso si scelga, tre proprietà devono essere soddisfatte, altrimenti il test non misura nulla di utile.
- Integrità referenziale. Ogni chiave esterna deve essere risolvibile. Un milione di righe orfane mettono alla prova il motore di archiviazione, ma non i percorsi di join effettivamente utilizzati dall'applicazione.
- Cardinalità realistica. Se la tabella di produzione contiene dieci milioni di righe relative a duecento clienti, la generazione di dieci milioni di righe relative a dieci milioni di clienti produce piani di query completamente diversi.
- Distribuzione realistica. I dati reali sono distorti. I dati generati in modo uniformemente casuale nascondono le partizioni critiche e i conflitti di indicizzazione che causano incidenti in produzione.
Un avvertimento pratico sulla privacy. Copiare i dati di produzione in un ambiente di test è la causa più comune di violazione dei dati durante le fasi di test. Mascherare i campi personali prima che la copia lasci l'ambiente di produzione, non dopo.
