Testing Black-Box vs. White-Box: Confronto Esperto

Combinare entrambi gli approcci migliora la copertura dei test e la qualità del software.

In questo articolo ti guiderò attraverso entrambi i tipi di test, spiegando cosa sono, le principali differenze fra loro, come vengono utilizzati, nonché i loro pro e contro. 

Cos’è il Black-Box Testing?

Il Black-box testing, talvolta chiamato testing comportamentale, è una tipologia di test del software in cui il tester non ha accesso al codice sorgente del sistema in fase di verifica. Di solito viene eseguito dal team di quality assurance e non richiede necessariamente competenze tecniche avanzate, come la programmazione.  

Nel black-box testing, i casi di test sono scritti sulla base degli input e degli output dell’AUT, come definiti nelle specifiche dei requisiti.

Le tecniche di black-box testing più rilevanti sono:

• Partizionamento di equivalenza: gli input vengono suddivisi in classi (o partizioni) di equivalenza, ossia ogni valore all’interno di una classe produrrà lo stesso output. È sufficiente un solo caso di test per ogni classe di equivalenza per ottenere una buona copertura dei test.

Esempio: Se un campo accetta valori interi tra 1 e 10, la classe valida comprende tutti i numeri tra 1 e 10, mentre le due classi non valide sono i numeri inferiori a 1 e quelli superiori a 10. Ciò significa che 3 casi di test sono sufficienti per coprire tutte le classi possibili. 

• Analisi dei valori limite: vengono testati i valori estremi degli input, che sono più propensi a generare difetti. 

Esempio: Utilizzando lo stesso campo visto sopra, i limiti validi sono 1 e 10 e quelli non validi sono 0 e 11. 

• Testing tramite tabella delle decisioni: le relazioni tra input e output vengono mostrate in formato tabellare. La tabella ha tipicamente colonne per le condizioni e righe per le diverse combinazioni. Ogni riga dovrebbe avere un caso di test corrispondente. 

Esempio: Questa tecnica viene utilizzata in scenari più complessi. Ad esempio, supponiamo di avere una richiesta di prestito bancario con le seguenti condizioni:

Abbiamo quattro possibili combinazioni, quindi sarà necessario eseguire quattro casi di test.

• Testing delle transizioni di stato: verifica il comportamento di un sistema mentre passa tra diversi stati.  

Esempio: Supponiamo di testare un semplice bug tracker. Il diagramma degli stati è il seguente:

Le transizioni disponibili sono:

• Da Nuovo a In lavorazione
• Da In lavorazione a In test
• Da In test a Chiuso
• Da In test di nuovo a In lavorazione

Per una copertura completa, è necessario assicurarsi che ciascuna delle transizioni e degli stati venga testata almeno una volta.

• Testing basato sull’esperienza, come l’exploratory testing. Questo tipo di test consiste nell’eseguire i test sulla base dell’esperienza del tester con il sistema o con sistemi simili e della conoscenza del comportamento dell’applicazione. 

Esempio: Immagina di testare una nuova applicazione di social media. Il tuo obiettivo è esplorare l'applicazione per trovare eventuali difetti o problemi che devono essere risolti. 

Durante il testing esplorativo, potresti eseguire le seguenti azioni:

• Registrare un nuovo account
• Caricare una foto del profilo
• Scrivere un post
• Visualizzare il proprio profilo
• Cercare amici
• Inviare una richiesta di amicizia
• Accettare una richiesta di amicizia
• Mettere "mi piace" e commentare un post

Utilizzando il testing esplorativo, eseguiresti queste azioni in modo non strutturato e senza un piano prestabilito. L'obiettivo sarebbe quello di trovare difetti o aree di miglioramento nell'applicazione.  

Se vuoi saperne di più sull'exploratory testing, ho trovato molto utile il libro di Elisabeth Hendrickson, Explore It!.

JOIN THE COMMUNITY

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Phone

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Pro e contro del Black Box Testing

Certo, ci sono vantaggi e anche svantaggi nell'esecuzione del black-box testing.

Pro:

• È meno soggetto a pregiudizi da parte del tester
• Non richiede la conoscenza del codice sorgente
• Può essere utilizzato anche da persone non tecniche
• Permette di valutare il sistema dal punto di vista dell'utente finale
• Testa la funzionalità del software nella sua interezza
• Può individuare problemi di integrazione tra vari moduli

Contro:

• Preparare l'ambiente di test ed eseguire i test può richiedere più tempo
• Il controllo sui casi di test è limitato
• Alcuni scenari specifici possono essere difficili da testare
• Informazioni limitate sulla causa principale di un errore
• Potrebbe non rilevare certi errori
• Capacità limitata di testare prestazioni e scalabilità

Quando utilizzare il Black-Box Testing?

Gli strumenti di black-box testing possono essere utilizzati a qualsiasi livello di test. Tuttavia, è meglio utilizzarli a livelli più alti, lasciando i test di livello inferiore al white-box testing. Questo significa che, sebbene sia possibile testare a livello unitario, la metodologia black-box è più appropriata per il testing di sistema e il testing di accettazione.   

Le tecniche di black-box possono essere utilizzate per test funzionali e non funzionali (come test di prestazioni, usabilità e accessibilità). 

Dovrebbero essere applicate anche alle funzionalità appena implementate, oppure i casi di test esistenti identificati attraverso queste tecniche possono essere eseguiti durante il testing di regressione.

Che cos'è il White-Box Testing?

Il White-Box (a volte chiamato anche clear box testing, glass box testing, test basato sul codice o test strutturale) è un metodo di testing che si concentra sul funzionamento interno dell’UAT.  

Approcci al white-box testing:

• Statement coverage: tutte le istruzioni di codice (righe di codice) vengono eseguite almeno una volta al livello del codice sorgente. La formula per calcolare la copertura è:

Statement coverage = (Numero di istruzioni eseguite / Numero totale di istruzioni nel codice sorgente) * 100

Esempio: Supponiamo di avere il seguente codice:

 if(condition1 or condition2)) {
print(“test 1 OK”)
}
else {
if(condition3) {
print(“test 2 OK”)
}
}

• Per ottenere una copertura completa delle istruzioni, è necessario eseguire ogni riga di codice almeno una volta. Questo significa che sono necessari più test:
  • condition1=true, condition2=false,  che stamperà "test 1 OK"
  • condition1=false, condition2=false e condition3=true, che stamperà "test 2 OK".

• Branch coverage: con questa tecnica, gli scenari di test coprono tutti i rami del grafo del flusso di controllo. Ogni possibile esito (vero e falso) delle condizioni viene coperto almeno una volta. La formula utilizzata per la branch coverage è:

• Copertura dei rami = (Numero di rami eseguiti / Numero totale di rami nel codice) * 100 
• Esempio: Per lo stesso codice, mentre la copertura delle istruzioni è al 100%, non tutti i possibili rami sono coperti. Sarà necessario un test aggiuntivo in cui:
  • condizione1=false, condizione2=false, condizione3=false - in questo modo copriamo anche il percorso false nel secondo if. In questo caso di test non dovrebbe essere stampato nulla,
• Copertura delle condizioni: una tecnica completa in cui vengono testati tutti i percorsi. Garantisce che ogni percorso applicativo sia coperto da almeno un test. È particolarmente utile per applicazioni complesse. Esempio: Per il codice sopra, serve un test in più per una copertura completa delle condizioni:
  • condizione1=false, condizione1=true, che avrà lo stesso risultato del primo test, ma copre una condizione diversa per raggiungere il risultato.

Pro e Contro del White-Box Testing

Vediamo i vantaggi e gli svantaggi del white-box testing.

Vantaggi:

• Può individuare errori nelle prime fasi del ciclo di vita dello sviluppo software
• Testa la struttura interna del codice.
• Verifica la copertura del codice e la logica.
• Migliora la conoscenza della base di codice.
• Può essere utilizzato per test di performance e scalabilità.

Svantaggi:

• Funziona meglio nei livelli di testing più bassi 
• Richiede una buona conoscenza del linguaggio di programmazione del sistema
• Test limitato dal punto di vista dell’utente finale
• Potrebbe trascurare scenari reali

Quando utilizzare il White-Box Testing 

I test white-box sono più indicati per i livelli più bassi, come i test unitari e di integrazione. Questo aiuta a identificare errori e difetti all’inizio del processo di sviluppo. Eseguire questi test dopo ogni deployment è una buona idea, soprattutto quando si lavora in un ambiente CI/CD. 

Il white-box testing può essere usato per testare la funzionalità, ma anche per individuare vulnerabilità nel sistema - cosa difficile da ottenere con le tecniche di black-box testing.

Riepilogo: Black-Box vs White-Box Testing 

Vediamo le principali differenze tra black-box e white-box testing:

Ma non dimentichiamo che, sebbene entrambi gli approcci abbiano vantaggi e svantaggi, dovremmo usarli entrambi nel processo di test per avere una buona copertura di test e del codice, e per trovare i difetti più importanti.

Conclusioni

Il black-box e il white-box testing sono due approcci differenti, e ognuno risponde a esigenze diverse durante il processo di sviluppo. Mentre il white-box testing viene utilizzato principalmente dagli sviluppatori e si applica ai test di livello più basso, il black-box testing viene svolto dal team QA nei livelli più alti; danno i migliori risultati quando vengono utilizzati insieme.

Se ti è piaciuto questo articolo, iscriviti alla newsletter per ricevere tutti i nuovi articoli pubblicati su test e quality assurance!