Differenza tra Test di unità, Test di sistema, Test di integrazione e Test di regressione

Differenza tra Test di unità, Test di sistema, Test di integrazione e Test di regressione

Differenza tra Test di unità, Test di sistema, Test di integrazione e Test di regressione

Test di unità

I test di unità vengono effettuati sulle singole unità di un programma ed hanno l’obiettivo di esaminare un componente individuale che è stato modificato oppure introdotto per la prima volta. Ogni test che ha come obiettivo di validare un singolo modulo deve essere presentato con la relativa documentazione tecnica in allegato, la quale conterrà tra le altre informazioni gli output che ci si aspetta che il modulo testato fornisca. I test di unità si focalizzano sulla funzionalità e affidabilità del software e sono svolti in una fase di test precedente all’integrazione del sistema. Se durante un test di unità venisse scoperto un difetto, verrebbe valutata la sua natura e l’impatto che questo può avere sul sistema generale; l’obiettivo è quello di risolverlo prima che il modulo testato venga approvato.

Test di sistema

I test di sistema vengono svolti su tutti i componenti e i moduli nuovi o modificati che caratterizzano un prodotto. L’obiettivo è quello di capire come i diversi blocchi unitari interagiscano tra di loro e se forniscano complessivamente gli output richiesti; viene posto l’accento sulla validazione e verifica dei requisiti di sistema e su come i singoli moduli lavorano tra di loro quando vengono connessi. Solitamente i test sul sistema sono più di uno: particolare menzione merita il primo (definito normalmente “smoke test”), il quale ha l’obiettivo di studiare a grandi linee come il programma si comporta e se le funzioni principali vengono svolte correttamente, senza soffermarsi sui dettagli. I test sull’intero sistema richiedono molto tempo, in quanto è necessario effettuarne un numero elevato per poter analizzare tutti i possibili scenari che possono verificarsi; il Test Plan in questo frangente ricopre un ruolo molto delicato, perché contiene la descrizione delle casistiche dei test, la sequenza in cui questi devono essere effettuati e la documentazione necessaria per elencarne i risultati. Quando viene scoperto e sistemato un errore, il test deve essere nuovamente effettuato, per accertarsi che le correzioni apportate non abbiano avuto influenze negative su componenti che precedentemente non presentavano errori (il test di regressione già citato in precedenza).

Test di integrazione

Dopo aver provveduto ai diversi test di sistema, è necessario accertarsi che il programma sviluppato fornisca i risultati desiderati anche se viene eseguito in ambienti diversi da quello nativo: risulta quindi necessario effettuare dei test di integrazione, nei quali il prodotto viene testato in concomitanza di altre interfacce e applicazioni. A differenza dei test di sistema, in quelli di integrazione non è necessario effettuare nuovamente la prova se viene scoperto un difetto dopo che questo è stato sistemato. I test di integrazione sono divisi in diversi gruppi e possono essere effettuati o meno a seconda dell’applicazione che deve essere testata:

  • Test di compatibilità: garantiscono che l’applicazione lavori con differenti configurazioni in base a quelli che ha a disposizione l’utente
  • Test di performance: valutano la capacità dell’applicazione di funzionare correttamente quando, ad esempio, più utenti la utilizzano contemporaneamente oppure il numero di input aumenta
  • Test di stress: testano il corretto funzionamento dell’applicazione quando questa viene stressata con carichi di lavoro inusuali
  • Test di carico: sono il complemento di quelli di stress e valutano il funzionamento dell’applicazione sotto normali carichi di lavoro

Test di regressione

Il test di regressione, già menzionato nei paragrafi precedenti, viene effettuato ogni volta che la procedura di un pezzo di programma viene modificata in seguito all’identificazione di un difetto; quando un errore viene corretto, nasce la possibilità che ne venga introdotto involontariamente uno nuovo: si ha perciò l’introduzione dell’incertezza circa la capacità dell’applicazione di ripetere nuovamente tutte le funzioni svolte in precedenza in modo corretto. Il test di regressione viene solitamente svolto in parallelo con altri test e può essere visto come un controllo di qualità per assicurarsi che il codice appena modificato continui a svolgere correttamente le funzioni che non sono state oggetto di modifica e che rispetti gli stessi requisiti verificati in precedenza. In conclusione, si può affermare che il test di regressione si assicura che il resto dell’applicazione non soggetta a modifiche non risulti affetta da errori nati dalla correzione di altri.

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 *