Cosa sono i test unitari, i test di integrazione, i test del fumo e i test di regressione?

Cosa sono i test unitari, i test di integrazione, i test del fumo e i test di regressione? Quali sono le differenze tra loro e quali strumenti posso usare per ognuno di essi?

Ad esempio, utilizzo JUnit e NUnit per test unitari e test di integrazione . Esistono strumenti per gli ultimi due, test del fumo o test di regressione ?

• Unit test : specificare e testare un punto del contratto del metodo singolo di una classe. Questo dovrebbe avere un ambito molto ristretto e ben definito. Dipendenze complesse e interazioni con il mondo esterno vengono respinte o derise .

• Test di integrazione : verifica della corretta interazione di più sottosistemi. C'è un intero spettro lì, dai test di integrazione tra due classi, ai test di integrazione con l'ambiente di produzione.

• Test del fumo (noto anche come controllo di integrità ) : un semplice test di integrazione in cui controlliamo solo che quando viene invocato il sistema in prova ritorni normalmente e non esploda.

  • Il test del fumo è sia un'analogia con l'elettronica, in cui il primo test si verifica quando si accende un circuito (se fuma, è male!) ...
  • ... e, a quanto pare , con un impianto idraulico , in cui un sistema di tubi viene letteralmente riempito dal fumo e quindi controllato visivamente. Se qualcosa fuma, il sistema perde.

• Test di regressione : test scritto quando è stato corretto un bug. Assicura che questo specifico bug non si verifichi più. Il nome completo è "test di non regressione". Può anche essere un test effettuato prima di modificare un'applicazione per assicurarsi che l'applicazione fornisca lo stesso risultato.

A questo aggiungerò:

• Test di accettazione : verifica che una funzionalità o un caso d'uso siano implementati correttamente. È simile a un test di integrazione, ma con un focus sul caso d'uso da fornire piuttosto che sui componenti coinvolti.

• Test di sistema : verifica un sistema come una scatola nera. Le dipendenze su altri sistemi vengono spesso derise o cancellate durante il test (altrimenti sarebbe più un test di integrazione).

• Controllo pre-volo : test che si ripetono in un ambiente simile alla produzione, per alleviare la sindrome delle "build sulla mia macchina". Spesso questo viene realizzato facendo un test di accettazione o fumo in un ambiente simile alla produzione.

• Unit test : un test automatico per testare il funzionamento interno di una classe. Dovrebbe essere un test autonomo che non è correlato ad altre risorse.
• Test di integrazione : un test automatico che viene eseguito su un ambiente, in modo simile ai test unitari ma con risorse esterne (db, accesso al disco)
• Test di regressione : dopo aver implementato nuove funzionalità o correzioni di bug, si verificano nuovamente gli scenari che hanno funzionato in passato. Qui descrivi la possibilità in cui le tue nuove funzionalità rompono le funzionalità esistenti.
• Test del fumo : primi test su cui i tester possono concludere se continueranno i test.

Ognuno avrà definizioni leggermente diverse e ci sono spesso aree grigie. Però:

• Unit test: funziona un pochino (il più isolato possibile)?
• Test di integrazione: questi due (o più) componenti funzionano insieme?
• Test del fumo: l'intero sistema (il più vicino possibile a un sistema di produzione possibile) si blocca ragionevolmente bene? (cioè siamo ragionevolmente sicuri che non creerà un buco nero?)
• Test di regressione: abbiamo inavvertitamente reintrodotto eventuali bug precedentemente risolti?

Una nuova categoria di test di cui sono appena venuto a conoscenza è il test canarino . Un test canarino è un test automatizzato e non distruttivo che viene eseguito regolarmente in un ambiente dal vivo , in modo tale che se dovesse mai fallire, è successo qualcosa di veramente brutto.

Esempi potrebbero essere:

• I dati che dovrebbero essere sempre disponibili solo in fase di sviluppo / testy sono apparsi dal vivo ?
• Non è stato possibile eseguire un processo in background?
• Un utente può accedere?

Risposta da uno dei migliori siti Web per le tecniche di test del software:

Tipi di test del software - elenco completo fare clic qui

È una descrizione piuttosto lunga e non ho intenzione di incollarlo qui: ma può essere utile per qualcuno che vuole conoscere tutte le tecniche di test.

Unit test: verifica che quel particolare componente (cioè classe) abbia creato o modificato le funzioni come previsto. Questo test può essere manuale o automatizzato, ma non si sposta oltre il limite del componente.

Test di integrazione: verifica che l'interazione di particolari componenti funzioni come previsto. I test di integrazione possono essere eseguiti a livello di unità o di sistema. Questi test possono essere manuali o automatizzati.

Test di regressione: verifica che non vengano introdotti nuovi difetti nel codice esistente. Questi test possono essere manuali o automatizzati.

A seconda dell'SDLC (a cascata , RUP , agile , ecc.) Particolari test possono essere eseguiti in 'fasi' o possono essere eseguiti tutti, più o meno, contemporaneamente. Ad esempio, i test unitari possono essere limitati agli sviluppatori che poi consegnano il codice ai tester per i test di integrazione e regressione. Tuttavia, un altro approccio potrebbe fare in modo che gli sviluppatori eseguano test unitari e un certo livello di test di integrazione e regressione (utilizzando un approccio TDD con integrazione continua e test automatici di regressione e unità).

Il set di strumenti dipenderà in gran parte dalla base di codice, ma ci sono molti strumenti open source per unit testing (JUnit). HP (Mercury) QTP o Borland's Silk Test sono entrambi strumenti per l'integrazione automatizzata e i test di regressione.

Unit test : test di un singolo modulo o componente indipendente in un'applicazione è noto per essere unit test. Il test dell'unità verrà eseguito dallo sviluppatore.

Test di integrazione : combinando tutti i moduli e testando l'applicazione per verificare che la comunicazione e il flusso di dati tra i moduli funzionino correttamente o meno. Questo test è stato eseguito anche dagli sviluppatori.

Test del fumo In un test del fumo controllano l'applicazione in modo superficiale e ampio. Nel test del fumo controllano la funzionalità principale dell'applicazione. In caso di problemi di blocco nell'applicazione, questi segnaleranno al team di sviluppo e il team di sviluppo lo risolverà, correggerà il difetto e lo restituirà al team di test. Ora il team di test controllerà tutti i moduli per verificare che le modifiche apportate in un modulo abbiano un impatto sull'altro modulo o meno. Nei test del fumo i casi di test sono scritti.

Il test di regressione che esegue ripetutamente gli stessi casi di test per garantire che il modulo invariato non causi alcun difetto. I test di regressione vengono sottoposti a test funzionali

TEST DI REGRESSIONE-

"Un test di regressione esegue nuovamente i test precedenti sul software modificato per garantire che le modifiche apportate al software corrente non influiscano sulla funzionalità del software esistente."

Volevo solo aggiungere e dare un po 'più di contesto sul perché abbiamo questi livelli di test, cosa significano veramente con esempi

Mike Cohn nel suo libro "Riuscire con Agile" ha inventato la "Piramide dei test" come un modo per affrontare i test automatizzati nei progetti. Esistono varie interpretazioni di questo modello. Il modello spiega che tipo di test automatici devono essere creati, quanto velocemente possono fornire feedback sull'applicazione in prova e chi scrive questi test. Esistono sostanzialmente 3 livelli di test automatizzati necessari per qualsiasi progetto e sono i seguenti.

Test unitari: testano il componente più piccolo dell'applicazione software. Questa potrebbe letteralmente essere una funzione in un codice che calcola un valore basato su alcuni input. Questa funzione fa parte di molte altre funzioni della base di codice hardware / software che costituisce l'applicazione.

Ad esempio - Prendiamo un'applicazione calcolatrice basata sul web. I componenti più piccoli di questa applicazione che devono essere testati in unità potrebbero essere una funzione che esegue l'addizione, un'altra che esegue la sottrazione e così via. Tutte queste piccole funzioni messe insieme compongono l'applicazione calcolatrice.

Storicamente lo sviluppatore scrive questi test in quanto sono generalmente scritti nello stesso linguaggio di programmazione dell'applicazione software. A tale scopo vengono utilizzati framework di unit test come JUnit e NUnit (per Java), MSTest (per C # e .NET) e Jasmine / Mocha (per JavaScript).

Il più grande vantaggio dei test unitari è che corrono molto velocemente sotto l'interfaccia utente e possiamo ottenere un rapido feedback sull'applicazione. Ciò dovrebbe comprendere oltre il 50% dei test automatici.

Test API / di integrazione: testano insieme vari componenti del sistema software. I componenti potrebbero includere database di test, API (Application Programming Interface), strumenti e servizi di terze parti insieme all'applicazione.

Ad esempio: nel nostro esempio di calcolatrice di cui sopra, l'applicazione Web potrebbe utilizzare un database per archiviare valori, utilizzare API per eseguire alcune convalide lato server e potrebbe utilizzare uno strumento / servizio di terze parti per pubblicare risultati sul cloud per renderlo disponibile su diversi piattaforme.

Storicamente uno sviluppatore o un QA tecnico avrebbe scritto questi test usando vari strumenti come Postman, SoapUI, JMeter e altri strumenti come Testim.

Eseguono molto più velocemente dei test dell'interfaccia utente poiché continuano a funzionare sotto il cofano, ma possono richiedere un po 'più di tempo rispetto ai test unitari poiché devono controllare la comunicazione tra i vari componenti indipendenti del sistema e garantire che abbiano una perfetta integrazione. Ciò dovrebbe comprendere oltre il 30% dei test automatizzati.

Test dell'interfaccia utente: infine, disponiamo di test che convalidano l'interfaccia utente dell'applicazione. Questi test sono generalmente scritti per testare i flussi end-to-end attraverso l'applicazione.

Ad esempio - Nell'applicazione calcolatrice, potrebbe essere un flusso end-to-end, aprendo il browser-> Accesso all'URL dell'applicazione calcolatrice -> Accesso con nome utente / password -> Apertura dell'applicazione calcolatrice -> Esecuzione di alcune operazioni sulla calcolatrice -> verifica quei risultati dall'interfaccia utente -> Disconnessione dall'applicazione. Questo potrebbe essere un flusso end-to-end che sarebbe un buon candidato per l'automazione dell'interfaccia utente.

Storicamente, i QA tecnici o i tester manuali scrivono test dell'interfaccia utente. Usano framework open source come Selenium o piattaforme di test dell'interfaccia utente come Testim per creare, eseguire e mantenere i test. Questi test forniscono più feedback visivi quando puoi vedere come sono in esecuzione i test, la differenza tra i risultati attesi e quelli effettivi attraverso schermate, registri, rapporti di prova.

Il limite maggiore dei test dell'interfaccia utente è che sono relativamente lenti rispetto ai test a livello di unità e API. Pertanto, dovrebbe comprendere solo il 10-20% dei test automatizzati complessivi.

I prossimi due tipi di test possono variare in base al progetto, ma l'idea è-

Test del fumo

Questa può essere una combinazione dei precedenti 3 livelli di test. L'idea è di eseguirlo durante ogni check in del codice e assicurarsi che le funzionalità critiche del sistema funzionino ancora come previsto; dopo che le nuove modifiche al codice sono state unite. In genere devono funzionare con 5-10 minuti per ottenere un feedback più rapido sugli errori

Test di regressione

Di solito vengono eseguiti almeno una volta al giorno e coprono varie funzionalità del sistema. Assicurano che l'applicazione funzioni ancora come previsto. Sono più dettagli dei test del fumo e coprono più scenari dell'applicazione inclusi quelli non critici.

I test unitari sono diretti nella parte più piccola possibile dell'implementazione. In Java questo significa che stai testando una singola classe. Se la classe dipende da altre classi, queste sono false.

Quando il tuo test chiama più di una classe, è un test di integrazione .

L'esecuzione di suite di test completi può richiedere molto tempo, quindi dopo una modifica molti team eseguono alcuni test rapidi per completare per rilevare rotture significative. Ad esempio, gli URI sono stati suddivisi in risorse essenziali. Questi sono i test del fumo .

I test di regressione vengono eseguiti su ogni build e consentono di refactoring in modo efficace catturando ciò che si interrompe. Qualsiasi tipo di test può essere un test di regressione, ma trovo che i test unitari siano molto utili per trovare la fonte dell'errore.

• Test di integrazione: il test di integrazione è l'integrazione di un altro elemento
• Test del fumo: il test del fumo è anche noto come test della versione build. Il test del fumo è il processo di test iniziale utilizzato per verificare se il software sottoposto a test è pronto / stabile per ulteriori test.
• Test di regressione: il test di regressione è un test ripetuto . Se il nuovo software viene eseguito o meno in un altro modulo.
• Test unitari: è un test in scatola bianca. Solo gli sviluppatori coinvolgere in esso

Test unitari: esegue sempre lo sviluppatore dopo lo sviluppo per scoprire il problema dal lato test prima di preparare qualsiasi requisito per il controllo qualità.

Test di integrazione: significa che il tester deve verificare la verifica da modulo a modulo secondario quando alcuni dati / funzioni vengono inviati a un modulo verso un altro modulo. O nel tuo sistema se utilizzi strumenti di terze parti che utilizzano i dati del tuo sistema per integrarli.

Test del fumo: tester eseguito per verificare il sistema per test di alto livello e provare a scoprire il bug dello stopper di show prima che le modifiche o il codice diventino effettivi.

Test di regressione: Tester ha eseguito la regressione per la verifica della funzionalità esistente a causa di modifiche implementate nel sistema per un nuovo miglioramento o modifiche nel sistema.

Test unitari

I test unitari vengono generalmente eseguiti da parte degli sviluppatori, mentre i tester sono parzialmente evoluti in questo tipo di test in cui i test vengono eseguiti unità per unità. In Java JUnit i casi di test possono anche essere possibili per verificare se il codice scritto è progettato perfettamente o no.

Test d'integrazione:

Questo tipo di test è possibile dopo il test dell'unità quando tutti / alcuni componenti sono integrati. Questo tipo di test farà in modo che, quando i componenti sono integrati, influiscono sulle reciproche capacità o funzionalità di lavoro?

Test del fumo

Questo tipo di test viene eseguito alla fine quando il sistema viene integrato correttamente e pronto per essere utilizzato sul server di produzione.

Questo tipo di test farà in modo che ogni funzionalità importante dall'inizio alla fine funzioni correttamente e che il sistema sia pronto per la distribuzione sul server di produzione.

Test di regressione

Questo tipo di test è importante per verificare che difetti involontari / indesiderati non siano presenti nel sistema quando lo sviluppatore ha risolto alcuni problemi. Questo test assicura inoltre che tutti i bug siano stati risolti correttamente e per questo motivo non si sono verificati altri problemi.

I test di fumo e sanità mentale vengono entrambi eseguiti dopo la creazione di un software per identificare se iniziare i test. La sanità mentale può o meno essere eseguita dopo il test del fumo. Possono essere eseguiti separatamente o allo stesso tempo - la sanità mentale è immediatamente dopo il fumo.

Poiché i test di integrità sono più approfonditi e richiedono più tempo, nella maggior parte dei casi vale la pena essere automatizzati.

Il test del fumo di solito non richiede più di 5-30 minuti per l'esecuzione. È più generale: controlla un numero limitato di funzionalità di base dell'intero sistema, al fine di verificare che la stabilità del software sia sufficientemente buona per ulteriori test e che non vi siano problemi, bloccando l'esecuzione dei casi di test pianificati.

I test di integrità sono più dettagliati del fumo e possono richiedere da 15 minuti a un'intera giornata, a seconda della scala della nuova costruzione. È un tipo più specializzato di test di accettazione, eseguito dopo la progressione o il riesame. Verifica le funzionalità principali di alcune nuove funzionalità e / o correzioni di bug insieme ad alcune funzionalità strettamente correlate ad esse, al fine di verificare che funzionino secondo la logica operativa richiesta, prima che i test di regressione possano essere eseguiti su larga scala.

Ci sono già alcune buone risposte, ma vorrei perfezionarle ulteriormente:

Il test unitario è l'unica forma di test in scatola bianca qui. Gli altri sono test della scatola nera. Test in white box significa che conosci l'input; conosci il funzionamento interno del meccanismo e puoi controllarlo e conosci l'output. Con il test della scatola nera sai solo qual è l'input e quale dovrebbe essere l'output.

Quindi chiaramente i test unitari sono l'unico test in white box qui.

• Test di unità test specifici pezzi di codice. Di solito metodi.
• Test di integrazione verifica se il tuo nuovo software può essere integrato con tutto il resto.
• Test di regressione. Questo è un test fatto per assicurarti di non aver rotto nulla. Tutto ciò che funzionava dovrebbe ancora funzionare.
• Il test del fumo viene eseguito come test rapido per assicurarsi che tutto appaia bene prima di essere coinvolto nei test più vigorosi.

I test del fumo sono già stati spiegati qui ed è semplice. I test di regressione rientrano nei test di integrazione.

I test automatizzati possono essere divisi in soli due.

Test unitari e test di integrazione (questo è tutto ciò che conta)

Chiamerei la frase "test lungo" (LT) per tutti i test come test di integrazione, test funzionali, test di regressione, test dell'interfaccia utente, ecc. E test unitari come "test brevi".

Un esempio LT potrebbe essere, il caricamento automatico di una pagina Web, l'accesso all'account e l'acquisto di un libro. Se il test ha esito positivo, è più probabile che venga eseguito sul sito live allo stesso modo (da cui il riferimento "sonno migliore"). Lunga = distanza tra la pagina Web (inizio) e il database (fine).

E questo è un ottimo articolo che discute i vantaggi dei test di integrazione (test lunghi) rispetto ai test unitari .

Test di regressione: è un tipo di test del software in cui proviamo a coprire o verificare la correzione dei bug . La funzionalità attorno alla correzione di bug non dovrebbe essere cambiata o alterata a causa della correzione fornita. I problemi riscontrati in tale processo sono chiamati problemi di regressione .

Test del fumo: viene eseguito un tipo di test per decidere se accettare la build / il software per ulteriori test QA.