C'è qualcuno che può definire chiaramente questi livelli di test perché trovo difficile differenziarli quando si eseguono TDD o unit test. Per favore, se qualcuno può elaborare come, quando implementarli?
Risposte:
Brevemente:
Test unitario : si esegue il test unitario di ogni singola parte di codice. Pensa a ogni file o classe.
Test di integrazione : quando si mettono insieme più unità che interagiscono, è necessario condurre test di integrazione per assicurarsi che l'integrazione di queste unità insieme non abbia introdotto errori.
Test di regressione : dopo l'integrazione (e forse la correzione) è necessario eseguire nuovamente i test unitari. Questo è un test di regressione per garantire che ulteriori modifiche non abbiano interrotto le unità già testate. Lo unit test che hai già eseguito ha prodotto gli unit test che possono essere eseguiti più volte per i test di regressione.
Test di accettazione : quando un utente / cliente / azienda riceve la funzionalità, (o il reparto di test) condurrà i test di accettazione per garantire che la funzionalità soddisfi i loro requisiti.
Potresti anche voler indagare sui test white box e black box. Ci sono anche prestazioni e test di carico e test delle "ilities" da considerare.
Unit test: quando fallisce, ti dice quale parte del tuo codice deve essere aggiustata.
Test di integrazione: quando fallisce, ti dice che i pezzi della tua applicazione non stanno lavorando insieme come previsto.
Test di accettazione: quando fallisce, ti dice che l'applicazione non sta facendo quello che il cliente si aspetta che faccia.
Test di regressione: quando fallisce, ti dice che l'applicazione non si comporta più come una volta.
Ecco una semplice spiegazione per ciascuno dei test menzionati e quando sono applicabili:
Test unitario Un test unitario viene eseguito su un'unità autonoma (di solito una classe o un metodo) e deve essere eseguito ogni volta che un'unità è stata implementata o l'aggiornamento di un'unità è stato completato.
Ciò significa che viene eseguito ogni volta che hai scritto una classe / metodo, corretto un bug, modificato funzionalità ...
Test di integrazione Il test di integrazione mira a testare quanto bene diverse unità interagiscono tra loro. Questo tipo di test dovrebbe essere eseguito ogni volta che è stata stabilita una nuova forma di comunicazione tra le unità o la natura della loro interazione è cambiata.
Ciò significa che viene eseguito ogni volta che un'unità scritta di recente è integrata nel resto del sistema o ogni volta che un'unità che interagisce con altri sistemi è stata aggiornata (e completato con successo i suoi test unitari).
Test di regressione I test di regressione vengono eseguiti ogni volta che qualcosa è stato modificato nel sistema, al fine di verificare che non siano stati introdotti nuovi bug.
Ciò significa che viene eseguito dopo tutte le patch, gli aggiornamenti e le correzioni di bug. Il test di regressione può essere visto come un caso speciale di unit test e test di integrazione combinati.
Test di accettazione I test di accettazione vengono eseguiti ogni volta che è importante verificare che un sottosistema (possibilmente l'intero sistema) soddisfi tutte le sue specifiche.
Ciò significa che viene eseguito principalmente prima di terminare un nuovo deliverable o annunciare il completamento di un'attività più ampia. Considera questo come il tuo controllo finale per vedere che hai davvero completato i tuoi obiettivi prima di correre dal cliente / capo e annunciare la vittoria.
Questo è almeno il modo in cui ho imparato, anche se sono sicuro che ci sono altri punti di vista opposti. Ad ogni modo, spero che aiuti.
Ci proverò:
Unit Test: il mio metodo singolo funziona correttamente? (NO dipendenze o dipendenze derise)
Test di integrazione: i miei due moduli sviluppati separatamente funzionano correttamente quando messi insieme?
Test di regressione: ho rotto qualcosa modificando / scrivendo nuovo codice? (l'esecuzione di test di unità / integrazione con ogni commit è un test di regressione tecnicamente (automatizzato)). Più spesso utilizzato nel contesto del controllo di qualità - manuale o automatizzato.
Test di accettazione : test effettuato dal cliente, che "accetta" il SW consegnato
Non posso commentare (reputazione troppo bassa Sorry) quindi ...
@Andrejs fa un buon punto sulle differenze tra gli ambienti associati a ciascun tipo di test.
Gli unit test vengono eseguiti in genere sulla macchina degli sviluppatori (e possibilmente durante la compilazione di CI) con dipendenze simulate da altre risorse / sistemi.
I test di integrazione per definizione devono avere (un certo grado) di disponibilità di dipendenze; le altre risorse e sistemi vengono chiamati in modo che l'ambiente sia più rappresentativo. I dati per i test possono essere derisi o un piccolo sottoinsieme offuscato di dati di produzione reale.
Il test UAT / di accettazione deve rappresentare l'esperienza del mondo reale per i team di QA e aziendali che accettano il software. Quindi necessita di piena integrazione e volumi di dati realistici e set di dati completamente mascherati / offuscati per fornire prestazioni realistiche ed esperienza dell'utente finale.
È probabile che anche altre "malattie" richiedano che l'ambiente sia il più vicino possibile alla realtà per simulare l'esperienza di produzione, ad esempio test delle prestazioni, sicurezza, ...