White Box Testing: una guida completa con tecniche, esempi e strumenti

white box testing complete guide with techniques

Cos'è il White Box Testing?

Se seguiamo la definizione, 'White box testing' (noto anche come clear, glass box o test strutturale) è una tecnica di test che valuta il codice e la struttura interna di un programma.

Il test della scatola bianca implica l'osservazione della struttura del codice. Quando si conosce la struttura interna di un prodotto, è possibile eseguire test per garantire che le operazioni interne siano eseguite secondo le specifiche. E tutti i componenti interni sono stati adeguatamente esercitati.

Cosa imparerai:

• La mia esperienza
  • Copertura
  • Perché eseguiamo WBT?
  • Questo test richiede competenze di programmazione dettagliate?
  • Limitazioni
• Differenza tra test white box e black box
• Passaggi per eseguire WBT
• Tipi e tecniche di test white box
• Esempio di test white box
• Strumenti di test White Box
• Conclusione
• Lettura consigliata

La mia esperienza

Sono passati quasi dieci anni da quando mi occupo di test del software e finora ho notato che i tester sono i più entusiasti dell'intera industria del software.

La ragione principale alla base di questo è che i tester hanno sempre qualcosa da imparare. Che si tratti di un dominio, di un processo o di una tecnologia, un tester può avere uno sviluppo completo se lo desidera.

Ma come si dice 'C'è sempre un lato oscuro' .

I tester evitano anche un tipo di test che ritengono molto complicato e il gioco da ragazzi per lo sviluppatore. Sì, il 'White Box Testing'.

Copertura

White Box Testing è la copertura delle specifiche nel codice:

1. Copertura del codice

2. Copertura del segmento: Assicurati che ogni istruzione di codice venga eseguita una volta.

3. Copertura delle filiali o test dei nodi: La copertura di ogni ramo di codice da tutto il possibile era.

4. Copertura delle condizioni del composto: Per più condizioni, testare ciascuna condizione con più percorsi e una combinazione del percorso diverso per raggiungere quella condizione.

5. Test del percorso di base: Ogni percorso indipendente nel codice viene preso per il test.

6. Test del flusso di dati (DFT): In questo approccio si tracciano le variabili specifiche attraverso ogni possibile calcolo, definendo così l'insieme di percorsi intermedi attraverso il codice. DFT tende a riflettere le dipendenze ma è principalmente attraverso sequenze di manipolazione dei dati. In breve, ogni variabile di dati viene tracciata e il suo utilizzo viene verificato. Questo approccio tende a scoprire bug come le variabili usate ma non inizializzate, o dichiarate ma non usate, e così via.

7. Test del percorso: Il test del percorso è dove vengono definiti e coperti tutti i possibili percorsi attraverso il codice. È un'attività che richiede tempo.

8. Test di loop: Queste strategie riguardano il test di loop singoli, loop concatenati e loop nidificati. I loop di codice e i valori indipendenti e dipendenti vengono testati da questo approccio.

Perché eseguiamo WBT?

Per garantire:

• Che tutti i percorsi indipendenti all'interno di un modulo siano stati esercitati almeno una volta.
• Tutte le decisioni logiche verificate sui loro valori veri e falsi.
• Tutti i cicli eseguiti ai loro confini e all'interno dei loro limiti operativi validità delle strutture dati interne.

Per scoprire i seguenti tipi di bug:

• L'errore logico tende a insinuarsi nel nostro lavoro quando progettiamo e implementiamo funzioni, condizioni o controlli che sono fuori programma
• Gli errori di progettazione dovuti alla differenza tra il flusso logico del programma e l'effettiva implementazione
• Errori tipografici e controllo della sintassi

Questo test richiede competenze di programmazione dettagliate?

Dobbiamo scrivere casi test che assicurano la copertura completa della logica del programma.

Per questo abbiamo bisogno di conoscere bene il programma, cioè dovremmo conoscere le specifiche e il codice da testare. La conoscenza dei linguaggi di programmazione e della logica è richiesta per questo tipo di test.

Limitazioni

Non è possibile testare ogni percorso dei loop nel programma. Ciò significa che è impossibile eseguire test esaustivi per sistemi di grandi dimensioni.

Ciò non significa che il WBT non sia efficace. Selezionando importanti percorsi logici e strutture dati per il test è praticamente possibile ed efficace.

Differenza tra test white box e black box

Per dirla in termini semplici:

Durante il test Black box, testiamo il software dal punto di vista di un utente, ma in White box, vediamo e testiamo il codice effettivo.

In Black box testing, eseguiamo test senza vedere il codice di sistema interno, ma in WBT vediamo e testiamo il codice interno.

La tecnica di test della scatola bianca viene utilizzata sia dagli sviluppatori che dai tester. Li aiuta a capire quale riga di codice viene effettivamente eseguita e quale no. Ciò potrebbe indicare che manca una logica o un errore di battitura, che alla fine può portare ad alcune conseguenze negative.

Lettura consigliata => Una guida completa ai test Black Box

Passaggi per eseguire WBT

Passo 1 - Comprendere la funzionalità di un'applicazione tramite il suo codice sorgente. Ciò significa che un tester deve essere esperto del linguaggio di programmazione e degli altri strumenti, nonché delle tecniche utilizzate per sviluppare il software.

Passo 2 - Crea i test ed eseguili.

Quando discutiamo del concetto di test, ' copertura 'È considerato il fattore più importante. Qui spiegherò come avere la massima copertura dal contesto del white box testing.

Leggi anche=> Causa ed effetto grafico - Tecnica di scrittura dinamica del test case per la massima copertura

Tipi e tecniche di test white box

Esistono diversi tipi e metodi diversi per ogni tipo di test white box.

Guarda l'immagine qui sotto come riferimento.

Oggi ci concentreremo principalmente sul tipi di test di esecuzione della 'tecnica della scatola bianca di test unitari'.

3 principali tecniche di test white box:

1. Copertura della dichiarazione
2. Copertura delle filiali
3. Copertura del percorso

Notare che l'istruzione, il ramo o la copertura del percorso non identifica alcun bug o difetto che deve essere corretto. Identifica solo quelle righe di codice che non vengono mai eseguite o che rimangono intatte. Sulla base di questo ulteriore test può essere focalizzato.

Comprendiamo queste tecniche una per una con un semplice esempio.

# 1) Copertura delle dichiarazioni:

In un linguaggio di programmazione, un'affermazione non è altro che la riga di codice o l'istruzione che il computer deve comprendere e agire di conseguenza. Un'istruzione diventa un'istruzione eseguibile quando viene compilata e convertita nel codice oggetto ed esegue l'azione quando il programma è in modalità di esecuzione.

Quindi 'Copertura della dichiarazione' , come suggerisce il nome stesso, è il metodo per verificare se ogni riga del codice viene eseguita almeno una volta.

# 2) Copertura delle filiali:

'Branch' in un linguaggio di programmazione è come le 'istruzioni IF'. Un'istruzione IF ha due rami: T ruta e falso .

Quindi, nella copertura delle filiali (chiamata anche copertura delle decisioni), convalidiamo se ogni filiale viene eseguita almeno una volta.

In caso di una 'dichiarazione IF', ci saranno due condizioni di test:

• Uno per convalidare il vero ramo e,
• Altro per convalidare il falso ramo.

Quindi, in teoria, Branch Coverage è un metodo di test che, una volta eseguito, garantisce l'esecuzione di ogni singolo ramo da ogni punto di decisione.

# 3) Copertura del percorso

La copertura del percorso verifica tutti i percorsi del programma. Questa è una tecnica completa che assicura che tutti i percorsi del programma vengano attraversati almeno una volta. La copertura del percorso è ancora più potente della copertura delle filiali. Questa tecnica è utile per testare i programmi complessi.

Facciamo un semplice esempio per comprendere tutte queste tecniche di test white box.

come restituire array in java

Controlla anche=> Diversi tipi di test

Esempio di test white box

Considera il seguente semplice pseudocodice:

Per Copertura della dichiarazione - avremmo bisogno di un solo test case per controllare tutte le righe del codice.

Questo significa:

Se considero TestCase_01 da essere (A = 40 e B = 70), quindi verranno eseguite tutte le righe di codice.

Ora sorge la domanda:

1. È sufficiente?
2. Cosa succede se considero il mio test case come A = 33 e B = 45?

Poiché la copertura delle dichiarazioni coprirà solo il lato vero, per lo pseudo codice, un solo test case NON sarebbe sufficiente per testarlo. In qualità di tester, dobbiamo considerare anche i casi negativi.

Quindi per la massima copertura, dobbiamo considerare ' Copertura delle filiali ' , che valuterà le condizioni “FALSE”.

Nel mondo reale, puoi aggiungere dichiarazioni appropriate quando la condizione fallisce.

Quindi ora lo pseudocodice diventa:

Poiché la copertura Statement non è sufficiente per testare l'intero pseudo codice, avremmo bisogno della copertura Branch per garantire la massima copertura .

Quindi, per la copertura delle filiali, avremmo bisogno di due casi di test per completare il test di questo pseudo codice.

TestCase_01 : A = 33, B = 45

TestCase_02 : A = 25, B = 30

come aprire il file .swf

Con questo, possiamo vedere che ogni riga del codice viene eseguita almeno una volta.

Ecco le conclusioni che sono derivate finora:

• La copertura delle filiali garantisce una copertura maggiore rispetto alla copertura delle dichiarazioni.
• La copertura delle filiali è più potente della copertura degli estratti conto.
• Copertura del 100% delle filiali in sé significa copertura del 100% delle dichiarazioni.
• Ma la copertura del 100% delle dichiarazioni non garantisce la copertura del 100% delle filiali.

Ora passiamo a Copertura percorso:

Come detto in precedenza, la copertura del percorso viene utilizzata per testare i frammenti di codice complessi, che fondamentalmente coinvolgono istruzioni di ciclo o una combinazione di cicli e istruzioni di decisione.

Considera questo pseudocodice:

Ora per garantire la massima copertura, avremmo bisogno di 4 casi di test.

Come? Semplicemente: ci sono 2 dichiarazioni di decisione, quindi per ogni dichiarazione di decisione, avremmo bisogno di due rami da testare. Uno per il vero e l'altro per la falsa condizione. Quindi, per 2 affermazioni decisionali, avremmo bisogno di 2 casi di test per testare il lato vero e 2 casi di test per testare il lato falso, per un totale di 4 casi di test.

Per semplificarli, consideriamo di seguito il diagramma di flusso dello pseudo codice che abbiamo:

Per avere la copertura completa, avremmo bisogno dei seguenti casi di test:

TestCase_01: A = 50, B = 60

TestCase_02 : A = 55, B = 40

TestCase_03: A = 40, B = 65

TestCase_04: A = 30, B = 30

Quindi il percorso coperto sarà:

Linea rossa - TestCase_01 = (A = 50, B = 60)

Linea blu = TestCase_02 = (A = 55, B = 40)

Linea arancione = TestCase_03 = (A = 40, B = 65)

Linea verde = TestCase_04 = (A = 30, B = 30)

******************
= >> Contattaci per suggerire il tuo annuncio qui
*****************

Strumenti di test White Box

Di seguito è riportato un elenco dei migliori strumenti di test white box.

# 1) Veracode

Gli strumenti di test white box di Veracode ti aiuteranno a identificare e risolvere i difetti del software rapidamente e facilmente a un costo ridotto. Supporta diversi linguaggi applicativi come .NET, C ++, JAVA ecc. E consente inoltre di testare la sicurezza di applicazioni desktop, web e mobili. Tuttavia, ci sono molti altri vantaggi dello strumento Veracode. Per informazioni dettagliate sugli strumenti di test della casella bianca Veracode, controllare il collegamento sottostante.

Link al sito web: Veracode

# 2) EclEmma

EclEmma è stato inizialmente progettato per l'esecuzione di test e analisi all'interno del workbench Eclipse. È considerato uno strumento gratuito di copertura del codice Java e ha anche diverse funzionalità. Per installare o saperne di più su EclEmma, ​​controlla il link sottostante.

Link al sito web: EclEmma

# 3) RCUNIT

Un framework utilizzato per testare i programmi C è noto come RCUNIT. RCUNIT può essere utilizzato di conseguenza in base ai termini della licenza MIT. È gratuito e per installarlo o saperne di più, controlla il link sottostante.

Link al sito web: RCUNIT

# 4) cfix

cfix è uno dei framework di unit test per C / C ++ che mira esclusivamente a rendere lo sviluppo di suite di test il più semplice e facile possibile. Nel frattempo, cfix è tipicamente specializzato per la modalità NT Kernel e Win32. Per installare e saperne di più su cfix, controlla il link sottostante

Link al sito web: cfix

# 5) Google Test

Googletest è il framework di test C ++ di Google. Test Discovery, test di morte, test parametrizzati con valore, errori irreversibili e non fatali, generazione di report di test XML ecc.Sono alcune funzionalità di GoogleTest ma ci sono anche molte altre funzionalità. Linux, Windows, Symbian, Mac OS X sono alcune piattaforme in cui è stato utilizzato GoogleTest. In modo daScarica, controlla il link sottostante.

Link per scaricare: Test di Google

# 6) EMMA

Emma è uno strumento gratuito di copertura del codice JAVA facile da usare. Include diverse funzionalità e vantaggi. Per scaricare e saperne di più su Emma, ​​controlla il link sottostante.

Link per scaricare: EMMA

# 7) NUnit

NUnit è un framework di unit test open source facile da usare che non richiede alcun intervento manuale per giudicare i risultati del test. Supporta tutti i linguaggi .NET. Supporta anche test basati sui dati e test eseguiti in parallelo con NUnit. Le versioni precedenti di NUnit utilizzavano la licenza NUnit ma NUnit 3 è rilasciata con la licenza MIT. Ma entrambe le licenze consentono un utilizzo gratuito senza alcuna restrizione. Per scaricare e saperne di più su NUnit, controlla il link sottostante.

Link per scaricare: NUnit

# 8) CppUnit

CppUnit è un framework di unit test scritto in C ++ ed è considerato il port di JUnit. L'output di test per CppUnit può essere in formato XML o testo. Crea unit test con la propria classe ed esegue i test nelle suite di test. È concesso in licenza con LGPL. Per scaricare e saperne di più su CppUnit, controlla il link sottostante.

Link per scaricare: CppUnit

# 9) JUnit

JUnit è un framework di unit test semplice e silenzioso che supporta l'automazione dei test in Java Programming Language. Supporta principalmente lo sviluppo basato sui test e fornisce anche il rapporto sulla copertura del test. È concesso in licenza con Eclipse Public License. Per il download gratuito e per saperne di più su JUnit, controlla il link sottostante.

Link per scaricare: JUnit

# 10) JsUnit

JsUnit è considerato il port di JUnit a javascript. Ed è un framework di unit test open source per supportare Javascript lato client. È concesso in licenza con GNU Public License 2.0, GNU Lesser Public License 2.1 e Mozilla Public License 1.1. Per scaricare e saperne di più su JsUnit, controlla il link sottostante.

Link per scaricare: JsUnit

Inoltre, controlla tutti gli strumenti che abbiamo elencato sotto Analisi statica del codice Qui .

Sentiti libero di suggerire strumenti più semplici o avanzati che stai utilizzando per la tecnica della scatola bianca.

Conclusione

Affidarsi solo al test della scatola nera non è sufficiente per la massima copertura del test. Abbiamo bisogno di una combinazione di tecniche di test della scatola nera e della scatola bianca per coprire i difetti massimi .

Se eseguito correttamente, il test White box contribuirà sicuramente alla qualità del software. È anche positivo per i tester partecipare a questo test in quanto può fornire l'opinione più 'imparziale' sul codice. :)

Facci sapere se hai domande sui metodi che abbiamo discusso in questo articolo.

Lettura consigliata

• Differenze chiave tra il test della scatola nera e il test della scatola bianca
• Black Box Testing: un tutorial approfondito con esempi e tecniche
• Test funzionale vs test non funzionale
• Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
• Pensare fuori dagli schemi durante il test del software!
• Guida ai test di portabilità con esempi pratici
• Alpha test e beta test (una guida completa)
• Tipi di test del software: diversi tipi di test con dettagli