Glossario · Fondamenti del testing
Black-box testing (test a scatola nera)
In inglese: Black-box testing
Detto anche: black box testing, test a scatola nera, test black-box, test basati sulle specifiche
Definizione
Testare un sistema attraverso input e output rispetto ai requisiti, senza guardare il codice interno o il design e senza basarsi su di essi.
Il black-box testing (test a scatola nera) tratta il sistema come una scatola chiusa: fornisci input, osservi gli output e li confronti con ciò che la specifica dice debba accadere. Il tester non ha bisogno di conoscere il linguaggio di programmazione, l’architettura o il modo in cui è strutturato il codice. La maggior parte dei test funzionali, di sistema, delle API e di accettazione è black-box.
Esempio
Un’API di bonifico accetta importi da 1 a 10.000. Senza vedere alcun codice, un tester black-box ricava i test dalla regola:
- Classi di equivalenza: sotto l’intervallo (0), valida (500), sopra l’intervallo (10.001), non numerica (
"abc"). - Valori limite: 0, 1, 2, 9.999, 10.000, 10.001.
- Risultati attesi: gli importi validi restituiscono
201 Created; quelli non validi restituiscono400 Bad Requestcon un messaggio di errore e non spostano denaro.
Le tecniche usate qui, partizionamento in classi di equivalenza e analisi dei valori limite, insieme alle tabelle decisionali, al test delle transizioni di stato e al pairwise testing, sono le tecniche di progettazione black-box fondamentali.
Black-box e white-box testing a confronto
| Black-box | White-box | |
|---|---|---|
| Base | Requisiti e specifiche | Struttura interna del codice |
| Conoscenze richieste | Cosa deve fare il sistema | Come è scritto il codice |
| Livelli tipici | Sistema, API, accettazione | Unit, parte dell’integrazione |
| Misurato con | Copertura dei requisiti | Code coverage (istruzioni, rami) |
| Trova | Comportamenti mancanti o errati, discrepanze con la specifica | Percorsi non testati, codice morto, errori di logica |
Nessuno dei due sostituisce l’altro. Il black-box testing può scoprire funzionalità mai implementate, cosa che il white-box testing non può fare, perché non c’è codice da ispezionare. Il white-box testing può trovare percorsi che la specifica non menziona mai. Il grey-box testing li combina: si testa attraverso l’interfaccia usando però qualche conoscenza interna, per esempio controllando il database dopo una chiamata API o sapendo quale servizio raggiunge una richiesta.
Punti di forza e limiti
I test black-box sono indipendenti dall’implementazione, quindi sopravvivono al refactoring e possono essere scritti partendo dai requisiti prima ancora che il codice esista. Il loro limite è che non puoi sapere quali percorsi interni hai mancato e, senza tecniche sistematiche, è facile testare solo gli happy path più ovvi.