Che cos'è il test di integrazione (Tutorial con esempio di test di integrazione)

what is integration testing

Che cos'è il test di integrazione: impara con gli esempi di test di integrazione

Il test di integrazione viene eseguito per testare i moduli / componenti quando integrati per verificare che funzionino come previsto, ovvero testare i moduli che funzionano bene individualmente non ha problemi quando integrati.

Quando si parla in termini di test di applicazioni di grandi dimensioni utilizzando la tecnica di test della scatola nera, implica la combinazione di molti moduli strettamente collegati tra loro. Possiamo applicare i concetti della tecnica di test di integrazione per testare questi tipi di scenari.

Elenco dei tutorial trattati in questa serie:

Tutorial n. 1: Che cos'è il test di integrazione? (Questo tutorial)
Tutorial n. 2: Cos'è il test incrementale
Tutorial n. 3: Che cos'è il test dei componenti
Tutorial n. 4: Integrazione continua
Tutorial n. 5 Differenza tra test unitari e integrazione
Tutorial # 6: I 10 migliori strumenti di test di integrazione

Cosa imparerai:

• Cos'è il test di integrazione?
• Perché test di integrazione?
• Vantaggi
• Sfide
• Tipi di test di integrazione
  • Approccio Big Bang:
• Approcci di integrazione dei test
  • Approccio bottom-up:
  • Approccio dall 'alto verso il basso
• Test di integrazione dell'applicazione GUI
  • Esempio di test di integrazione:
• Passaggi per avviare i test di integrazione
• Criteri di ingresso / uscita per il test di integrazione
• Casi di test di integrazione
• L'integrazione è una tecnica scatola bianca o scatola nera?
• Strumenti di test di integrazione
• Test di integrazione del sistema
• Differenza tra test di integrazione e test di sistema
• Conclusione
• Lettura consigliata

Cos'è il test di integrazione?

Il significato del test di integrazione è abbastanza semplice- Integra / combina il modulo testato uno per uno e verifica il comportamento come un'unità combinata.

La funzione o l'obiettivo principale di questo test è testare le interfacce tra le unità / moduli.

Normalmente eseguiamo test di integrazione dopo il 'test unitario'. Una volta che tutte le singole unità sono state create e testate, iniziamo a combinare quei moduli 'Unit Tested' e iniziamo a fare il test integrato.

La funzione o l'obiettivo principale di questo test è testare le interfacce tra le unità / moduli.

I singoli moduli vengono prima testati separatamente. Una volta che i moduli sono stati testati, vengono integrati uno per uno, fino a quando tutti i moduli sono integrati, per verificare il comportamento combinatorio e convalidare se i requisiti sono implementati correttamente o meno.

Qui dovremmo capire che il test di integrazione non avviene alla fine del ciclo, ma viene condotto contemporaneamente allo sviluppo. Quindi nella maggior parte delle volte, tutti i moduli non sono effettivamente disponibili per testare ed ecco qual è la sfida per testare qualcosa che non esiste!

Perché test di integrazione?

Riteniamo che il test di integrazione sia complesso e richieda un certo sviluppo e abilità logiche. È vero! Allora qual è lo scopo di integrare questo test nella nostra strategia di test?

Ecco alcuni motivi:

1. Nel mondo reale, quando le applicazioni vengono sviluppate, vengono suddivise in moduli più piccoli e ai singoli sviluppatori viene assegnato 1 modulo. La logica implementata da uno sviluppatore è abbastanza diversa da un altro sviluppatore, quindi diventa importante verificare se la logica implementata da uno sviluppatore è conforme alle aspettative e restituisce il valore corretto in conformità con gli standard prescritti.
2. Molte volte il volto o la struttura dei dati cambiano quando viaggiano da un modulo all'altro. Alcuni valori vengono aggiunti o rimossi, il che causa problemi nei moduli successivi.
3. I moduli interagiscono anche con alcuni strumenti o API di terze parti che devono anche essere testati che i dati accettati da quell'API / strumento siano corretti e che anche la risposta generata sia quella prevista.
4. Un problema molto comune nei test: frequenti modifiche ai requisiti! :) Molte volte gli sviluppatori distribuiscono le modifiche senza testare l'unità. Il test di integrazione diventa importante in quel momento.

Vantaggi

Ci sono diversi vantaggi di questo test e alcuni di essi sono elencati di seguito.

• Questo test si assicura che i moduli / componenti integrati funzionino correttamente.
• Una volta disponibili i moduli da testare, è possibile avviare il test di integrazione. Non richiede il completamento dell'altro modulo per eseguire il test, poiché per lo stesso è possibile utilizzare Stub e Driver.
• Rileva gli errori relativi all'interfaccia.

Sfide

Di seguito sono elencate alcune sfide coinvolte nel test di integrazione.

# 1) Test di integrazione significa testare due o più sistemi integrati al fine di garantire che il sistema funzioni correttamente. Non solo i collegamenti di integrazione dovrebbero essere testati, ma dovrebbe essere fatto un test esaustivo considerando l'ambiente per garantire che il sistema integrato funzioni correttamente.

Potrebbero esserci diversi percorsi e permutazioni che possono essere applicati per testare il sistema integrato.

#Due) La gestione dei test di integrazione diventa complessa a causa di pochi fattori coinvolti come il database, la piattaforma, l'ambiente ecc.

# 3) Pur integrando qualsiasi nuovo sistema con il sistema legacy, richiede molti cambiamenti e sforzi di test. Lo stesso vale per l'integrazione di due sistemi legacy.

# 4) L'integrazione di due diversi sistemi sviluppati da due diverse società è una grande sfida in quanto non è sicuro come uno dei sistemi influirà sull'altro sistema se vengono apportate modifiche a uno qualsiasi dei sistemi.

Per ridurre al minimo l'impatto durante lo sviluppo di un sistema, è necessario prendere in considerazione poche cose come la possibile integrazione con altri sistemi, ecc.

Tipi di test di integrazione

Di seguito è riportato un tipo di integrazione di test con i suoi vantaggi e svantaggi.

Approccio Big Bang:

L'approccio Big Bang integra tutti i moduli in una volta, ovvero non prevede l'integrazione dei moduli uno per uno. Verifica se il sistema funziona come previsto o meno una volta integrato. Se viene rilevato un problema nel modulo completamente integrato, diventa difficile scoprire quale modulo ha causato il problema.

L'approccio big bang è un processo che richiede tempo per trovare un modulo che ha un difetto in sé, poiché ciò richiederebbe tempo e una volta rilevato il difetto, la riparazione dello stesso costerebbe molto in quanto il difetto viene rilevato nella fase successiva.

Vantaggi dell'approccio Big Bang:

• È un buon approccio per i piccoli sistemi.

Svantaggi dell'approccio Big Bang:

• È difficile rilevare il modulo che causa un problema.
• L'approccio Big Bang richiede tutti i moduli tutti insieme per i test, il che a sua volta porta a meno tempo per i test poiché la progettazione, lo sviluppo e l'integrazione richiederebbero la maggior parte del tempo.
• Il test viene eseguito in una sola volta, il che quindi non lascia tempo per il test critico del modulo in isolamento.

Passaggi del test di integrazione:

1. Preparare l'integrazione Piano di test.
2. Preparare scenari di test di integrazione e casi di test.
3. Prepara script di automazione dei test.
4. Esegui casi di test.
5. Segnala i difetti.
6. Tieni traccia e verifica nuovamente i difetti.
7. Il nuovo test e il test continuano fino al completamento del test di integrazione.

Approcci di integrazione dei test

Esistono fondamentalmente 2 approcci per eseguire l'integrazione dei test:

1. Approccio dal basso verso l'alto
2. Approccio dall 'alto verso il basso.

Consideriamo la figura seguente per testare gli approcci:

Approccio bottom-up:

Il test bottom-up, come suggerisce il nome, inizia dall'unità più bassa o più interna dell'applicazione e si sposta gradualmente verso l'alto. Il test di integrazione inizia dal modulo più basso e procede gradualmente verso i moduli superiori dell'applicazione. Questa integrazione continua finché tutti i moduli sono integrati e l'intera applicazione viene testata come una singola unità.

In questo caso, i moduli B1C1, B1C2 e B2C1, B2C2 sono il modulo più basso sottoposto a test unitario. I moduli B1 e B2 non sono ancora sviluppati. La funzionalità del modulo B1 e B2 è che chiama i moduli B1C1, B1C2 e B2C1, B2C2. Poiché B1 e B2 non sono ancora sviluppati, avremmo bisogno di un programma o di uno “stimolatore” che chiamerà i moduli B1C1, B1C2 e B2C1, B2C2. Questi programmi stimolatori sono chiamati AUTISTI .

In parole semplici, AUTISTI sono i programmi fittizi che vengono utilizzati per chiamare le funzioni del modulo più basso nel caso in cui la funzione chiamante non esiste. La tecnica bottom-up richiede che il driver del modulo invii l'input del test case all'interfaccia del modulo da testare.

Il vantaggio di questo approccio è che, se esiste un errore grave nell'unità più bassa del programma, è più facile individuarlo e possono essere prese misure correttive.

Lo svantaggio è che il programma principale in realtà non esiste fino a quando l'ultimo modulo non viene integrato e testato. Di conseguenza, i difetti di progettazione di livello superiore verranno rilevati solo alla fine.

Approccio dall 'alto verso il basso

Questa tecnica parte dal modulo più in alto e procede gradualmente verso i moduli inferiori. Solo il modulo superiore viene testato separatamente dall'unità. Successivamente, i moduli inferiori vengono integrati uno per uno. Il processo viene ripetuto fino a quando tutti i moduli sono integrati e testati.

software di download gratuito di video musicali di YouTube

Nel contesto della nostra figura, il test inizia dal Modulo A e i moduli inferiori B1 e B2 sono integrati uno per uno. Ora qui i moduli inferiori B1 e B2 non sono effettivamente disponibili per l'integrazione. Quindi, per testare i moduli A più in alto, sviluppiamo ' STUBS '.

Gli 'stub' possono essere indicati come codice uno snippet che accetta gli input / richieste dal modulo superiore e restituisce i risultati / risposta. In questo modo, nonostante i moduli inferiori, non esistono, siamo in grado di testare il modulo superiore.

In scenari pratici, il comportamento degli stub non è così semplice come sembra. In questa era di moduli e architettura complessi, il cosiddetto modulo, la maggior parte delle volte coinvolge logica di business complessa come la connessione a un database. Di conseguenza, la creazione di Stub diventa complessa e richiede tempo come il modulo reale. In alcuni casi, il modulo Stub potrebbe risultare più grande del modulo stimolato.

Sia gli stub che i driver sono parti fittizie di codice che vengono utilizzate per testare i moduli 'non esistenti'. Attivano le funzioni / il metodo e restituiscono la risposta, che viene confrontata con il comportamento previsto

Concludiamo alcune differenze tra Stub e driver :

L'unico cambiamento è Constant in questo mondo, quindi abbiamo un altro approccio chiamato ' Test a sandwich 'Che combina le caratteristiche dell'approccio top-down e bottom-up. Quando testiamo programmi enormi come i sistemi operativi, dobbiamo disporre di alcune tecniche in più che siano efficienti e aumentino la fiducia. I test sandwich svolgono un ruolo molto importante qui, dove vengono avviati contemporaneamente sia il test top down che quello bottom up.

L'integrazione inizia con lo strato intermedio e si sposta simultaneamente verso l'alto e verso il basso. Nel caso della nostra figura, il nostro test inizierà da B1 e B2, dove un braccio testerà il modulo superiore A e un altro braccio testerà i moduli inferiori B1C1, B1C2 e B2C1, B2C2.

Poiché entrambi gli approcci iniziano simultaneamente, questa tecnica è un po 'complessa e richiede più persone insieme a set di abilità specifiche e quindi aumenta il costo.

Test di integrazione dell'applicazione GUI

Ora parliamo di come possiamo implicare il test di integrazione nella tecnica della scatola nera.

Sappiamo tutti che un'applicazione web è un'applicazione a più livelli. Abbiamo un front-end che è visibile all'utente, abbiamo un livello intermedio che ha una logica di business, abbiamo un altro livello intermedio che esegue alcune convalide, integriamo alcune API di terze parti ecc., Quindi abbiamo il livello posteriore che è il Banca dati.

Esempio di test di integrazione:

Controlliamo l'esempio seguente:

Sono il titolare di una società di pubblicità e inserisco annunci su diversi siti web. Alla fine del mese, voglio vedere quante persone hanno visto i miei annunci e quante persone hanno fatto clic sui miei annunci. Ho bisogno di un rapporto per i miei annunci visualizzati e addebito di conseguenza ai miei clienti.

Software GenNext ha sviluppato questo prodotto per me e sotto c'era l'architettura:

CIPOLLA - Modulo interfaccia utente, visibile all'utente finale, dove vengono forniti tutti gli input.
BL - È il modulo Business Logic, che contiene tutti i calcoli e metodi specifici di business.
VAL - È il modulo Validation, che ha tutte le convalide della correttezza dell'input.
CNT - È il modulo di contenuto che ha tutti i contenuti statici, specifici per gli input inseriti dall'utente. Questi contenuti vengono visualizzati nei rapporti.
NEL - È il modulo Engine, questo modulo legge tutti i dati che provengono dal modulo BL, VAL e CNT ed estrae la query SQL e la attiva nel database.
Scheduler - È un modulo che pianifica tutti i report in base alla selezione dell'utente (mensile, trimestrale, semestrale e annuale)
DB - È il database.

Ora, vista l'architettura dell'intera applicazione web, come singola unità, Integration testing, in questo caso, si concentrerà sul flusso di dati tra i moduli.

Le domande qui sono:

1. In che modo i moduli BL, VAL e CNT leggeranno e interpreteranno i dati inseriti nel modulo UI?
2. I moduli BL, VAL e CNT ricevono i dati corretti dall'interfaccia utente?
3. In quale formato vengono trasferiti i dati da BL, VAL e CNT al modulo EQ?
4. In che modo l'EQ leggerà i dati ed estrarrà la query?
5. La query è stata estratta correttamente?
6. Lo Scheduler sta ottenendo i dati corretti per i rapporti?
7. Il set di risultati ricevuto dall'EN, dal database è corretto e come previsto?
8. EN è in grado di inviare la risposta al modulo BL, VAL e CNT?
9. Il modulo UI è in grado di leggere i dati e visualizzarli in modo appropriato all'interfaccia?

Nel mondo reale, la comunicazione dei dati avviene in un formato XML. Quindi, qualunque dato l'utente inserisca nell'interfaccia utente, viene convertito in un formato XML.

Nel nostro scenario, i dati inseriti nel modulo UI vengono convertiti in file XML che viene interpretato dai 3 moduli BL, VAL e CNT. Il modulo EN legge il file XML risultante generato dai 3 moduli e ne estrae l'SQL e interroga nel database. Il modulo EN riceve anche il set di risultati e lo converte in un file XML e lo restituisce al modulo UI che converte i risultati in forma leggibile dall'utente e li visualizza.

Al centro abbiamo il modulo scheduler che riceve il set di risultati dal modulo EN, crea e pianifica i report.

Allora, dove entra in gioco il test di integrazione?

Bene, testare se le informazioni / dati scorrono correttamente o meno sarà il test di integrazione, che in questo caso convaliderà i file XML. I file XML vengono generati correttamente? Hanno i dati corretti? I dati vengono trasferiti correttamente da un modulo all'altro? Tutte queste cose saranno testate come parte del test di integrazione.

Prova a generare o ottenere i file XML e ad aggiornare i tag e controlla il comportamento. Questo è qualcosa di molto diverso dai normali test che i tester fanno normalmente, ma questo aggiungerà valore alla conoscenza e alla comprensione dell'applicazione da parte dei tester.

Poche altre condizioni di prova del campione possono essere le seguenti:

• Le opzioni di menu generano la finestra corretta?
• Le finestre sono in grado di richiamare la finestra sotto test?
• Per ogni finestra, identificare le chiamate di funzione per la finestra che l'applicazione dovrebbe consentire.
• Identifica tutte le chiamate dalla finestra ad altre funzionalità che l'applicazione dovrebbe consentire
• Identificare le chiamate reversibili: chiudere una finestra chiamata dovrebbe tornare alla finestra chiamante.
• Identifica le chiamate irreversibili: le finestre chiamanti si chiudono prima che appaia la finestra chiamata.
• Testare i diversi modi di eseguire chiamate a un'altra finestra, ad es. - menu, pulsanti, parole chiave.

Passaggi per avviare i test di integrazione

1. Comprendi l'architettura della tua applicazione.
2. Identifica i moduli
3. Comprendi cosa fa ogni modulo
4. Comprendere come i dati vengono trasferiti da un modulo a un altro.
5. Comprendere come i dati vengono inseriti e ricevuti nel sistema (punto di ingresso e punto di uscita dell'applicazione)
6. Separare l'applicazione in base alle proprie esigenze di test.
7. Identifica e crea le condizioni di prova
8. Prendi una condizione alla volta e scrivi i casi di test.

Criteri di ingresso / uscita per il test di integrazione

Criteri di ingresso:

• Il documento del piano di test di integrazione viene firmato e approvato.
• Sono stati preparati casi di test di integrazione.
• I dati del test sono stati creati.
• Test di unità dei moduli / componenti sviluppati è completo.
• Tutti i difetti critici e ad alta priorità vengono chiusi.
• L'ambiente di test è configurato per l'integrazione.

Criteri di uscita:

• Tutti i casi di test di integrazione sono stati eseguiti.
• Non vengono aperti difetti critici e prioritari P1 e P2.
• Il rapporto di prova è stato preparato.

Casi di test di integrazione

I casi di test di integrazione si concentrano principalmente sul interfaccia tra i moduli, collegamenti integrati, trasferimento dati tra i moduli come moduli / componenti che sono già unit test, ovvero la funzionalità e gli altri aspetti del test sono già stati coperti.

Quindi, l'idea principale è di verificare se l'integrazione di due moduli funzionanti funziona come previsto una volta integrati.

Ad esempio, i casi di test di integrazione per l'applicazione Linkedin includeranno:

• Verifica il collegamento dell'interfaccia tra la pagina di accesso e la home page, ovvero quando un utente inserisce le credenziali e registra deve essere indirizzato alla home page.
• Verifica del collegamento dell'interfaccia tra la home page e la pagina del profilo, ovvero la pagina del profilo dovrebbe aprirsi.
• Verificare il collegamento dell'interfaccia tra la pagina di rete e le pagine di connessione, ad esempio facendo clic sul pulsante Accetta su Inviti della pagina di rete dovrebbe mostrare l'invito accettato nella pagina di connessione una volta cliccato.
• Verificare il collegamento dell'interfaccia tra le pagine di notifica e dire il pulsante di congratulazioni, ovvero fare clic sul pulsante di congratulazioni per dirigersi verso la finestra del nuovo messaggio.

Molti casi di test di integrazione possono essere scritti per questo sito specifico. I quattro punti precedenti sono solo un esempio per capire quali casi di test di integrazione sono inclusi nei test.

L'integrazione è una tecnica scatola bianca o scatola nera?

La tecnica di test di integrazione può essere contata sia in scatole nere che in tecnica della scatola bianca . Tecnica della scatola nera è dove un tester non ha bisogno di alcuna conoscenza interna del sistema, ovvero non è richiesta la conoscenza della codifica mentre la tecnica della scatola bianca richiede una conoscenza interna dell'applicazione.

Ora, mentre si esegue il test di integrazione, potrebbe includere il test dei due servizi Web integrati che recupereranno i dati dal database e forniranno i dati come richiesto, il che significa che potrebbe essere testato utilizzando la tecnica di test white box mentre l'integrazione di una nuova funzionalità nel sito Web può essere testata utilizzando la tecnica della scatola nera.

Quindi, non è specifico che il test di integrazione sia una tecnica black box o white box.

Strumenti di test di integrazione

Sono disponibili diversi strumenti per questo test.

Di seguito è riportato un elenco di strumenti:

• Rational Integration Tester
• Goniometro
• Vapore
• TESSY

Per maggiori dettagli sugli strumenti di cui sopra, controlla questo tutorial:

I 10 migliori strumenti di test di integrazione per scrivere test di integrazione

Test di integrazione del sistema

Il test di integrazione del sistema viene eseguito per testare il file sistema integrato completo .

Moduli o componenti vengono testati individualmente in unit test prima di integrare i componenti.

Una volta che tutti i moduli sono stati testati, il test di integrazione del sistema viene eseguito integrando tutti i moduli e il sistema nel suo insieme viene testato.

Differenza tra test di integrazione e test di sistema

Il test di integrazione è un test in cui uno o due moduli sottoposti a test di unità vengono integrati per il test e la verifica viene eseguita per verificare se i moduli integrati funzionano come previsto o meno.

Il test di sistema è un test in cui il sistema nel suo complesso viene testato, ovvero tutti i moduli / componenti sono integrati insieme per verificare se il sistema funziona come previsto e non si verificano problemi a causa dei moduli integrati.

Conclusione

Si tratta di test di integrazione e della sua implementazione sia nella tecnica White box che nella Black box. Spero di averlo spiegato chiaramente con esempi pertinenti.

Test Integration è una parte importante del ciclo di test in quanto rende più facile trovare il difetto quando due o più moduli sono integrati al fine di integrare tutti i moduli tutti insieme nella prima fase stessa.

Aiuta a trovare i difetti in una fase iniziale, il che a sua volta consente di risparmiare sforzi e costi. Assicura che i moduli integrati funzionino correttamente come previsto.

Spero che questo tutorial informativo sui test di integrazione avrebbe arricchito la tua conoscenza del concetto.

Lettura consigliata

• Che cos'è il test dei componenti o il test dei moduli (impara con esempi)
• Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
• Spock per integrazione e test funzionali con selenio
• Le differenze tra test unitari, test di integrazione e test funzionali
• Integrazione del selenio con JMeter
• Download dell'eBook Testing Primer
• Test funzionale vs test non funzionale
• Esercitazione sul test di coppia o sul test di tutte le coppie con strumenti ed esempi