it-swarm.it

Che cos'è esattamente un test di integrazione?

Io e i miei amici abbiamo faticato a classificare esattamente cos'è un test di integrazione.

Ora, tornando a casa, mi sono appena reso conto che ogni volta che provo a dare un esempio reale di un test di integrazione, si rivela un test di accettazione, vale a dire. qualcosa che un uomo d'affari direbbe ad alta voce che specifica cosa dovrebbe fornire il sistema.

Ho controllato la documentazione Ruby on Rails per la loro classificazione di questi tipi di test, e ora mi ha completamente gettato.

Potete darmi una breve descrizione accademica di un test di integrazione con un esempio del mondo reale?

116
Martin Blore

Al momento mi piace questa affermazione: "Non è importante come la chiami, ma cosa fa" fatta da Gojko Adzic in questo articolo .

Devi davvero specificare con le persone che parlano dei test cosa intendi testare.

Ci sono molte persone che hanno opinioni diverse, a seconda del loro ruolo.

Per i tester una metodologia di test generalmente accettata nei Paesi Bassi è TMap . TMap fa la seguente distinzione.

  • unit test
  • test di integrazione dell'unità
  • test di sistema
  • test di integrazione del sistema
  • test di accettazione (tutti i tipi/livelli)
  • test di accettazione funzionale
  • test di accettazione dell'utente
  • test di accettazione della produzione

Hanno tipi più specifici di test che possono essere eseguiti all'interno dei test sopra menzionati. Guarda questo documento Word per una panoramica.

Wikipedia ha anche un bella panoramica .

Il prenota il programmatore pragmatico dice:

  • un unit test è un test che esercita un modulo
  • i test di integrazione mostrano che le parti principali di un sistema funzionano bene insieme

Osservando queste diverse fonti e inserendo alcune delle mie esperienze e opinioni, inizierei facendo distinzioni per tre categorie

  • chi fa i test in generale
  • ciò che è testato
  • qual è l'obiettivo del test

    • Unit test : logica di test in classi da parte dei programmatori per mostrare la correttezza a livello di codice. Dovrebbero essere veloci e non dipendere da altre parti del sistema che non si intende testare
    • Test di accettazione funzionale : lo scenario del caso d'uso del test è su un set di dati limitato (appositamente creato) eseguito dal reparto test per dimostrare che ogni scenario specificato funziona come specificato.
    • Test di accettazione dell'utente : verifica lo scenario del caso d'uso sulla produzione come i dati fatti dai rappresentanti degli utenti per far accettare formalmente la domanda
    • Test di integrazione : verifica i percorsi di comunicazione tra le diverse parti del modulo eseguite dal reparto test o dagli sviluppatori per dimostrare che tutti i moduli funzionano correttamente insieme.

La mia lista sopra è solo un inizio e un suggerimento, ma penso davvero: "Non è importante come lo chiami, ma cosa fa"

Spero che sia di aiuto.

26-10-2016 Modifica: Di recente è stata introdotta su YouTube un'introduzione molto piacevole Test unitari vs Test di integrazione - Musulmani di MPJ - FunFunFunction # 55

81
KeesDijk

test di integrazione, risulta essere un test di accettazione

Ovviamente.

Questi due sono quasi la stessa cosa. Ma ci sono alcune dimensioni leggermente diverse nella definizione del test.

Integrazione == l'intero sistema.

Accettazione == l'intero sistema.

L'unica differenza - e questo è sottile - è la definizione dei casi di test.

Integrazione == casi di test per verificare la profondità e il grado di integrazione. Funziona con tutte le custodie Edge e Corner? I casi di test sono tendenzialmente tecnici, scritti da progettisti e programmatori.

Accettazione == casi di test per esercitare solo l'80% incentrato sull'utente finale del set di funzionalità. Non tutti i casi Edge e corner. I casi di test tendono ad essere non tecnici, scritti dagli utenti finali.

31
S.Lott

Personalmente mi piace pensare a un test di integrazione come a un test di funzionalità quando ogni componente del sistema è reale, nessun oggetto finto.

Un vero repository, un vero database, una vera interfaccia utente. Si verifica la funzionalità specifica quando il sistema è completamente assemblato ed è come dovrebbe essere quando viene distribuito.

16
user8685

Nella mia (ammetto) poca esperienza, ho capito che l'integrazione di Word può davvero creare fraintendimenti: davvero, è difficile trovare qualcosa di completamente isolato in un sistema, alcuni elementi avranno sicuramente bisogno di integrazione.

Pertanto, mi sono abituato a fare le seguenti distinzioni:

  • Uso nit test per identificare, documentare e sottolineare tutti i comportamenti che la classe che sto testando è responsabile a realizzare.
  • Sto facendo test di integrazione ogni volta che ho un componente (forse più di uno) nel mio sistema che sta conversando con un altro sistema "esterno". (continua sotto ...)
  • Implemento un test di accettazione per definire, documentare e sottolineare un certo flusso di lavoro previsto dal sistema.

Nella definizione del test di integrazione, per esterno intendevo un sistema che è fuori dal mio intervallo di sviluppo: non posso cambiare immediatamente il modo in cui si comportano, per qualsiasi motivo. Potrebbe essere una libreria, un componente del sistema che non può essere modificato (cioè è condiviso con altri progetti dell'azienda), un dbms, ecc. Per questi test ho bisogno di impostare qualcosa di molto simile all'ambiente reale del sistema funzionerà in: un sistema esterno deve essere inizializzato e impostato su un determinato stato; i dati realistici devono essere registrati nel db; eccetera.

Invece, quando sto facendo il test di accettazione, falso cose: sto lavorando su qualcosa di diverso, sto lavorando sulle specifiche del sistema, non sulla sua capacità di collaborare con entità esterne.

Questa è davvero una visione più ristretta rispetto a quanto descritto in precedenza da KeesDijk, tuttavia suppongo che i progetti a cui ho lavorato finora fossero abbastanza piccoli da permettermi questo livello di semplificazione.

8
Marco Ciambrone

Un test di integrazione verifica che i componenti di un sistema complesso (ad esempio software, aeromobile, centrale elettrica) funzionino insieme come previsto.

Immaginiamo di parlare di un aereo (con il software è più astratto e difficile fare la differenza). I test di integrazione comprendono, verificando:

  • corretta interazione tra alcuni componenti. Esempio: premendo il pulsante di avvio, il motore si avvia e l'elica raggiunge la velocità di rotazione prevista (l'aeromobile rimane a terra)
  • corretta interazione con componenti esterni. Esempio: verificare che la radio incorporata possa comunicare con una radio stazionaria (aeromobili ancora a terra)
  • corretta interazione tra tutti i componenti coinvolti, in modo che il sistema nel suo complesso funzioni come previsto. Esempio: un equipaggio di piloti collaudatori e ingegneri avvia l'aereo e vola con esso (indossano tutti i paracadute ...).

Il test di integrazione risolve un problema tecnico , vale a dire che il sistema funziona nonostante la sua suddivisione in componenti. Nel software i componenti possono essere casi d'uso, moduli, funzioni, interfacce, librerie, ecc ...

Il test di accettazione verifica che il prodotto sia idoneo allo scopo. In linea di principio vengono eseguite dal cliente. Prendendo l'analogia dell'aeromobile, includono la verifica che:

  • gli scenari di business previsti portano al risultato atteso in una situazione quasi reale. Esempio: provare un imbarco con passeggeri di prova per verificare che il personale possa monitorare l'imbarco come previsto con le procedure operative. Alcuni scenari potrebbero essere così semplici da sembrare un test unitario, ma vengono eseguiti dall'utente (ad es. Provare le prese elettriche con le apparecchiature dell'azienda).
  • il sistema funziona in una situazione aziendale quasi reale. Esempio: effettuare un volo di prova vuoto tra due destinazioni reali, con piloti appena addestrati dalla compagnia aerea per verificare che il consumo di carburante sia come promesso.

Il test di accettazione affronta più un problema di responsabilità . In una relazione cliente/fornitore può essere una responsabilità contrattuale (conformità a tutti i requisiti). Ma in ogni caso è anche responsabilità dell'organizzazione utilizzatrice assicurarsi che i propri compiti possano essere esercitati con il sistema e prevenire con prudenza qualsiasi problema imprevisto (ad esempio come questa società ferroviaria che durante i test di accettazione ha scoperto di dover accorciare alcuni quais perché i nuovi carri erano troppo grandi di 5 cm - nessuno scherzo!).

Conclusioni: I test di integrazione e accettazione si sovrappongono. Entrambi intendono dimostrare che il sistema nel suo insieme funziona. Tuttavia il "tutto" potrebbe essere più grande per il cliente (perché il sistema stesso può far parte di un sistema organizzativo più ampio) e più tecnico per l'integratore di sistema:

enter image description here

7
Christophe

Il test di integrazione non è altro che il controllo della connessione e della correttezza del flusso di dati tra due o più moduli.

Ad esempio: quando componiamo una posta (un modulo) e la inviamo a un ID utente valido (secondo modulo), il test di integrazione è verificare se la posta inviata è presente negli articoli inviati.

1
Anita

Una definizione pratica di un test di integrazione è: Qualsiasi test che richiede l'interazione con qualcosa di fuori processo.

Per esempio:

  • Il file system
  • Il network
  • Un database
  • Un'API esterna

Esiste un tipo di contratto tra il processo e il mondo esterno e la verifica minima che il contratto debba essere l'obiettivo di un test di integrazione. cioè non dovrebbe fare altro che verificare il contratto. In tal caso, ci si sposta verso lo spazio del sistema/end-to-end.

I test unitari sono in grado di testare tutta la logica entro il limite del processo e possono farlo facilmente precisamente a causa della mancanza di dipendenze dal lento/fragile/complesso "mondo esterno".

Mentre ci sono test di integrazione questa definizione non copre (quindi perché l'ho definita una definizione pratica ) Penso che siano molto meno comuni/utili.

N.B. A rigor di termini, sì, questa definizione coprirebbe anche i test di sistema/end-to-end. Nella mia filosofia sono una forma di test di integrazione "estrema", quindi perché i loro nomi sottolineano un altro aspetto. Nella direzione opposta, un test unitario può essere considerato un test di integrazione di zero componenti, ovvero Tutti i test possono essere considerati in qualche punto dello spettro di integrazione, integrando tra componenti 0-n :-)

0
Schneider