what is incremental testing
Con l'aiuto di questo articolo, tratterò uno degli importanti approcci di integrazione: il test incrementale.
Entro la fine di questa sezione, il pubblico avrà una discreta conoscenza di quanto segue:
- Cos'è il test incrementale?
- Il suo obiettivo
- Metodologie
- Vantaggi
- Inconvenienti
Cosa imparerai:
- Cos'è il test incrementale
Cos'è il test incrementale
Incremental Testing, noto anche come Incremental Integration Testing, è uno degli approcci del test di integrazione e incorpora i suoi concetti fondamentali.
È come un test che combina Modulo e Integrazione strategia di test .
In questo test, testiamo ogni modulo individualmente nella fase di test dell'unità, quindi i moduli vengono integrati in modo incrementale e testati per garantire un'interfaccia e un'interazione fluide tra i moduli.
In questo approccio, ogni modulo viene combinato in modo incrementale, cioè uno per uno fino a quando tutti i moduli o componenti vengono aggiunti logicamente per creare l'applicazione richiesta, invece di integrare l'intero sistema in una volta e quindi eseguire il test sul prodotto finale. I moduli integrati vengono testati come gruppo per garantire l'integrazione e il flusso di dati di successo tra i moduli.
Come nel test di integrazione, l'obiettivo principale di eseguire questo test è controllare l'interfaccia, i collegamenti integrati e il flusso di informazioni tra i moduli. Questo processo viene ripetuto fino a quando i moduli vengono combinati e testati con successo.
Esempio
Comprendiamo questo concetto con un esempio:
L'applicazione di sistema o software è costituita dai seguenti moduli:
Approccio al test di integrazione incrementale
- Ogni modulo, ad esempio M1, M2, M3, ecc. Viene testato individualmente come parte del test di unità
- I moduli vengono combinati in modo incrementale, ovvero uno per uno, e testati per un'interazione riuscita
- In Fig2, il modulo M1 e il modulo M2 sono combinati e testati
- In Fig3, il modulo M3 viene aggiunto e testato
- In Fig4, viene aggiunto il modulo M4 e viene eseguito il test per assicurarsi che tutto funzioni correttamente
- Anche il resto dei moduli viene aggiunto in modo incrementale ad ogni passaggio e testato per una corretta integrazione
Fig2
Fig3
qual è il ciclo di vita dello sviluppo del software?
Fig4
Obiettivo del test incrementale
- Per garantire che diversi moduli funzionino insieme correttamente dopo l'integrazione
- Identificare i difetti prima e in ogni fase. Ciò offre agli sviluppatori un vantaggio per identificare dove si trova il problema. Come se il test dopo l'integrazione di M1 e M2 avesse successo, ma quando si aggiunge M3, il test fallisce; questo aiuterà lo sviluppatore a separare il problema
- I problemi possono essere risolti nella fase iniziale senza troppe modifiche e con un costo inferiore
Metodologie di test di integrazione incrementale
Prima di iniziare con questo argomento, vorrei fare una breve introduzione Stub e driver poiché utilizzeremo spesso questi termini.
Stub e driver sono pseudo codice o codice fittizio utilizzato in Integration o test dei componenti quando uno o più moduli non sono sviluppati ma sono necessari per testare qualche altro modulo.
Stub sono utilizzati nell'approccio di test dall'alto verso il basso e sono noti come 'programmi chiamati'. Gli stub aiutano a simulare l'interfaccia tra i moduli della leva inferiore che non sono disponibili o sviluppati.
Autisti sono utilizzati nell'approccio di test dal basso verso l'alto e sono noti come 'programmi chiamanti'. I driver aiutano a simulare l'interfaccia tra i moduli di primo livello che non sono sviluppati o disponibili.
Una domanda che potrebbe sorgere ad alcuni di noi è perché non aspettare che tutti i moduli dell'applicazione siano sviluppati invece di usare stub / driver prima di iniziare il test?
La risposta semplice è che aumenta il tempo di esecuzione del progetto poiché i tester resteranno inattivi finché tutti i moduli non saranno sviluppati. Inoltre, questo rende difficile l'analisi alla radice del difetto. Questo tipo di approccio al test è noto come test di integrazione Big Bang.
Ora che abbiamo coperto Stub e driver, passiamo a diverse metodologie di test incrementale:
# 1) Dall'alto verso il basso
Come suggerisce il nome, il test si svolge dall'alto verso il basso, cioè dal modulo centrale al sottomodulo. I moduli che inquadrano il livello superiore dell'applicazione vengono testati per primi.
Questo approccio segue il flusso strutturale dell'applicazione in fase di test. I moduli oi componenti non disponibili o non sviluppati vengono sostituiti da stub.
Capiamo questo con un esempio:
- Modulo : Accesso al sito web aka L
- Modulo : Order aka O
- Riepilogo dell'ordine del modulo aka OS (non ancora sviluppato)
- Modulo : Payment aka P
- Modulo pagamento in contanti aka CP
- Modulo Debito / Pagamento con credito aka DP (Non ancora sviluppato)
- Modulo Wallet Payment aka WP (non ancora sviluppato)
- Modulo: Reporting aka R (Non ancora sviluppato)
Approccio di test di integrazione incrementale dall'alto verso il basso
Verranno derivati i seguenti casi di test:
miglior cloud storage per file di grandi dimensioni
Scenario di test 1: Il Modulo L e il Modulo O saranno integrati e testati
Scenario di test 2: I moduli L, O e P saranno integrati e testati
Scenario di test 3: I moduli L, O, P e R saranno integrati e testati.
E così via vengono derivati altri casi di test.
Questo tipo di test in cui tutti i moduli di un livello vengono prima integrati e testati è noto come 'breadth-first'. Un'altra categoria è 'prima la profondità'.
I seguenti casi di test verranno derivati per 'prima in profondità':
Scenario di test 1: Il Modulo L e il Modulo O saranno integrati e testati
Scenario di test 2: Modulo L, O e OS saranno integrati e testati
Scenario di test 3: I moduli L, O, OS, P saranno integrati e testati
Caso di test 4: I moduli L, O, OS, P, CP saranno integrati e testati
E così via vengono derivati altri casi di test.
Meriti della metodologia top-down
- Esposizione precoce dei difetti di architettura
- Descrive il funzionamento di un'applicazione nel suo insieme nelle fasi iniziali e aiuta nella rivelazione precoce dei difetti di progettazione
- I principali punti di controllo vengono testati in anticipo
De-meriti della metodologia top-down
- I moduli significativi vengono testati alla fine del ciclo
- È molto difficile scrivere condizioni di prova
- Uno stub non è un'implementazione perfetta del modulo correlato. Simula semplicemente il flusso di dati tra due moduli
# 2) Dal basso verso l'alto
In questo approccio, il test avviene dal basso verso l'alto, cioè i moduli nello strato inferiore vengono integrati e testati prima e poi in sequenza altri moduli vengono integrati mentre ci spostiamo verso l'alto. I moduli non disponibili o non sviluppati vengono sostituiti dai driver.
Diamo un'occhiata a un esempio sotto citato per una migliore comprensione:
I moduli Rank, Marks, Percentage e Sports Grade non sono ancora sviluppati quindi verranno sostituiti con il relativo Driver:
Approccio al test di integrazione incrementale dal basso
Verranno derivati i seguenti casi di test:
Scenario di test 1: Test unitario del modulo Practical and Theory
Scenario di test 2: Integrazione e verifica dei moduli Marks-Practical-theory
Caso di prova 3 : Integrazione e test di moduli Percentage-Marks-Practical-Theory
Caso di test 4: Test unitario del modulo Sports Grade
Scenario di test 5: Integrazione e test di moduli Rank-Sports Grade-Percentage-Marks-Practical-Theory
Meriti della metodologia bottom-up
- Questa metodologia è molto utile per le applicazioni in cui viene utilizzato il modello di progettazione bottom-up
- È più facile creare condizioni di test con un approccio dal basso verso l'alto
- Iniziare il test dal livello più basso della gerarchia significa testare i moduli o le funzionalità critici in una fase iniziale. Questo aiuta nella scoperta precoce degli errori
- I difetti dell'interfaccia vengono rilevati in una fase iniziale
De-meriti della metodologia bottom-up
- I driver sono più difficili da scrivere rispetto allo stub
- I difetti di progettazione vengono rilevati nella fase successiva
- In questo approccio, non abbiamo un'applicazione funzionante fino alla creazione dell'ultimo modulo
- Il driver non è un'implementazione completa del modulo correlato. Simula semplicemente il flusso di dati tra due moduli.
# 3) Test a sandwich
Questo approccio è un ibrido di metodologie top-down e bottom-up. Stub e driver vengono utilizzati per moduli incompleti o non sviluppati.
Approccio al test
- Viene identificato uno strato intermedio da cui vengono eseguiti i test bottom-up e top-down. Questo livello intermedio è noto anche come livello di destinazione
- Il livello di destinazione viene identificato in base all'approccio euristico, ovvero selezionare un livello che consente un utilizzo minimo di Stub e driver
- Il test top-down inizia dallo strato intermedio e si sposta verso il basso verso i moduli di livello inferiore. Questo strato sotto lo strato intermedio è noto come strato inferiore
- Anche i test bottom-up iniziano dal livello intermedio e si spostano verso i moduli del livello superiore. Questo strato sopra lo strato intermedio è noto come strato superiore
- Con l'uso di stub e driver, l'interfaccia utente e le funzioni dei moduli di livello inferiore vengono rispettivamente testate
- Alla fine, rimane solo lo strato intermedio per l'esecuzione del test finale
Esempio:
I seguenti casi di test possono essere derivati con Sandwich Testing Strategy:
Scenario di test 1: Test A, X, Y e Z individualmente - dove il test A rientra nel test dello strato superiore e il test X, Y e Z rientra nei test dello strato inferiore
Scenario di test 2: Prova A, G, H e I.
Scenario di test 3: Prova G, X e Y
Caso di test 4: Mano di prova Z
Scenario di test 5: Prova A, G, H, I, X, Y e Z
Meriti della metodologia dei test sandwich
- È molto vantaggioso per un grande progetto che ha vari sottoprogetti
- La metodologia di test top-down e bottom-up può essere eseguita fianco a fianco
De-meriti della metodologia dei test sandwich
- Prima dell'unificazione dei moduli, i sottosistemi e le loro interfacce non vengono testati a fondo
- Costo più elevato dovuto al coinvolgimento della metodologia di test sia dall'alto verso il basso che dal basso verso l'alto
- Questo tipo di test non è consigliato per un sistema in cui i moduli sono altamente interdipendenti
Conclusione
Il test incrementale rientra nel campo dei test di integrazione. In questo approccio di test, il test di integrazione viene eseguito sul singolo modulo come parte del test unitario e nella fase successiva, i moduli oi componenti dell'applicazione vengono integrati in modo incrementale e il test viene eseguito sui moduli combinati come gruppo.
Su tre metodologie di Incremental Integration Testing, la scelta di quale metodologia scegliere dipende dalla struttura dell'applicazione e anche dalla posizione dei moduli ad alto rischio.
Tutte e tre le metodologie di test incrementale rientrano nella categoria Orizzontale a causa dei seguenti aspetti comportamentali:
- Tutte e tre le metodologie si concentrano sul test di livello
- Tutti considerano un progetto strutturale o gerarchico
- Tutti integrano i livelli in modo incrementale
Pregi:
Con questo approccio di test, è più facile identificare i difetti in anticipo e aiuta anche lo sviluppatore a determinare la causa del problema. Poiché utilizza le basi del test strutturato, questo approccio di test è molto efficace e accurato.
Demeriti:
Questo tipo di approccio al test richiede molto tempo a causa dell'uso di stub e driver. È anche ripetitivo.
Riguardo a autore: Questo utile tutorial è stato scritto da Neha B. Lei è Lead Quality Analyst certificata ISTQB con 8+ anni di esperienza.
Fateci sapere se avete domande / suggerimenti.
Lettura consigliata
- Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
- Che cos'è il test dei componenti o il test dei moduli (impara con esempi)
- Download dell'eBook Testing Primer
- Test funzionale vs test non funzionale
- Che cos'è il test di resistenza nel test del software (esempi)
- Esercitazione sul test di coppia o sul test di tutte le coppie con strumenti ed esempi
- Tipi di test del software: diversi tipi di test con dettagli
- Esercitazione sul test del volume: esempi e strumenti per il test del volume