Che cos'è il test di integrazione del sistema?
Il System Integration Testing è definito come un tipo di test del software eseguito in un ambiente hardware e software integrato per verificare il comportamento dell'intero sistema. Si tratta di test condotti su un sistema completo e integrato per valutare la conformità del sistema ai requisiti specificati.
Il System Integration Testing (SIT) viene eseguito per verificare le interazioni tra i moduli di un sistema software. Si occupa della verifica dei requisiti software di alto e basso livello specificati nella specifica / dati dei requisiti software e nel documento di progettazione del software.
Verifica inoltre la coesistenza di un sistema software con altri e testa l'interfaccia tra i moduli dell'applicazione software. In questo tipo di test, i moduli vengono prima testati individualmente e poi combinati per creare un sistema.
Ad esempio, i componenti software e / o hardware vengono combinati e testati progressivamente fino a quando l'intero sistema non è stato integrato.
In questo tutorial imparerai-
- Che cos'è il test di integrazione del sistema?
- Perché eseguire il test di integrazione del sistema
- Come eseguire il test di integrazione del sistema
- Criteri di ingresso e di uscita per il test di integrazione
- Test di integrazione tra hardware e software
- Software per test di integrazione software
- Approccio dall 'alto verso il basso
- Approccio bottom-up
- Approccio Big Bang
Perché eseguire il test di integrazione del sistema
Nell'ingegneria del software, il test di integrazione del sistema viene eseguito perché,
- Aiuta a rilevare il difetto in anticipo
- Sarà disponibile un feedback precedente sull'accettabilità del singolo modulo
- La pianificazione delle correzioni dei difetti è flessibile e può essere sovrapposta allo sviluppo
- Correggere il flusso di dati
- Correggere il flusso di controllo
- Tempismo corretto
- Correggere l'utilizzo della memoria
- Correggere con i requisiti software
Come eseguire il test di integrazione del sistema
È una tecnica sistematica per costruire la struttura del programma durante l'esecuzione di test per scoprire gli errori associati all'interfacciamento.
Tutti i moduli vengono integrati in anticipo e l'intero programma viene testato nel suo insieme. Ma durante questo processo, è probabile che si verifichi una serie di errori.
La correzione di tali errori è difficile perché le cause dell'isolamento sono complicate dalla vasta espansione dell'intero programma. Una volta che questi errori sono stati corretti e corretti, ne apparirà uno nuovo e il processo continua senza interruzioni in un ciclo infinito . Per evitare questa situazione, viene utilizzato un altro approccio, l'integrazione incrementale. Vedremo più dettagli su un approccio incrementale più avanti nel tutorial.
Esistono alcuni metodi incrementali come i test di integrazione condotti su un sistema basato sul processore di destinazione. La metodologia utilizzata è il Black Box Testing. È possibile utilizzare l'integrazione dal basso verso l'alto o dall'alto verso il basso.
I casi di test vengono definiti utilizzando solo i requisiti software di alto livello.
L'integrazione del software può anche essere ottenuta in gran parte nell'ambiente host, con le unità specifiche per l'ambiente di destinazione che continuano a essere simulate nell'host. Sarà nuovamente necessario ripetere i test nell'ambiente di destinazione per la conferma.
I test di conferma a questo livello identificheranno problemi specifici dell'ambiente, come errori nell'allocazione e nella disallocazione della memoria. La praticità di condurre l'integrazione del software nell'ambiente host dipenderà dalla quantità di funzionalità specifiche di destinazione presenti. Per alcuni sistemi embedded, l'accoppiamento con l'ambiente di destinazione sarà molto forte, rendendo impraticabile condurre l'integrazione del software nell'ambiente host.
I grandi sviluppi del software divideranno l'integrazione del software in una serie di livelli. I livelli inferiori di integrazione del software potrebbero essere basati prevalentemente nell'ambiente host, con i livelli successivi di integrazione del software che diventano più dipendenti dall'ambiente di destinazione.
Nota: se viene testato solo il software, viene chiamato Software Software Integration Testing [SSIT] e se vengono testati sia l'hardware che il software, viene chiamato Hardware Software Integration Testing [HSIT].
Criteri di ingresso e di uscita per il test di integrazione
Di solito durante l'esecuzione del test di integrazione, viene utilizzata la strategia ETVX (criteri di ingresso, attività, convalida e criteri di uscita).
Criteri di ingresso:
- Completamento degli unit test
Ingressi:
- Dati sui requisiti software
- Documento di progettazione del software
- Piano di verifica del software
- Documenti di integrazione software
Attività:
- In base ai requisiti di alto e basso livello, creare procedure e casi di test
- Combina build di moduli di basso livello che implementano una funzionalità comune
- Sviluppa un'imbracatura di prova
- Prova la build
- Una volta superato il test, la build viene combinata con altre build e testata fino a quando il sistema non viene integrato nel suo insieme.
- Rieseguire tutti i test sulla piattaforma basata sul processore di destinazione e ottenere i risultati
Criteri di uscita:
- Completamento con successo dell'integrazione del modulo Software sull'Hardware di destinazione
- Corrette prestazioni del software in base ai requisiti specificati
Uscite
- Rapporti sui test di integrazione
- Procedure e casi di test del software [SVCP].
Test di integrazione software hardware
Il test di integrazione software hardware è un processo di verifica dei componenti software del computer (CSC) per funzionalità di alto livello nell'ambiente hardware di destinazione. L'obiettivo del test di integrazione hardware / software è testare il comportamento del software sviluppato integrato sul componente hardware.
Test di integrazione hardware-software basato sui requisiti
Lo scopo del test di integrazione hardware / software basato sui requisiti è assicurarsi che il software nel computer di destinazione soddisfi i requisiti di alto livello. Gli errori tipici rilevati da questo metodo di test includono:
- Errori delle interfacce hardware / software
- Violazioni del partizionamento del software.
- Incapacità di rilevare i guasti tramite test integrato
- Risposta errata ai guasti hardware
- Errore dovuto a sequenziamento, carichi transitori in ingresso e transitori di potenza in ingresso
- Il feedback riproduce un comportamento errato
- Controllo errato o improprio dell'hardware di gestione della memoria
- Problema di contesa del bus di dati
- Funzionamento errato del meccanismo per verificare la compatibilità e la correttezza del software caricabile sul campo
Hardware Software Integration si occupa della verifica dei requisiti di alto livello. Tutti i test a questo livello vengono condotti sull'hardware di destinazione.
- Il test black box è la metodologia di test principale utilizzata a questo livello di test.
- Definisci i casi di test solo dai requisiti di alto livello
- È necessario eseguire un test sull'hardware standard di produzione (sul target)
Aspetti da considerare quando si progettano casi di test per l'integrazione HW / SW
- Corretta acquisizione di tutti i dati da parte del software
- Ridimensionamento e gamma di dati come previsto dall'hardware al software
- Correzione dell'output dei dati dal software all'hardware
- Dati entro le specifiche (intervallo normale)
- Dati al di fuori delle specifiche (intervallo anomalo)
- Dati di confine
- Interrompe l'elaborazione
- Tempistica
- Utilizzo corretto della memoria (indirizzamento, sovrapposizioni, ecc.)
- Transizioni di stato
Nota: per il test degli interrupt, tutti gli interrupt verranno verificati indipendentemente dalla richiesta iniziale attraverso la manutenzione completa e fino al completamento. I casi di test saranno progettati specificamente per testare adeguatamente gli interrupt.
Software per test di integrazione software
È il test del componente software del computer che opera all'interno del computer host / di destinazione
Ambiente, simulando l'intero sistema [altri CSC] e sulla funzionalità di alto livello.
Si concentra sul comportamento di un CSC in un ambiente host / target simulato. L'approccio utilizzato per l'integrazione del software può essere un approccio incrementale (top-down, bottom-up o una combinazione di entrambi).
Approccio incrementale
Il test incrementale è un modo di test di integrazione. In questo tipo di metodo di test, si testa prima ogni modulo del software individualmente e poi si continua il test aggiungendovi altri moduli, poi un altro e così via.
L'integrazione incrementale è in contrasto con l'approccio del big bang. Il programma è costruito e testato in piccoli segmenti, dove gli errori sono più facili da isolare e correggere. È più probabile che le interfacce vengano testate completamente e può essere applicato un approccio di test sistematico.
Esistono due tipi di test incrementali
- Approccio dall 'alto verso il basso
- Approccio dal basso verso l'alto
Approccio dall 'alto verso il basso
In questo tipo di approccio, i singoli iniziano testando solo l'interfaccia utente, con la funzionalità sottostante simulata dagli stub, quindi ci si sposta verso il basso integrando livelli inferiori e inferiori come mostrato nell'immagine sottostante.
- A partire dal modulo di controllo principale, i moduli vengono integrati spostandosi verso il basso attraverso la gerarchia di controllo
- I sottomoduli al modulo di controllo principale sono incorporati nella struttura in un modo basato sull'ampiezza o sulla profondità.
- L'integrazione in profondità integra tutti i moduli su un percorso di controllo principale della struttura come mostrato nel diagramma seguente:
Il processo di integrazione del modulo viene eseguito nel modo seguente:
- Il modulo di controllo principale viene utilizzato come driver di prova e gli stub vengono sostituiti per tutti i moduli direttamente subordinati al modulo di controllo principale.
- Gli stub subordinati vengono sostituiti uno alla volta con moduli effettivi a seconda dell'approccio selezionato (prima larghezza o prima profondità).
- I test vengono eseguiti non appena ogni modulo è integrato.
- Al termine di ogni serie di test, un altro stub viene sostituito con un modulo reale al termine di ogni serie di test
- Per assicurarsi che non siano stati introdotti nuovi errori, è possibile eseguire il test di regressione.
Il processo continua dal passaggio 2 fino alla creazione dell'intera struttura del programma. La strategia top-down sembra relativamente semplice, ma in pratica sorgono problemi logistici.
Il più comune di questi problemi si verifica quando l'elaborazione a livelli bassi nella gerarchia è necessaria per testare adeguatamente i livelli superiori.
Gli stub sostituiscono i moduli di basso livello all'inizio del test top-down e, pertanto, nessun dato significativo può fluire verso l'alto nella struttura del programma.
Sfide che il tester potrebbe dover affrontare:
- Ritarda molti test finché gli stub non vengono sostituiti con i moduli effettivi.
- Sviluppa stub che eseguono funzioni limitate che simulano il modulo effettivo.
- Integra il software dal fondo della gerarchia verso l'alto.
Nota: il primo approccio ci fa perdere un po 'di controllo sulla corrispondenza tra test specifici e incorporazione di moduli specifici. Ciò può comportare difficoltà nel determinare la causa degli errori che tende a violare la natura altamente vincolata dell'approccio dall'alto verso il basso.
Il secondo approccio è praticabile ma può portare a un sovraccarico significativo, poiché gli stub diventano sempre più complessi.
Approccio bottom-up
L'integrazione dal basso verso l'alto inizia la costruzione e il test con i moduli al livello più basso nella struttura del programma. In questo processo, i moduli vengono integrati dal basso verso l'alto.
In questo approccio l'elaborazione richiesta per i moduli subordinati a un dato livello è sempre disponibile e la necessità degli stub viene eliminata.
Questo processo di test di integrazione viene eseguito in una serie di quattro passaggi
- I moduli di basso livello sono combinati in cluster che svolgono una specifica sottofunzione software.
- Viene scritto un driver per coordinare l'input e l'output del test case.
- Il cluster o la build viene testato.
- I driver vengono rimossi e i cluster vengono combinati spostandosi verso l'alto nella struttura del programma.
Con l'aumento dell'integrazione, la necessità di lezioni separate per i collaudatori. Infatti, se i primi due livelli della struttura del programma sono integrati dall'alto verso il basso, il numero di driver può essere ridotto in modo sostanziale e l'integrazione dei cluster è notevolmente semplificata. L'integrazione segue lo schema illustrato di seguito. Con l'aumento dell'integrazione, la necessità di lezioni separate per i collaudatori.
Nota: se i primi due livelli della struttura del programma sono integrati dall'alto verso il basso, il numero di driver può essere ridotto in modo sostanziale e l'integrazione delle build è notevolmente semplificata.
Approccio Big Bang
In questo approccio, tutti i moduli non vengono integrati fino a quando ea meno che tutti i moduli non siano pronti. Una volta pronti, tutti i moduli vengono integrati e quindi viene eseguito per sapere se tutti i moduli integrati funzionano o meno.
In questo approccio, è difficile conoscere la causa principale del fallimento a causa dell'integrazione di tutto in una volta.
Inoltre, ci sarà un'alta probabilità che si verifichino bug critici nell'ambiente di produzione.
Questo approccio viene adottato solo quando il test di integrazione deve essere eseguito contemporaneamente.
Sommario:
- L'integrazione viene eseguita per verificare le interazioni tra i moduli di un sistema software. Aiuta a rilevare precocemente il difetto
- È possibile eseguire test di integrazione per l'integrazione hardware-software o hardware-hardware
- Il test di integrazione viene eseguito con due metodi
- Approccio incrementale
- Approccio big bang
- Durante l'esecuzione del test di integrazione viene generalmente utilizzata la strategia ETVX (criteri di ingresso, attività, convalida e criteri di uscita).