Che cosa è di Unit test, Test di Integrazione, test del Fumo, Test di Regressione?

https://stackoverflow.com/questions/520064

21-08-2019
|

Domanda

Che cosa è di Unit test, Test di Integrazione, test del Fumo, Test di Regressione e quali sono le differenze tra di loro?E Che strumenti posso usare per ognuno di loro?

Per esempio io uso JUnit e NUnit per i test di Unità e Test di Integrazione.Ci sono il Fumo di Test o Test di Regressione di strumenti?

Soluzione

prova Unità : specificare e testare un punto del contratto di singolo metodo di una classe. Questo dovrebbe avere un campo di applicazione molto limitato e ben definito. dipendenze complesse e interazioni con il mondo esterno sono stubbed o deriso .
test di integrazione : testare il corretto funzionamento del inter-più sottosistemi. C'è tutto lo spettro lì, dal test di integrazione tra le due classi, per l'integrazione di test con l'ambiente di produzione.
Smoke test (aka controllo di integrità) : un semplice test di integrazione, dove abbiamo appena controlliamo che, quando viene richiamato il sistema in prova restituisce normalmente e non saltare in aria.
- Le prove di 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 idraulici, in cui un sistema di tubi è letteralmente riempito da fumo e poi controllato visivamente. Semmai fuma, il sistema non è a tenuta.
test della regressione : un test che è stato scritto quando un bug è stato risolto. Assicura che questo specifico bug non si verificherà di nuovo. Il nome completo è "test di non regressione". Può essere un test effettuato anche prima di cambiare un'applicazione per assicurarsi che l'applicazione fornisce lo stesso risultato.

Per questo, vorrei aggiungere:

Test di collaudo : prova che una caratteristica o utilizzare caso sia correttamente attuate. È simile a un test di integrazione, ma con una particolare attenzione per il caso dell'uso di fornire piuttosto che sui componenti coinvolti.
Test del sistema : Test di un sistema come una scatola nera. Dipendenze da altri sistemi sono spesso derisi o estirpare spontaneamente durante la prova (altrimenti sarebbe più di un test di integrazione).
Controlli pre-volo : I test che si ripetono in un ambiente di produzione simile, per alleviare la 'si basa sulla mia macchina' sindrome. Spesso questo viene realizzato facendo una prova di accettazione o di fumo in una produzione come l'ambiente.

Altri suggerimenti

Unità di prova : un test automatico per testare il funzionamento interno di una classe. Dovrebbe essere un test stand-alone, che non è legato ad altre risorse.
Integrazione test : un test automatico che viene fatto su un ambiente, in modo simile al test di unità, ma con risorse esterne (db, accesso al disco)
test della regressione : scenari dopo l'implementazione di nuove funzionalità o correzioni di bug, si ri-test che ha lavorato in passato. Qui si coprono la possibilità in cui i vostri nuove funzionalità rompono funzioni esistenti.
test di fumo : primi test su cui i tester possono concludere se continueranno i test

Tutti avranno le definizioni leggermente diverse, e spesso ci sono zone grigie. Tuttavia:

Unità di prova: non questo uno po '(come isolato come possibile) funziona
test di integrazione: queste due (o più) componenti lavorano insieme
Smoke test: non l'intero sistema (il più vicino ad essere un sistema di produzione il più possibile) appendere insieme ragionevolmente bene? (Vale a dire siamo ragionevolmente sicuri che non creerà un buco nero?)
di test di regressione:? Abbiamo noi inavvertitamente reintrodotto eventuali bug avevamo già fissato

Una nuova categoria di test che ho appena venissero a conoscenza di è il:

prova Canarie

A Test Canarie è un sistema automatico, controlli non distruttivi che è eseguito su base regolare in Pubblicato l'ambiente, in modo tale che se mai riesce, qualcosa di veramente brutto è accaduto.

Gli esempi potrebbero essere:

ha dati che dovrebbero essere solo disponibile in DEV / TEST apparso in LIVE.
ha un processo in background non è riuscito a eseguire
Può un accesso utente

apocrifo curiosità storica: "test di fumo" deriva dall'ingegneria sottomarino (ereditato da idraulico) in cui il fumo letterale sarebbe pompato nello scafo per vedere se c'è ne è uscito ancora una volta, che sarebbe piuttosto un fallimento drammatico per un sottomarino!

Risposta da uno dei migliori siti web per le tecniche di Software Testing:

Tipi di Software Testing - Elenco completo Clicca qui

E 'piuttosto una lunga descrizione, non ho intenzione di incollarlo qui:., Ma può essere utile per chi vuole conoscere tutte le tecniche di testing

Spero che sarà utile:)

Unità di prova: Verifica quel particolare componente (cioè classe) creati o funzioni modificato come progettato. Questo test può essere manuale o automatico, ma non andare oltre il limite del componente.

Test Integration: Verifica che l'interazione di componenti particolari funzionare come previsto. test di integrazione possono essere eseguite a livello di unità o il livello di sistema. Questi test possono essere manuale o automatizzato.

Test di regressione: Verifica che i nuovi difetti non sono introdotti nel codice esistente. Questi test possono essere manuale o automatizzato.

A seconda della vostra SDLC (cascata, rup, agile, ecc) le prove particolari può essere eseguita in 'fasi' o possono tutti essere eseguite, più o meno, allo stesso tempo. Ad esempio, test di unità può essere limitata agli sviluppatori che poi girare il codice sopra ai tester per l'integrazione e test di regressione. Tuttavia un altro approccio può avere sviluppatori di fare test di unità e un certo livello di integrazione e di regressione (usando un approccio TDD insieme continuo di integrazione e unità automatizzata e test di regressione).

Il set di strumenti dipenderà in gran parte dalla base di codice, ma ci sono molti strumenti open source per unit testing (JUnit). (Mercurio) QTP di HP o SilkTest di Borland sono entrambi strumenti di test di integrazione e di regressione automatizzati.

unit test : test di singolo modulo o di un componente indipendente in un'applicazione si caratterizza per essere unit test, il test di unità sarà fatto da sviluppatore

test di integrazione :. Combinando tutti i moduli e testare l'applicazione per verificare la comunicazione e il flusso di dati tra i moduli funzionino correttamente o meno, questo test eseguiti anche da sviluppatori

test del fumo nel test del fumo controllano l'applicazione in maniera superficiale e in largo, durante le prove del fumo controllano la funzionalità principale dell'applicazione, se non v'è alcun problema bloccante nell'applicazione si riferirà al team di sviluppo, e il team di sviluppo sarà risolvere il problema e correggere il difetto, e dare di nuovo al test team e ora team di test controllerà tutti i moduli per verificare le modifiche apportate TAT in un modulo avrà un impatto l'altro modulo o no. IN FUMO COLLAUDO i casi di test sono script

test di regressione eseguire gli stessi casi di test ripetutamente per assicurare tat modulo invariato non provoca alcun difetto. Test di regressione è sotto collaudo funzionale

Testing di regressione -

"un test di regressione repliche test precedenti contro il software modificato per garantire che le modifiche apportate nel software attuale non influiscono sulla funzionalità del software esistente".

Unità di test è diretto alla parte più piccola della realizzazione possibile. In Java questo significa che si sta testando una singola classe. Se la classe dipende da altre classi di questi sono falsi.

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

test suite completa può richiedere molto tempo per l'esecuzione, così dopo un cambiamento di molte squadre corrono qualche rapido per completare i test per rilevare rotture significative. Per esempio, hai rotto gli URI di risorse essenziali. Queste sono le prove di fumo .

test regressione Esegui su ogni costruzione e consentono di refactoring in modo efficace con la cattura di quello che si rompe. Qualsiasi tipo di test può essere test di regressione, ma trovo test di unità sono più disponibile a trovare la fonte del guasto.

Test di regressione: Verifica che i nuovi difetti non sono introdotti nel codice esistente. Questi test possono essere manuale o automatizzato.

Un tipo di test che sembra essere degni di nota in questa discussione è prove di stress / prestazioni / carichi che potrebbero essere semplicemente messo come scoprire i limiti oltre che un certo pezzo di rotture software. Si noti che in termini di utensili è essenziale per determinare con precisione la portata di ciò che si propone di stress test da una prospettiva di sistema. Ad esempio nel caso di un test di stress "applicazione web" può includere nel suo ambito di applicazione web server stesso e quindi l'utensile potrebbe intervengono su tale estremità. Ecco un bel post su http carico test

Test di integrazione: Test di integrazione è il integrare l'altro elemento
Fumo Test: fumatrice test è noto anche come versione build di test Testing.Smoke è il processo di testing iniziale, esercitata per verificare se il software in prova è pronto / stabile per ulteriori test
Regression Testing: test di regressione è Reapeated Testing. Sia il nuovo software avviene in un altro modulo o meno.
Unit Testing: Si tratta di una scatola bianca test .Solo sviluppatori coinvolgere in esso

Unit Testing: - unit test viene solitamente effettuata dal lato sviluppatori, dove come tester sono parzialmente evoluti in questo tipo di test dove test è fatto unità per unità. In java Junit casi di test possono anche essere possibile verificare se il codice scritto è perfettamente progettato o meno.

Test di integrazione: - Questo tipo di test è possibile dopo il test delle unità quando tutti / alcuni componenti sono integrated.This tipo di test farà in modo che quando i componenti sono integrati, fanno influenzano ogni altri capacità o funzionalisti di lavoro.

Fumo di controllo: - Questo tipo di test è fatto all'ultimo quando il sistema è integrato con successo e pronto ad andare sul server di produzione. Questo tipo di test farà in modo che ogni multa funzionalità importante dall'inizio alla fine sta lavorando e il sistema è pronto per la distribuzione sul server di produzione.

Regression Testing: - Questo tipo di test è importante verificare che non intenzionali / difetti indesiderati non sono presenti nel sistema quando sviluppatore risolto alcuni problemi. Questo test anche fare in modo che tutti i bug sono risolti con successo e per questo sono verificati altri problemi.

Unit Test:Si esegue sempre dallo sviluppatore dopo il loro sviluppo fatto per scoprire rilascio da parte del proprio test di lato, prima di effettuare qualsiasi esigenza pronto per il QA.

Test Di Integrazione:Significa tester per verificare modulo sub modulo verifica quando alcuni dati/funzione di uscita sono auto da un modulo all'altro modulo.O il sistema in caso di utilizzo di tool di terze parti che utilizza i dati del sistema per integrare.

Prova Del Fumo:tester eseguita per verificare il sistema di un livello elevato di prova e cercando di scoprire tappo show bug prima o modifiche di codice entra nel vivo.

Test Di Regressione:Tester eseguita regressione per la verifica di funzionalità esistenti a causa di cambiamenti implementati nel sistema per i nuovi miglioramenti o cambiamenti nel sistema.

Fumo e collaudo sanità mentale sono entrambi eseguiti dopo una build software per identificare se avviare il test. Sanity può o non può essere eseguito dopo la prova di fumo. Essi possono essere eseguiti separatamente o contemporaneamente -. Sanity essendo immediatamente dopo il fumo

Perché test sanità è più approfondita e richiede più tempo, nella maggioranza dei casi è ben worthed da movimentare.

Le prove di fumo di solito non più di 5-30 minuti per l'esecuzione prende. E 'più generale: si verifica un piccolo numero di funzionalità di base di tutto il sistema, al fine di verificare che la stabilità del software è abbastanza buono per ulteriori test e che non ci sono problemi, bloccando la corsa dei casi di test in programma.

test Sanity è più dettagliata rispetto fumo e può richiedere da 15 minuti fino a un giorno intero, a seconda della scala della nuova costruzione. Si tratta di un tipo più specializzato di collaudo, effettuato dopo la progressione o ri-test. Esso controlla le caratteristiche fondamentali di talune nuove funzionalità e / o correzioni insieme con qualche strettamente legate alla loro funzionalità, al fine di verificare che funzionino come alla logica operativa richiesta, prima del test di regressione può essere eseguita in scala maggiore.

Alcune risposte buone già ma Desidero raffinarli:

Il test delle unità è l'unica forma di test white box qui. Gli altri sono test scatola nera. test white box significa che si conosce l'ingresso, si conosce il funzionamento interno del meccanismo e può controllare e si conosce l'output. Con il test scatola nera si conosce solo ciò che è l'ingresso e ciò che l'uscita dovrebbe essere.

Quindi, chiaramente test delle unità è l'unico test white box qui.

di test Unit testing pezzi specifici di codice. Di solito i metodi.
Integrazione di prova testare se il vostro nuovo pezzo caratteristica del software è in grado intergrate con tutto il resto.
test di regressione. Questo è il test fatto per rendere sicuri di non aver rotto niente. Tutto ciò che lavorava dovrebbe funzionare.
Il fumo è fatto come un rapido test per assicurarsi che tutto sia a posto prima di essere coinvolti nella sperimentazione più vigorosa.

Test di regressione - È un tipo di test SW dove cerchiamo di coprire o controllare tutto il Fix bug. la funzionalità di tutto il fix bug non dovrebbe avere cambiato o alterato a causa della correzione fornita. Problemi rilevati in tale processo sono chiamati come Regressione problemi.

Fumo Test:. È una sorta di test fatto per decidere se accettare Build / Software per ulteriori test QA

Smoke test è stato spiegato già qui ed è semplice. test di regressione viene sottoposto a test di integrazione.

I test automatici possono essere suddivisi in soli 2.

Unità di prova e di test di integrazione. (questo è tutto ciò che conta)

che chiamerei usare la frase "prova lunga" (LT) per tutti i test come test di integrazione, test funzionali, test di regressione, test di interfaccia utente, ecc E unit test come "breve test".

Un esempio potrebbe essere LT, il caricamento automatico di una pagina web, l'accesso al conto e l'acquisto di un libro. Se il test viene superato è più probabile per l'esecuzione in loco dal vivo allo stesso modo (da qui il 'sonno migliore' di riferimento). Lunga = distanza fra le pagine web (partenza) e di database (fine).

E questo è un grande articolo che discute i vantaggi di test di integrazione (lungo test) su unità di prova

Prove di unità I test unitari sono livello molto basso, vicino alla sorgente del tuo   applicazione. Essi consistono in test su singole metodi e funzioni   delle classi, componenti o dei moduli utilizzati dal software. Unità   test sono in generale abbastanza a buon mercato per automatizzare e può essere eseguito molto   rapidamente da un server di integrazione continua.

test di integrazione test di integrazione verificare che i diversi moduli o   servizi utilizzati dal vostro lavoro applicazione bene insieme. Ad esempio,   può essere testare l'interazione con il database o facendo in modo che   microservices lavorano insieme come previsto. Questi tipi di test sono più   costoso da eseguire in quanto richiedono più parti dell'applicazione di   essere installato e funzionante.

I test funzionali Test funzionali si concentrano sulle esigenze di business   di un'applicazione. Verificano solo l'uscita di un'azione e non lo fanno   controllare gli stati intermedi del sistema durante l'esecuzione che   azione.

A volte c'è una confusione tra i test di integrazione e   test funzionali in quanto entrambi richiedono più componenti per interagire   insieme. La differenza è che un test di integrazione semplicemente può   verificare che sia possibile interrogare il database durante un test funzionale sarebbe   si aspettano di ottenere un valore specifico dal database come definito dalla   requisiti del prodotto.

test end-to-end end-to-end testing replica un comportamento degli utenti con   il software in un ambiente applicativo completo. Si verifica che   vari utente scorre lavoro come previsto e può essere semplice come una loading   pagina web o la registrazione o molto scenari più complessi che verificano e-mail   notifiche, pagamenti online, etc ...

test end-to-end sono molto utili, ma sono costosi da eseguire e   può essere difficile da mantenere quando sono automatizzati. Si consiglia di   avere alcuni test chiave end-to-end e contare su più tipi di livello inferiore   test (test di unità e di integrazione) per essere in grado di identificare rapidamente   rompendo modifiche.

test di accettazione test di collaudo test formali eseguita per   Controllare se un sistema soddisfa i suoi requisiti di business. Richiedono   l'intera applicazione per essere installato e funzionante e concentrarsi sulla replica   comportamenti degli utenti. Ma possono anche andare oltre e misurare la   le prestazioni del sistema e rifiutare modifiche se alcuni obiettivi non sono   incontrato.

Verifica delle prestazioni I test delle prestazioni di controllo comportamenti del   sistema quando è sotto carico significativo. Questi test sono   non funzionale e può avere varie forme di comprendere la   affidabilità, la stabilità e la disponibilità della piattaforma. Per   esempio, può essere osservando i tempi di risposta quando si esegue un elevato   numero di richieste, o di vedere come il sistema si comporta con un   significativa di dati.

I test sono per loro natura molto costoso da implementare e   corrono, ma possono aiutare a capire se i nuovi cambiamenti stanno per   degradare il sistema.

test di fumo test di fumo sono test di base che controllano base   funzionalità dell'applicazione. Essi sono destinati ad essere veloce a   esecuzione, e il loro obiettivo è quello di dare la certezza che il maggiore   caratteristiche del sistema funzionino come previsto.

test di fumo possono essere utili a destra dopo una nuova build è fatto per decidere   anche se non è possibile eseguire i test più costosi, o subito dopo un   distribuzione per assicurarsi che l'applicazione è in esecuzione in modo corretto   l'ambiente appena distribuito.

fonte: https: //www.atlassian .com / continuo-consegna / software-test / tipi-di-software-test

Volevo solo aggiungere e dare un po 'di contesto sul perché abbiamo questi livelli di prova, che cosa realmente significano con esempi

Mike Cohn nel suo libro “Riuscire con Agile” si avvicinò con la “Piramide Testing” come un modo per avvicinarsi test automatizzati nei progetti. Ci sono varie interpretazioni di questo modello. Il modello illustra la tipologia di test automatizzati devono essere create, quanto velocemente possono dare un feedback sulla domanda in prova e chi scrive questi test. Ci sono fondamentalmente 3 livelli di test automatizzati necessari per qualsiasi progetto e sono come segue.

unit test - Questi testare la componente più piccola della vostra applicazione software. Questo potrebbe essere letteralmente una funzione in un codice che calcola un valore basato su alcuni input. Questa funzione è parte di diverse altre funzioni del codice di base hardware / software che rende l'applicazione.

Per esempio - Diamo una calcolatrice web based. I componenti più piccoli di questa applicazione che deve essere testato unità potrebbe essere una funzione che esegue Inoltre, un altro che esegue sottrazione e così via. Tutte queste piccole funzioni messe insieme rende l'applicazione calcolatrice.

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

Il più grande vantaggio di unit test sono, corrono molto velocemente sotto l'interfaccia utente e si può ottenere un feedback circa la propria applicazione. Questo dovrebbe comprendere oltre il 50% dei vostri test automatizzati.

Test API / integrazione - Questi testare vari componenti del sistema software insieme. I componenti potrebbero includere i database di test, (Application Programming Interface) di API, strumenti 3rd party e servizi insieme con l'applicazione.

Per esempio - Nel nostro esempio calcolatrice sopra, l'applicazione web può utilizzare un database per memorizzare i valori, utilizzare API per fare alcune convalide lato server e si può utilizzare un terzo strumento di partito / servizio per pubblicare i risultati al cloud per renderlo disponibile su diverse piattaforme.

Storicamente uno sviluppatore o QA tecnico scriverebbero questi test utilizzando vari strumenti come postino, SoapUI, JMeter e altri strumenti come Testim.

Questi correre molto più velocemente rispetto ai test UI come ancora corrono sotto la cappa, ma possono consumare un po 'più di tempo di unit test come deve controllare la comunicazione tra i vari componenti indipendenti del sistema e assicurarsi che abbiano una perfetta integrazione. Questo dovrebbe costituire più che il 30% dei test automatizzati.

Test UI - Infine, abbiamo le prove che convalidano l'interfaccia utente dell'applicazione. Questi test sono scritti per testare un'estremità all'altra scorre attraverso l'applicazione.

Per esempio - Nell'applicazione calcolatrice, fine al flusso di finale potrebbe essere, aprendo la browser-> inserendo l'URL calcolatrice -> Accesso con nome utente / password -> Apertura del calcolatrice -> Esecuzione di alcune operazioni sulla calcolatrice -> il controllo di detti risultati da l'interfaccia utente -> Registrazione fuori dell'applicazione. Questo potrebbe essere uno end to end flusso che sarebbe un buon candidato per l'automazione interfaccia utente.

Storicamente, i tester manuale di tecnica QA o scrivere test dell'interfaccia utente. Usano framework open source come il selenio o piattaforme di test dell'interfaccia utente come Testim all'autore, eseguire e mantenere i test. Questi test danno più un feedback visivo, come si può vedere come i test sono in esecuzione, la differenza tra i risultati attesi e reale attraverso le immagini, i registri, rapporti di prova.

La limitazione maggiore di test UI è, sono relativamente lento rispetto ai test unitari e API. Quindi, si dovrebbe comprendere solo il 10-20% dei test automatizzati globali.

I due tipi di test possono variare based sul vostro progetto, ma l'idea è -

Test di fumo

Questo può essere una combinazione di quanto sopra 3 livelli di test. L'idea è di eseguirlo durante ogni controllo codice e assicurare le funzionalità critiche del sistema sono ancora lavorando come previsto; dopo vengono unite le nuove modifiche al codice. Essi in genere hanno bisogno di correre con 5 - 10 minuti per ottenere un feedback più velocemente su fallimenti

Test regressione

Di solito vengono eseguiti una volta al giorno almeno e coprono varie funzionalità del sistema. Essi garantiscono l'applicazione è ancora funziona come previsto. Sono maggiori dettagli rispetto ai test di fumo e coprono più scenari dell'applicazione compresi quelli non critici.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow