Che cos'è il test di integrazione?
Il TEST DI INTEGRAZIONE è definito come un tipo di test in cui i moduli software sono integrati logicamente e testati come un gruppo. Un tipico progetto software è costituito da più moduli software, codificati da diversi programmatori. Lo scopo di questo livello di test è di esporre i difetti nell'interazione tra questi moduli software quando sono integrati
Il test di integrazione si concentra sul controllo della comunicazione dei dati tra questi moduli. Quindi è anche definito come "I & T" (integrazione e test), "String Testing" e talvolta "Thread Testing" .
- Che cos'è il test di integrazione?
- Perché i test di integrazione?
- Esempio di test case di integrazione
- Approcci, strategie, metodologie di test di integrazione
- Approccio Big Bang:
- Approccio incrementale
- Cosa sono Stub e Driver?
- Integrazione dal basso
- Integrazione top-down:
- Integrazione ibrida / sandwich
- Come eseguire il test di integrazione?
- Breve descrizione dei piani di test di integrazione:
- Criteri di ingresso e di uscita del test di integrazione
- Migliori pratiche / linee guida per i test di integrazione
Perché i test di integrazione?
Sebbene ogni modulo software sia testato in unità, i difetti esistono ancora per vari motivi come
- Un modulo, in generale, è progettato da un singolo sviluppatore di software la cui comprensione e logica di programmazione possono differire da altri programmatori. Il test di integrazione diventa necessario per verificare che i moduli software funzionino in unità
- Al momento dello sviluppo del modulo, ci sono ampie possibilità di cambiamento nei requisiti da parte dei clienti. Questi nuovi requisiti potrebbero non essere testati dall'unità e quindi il test di integrazione del sistema diventa necessario.
- Le interfacce dei moduli software con il database potrebbero essere errate
- Le interfacce hardware esterne, se presenti, potrebbero essere errate
- Una gestione inadeguata delle eccezioni potrebbe causare problemi.
Fare clic qui se il video non è accessibile
Esempio di test case di integrazione
Il caso di test di integrazione differisce dagli altri casi di test nel senso che si concentra principalmente sulle interfacce e sul flusso di dati / informazioni tra i moduli . In questo caso la priorità deve essere data ai collegamenti di integrazione piuttosto che alle funzioni dell'unità che sono già testate.
Casi di test di integrazione di esempio per il seguente scenario: L'applicazione ha 3 moduli che dicono "Pagina di accesso", "Cassetta postale" ed "Elimina messaggi di posta elettronica" e ciascuno di essi è integrato logicamente.
Qui non concentrarti molto sul test della pagina di accesso poiché è già stato fatto in Unit Testing. Ma controlla come è collegato alla pagina della casella di posta.
Allo stesso modo Mail Box: controlla la sua integrazione con il modulo Elimina messaggi.
| ID caso di test | Obiettivo del test case | Descrizione del test case | Risultato atteso |
|---|---|---|---|
| 1 | Verificare il collegamento dell'interfaccia tra il modulo Login e Mailbox | Immettere le credenziali di accesso e fare clic sul pulsante Accedi | Da indirizzare alla Mail Box |
| 2 | Controllare il collegamento dell'interfaccia tra la casella di posta e il modulo Elimina messaggi | Dalla casella di posta seleziona l'e-mail e fai clic su un pulsante Elimina | L'email selezionata dovrebbe apparire nella cartella Eliminato / Cestino |
Approcci, strategie, metodologie di test di integrazione
L'ingegneria del software definisce una varietà di strategie per eseguire i test di integrazione, vale a dire.
- Approccio Big Bang:
- Approccio incrementale: che è ulteriormente suddiviso in quanto segue
- Approccio dall 'alto verso il basso
- Approccio dal basso verso l'alto
- Approccio Sandwich - Combinazione di Top Down e Bottom Up
Di seguito sono elencate le diverse strategie, il modo in cui vengono eseguite e i loro limiti e vantaggi.
Big Bang Testing
Big Bang Testing è un approccio di test di integrazione in cui tutti i componenti o moduli vengono integrati insieme contemporaneamente e quindi testati come un'unità. Questo insieme combinato di componenti viene considerato come un'entità durante il test. Se tutti i componenti dell'unità non sono stati completati, il processo di integrazione non verrà eseguito.
Vantaggi:
- Comodo per piccoli impianti.
Svantaggi:
- La localizzazione dei guasti è difficile.
- Dato l'enorme numero di interfacce che devono essere testate in questo approccio, alcuni collegamenti di interfacce da testare potrebbero essere facilmente persi.
- Poiché il test di integrazione può iniziare solo dopo che "tutti" i moduli sono stati progettati, il team di test avrà meno tempo per l'esecuzione nella fase di test.
- Poiché tutti i moduli vengono testati contemporaneamente, i moduli critici ad alto rischio non vengono isolati e testati in base alla priorità. Anche i moduli periferici che si occupano delle interfacce utente non sono isolati e testati in base alla priorità.
Test incrementali
Nell'approccio del test incrementale , il test viene eseguito integrando due o più moduli che sono logicamente correlati tra loro e quindi testati per il corretto funzionamento dell'applicazione. Quindi gli altri moduli correlati vengono integrati in modo incrementale e il processo continua fino a quando tutti i moduli correlati logicamente non vengono integrati e testati correttamente.
L'Approccio Incrementale, a sua volta, è svolto da due diversi Metodi:
- Dal basso verso l'alto
- Dall'alto al basso
Stub e driver
Stub e driver sono i programmi fittizi nei test di integrazione utilizzati per facilitare l'attività di test del software. Questi programmi agiscono come sostituti dei modelli mancanti nel test. Non implementano l'intera logica di programmazione del modulo software ma simulano la comunicazione dati con il modulo chiamante durante il test.
Stub : viene chiamato dal modulo in prova.
Driver : chiama il modulo da testare.
Test di integrazione bottom-up
Il test di integrazione bottom-up è una strategia in cui vengono testati per primi i moduli di livello inferiore. Questi moduli testati vengono poi ulteriormente utilizzati per facilitare il test di moduli di livello superiore. Il processo continua fino a quando non vengono testati tutti i moduli al livello superiore. Una volta che i moduli di livello inferiore sono stati testati e integrati, viene formato il livello successivo di moduli.
Rappresentazione schematica :
Vantaggi:
- La localizzazione dei guasti è più semplice.
- Non si perde tempo ad aspettare che tutti i moduli vengano sviluppati a differenza dell'approccio Big-bang
Svantaggi:
- I moduli critici (al livello più alto dell'architettura software) che controllano il flusso dell'applicazione vengono testati per ultimi e possono essere soggetti a difetti.
- Un primo prototipo non è possibile
Test di integrazione top-down
Il test di integrazione dall'alto verso il basso è un metodo in cui il test di integrazione avviene dall'alto verso il basso seguendo il flusso di controllo del sistema software. I moduli di livello superiore vengono prima testati e quindi i moduli di livello inferiore vengono testati e integrati per verificare la funzionalità del software. Gli stub vengono utilizzati per testare se alcuni moduli non sono pronti.
Rappresentazione schematica:
Vantaggi:
- La localizzazione dei guasti è più semplice.
- Possibilità di ottenere un primo prototipo.
- I moduli critici vengono testati in base alla priorità; i principali difetti di progettazione potevano essere individuati e risolti per primi.
Svantaggi:
- Ha bisogno di molti Stub.
- I moduli a un livello inferiore vengono testati in modo inadeguato.
Test a sandwich
Sandwich Testing è una strategia in cui i moduli di livello superiore vengono testati con moduli di livello inferiore e allo stesso tempo i moduli inferiori vengono integrati con i moduli superiori e testati come un sistema. È una combinazione di approcci Top-down e Bottom-up, pertanto si chiama Hybrid Integration Testing . Utilizza sia gli stub che i driver.
Come eseguire il test di integrazione?
La procedura di test di integrazione indipendentemente dalle strategie di test del software (discusse sopra):
- Preparare il piano dei test di integrazione
- Progettare gli scenari di test, i casi e gli script.
- Esecuzione dei casi di test seguita dalla segnalazione dei difetti.
- Monitoraggio e riesame dei difetti.
- I passaggi 3 e 4 vengono ripetuti fino al completamento dell'integrazione.
Breve descrizione dei piani di test di integrazione:
Include i seguenti attributi:
- Metodi / approcci al test (come discusso sopra).
- Ambiti e elementi fuori ambito del test di integrazione.
- Ruoli e responsabilità.
- Prerequisiti per il test di integrazione.
- Ambiente di prova.
- Piani di rischio e mitigazione.
Criteri di ingresso e di uscita del test di integrazione
Criteri di ingresso e di uscita per la fase di test di integrazione in qualsiasi modello di sviluppo software
Criteri di ingresso:
- Componenti / moduli testati per unità
- Tutti i bug con priorità alta risolti e chiusi
- Tutti i moduli devono essere completati con codice e integrati con successo.
- Test di integrazione Piano, test case, scenari da firmare e documentare.
- Ambiente di test richiesto da configurare per il test di integrazione
Criteri di uscita:
- Test di successo dell'applicazione integrata.
- I casi di test eseguiti sono documentati
- Tutti i bug con priorità alta risolti e chiusi
- Documenti tecnici da presentare seguiti da note di rilascio.
Migliori pratiche / linee guida per i test di integrazione
- In primo luogo, determinare la strategia di test di integrazione che potrebbe essere adottata e successivamente preparare i casi di test ei dati di test di conseguenza.
- Studia il design dell'architettura dell'applicazione e identifica i moduli critici. Questi devono essere testati in base alla priorità.
- Ottieni i progetti di interfaccia dal team di Architectural e crea casi di test per verificare in dettaglio tutte le interfacce. L'interfaccia al database / all'hardware esterno / all'applicazione software deve essere testata in dettaglio.
- Dopo i casi di test, sono i dati di test che giocano il ruolo critico.
- Preparare sempre i dati fittizi prima dell'esecuzione. Non selezionare i dati di test durante l'esecuzione dei casi di test.