Che cos'è l'esempio di System Integration Testing (SIT).

Cos'è il test di integrazione del sistema?

Sistema Test d'integrazione è definito come un tipo di test del software effettuato in un ambiente integrato hardware e software per verificare il comportamento del sistema completo. 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 nelle Specifiche/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 singolarmente e poi combinati per formare un sistema. Ad esempio, i componenti software e/o hardware vengono combinati e testati progressivamente fino all'integrazione dell'intero sistema.

Test di integrazione del sistema

Perché eseguire test di integrazione di sistema?

Nell'ingegneria del software, i test di integrazione dei sistemi vengono eseguiti perché,

  • Aiuta a rilevare Difetto presto
  • Sarà disponibile un feedback anticipato sull'accettabilità del singolo modulo
  • La pianificazione delle correzioni dei difetti è flessibile e può essere sovrapposta allo sviluppo
  • Flusso di dati corretto
  • Flusso di controllo corretto
  • Tempismo corretto
  • Utilizzo corretto della memoria
  • Correggere con i requisiti software

Come eseguire test di integrazione del sistema

È una tecnica sistematica per costruire la struttura del programma mentre si conducono test per scoprire errori associati all'interfaccia.

Tutti i moduli sono 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 di isolamento sono complicate dalla vasta espansione dell'intero programma. Una volta corretti e corretti questi errori, ne apparirà uno nuovo e il processo continuerà senza interruzioni in un ciclo infinito. Per evitare questa situazione, si usa un altro approccio, l'integrazione incrementale. Vedremo maggiori 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 è Nero 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 unità specifiche per l'ambiente target che continuano ad essere simulate nell'host. Sarà nuovamente necessario ripetere i test nell’ambiente di destinazione per conferma.

I test di conferma a questo livello identificheranno problemi specifici dell'ambiente, come errori nell'allocazione e deallocazione della memoria. La praticità della conduzione integrazione software nell'ambiente host dipenderà dalla quantità di funzionalità specifiche del target presenti. Per alcuni sistemi embedded l'accoppiamento con l'ambiente di destinazione sarà molto forte, rendendo poco pratico l'integrazione del software nell'ambiente host.

I grandi sviluppi software divideranno l'integrazione software in diversi livelli. I livelli inferiori di integrazione software potrebbero essere basati prevalentemente sull'ambiente host, con livelli successivi di integrazione software che diventeranno più dipendenti dall'ambiente di destinazione.

Nota: Se viene testato solo il software, allora si chiama Software Software Integration Testing [SSIT] e se vengono testati sia l'hardware che il software, allora si chiama Hardware Software Integration Testing [HSIT].

Criteri di entrata e uscita per i 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 partecipazione:

Ingressi:

  • Dati sui requisiti software
  • Documento di progettazione del software
  • Piano di verifica del software
  • Documenti di integrazione del software

Attività:

  • Sulla base dei requisiti di livello Alto e Basso, creare casi di test e procedure
  • Combina build di moduli di basso livello che implementano una funzionalità comune
  • Sviluppare un cablaggio di prova
  • Testare la costruzione
  • Una volta superato il test, la build viene combinata con altre build e testata finché il sistema non viene integrato nel suo insieme.
  • Eseguire nuovamente 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 target
  • Corretta prestazione del software secondo i requisiti specificati

Uscite

  • Rapporti sui test di integrazione
  • Casi e procedure di test del software [SVCP].

Test di integrazione software hardware

Test di integrazione software hardware è un processo di test dei componenti software del computer (CSC) per funzionalità di alto livello sull'ambiente hardware di destinazione. L'obiettivo del test di integrazione hardware/software è testare il comportamento del software sviluppato integrato nel componente hardware.

Test di integrazione hardware-software basato sui requisiti

Lo scopo dei test di integrazione hardware/software basati sui requisiti è garantire che il software nel computer di destinazione soddisfi i requisiti di alto livello. Gli errori tipici rilevati da questo metodo di test includono:

  • Errori nelle interfacce hardware/software
  • Violazioni del partizionamento del software.
  • Impossibilità di rilevare guasti tramite test integrato
  • Risposta errata ai guasti hardware
  • Errore dovuto alla sequenza, ai carichi transitori di ingresso e ai transitori di potenza in ingresso
  • Comportamento errato dei cicli di feedback
  • Controllo errato o improprio dell'hardware di gestione della memoria
  • Problema di contesa del bus dati
  • Funzionamento errato del meccanismo per verificare la compatibilità e la correttezza del software caricabile sul campo

L'integrazione hardware software si occupa della verifica dei requisiti di alto livello. Tutti i test a questo livello vengono condotti sull'hardware di destinazione.

  • Il test della scatola nera è la metodologia di test principale utilizzata a questo livello di test.
  • Define casi test solo dai requisiti di alto livello
  • È necessario eseguire un test sull'hardware standard di produzione (sul target)

Cose da considerare quando si progettano casi di test per l'integrazione HW/SW

  • Corretta acquisizione di tutti i dati da parte del software
  • Scalabilità e gamma di dati come previsto dall'hardware al software
  • Corretto output dei dati dal software all'hardware
  • Dati entro le specifiche (intervallo normale)
  • Dati fuori specifica (intervallo anomalo)
  • Dati di confine
  • Interrompe l'elaborazione
  • Sincronizzazione
  • Corretto utilizzo della memoria (indirizzamento, sovrapposizioni, ecc.)
  • Transizioni di stato

Nota: Per il test delle interruzioni, tutte le interruzioni verranno verificate indipendentemente dalla richiesta iniziale fino alla manutenzione completa e al completamento. I casi di test saranno specificatamente progettati per testare adeguatamente gli interrupt.

Test di integrazione da software a 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/destinazione simulato. L'approccio utilizzato per l'integrazione del software può essere un approccio incrementale (approccio 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, prima si testa individualmente ciascun modulo del software e poi si continua il test aggiungendovi altri moduli, poi un altro e così via.

L’integrazione incrementale è il 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, l'individuo inizia testando solo l'interfaccia utente, con le funzionalità sottostanti simulate da stub, quindi si sposta verso il basso integrando strati sempre più bassi come mostrato nell'immagine qui sotto.

Approccio dall 'alto verso il basso

  • Partendo dal modulo di controllo principale, i moduli vengono integrati procedendo verso il basso lungo la gerarchia di controllo
  • I sottomoduli del modulo di controllo principale sono incorporati nella struttura sia in ampiezza che in profondità.
  • L'integrazione depth-first integra tutti i moduli su un percorso di controllo principale della struttura, come mostrato nel diagramma seguente:

Approccio dall 'alto verso il basso

Il processo di integrazione dei moduli avviene nel modo seguente:

  1. Il modulo di controllo principale viene utilizzato come test driver e gli stub sostituiscono tutti i moduli direttamente subordinati al modulo di controllo principale.
  2. Gli stub subordinati vengono sostituiti uno alla volta con moduli veri e propri a seconda dell'approccio selezionato (prima la larghezza o prima la profondità).
  3. I test vengono eseguiti man mano che ciascun modulo viene integrato.
  4. Al completamento di ciascuna serie di test, un altro stub viene sostituito con un modulo reale al completamento di ciascuna serie di test
  5. Per assicurarsi che non siano stati introdotti nuovi errori Test di regressione può essere eseguito.

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 è necessaria l'elaborazione ai livelli bassi della gerarchia per testare adeguatamente i livelli superiori.

Gli stub sostituiscono i moduli di basso livello all'inizio del test top-down e quindi nessun dato significativo può fluire verso l'alto nella struttura del programma.

Sfide che il Tester potrebbe affrontare:

  • Ritardare molti test finché gli stub non verranno sostituiti con moduli effettivi.
  • Sviluppa stub che eseguono funzioni limitate che simulano il modulo reale.
  • Integrare il software dal basso verso l'alto della gerarchia.

Nota: Il primo approccio ci fa perdere un po' di controllo sulla corrispondenza tra test specifici e sull'incorporazione di moduli specifici. Ciò può comportare difficoltà nel determinare la causa degli errori, il che tende a violare la natura altamente vincolata dell’approccio top-down.

Il secondo approccio è praticabile, ma può comportare notevoli spese generali, poiché gli stub diventano sempre più complessi.

Approccio dal basso verso l'alto

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 ad un dato livello è sempre disponibile e viene eliminata la necessità degli stub.

Questo processo di test di integrazione viene eseguito in una serie di quattro passaggi

  1. I moduli di basso livello sono combinati in cluster che eseguono una specifica sottofunzione del software.
  2. Viene scritto un driver per coordinare l'input e l'output del test case.
  3. Il cluster o la build vengono testati.
  4. I driver vengono rimossi e i cluster vengono combinati salendo verso l'alto nella struttura del programma.

Man mano che l'integrazione procede verso l'alto, cresce la necessità di lezioni separate per i collaudatori. Infatti, se i primi due livelli della struttura del programma vengono integrati dall’alto verso il basso, il numero di fattori trainanti può essere ridotto sostanzialmente e l’integrazione dei cluster risulta notevolmente semplificata. L'integrazione segue lo schema illustrato di seguito. Man mano che l'integrazione procede verso l'alto, cresce la necessità di lezioni separate per i collaudatori.

Approccio dal basso verso l'alto

Nota: Se i primi due livelli della struttura del programma vengono integrati dall'alto verso il basso, il numero di conducenti può essere ridotto sostanzialmente e l'integrazione delle build risulta notevolmente semplificata.

Approccio del Big Bang

In questo approccio, tutti i moduli non vengono integrati finché e a meno che tutti i moduli non siano pronti. Una volta pronti, tutti i moduli vengono integrati e quindi vengono eseguiti per sapere se tutti i moduli integrati funzionano o meno.

In questo approccio, è difficile conoscere la causa principale del fallimento perché si integra 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 i test di integrazione devono essere eseguiti contemporaneamente.

Sintesi

  • L'integrazione viene eseguita per verificare le interazioni tra i moduli di un sistema software. Aiuta a rilevare precocemente il difetto
  • Il test di integrazione può essere eseguito 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 dei test di integrazione viene generalmente utilizzata la strategia ETVX (criteri di ingresso, attività, convalida e criteri di uscita).