Test d’integrazione: Strategie di testing Big bang, Bottom up, Top down e Sandwich

Il test di integrazione è il processo di verifica dell’interazione tra componenti software. Le strategie classiche di test di integrazione, top-down o bottom-up, vengono utilizzate con il software tradizionale, strutturato in modo gerarchico. Le strategie moderne di integrazione sistematica sono invece guidate dall’architettura, cioè i componenti e sottosistemi software vengono integrati sulla base delle funzionalità identificate. Il test a livello di integrazione è un’attività continuativa. Tranne i casi di software molto piccoli e semplici, le strategie di test di integrazione sistematiche ed incrementali sono da preferire rispetto alla strategia di mettere tutti i componenti insieme nello stesso momento, in quello che viene chiamato “big bang” testing. Partendo da una architettura organizzata gerarchicamente, le integrazioni possono essere realizzate con approccio top-down o bottom-up o misto.

Il testing di integrazione rileva bug che non sono stati individuati durante il testing di unità, focalizzandosi su un insieme di componenti che integrate.
Due o più componenti sono integrate e analizzate, e quando dei bug sono rilevati nuove componenti possono essere aggiunte per riparare i bug. Sviluppare test stub e test driver per un test di integrazione sistematico è oneroso in termini di tempo.

I test di integrazione verificano come due (o più) unità lavorano insieme. I test d’integrazione richiede:

• la costruzione del sistema a partire dai suoi componenti ed il testing del sistema risultante per scoprire problemi che nascono dall’interazione fra I vari componenti.
• l’identificazione di gruppi di componenti che realizzano le varie funzionalità del sistema e la loro integrazione mediante componenti che li fanno lavorare insieme.

Strategie di testing

L’ordine in cui le componenti sono integrate può influenzare lo sforzo richiesto per l’integrazione. L’ordine in cui i sottosistemi sono selezionati per il testing e l’integrazione determina la strategia di testing:

1. Integrazione Big bang (Non incrementale)
2. Integrazione Bottom up
3. Integrazione Top down
4. Sandwich testing
5. Varianti: ognuna di queste strategie è stata originariamente concepita per una decomposizione gerarchica del sistema. Ciascuna componente appartiene ad una gerarchia di layer, ordinati in base all’associazione “Call”.

Approccio BIG-BANG

Le componenti sono prima testate individualmente e poi testate insieme come un singolo sistema. Sebbene sia semplice da realizzare è costoso: se un test scopre un fallimento è impossibile distinguere i fallimenti nelle interfacce dai fallimenti all’interno delle componenti.

Approccio BOTTOM-UP

I sottosistemi nel layer più in basso della gerarchia sono testati individualmente. I successivi sottosistemi da testare sono quelli che “chiamano” i sottosistemi testati in precedenza. Si ripete questo processo finché non sono testati tutti i sottosistemi. I test driver sono usati per simulare le componenti dei layer più “in alto” che non sono stati ancora integrati.

Pro e contro dell’approccio BOTTOM-UP

Non è ideale per sistemi funzionalmente decomposti:

• Testa i sottosistemi più importanti alla fine
• Utile per integrare i seguenti sistemi: Sistemi Object-oriented, Sistemi real-time e Sistemi con requisiti stringenti sulle performance Non sono necessari test stub.

Gli errori nelle interfacce possono essere individuati più facilmente se la componente ad alto livello viola le assunzioni fatte dalla componente a basso livello, questo può essere individuato più facilmente dagli sviluppatori.

Approccio TOP-DOWN

Questo approccio testa prima i layer al top o i sottosistemi di controllo. Successivamente combina tutti i sottosistemi che sono chiamati dai sottosistemi testati e quindi testa la collezione di sottosistemi risultante. Itera questa attività fino a quando tutti i sistemi non sono integrati e testati. I test stub sono usati per simulare le componenti dei layer al bottom che non sono state ancora integrate.

I test cases possono essere definiti in termini di funzionalità del sistema.

Vantaggio: si inzia dall’interfaccia utente

Svantaggi:

• Scrivere gli stub può essere difficile: gli stub devono consentire tutte le possibili condizioni da testare.
• É possibile che un grande numero di stub sia richiesto, specialmente se il livello più in basso del sistema contiene molti metodi,

Una soluzione per evitare molti stub: top-down modificato

• Testa individualmente ogni layer della decomposizione prima di fare il merge dei layer
• Svantaggio: sono necessari sia test stub sia test driver

Approccio SANDWICH

Combina la strategia top-down con quella bottom-up Il sistema è visto come se avesse 3 layers:

• Un layer target
• Un layer sopra il target
• Un layer sotto il target

Il testing converge al layer target. Come selezionare il layer target se ci sono più di 3 layers? Si può tentare di minimizzare il numero di stub e driver.

Pro e contro dell’approccio SANDWICH

I test dei layer al top e al bottom possono essere effettuati in parallelo. Problema: non sono testati i sottosistemi individuali prima dell’integrazione.