Differenza tra unit test, test di sistema, test di integrazione e test di regressione

Unità di test

Unità di test vengono effettuati sulle singole unità immobiliari di un programma e che sono destinate ad esaminare un singolo componente che è stato modificato o introdotto per la prima volta. Ogni test che mira a validare un singolo modulo deve essere presentato con la relativa documentazione tecnica allegata, che conterrà tra le altre informazioni gli output che il modulo testato dovrebbe fornire. Gli unit test si concentrano sulla funzionalità e l’affidabilità del software e vengono eseguiti in una fase di test prima dell’integrazione del sistema. Se un difetto fosse scoperto durante un test unitario, la sua natura e l’impatto sul sistema generale sarebbero valutati; l’obiettivo è risolverlo prima che il modulo testato sia approvato.

System test

System test vengono eseguiti su tutti i componenti e moduli nuovi o modificati che caratterizzano un prodotto. L’obiettivo è capire come i diversi blocchi unitari interagiscono tra loro e se forniscono gli output richiesti nel complesso; l’enfasi è posta sulla convalida e la verifica dei requisiti di sistema e su come i singoli moduli lavorano insieme quando sono collegati. Di solito i test sul sistema sono più di uno: il primo merita una menzione speciale (normalmente chiamato “smoke test”), che mira a studiare in termini generali come si comporta il programma e se le funzioni principali vengono eseguite correttamente, senza soffermarsi sui dettagli. Test sull’intero sistema di prendere un lungo periodo di tempo, in quanto è necessario effettuare un gran numero di per analizzare tutti i possibili scenari che possono verificarsi; il Piano di Test, in questo frangente, gioca un ruolo delicato, perché contiene la descrizione dei casi di test, la sequenza in cui devono essere eseguiti e la documentazione necessaria per l’elenco dei risultati. Quando viene rilevato e corretto un errore, il test deve essere nuovamente eseguito per garantire che le correzioni apportate non abbiano avuto alcuna influenza negativa su componenti che in precedenza non avevano errori (il test di regressione già menzionato sopra).

Integration test

Dopo aver eseguito i vari test di sistema, è necessario assicurarsi che il programma sviluppato fornisca i risultati desiderati anche se viene eseguito in ambienti diversi da quello nativo: è quindi necessario effettuare test di integrazione, in cui il prodotto viene testato insieme ad altre interfacce e applicazioni. A differenza dei test di sistema, nei test di integrazione non è necessario testare nuovamente se un difetto viene scoperto dopo che è stato risolto. I test di integrazione sono suddivisi in diversi gruppi e possono essere eseguiti o meno a seconda dell’applicazione da testare:

• Test di compatibilità: garantire che l’applicazione funzioni con diverse configurazioni in base a quelle disponibili per l’utente
• Test delle prestazioni: valutano la capacità dell’applicazione di funzionare correttamente quando, ad esempio, più utenti la utilizzano contemporaneamente o il numero di ingressi aumenta
• Stress test: testano il corretto funzionamento dell’applicazione quando viene sollecitata con carichi di lavoro insoliti
• Test di carico: essi sono complementari agli stress test e valutare il funzionamento dell’applicazione in condizioni normali carichi di lavoro

test di Regressione

Il test di regressione, già accennato nel paragrafo precedente, è effettuata ogni volta che la procedura di un programma pezzo è modificato in seguito all’identificazione di un difetto; quando un errore è stato corretto, la possibilità che sorga un nuovo introdotto involontariamente: c’è quindi l’introduzione di incertezza circa la capacità dell’applicazione di ripetere il tutto eseguito in precedenza funzioni correttamente. Il test di regressione viene solitamente eseguito in parallelo ad altri test e può essere visto come un controllo di qualità per garantire che il codice appena modificato continui a svolgere correttamente le funzioni che non sono state modificate e che soddisfi gli stessi requisiti verificati in precedenza . In conclusione, si può affermare che il test di regressione garantisce che il resto dell’applicazione non soggetto a modifiche non sia influenzato da errori derivanti dalla correzione di altri.