Che cos’è il System Integration Testing?
System Integration Testing (SIT) è il test globale dell’intero sistema che è composto da molti sottosistemi. L’obiettivo principale del SIT è di assicurare che tutte le dipendenze dei moduli software funzionino correttamente e che l’integrità dei dati sia preservata tra i moduli distinti dell’intero sistema.
SUT (System Under Test) può essere composto da hardware, database, software, una combinazione di hardware e software o un sistema che richiede interazione umana (HITL – Human in the Loop Testing).
Dal contesto dell’ingegneria del software e del test del software, il SIT può essere considerato come un processo di test che verifica la co-occorrenza del sistema software con altri.
SIT ha un prerequisito in cui più sistemi integrati sottostanti hanno già subito e superato il test di sistema. Il SIT testa quindi le interazioni richieste tra questi sistemi nel loro insieme. I risultati del SIT vengono passati all’UAT (User acceptance testing).
Necessità del System Integration Test
La funzione principale del SIT è quella di testare le dipendenze tra i diversi componenti del sistema e quindi il test di regressione è una parte importante del SIT.
Per i progetti collaborativi, il SIT è una parte del STLC (Software Testing lifecycle). Generalmente, un round pre-SIT è condotto dal fornitore del software prima che il cliente esegua i propri casi di test SIT.
Nella maggior parte delle organizzazioni che lavorano in progetti IT seguendo il modello Agile sprint, un round di SIT è condotto dal team QA prima di ogni rilascio. I difetti trovati nel SIT sono rimandati al team di sviluppo e loro lavorano sulle correzioni.
Il rilascio MVP (Minimum Viable Product) dallo sprint va solo quando passa attraverso il SIT.
SIT è richiesto per esporre i difetti che si verificano quando l’interazione avviene tra i sottosistemi integrati.
Ci sono diversi componenti usati nel sistema e non possono essere testati individualmente. Anche se l’unità è testata individualmente, allora c’è anche la possibilità che possa fallire quando è combinata nel sistema perché ci sono molti problemi che sorgono quando i sottosistemi interagiscono tra loro.
Quindi, il SIT è molto richiesto per esporre e risolvere i fallimenti prima di distribuire il sistema alla fine dell’utente. Il SIT rileva i difetti in una fase iniziale e quindi risparmia il tempo e il costo di correggerli in seguito. Aiuta anche ad ottenere un feedback precedente sull’accettabilità del modulo.
La granularità del SIT
Il SIT può essere condotto a tre diversi livelli di granularità:
(i) Intra-System Testing: Questo è un basso livello di test di integrazione che mira a fondere i moduli insieme per costruire un sistema unificato.
(ii) Inter-System Testing: Questo è un test di alto livello che ha bisogno di interfacciare sistemi testati indipendentemente.
(iii) Pairwise Testing: Qui, solo due sottosistemi interconnessi nell’intero sistema sono testati alla volta. Questo mira a garantire che i due sottosistemi possano funzionare bene quando combinati insieme, presumendo che gli altri sottosistemi stiano già lavorando bene.
Come eseguire i test di integrazione del sistema?
Il modo più semplice per eseguire il SIT è attraverso il metodo Data-driven. Richiede un uso minimo di strumenti di test del software.
Prima, lo scambio di dati (importazione ed esportazione di dati) avviene tra i componenti del sistema e poi viene esaminato il comportamento di ogni campo di dati all’interno del singolo strato.
Una volta che il software è integrato, ci sono tre stati principali del flusso di dati come menzionato sotto:
#1) Stato dei dati all’interno dello strato di integrazione
Lo strato di integrazione funge da interfaccia tra importazione ed esportazione dei dati. L’esecuzione del SIT a questo livello richiede alcune conoscenze di base su certe tecnologie come lo schema (XSD), XML, WSDL, DTD, e EDI.
Le prestazioni dello scambio di dati possono essere esaminate a questo livello attraverso i seguenti passi:
- Validate le proprietà dei dati all’interno di questo livello contro BRD/ FRD/ TRD (Business requirement document/ Functional requirement Document/ Technical requirement document).
- Controllo incrociato della richiesta del servizio web usando XSD e WSDL.
- Eseguire alcuni test unitari e convalidare le mappature dei dati e le richieste.
- Rivedere i log del middleware.
#2) Stato dei dati nel livello Database
Eseguire il SIT in questo livello richiede una conoscenza di base di SQL e stored procedure.
Le prestazioni dello scambio di dati a questo livello possono essere esaminate attraverso i seguenti passi:
- Controlla se tutti i dati dal livello di integrazione hanno raggiunto con successo il livello del database e sono stati impegnati.
- Valida le proprietà della tabella e della colonna contro BRD/ FRD/ TRD.
- Valida i vincoli e le regole di validazione dei dati applicate nel database come da specifiche aziendali.
- Controlla le stored procedure per qualsiasi elaborazione di dati.
- Esamina i log del server.
#3) Stato dei dati all’interno del livello dell’applicazione
Il SIT può essere eseguito a questo livello attraverso i seguenti passi:
- Controlla se tutti i campi richiesti sono visibili nell’UI.
- Eseguire alcuni casi di test positivi e negativi e validare le proprietà dei dati.
Nota: Ci possono essere molte combinazioni corrispondenti all’importazione e all’esportazione dei dati. Dovrete eseguire il SIT per le migliori combinazioni considerando il tempo a vostra disposizione.
System Testing Vs System Integration Testing
Differenze tra System Testing e SIT:
| SIT (System Integration Testing) | System Testing |
|---|---|
| SIT è fatto principalmente per controllare come i singoli moduli interagiscono tra loro quando sono integrati in un sistema nel suo complesso. | Il test di sistema è principalmente fatto per controllare se l’intero sistema funziona come previsto con riferimento ai requisiti specificati. |
| E’ condotto dopo il test delle unità e sarà fatto ogni volta che un nuovo modulo viene aggiunto al sistema. | E’ condotto al livello finale cioè dopo il completamento del test di integrazione.e. dopo il completamento dei test di integrazione e appena prima di consegnare il sistema per UAT. |
| È un test di basso livello. | È un test di alto livello. |
| I casi di test SIT si concentrano sull’interfaccia tra i componenti del sistema. | I casi di test, in questo caso, si concentrano sulla simulazione degli scenari di vita reale. |
System Integration Testing Vs User Acceptance Testing
Ecco la differenza tra SIT e UAT:
| SIT (System Integration Testing) | UAT (User Acceptance Testing) |
|---|---|
| Questo test è dalla prospettiva dell’interfacciamento tra i moduli. | Questo test è dalla prospettiva dei requisiti utente. |
| SIT è fatto da sviluppatori e tester. | UAT è fatto da clienti e utenti finali. |
| Fatto dopo il test delle unità e prima del test del sistema. | Questo è l’ultimo livello di test e viene fatto dopo il test del sistema. |
| Generalmente, i problemi trovati nel SIT sarebbero legati al flusso di dati, al flusso di controllo, ecc. | I problemi trovati in UAT sarebbero generalmente come le caratteristiche che non funzionano secondo i requisiti dell’utente. |
L’immagine qui sotto sui livelli di test vi renderà chiaro il flusso dall’Unit testing all’UAT:
Esempio SIT
Immaginiamo che un’azienda stia usando un software per memorizzare i dati dei clienti.
Questo software ha due schermate nell’UI – Schermo 1 & Schermo 2, e ha un database. I dettagli inseriti nello schermo 1 e nello schermo 2 sono inseriti nel database. Finora, l’azienda è soddisfatta di questo software.
Tuttavia, qualche anno dopo l’azienda scopre che il software non soddisfa i requisiti e c’è bisogno di un miglioramento. Quindi, hanno sviluppato uno schermo 3 e un database. Ora, questo sistema che ha Screen 3 e un database è integrato con il software più vecchio/esistente.
Ora, il test fatto sull’intero sistema dopo l’integrazione è chiamato test di integrazione del sistema. Qui, la coesistenza di un nuovo sistema con uno esistente viene testata per assicurare che l’intero sistema integrato funzioni bene.
Tecniche SIT
Principalmente, ci sono 4 approcci per fare SIT:
- Approccio Top-Down
- Approccio Bottom-up
- Approccio Sandwich
- Approccio Big Bang
L’approccio top-down e l’approccio bottom-up sono un tipo di approcci incrementali. Cominciamo prima la discussione con l’approccio Top-down.
#1) Approccio Top-Down:
In questo, il test inizia con solo il modulo più in alto di un’applicazione, cioè l’UI che chiamiamo test driver.
La funzionalità dei moduli sottostanti è simulata con stub. Il modulo superiore viene integrato con lo stub del modulo di livello inferiore uno per uno e successivamente la funzionalità viene testata.
Una volta che ogni test è completato, lo stub viene sostituito dal modulo reale. I moduli possono essere integrati sia in modo breadth-first che in modo depth-first. Il test continua fino a quando l’intera applicazione è costruita.
Il vantaggio di questo approccio è che non c’è bisogno di driver e i casi di test possono essere specificati in termini di funzionalità del sistema.
La sfida principale in questo tipo di approccio è la dipendenza dalla disponibilità delle funzionalità dei moduli di livello inferiore. Ci può essere un ritardo nei test fino a quando i moduli reali sono sostituiti da stub. Scrivere stub è anche difficile.
#2) Approccio Bottom-up:
Elimina le limitazioni dell’approccio top-down.
In questo metodo, prima, i moduli di livello più basso sono assemblati per formare cluster. Questi cluster servono come sotto-funzione dell’applicazione. Poi viene creato un driver per gestire l’input e l’output del test case. Dopo questo, il cluster viene testato.
Una volta che il cluster viene testato, il driver viene rimosso, e il cluster viene combinato con il livello superiore successivo. Questo processo va avanti fino a quando l’intera struttura dell’applicazione è raggiunta.
Non c’è bisogno di stub in questo approccio. Diventa semplificato man mano che l’elaborazione si sposta verso l’alto e la necessità di driver si riduce. Questo approccio è consigliabile per fare il SIT per sistemi orientati agli oggetti, sistemi in tempo reale, e sistemi con strette esigenze di performance.
Tuttavia, il limite di questo approccio è che il sottosistema più importante, cioè l’UI, viene testato per ultimo.
#3) Approccio Sandwich:
Qui, gli approcci top down e bottom up discussi sopra sono combinati insieme.
Il sistema è percepito come se avesse tre strati – lo strato centrale che è lo strato target, uno strato sopra il target e uno strato sotto il target. I test vengono fatti in entrambe le direzioni e si concentrano sullo strato di destinazione che si trova al centro, come illustrato nell’immagine sottostante.
Sandwich Testing Strategy
Un vantaggio di questo approccio è che lo strato superiore e quello inferiore del sistema possono essere testati in parallelo. Tuttavia, il limite di questo approccio è che non testa esaustivamente i singoli sottosistemi prima dell’integrazione.
Per eliminare questa limitazione, abbiamo modificato il test sandwich in cui l’integrazione dei livelli superiore, centrale e inferiore sono testati in parallelo usando stub e driver.
#4) Approccio Big Bang:
In questo approccio, l’integrazione viene fatta una volta che tutti i moduli dell’applicazione sono completamente pronti. Il test viene fatto dopo l’integrazione di tutti i moduli per controllare se il sistema integrato funziona o no.
In questo approccio è difficile trovare la causa principale del problema perché tutto viene integrato in una volta sola, al contrario del test incrementale. Questo approccio è generalmente adottato quando è richiesto un solo ciclo di SIT.
Conclusione
In questo articolo, abbiamo imparato cos’è il System Integration Testing (SIT) e perché è importante eseguirlo.
Abbiamo capito i concetti fondamentali, le tecniche, gli approcci e i metodi coinvolti nello svolgimento del SIT. Abbiamo anche spiegato come il SIT è diverso dall’UAT e dai test di sistema.
Spero che questo eccellente articolo vi sia piaciuto!