Differenza tra Test di Unità, Regressione, Integrazione, Sistema e Accettazione

Differenza tra Test di Unità, Regressione, Integrazione, Sistema e Accettazione

In base all’obiettivo preposto ed il livello di software considerato nelle singole attività di testing, si differenziano le seguenti tipologie:

  1. Test di Unità (o Unit Test);
  2. Test di Regressione (o Regression Test);
  3. Test di Integrazione (o Integration Test);
  4. Test di Sistema (o System Test);
  5. Test di Accettazione (o Acceptance test sia Alpha Testing che Beta Testing).

I modelli di sviluppo, in base alla fase del progetto corrente, utilizzano tipologie di testing differenti.

Differenza tra Test di Unità, Regressione, Integrazione, Sistema e Accettazione

Test di Unità

Gli Unit Test o letteralmente Test di Unità è l’attività volta a determinare la correttezza e completezza, rispetto ai requisiti, di un programma visto come singolo modulo.
Riconosciuto come modello standardizzato da IEEE (1008-1987), è composto dalle seguenti attività:

  1. Pianificazione dell’approccio, risorse e tempistiche previste;
  2. Individuazione delle caratteristiche da testare;
  3. Determinazione dell’insieme di test;
  4. Esecuzione dei test;
  5. Verifica se altri test sono necessari;
  6. Valutazione dei risultati.

Il concetto di unità o isolamento del modulo, comporta particolare attenzione per i riferimenti a servizi derivanti da componenti esterni. Essi vengono simulati attraverso l’uso di “Stubs” o “Driver” per “sostituire” o “pilotare” il flusso di controllo del singolo test inerente al contesto che si sta testando. Altre tecniche di simulazioni prevedono il “Mock” o “Fake” dei dati utilizzati per non accedere ai sistemi esterni e poter testare la sola unità di codice sorgente, simulando il valore del dato che normalmente è fornito dal sistema esterno.

Test di Regressione

Ad ogni aggiornamento di un modulo software la nuova versione deve mantenere le funzionalità di quella precedente. Un test di regressione considera il caso di verifica di questa compatibilità attraverso l’esecuzione dei due programmi (vecchio e nuovo) sugli stessi dati (eventualmente convertiti nel nuovo formato) ed il successivo confronto dei risultati.
I test di regressione possono essere fatti a livello di singolo modulo o sull’intera test suite.

Test di Integrazione

Questa tipologia di test, verifica la correttezza funzionale nell’iterazione tra più moduli. Di seguito diverse tecniche per testare l’integrazione tra i moduli:

  • Assemblare i moduli tra loro in modo incrementale;
  • Assemblare produttori prima dei consumatori dove la verifica dei primi fornisce ai secondi un flusso di controllo (chiamate) e flusso dei dati già corretti;
  • Assemblare tutti i moduli e testare il sistema come unità (anche detto “Big Bang Test”, letteralmente “prova a grande scoppio”).

Ogni singolo test di integrazione normalmente fa riferimento ad un flusso operativo dell’applicazione.

Test di Sistema

Per sistema si intende l’applicativo software completo, messo in esercizio ed arrivato all’obiettivo del progetto. Il test di sistema è volto a testare particolari proprietà globali di esso. Si possono quindi distinguere :

  1. Test di stress: per verificare le proprietà del sistema in condizioni di sovraccarico;
  2. Test di robustezza: per verificare le proprietà del sistema quando i dati trattati non sono corretti;
  3. Test di sicurezza: per verificare le proprietà di sicurezza del sistema.

Test di Accettazione

I Test di Accettazione fanno parte dell’ultima fase prima della messa in esercizio. Sulla base di dati forniti dall’utente, viene testata una speciale versione del software chiamata “Alpha Testing“. Successivamente è possibile rilasciare in produzione oppure utilizzare una seconda metodologia, che potrà essere utilizzata ad ogni rilascio. Essa consiste nella messa in produzione di una versione del programma chiamata “Beta Testing“, disponibile per pochi utenti finali che svolgeranno l’attività di accettazione usando il sistema ad un prezzo vantaggioso per riportarne gli eventuali problemi. In questo secondo caso dopo le correzioni segnalate, la nuova versione verrà rilasciata a tutti gli utenti finali. Questa seconda metodologia si adotta quando la mole di utenti finale è alta ed il sistema è molto complesso.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *