Cos'è il test di integrazione? (Esempio)

Cos'è il test di integrazione?

Test d'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 è quello 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 chiamato come 'ESSO' (Integrazione e Test), "Test delle stringhe" e talvolta "Test del filo".

Perché eseguire i test di integrazione?

Sebbene ogni modulo software sia testato unitariamente, esistono ancora difetti per vari motivi, ad esempio

• Un Modulo, in generale, è progettato da un singolo sviluppatore di software la cui comprensione e logica di programmazione possono differire da quelle di 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 dei requisiti da parte dei clienti. Questi nuovi requisiti potrebbero non essere testati unitariamente e quindi diventa necessario il test di integrazione del sistema.
• 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.

Clicchi qui se il video non è accessibile

Esempio di caso di test di integrazione

integrazione Test Case differisce da 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à va data al collegamenti integrativi piuttosto che le funzioni dell'unità già testate.

Casi di test di integrazione di esempio per il seguente scenario: l'applicazione ha 3 moduli denominati 'Pagina di accesso', 'Mailcasella' ed 'Elimina email' e ciascuna di esse è integrata logicamente.

Qui non concentrarti molto sul test della pagina di accesso poiché è già stato eseguito Test unitari. Ma controlla come è collegato a Mail Box Pagina.

Allo stesso modo Mail Box: Controlla la sua integrazione con l'Elimina MailModulo s.

ID caso di prova	Obiettivo del caso di test	Test Case Descriptione	Risultato atteso
1	Controllare il collegamento dell'interfaccia tra Login e Mailmodulo scatola	Inserisci le credenziali di accesso e clicca sul pulsante Accedi	Essere indirizzato al Mail Box
2	Controllare il collegamento dell'interfaccia tra Mailcasella e Elimina MailModulo s	Da fantastiche Mailcasella seleziona l'email e clicca sul pulsante Elimina	L'email selezionata dovrebbe apparire nella cartella Eliminati/Cestino

Tipi di test di integrazione

L'ingegneria del software definisce una serie di strategie per eseguire i test di integrazione, vale a dire:

• Approccio del 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, i loro limiti e i vantaggi.

Test del Big Bang

Test del Big Bang è 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 vengono completati, il processo di integrazione non verrà eseguito.

vantaggi:

• Conveniente per piccoli sistemi.

svantaggi:

• La localizzazione dei guasti è difficile.
• Dato l'enorme numero di interfacce che devono essere testate in questo approccio, alcuni collegamenti delle 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 della 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 via prioritaria.

Test incrementali

Nel Test incrementali approccio, il test viene eseguito integrando due o più moduli logicamente correlati tra loro e quindi testato per il corretto funzionamento dell'applicazione. Quindi gli altri moduli correlati vengono integrati in modo incrementale e il processo continua finché tutti i moduli logicamente correlati non vengono integrati e testati con successo.

L'approccio incrementale, a sua volta, viene effettuato mediante due diversi metodi:

• Basso Alto
• Alto Basso

Stub e driver

Stub e driver sono i programmi fittizi nei test di integrazione utilizzati per facilitare il test del software attività. Questi programmi fungono da sostituti dei modelli mancanti nei test. Non implementano l'intera logica di programmazione del modulo software ma simulano la comunicazione dati con il modulo chiamante durante il test.

mozzicone: Viene chiamato dal Modulo in Test.

Guidatore: Richiama il Modulo da testare.

Test di integrazione dal basso verso l'alto

Test di integrazione dal basso verso l'alto è una strategia in cui i moduli di livello inferiore vengono testati per primi. Questi moduli testati vengono poi ulteriormente utilizzati per facilitare il test di moduli di livello superiore. Il processo continua finché tutti i moduli al livello superiore non vengono testati. Una volta testati e integrati i moduli di livello inferiore, viene formato il livello successivo di moduli.

Rappresentazione schematica:

vantaggi:

• La localizzazione dei guasti è più semplice.
• Non si perde tempo aspettando 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 potrebbero essere soggetti a difetti.
• Un primo prototipo non è possibile

Test di integrazione top-down

Test di integrazione top-down è 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 testati per primi e poi 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 potrebbero essere trovati e risolti prima.

svantaggi:

• Ha bisogno di molti Stub.
• I moduli di livello inferiore non vengono testati in modo adeguato.

Come eseguire i test di integrazione?

La procedura di test di integrazione indipendentemente dalle strategie di test del software (discusse sopra):

1. Preparare l'integrazione Piano dei test
2. Progetta scenari, casi e script di test.
3. Esecuzione dei casi di test seguita dalla segnalazione dei difetti.
4. Tracciamento e nuovo test dei difetti.
5. I passaggi 3 e 4 vengono ripetuti fino al completamento dell'integrazione.

Slip Descriptione dei piani di test di integrazione

Include i seguenti attributi:

• Metodi/Approcci ai test (come discusso sopra).
• Ambiti ed elementi fuori ambito del test di integrazione.
• Ruoli e responsabilità.
• Prerequisiti per il test di integrazione.
• Ambiente di test.
• Piani di mitigazione e rischio.

Criteri di entrata e di uscita dei test di integrazione

Criteri di ingresso e uscita alla fase di test di integrazione in qualsiasi modello di sviluppo software

Criteri di partecipazione:

• Componenti/moduli testati sull'unità
• Tutti i bug con priorità alta risolti e chiusi
• Tutti i moduli devono essere completati e integrati con successo.
• Test di integrazione Piano, test case, scenari da approvare e documentare.
• Obbligatorio Ambiente di test da impostare per il test di integrazione

Criteri di uscita:

• Test riuscito dell'applicazione integrata.
• I casi di test eseguiti sono documentati
• Tutti i bug con priorità alta risolti e chiusi
• Documenti tecnici da presentare seguiti dalle note di rilascio.

migliori pratiche/linee guida per i test di integrazione

• Innanzitutto, determinare l'integrazione Strategia di prova che potrebbero essere adottati e preparare successivamente i casi di prova e i dati di prova di conseguenza.
• Studiare il Archiprogettazione strutturale dell'Applicazione e identificazione dei Moduli Critici. Questi devono essere testati in via prioritaria.
• Ottieni i progetti di interfaccia da Architeam tecnico e creare casi di test per verificare tutte le interfacce in dettaglio. L'interfaccia con il database/l'applicazione hardware/software esterna deve essere testata in dettaglio.
• Dopo i casi di test, sono i dati di test a svolgere il ruolo critico.
• Preparare sempre i dati fittizi prima dell'esecuzione. Non selezionare i dati di test durante l'esecuzione dei casi di test.