White box è una categoria di test del software che si riferisce ai metodi di verifica del funzionamento della struttura interna e della progettazione del software. Si contrappone al black box testing, che non si occupa delle operazioni interne del software, ma si limita a testare gli output esterni del software.
In questo articolo esploreremo il tema del white box testing: cos’è, come funziona e quali tipi di strumenti di test del software possono aiutare i tester e gli sviluppatori a eseguire il white box testing nel test del software.
Che cos’è il white box testing?
Il white box testing è una tecnica di test del software che prevede la verifica della struttura interna e della progettazione di un software, in contrapposizione agli output esterni o all’esperienza dell’utente finale che vengono testati nel black box testing.
White box testing è un termine generico che comprende molti tipi diversi di test del software, tra cui i test di unità e i test di integrazione. Poiché i test white box implicano la verifica del codice e della programmazione, l’esecuzione dei test white box richiede solitamente una certa conoscenza della programmazione informatica.
I test white box nell’ingegneria del software possono riguardare il codice e la progettazione interna del software per verificare il flusso di input-output e controllare il design, l’usabilità e la sicurezza del software.
I test white box consentono ai tester di ispezionare il funzionamento interno del sistema, verificando al tempo stesso che gli input producano gli output specifici previsti.
Il test white box è una fase essenziale del test del software perché è l’unico tipo di test che considera il funzionamento del codice stesso.
1. Quando e perché è necessario il white box
nel testing e nell’ingegneria del software?
I test white box possono essere eseguiti in diverse fasi del ciclo di test per verificare il funzionamento del codice interno e della struttura.
Più comunemente, i test white box si verificano quando gli sviluppatori e i tester eseguono i test unitari e talvolta durante i test di integrazione.
Per definizione, il test unitario è considerato un tipo di test white box, mentre il test di integrazione può condividere caratteristiche sia del test white box che di quello black box, ma è generalmente considerato una forma di test black box.
Altrimenti, i test white box possono essere utilizzati ad hoc per verificare il funzionamento interno di una build di software. I test white box sono il modo più economico per aumentare la copertura dei test, se necessario, e sono anche un modo semplice per verificare il funzionamento di specifiche sezioni di codice o per testare aree di una build di software che i tester sospettano essere poco testate.
Le revisioni formali del codice, che vengono eseguite con i test white box, possono essere utilizzate anche per identificare le falle di sicurezza e altre vulnerabilità. Allo stesso modo, se alcuni elementi del codice sono danneggiati, i test white box possono aiutare gli ingegneri del software a determinare dove si trova l’errore.
2. Quando non è necessario eseguire i test white box
Nella maggior parte dei casi, quando gli ingegneri del software e i collaudatori sottopongono una nuova versione del software al ciclo di test, è necessaria una certa quantità di test white box per verificare il funzionamento interno del codice.
Il test delle unità è un tipo di test white box che viene eseguito dagli sviluppatori per verificare che le singole unità funzionino come previsto. Questo tipo di test precoce consente agli sviluppatori di identificare bug e difetti prima che vengano eseguiti i test formali in un ambiente QA.
Dopo il test unitario, si procede al test di integrazione, al test di sistema e al test di accettazione da parte dell’utente. Queste sono generalmente considerate forme di test black box che di solito non coinvolgono molte tecniche di test white box.
Tuttavia, in alcuni casi, i tester e gli sviluppatori possono utilizzare i test white box durante queste fasi per identificare difetti specifici all’interno del codice. In questa fase, se non ci sono indicazioni che il codice sia sbagliato e i test black box passano tutti, molti team di test possono ritenere che non sia necessario eseguire ulteriori test white box.
3. Chi è coinvolto nei test white box?
I test white box sono quasi sempre eseguiti da sviluppatori e ingegneri del software. Questo perché i test white box richiedono una conoscenza dettagliata del codice informatico e delle tecniche di codifica, e la maggior parte dei tester QA non ha le competenze tecniche necessarie per eseguire i test white box.
Il test delle unità, il tipo principale di test white box, viene sempre eseguito dagli sviluppatori nell’ambiente di sviluppo. Gli sviluppatori possono anche eseguire test white box quando è necessario, per verificare il funzionamento di diversi elementi del codice o per controllare che i bug siano stati risolti correttamente.
I vantaggi del white box testing
I test white box consentono agli sviluppatori e agli ingegneri del software di testare più aspetti del codice rispetto ai test black box.
Mentre i test black box possono dirci come funziona un software per gli utenti finali, i white box possono dirci di più su come funziona il codice del software. Un codice pulito ed efficiente è essenziale nello sviluppo del software, soprattutto se gli sviluppatori vogliono riutilizzare il codice in seguito o aggiungere patch e aggiornamenti in futuro.
1. Massimizzare la copertura dei test
I test white box possono aiutare i tester a massimizzare la copertura dei test. Testare la maggior parte possibile del codice software di solito massimizza la possibilità di rilevare eventuali bug o errori presenti nel codice, e lo scopo del white box testing è di solito quello di testare la maggior parte possibile del codice.
I test black box, invece, consistono semplicemente nell’esecuzione di casi di test che possono o meno offrire un’ampia copertura del codice.
2. Trovare errori e bug nascosti
Uno dei maggiori vantaggi dei test white box è che, poiché i test white box verificano la funzionalità interna, rendono più facile per gli sviluppatori trovare errori e bug che altrimenti potrebbero essere nascosti nelle profondità del codice.
Oltre a identificare la presenza di bug, di solito è più facile individuare esattamente la posizione del bug nella base di codice quando si eseguono i test white box, a causa della natura altamente specifica di questo tipo di tecnica di test.
3. Facilità di automazione
È molto facile automatizzare i test white box, soprattutto quando si eseguono i test unitari. I test unitari di solito richiedono agli sviluppatori di testare singolarmente piccole parti di codice per verificare se funzionano come previsto. È molto facile da automatizzare, il che significa che si tratta di una forma rapida ed efficiente di test del software.
Questo è uno dei motivi per cui i test unitari vengono eseguiti prima di altri tipi di test che richiedono più tempo.
4. Efficienza temporale
I test white box sono efficienti in termini di tempo per una serie di motivi.
Come già detto, è relativamente facile automatizzare la maggior parte dei tipi di test white box, il che significa che spesso è più veloce eseguire i test white box rispetto ai test black box. Inoltre, i test white box consentono agli sviluppatori di individuare facilmente i bug e gli errori che identificano nel codice, perché li trovano durante il test del codice stesso.
5. Qualità del codice
I test white box consentono agli sviluppatori di dare una seconda occhiata al codice che hanno scritto e di valutarne la qualità e la pulizia.
Esaminando il codice pezzo per pezzo, gli sviluppatori hanno la possibilità di rimuovere le sezioni di codice non necessarie e di ripulire il codice, rendendo più facile il riutilizzo e la modifica di sezioni di codice in futuro.
Potrebbe anche costringere gli sviluppatori a considerare il modo in cui il codice viene implementato e se questo sarà scalabile in futuro.
Le sfide del white box testing
I test white box non sono privi di sfide. Ci sono alcuni motivi per cui alcuni team di sviluppo possono trovare il white box testing più difficile da eseguire rispetto al black box testing, così come altri motivi per cui alcuni lo considerano meno importante del black box testing.
1. Barriere tecniche
I test in scatola bianca comportano barriere tecniche che i test in scatola nera non comportano. Per eseguire i test white box, i tester devono conoscere il funzionamento interno del sistema, il che, nel caso dei test software, significa di solito conoscere la programmazione.
Per questo motivo i test white box sono quasi sempre eseguiti da ingegneri del software e sviluppatori e non da tester QA, che raramente hanno le competenze tecniche necessarie per eseguire questo tipo di test.
2. Costo
L’esecuzione dei test white box può essere più costosa rispetto a quella dei test black box, a causa dell’accuratezza di questo tipo di test.
Gli sviluppatori devono dedicare molto tempo alla scrittura di test unitari intensivi e i test white box spesso non possono essere riutilizzati per altre applicazioni, il che significa che i test white box di solito costano parecchio.
3. Precisione
I test white box non sono sempre il metodo più accurato per testare il software e se i team di sviluppo si affidassero esclusivamente ai test white box, si verificherebbero molti casi e bug non risolti.
I test white box convalidano solo le funzionalità già esistenti, mentre i test black box possono essere utilizzati per testare le funzionalità parzialmente implementate o per identificare le funzionalità effettivamente mancanti nel software e che dovrebbero essere incluse nelle iterazioni successive.
4. Ambito di applicazione
I test white box di solito non ci dicono molto sull’esperienza dell’utente o sul risultato finale delle funzioni integrate nel software.
Sebbene gli sviluppatori possano utilizzare i test white box per verificare se il codice funziona come dovrebbe, non possono concludere che il codice funzionante fornisca i risultati corretti agli utenti finali senza combinare i test white box con i test black box.
Ciò significa che l’ambito dei test white box e la loro portata sono limitati.
Le caratteristiche dei test white box
I test white box possono essere definiti da caratteristiche particolari che li differenziano da altre forme di test come i test black box e grey box.
La maggior parte di queste caratteristiche può essere considerata dal punto di vista di come si differenziano dalle caratteristiche del black box testing e di come questo distingua il white box testing dal black box testing.
1. Manutenibilità
I test white box portano a un maggiore livello di manutenibilità del codice, semplificando il lavoro che il team deve svolgere in futuro.
Poiché il codice e le sue operazioni con i dati sono costantemente monitorati, la manutenzione è molto più semplice, in quanto si capisce dove si verificano i problemi e perché si verificano. In questo modo si semplifica anche il codice per gli aggiornamenti futuri, in quanto non si sviluppano patch grandi e complesse per problemi sconosciuti e semplici.
2. Flessibilità
I test white box vengono eseguiti su codice sufficientemente flessibile da accettare modifiche in tempi relativamente brevi. Il codice poco flessibile, come quello che fa parte di un modulo o di un’integrazione di terze parti, impedisce al tester white box di apportare modifiche rapide.
Concentrarsi su un codice che si possa modificare non appena si scopre un problema rende i test white box altamente adattabili e significa che i problemi di un programma vengono risolti molto prima.
3. Modularità
I test white box prosperano nel codice che ha un certo grado di modularità, il che significa che gli elementi separati del software hanno una chiara distinzione l’uno dall’altro.
Se un programma ha un problema di “codice spaghetti” in cui ogni aspetto è legato a un altro, il test white box diventa infinitamente più complesso, poiché il tester deve esaminare l’intero programma piuttosto che una specifica unità.
4. Integrazione
I test white box sono estremamente utili per i test di integrazione. I tester possono vedere se una funzione funziona fino al punto in cui lascia il software in questione e se ritorna dal sistema integrato in modo funzionale come previsto.
Si tratta di un dato molto informativo che consente all’organizzazione di sapere se il problema è locale o fa parte della piattaforma integrata.
Cosa testiamo nei test white box?
I test white box sono utilizzati per verificare le caratteristiche del codice che non possono essere verificate con i metodi di test black box. Ciò potrebbe significare testare il funzionamento del codice stesso, il che consente agli sviluppatori di comprendere la causa e l’effetto di diversi aspetti del codice.
Gli sviluppatori utilizzano i test white box per verificare le falle di sicurezza, le dichiarazioni e le funzioni, gli output e i percorsi nel codice.
1. Fori di sicurezza interni
I test white box possono essere utilizzati per individuare le lacune di sicurezza e le vulnerabilità all’interno del codice che gli hacker e i criminali informatici potrebbero sfruttare in futuro.
I test white box possono essere utilizzati per verificare se le migliori pratiche di sicurezza sono state seguite durante la fase di sviluppo e per cercare vulnerabilità di sicurezza che potrebbero essere riparate prima che il codice passi a ulteriori test.
2. Percorsi nei processi di codifica
I test white box consentono agli sviluppatori di verificare i percorsi che collegano tra loro i diversi elementi del codice. Gli sviluppatori non si limitano a testare la logica del codice, ma possono anche verificarne la struttura e l’igiene.
Un codice buono e pulito non presenta linee inutili o elementi rotti che non funzionano come previsto, anche se i risultati esterni dei test black box sono quelli attesi.
3. Risultati attesi
I test white box possono anche verificare i risultati attesi dal codice proprio come i test black box, sebbene i tester lo facciano considerando il codice piuttosto che utilizzando l’applicazione come potrebbero fare nei test black box.
Gli sviluppatori testano gli output previsti verificando gli input uno per uno e controllando che l’output risultante sia in linea con le aspettative.
4. Dichiarazioni, oggetti e funzioni
Eseguendo le tecniche di white box testing, gli sviluppatori di software possono assicurarsi che le dichiarazioni, gli oggetti e le funzioni del codice si comportino in modo logico e producano gli output previsti.
5. Funzionalità dei cicli condizionali
I test white box possono essere utilizzati anche per verificare la funzionalità dei cicli condizionali, compresi i cicli singoli, concatenati e annidati. Gli sviluppatori verificheranno se questi cicli sono efficienti, se soddisfano i requisiti della logica condizionale e se gestiscono correttamente le variabili locali e globali.
Per chiarire un po’ di confusione:
Test white box vs. black box vs. grey box
White box testing, black box testing e grey box testing sono termini che i tester del software usano per riferirsi a diverse categorie di test o a diversi metodi di test.
Una visione moderna di queste distinzioni di test è che le linee tracciate tra i diversi tipi di box testing stanno diventando sempre più sfumate, in quanto i diversi tipi di test spesso combinano elementi di white e black box testing e derivano i test da documenti a vari livelli di astrazione.
Tuttavia, esistono ancora importanti distinzioni tra queste forme di test.
1. Che cos’è il black box testing?
Il test black box è una forma di test del software in cui la funzionalità del software viene verificata da tester che non hanno alcuna conoscenza della struttura interna del codice o di come implementare il codice a un livello più tecnico.
I test black box si limitano a verificare le uscite esterne del software o, in altre parole, a verificare ciò che l’utente finale sperimenterà durante l’utilizzo del software.
I test black box sono noti anche come test comportamentali perché verificano il comportamento del software in determinate condizioni.
I tester possono utilizzare il black box testing per valutare il comportamento delle diverse funzioni del software e verificarlo rispetto alle aspettative per assicurarsi che il software soddisfi i requisiti degli utenti. I test black box sono utilizzati nei test di sistema e nei test di accettazione per verificare diverse funzioni e controllare che il sistema funzioni come previsto quando funziona nel suo complesso.
Quando si eseguono test black box, gli utenti scrivono casi di test per verificare i diversi elementi singolarmente. Poiché i test black box non richiedono le stesse competenze tecniche dei test white box, questi ultimi vengono solitamente eseguiti da tester in un ambiente QA piuttosto che da sviluppatori.
L’automazione dei test black box è di solito più facile da realizzare rispetto ai test white box utilizzando strumenti di automazione end-to-end come ZAPTEST.
Quali sono le differenze tra white box e black box?
La differenza principale tra i test black box e white box è l’oggetto del test.
I test black box riguardano i risultati esterni della creazione del software, mentre i test white box riguardano ciò che avviene sotto il cofano.
Alcune delle principali differenze tra i test black box e white box sono:
Scopo
Lo scopo dei test black box è verificare che il sistema funzioni come previsto per l’utente finale, mentre lo scopo dei test white box è controllare la qualità e l’integrità del codice del software.
Ad esempio, il black box testing per un videogioco può vedere un utente finale che prova il gioco e lo recensisce per la sua esperienza, mentre il white box testing sullo stesso progetto assicura che l’immissione di input specifici porti il personaggio a completare l’azione giusta.
Processo
I processi utilizzati nei test white e black box sono molto diversi. I test white box sono molto più facili da automatizzare rispetto ai test black box e, di solito, i test black box devono essere automatizzati con l’aiuto di strumenti di automazione del software.
Per esempio, quando si testa un database, un test white box prevede l’automazione dell’inserimento dei dati per verificare che tutti i risultati siano corretti, mentre il test black box prevede che gli utenti replichino i processi manuali e ne diano conto senza l’uso di un sistema di automazione.
Tester
I test black box sono quasi sempre eseguiti in un ambiente QA da tester software professionisti, mentre i test white box sono eseguiti da sviluppatori e ingegneri software che hanno una conoscenza tecnica più dettagliata del codice sorgente.
Tecniche
I test black box utilizzano varie tecniche come il partizionamento delle equivalenze, l’analisi del valore limite e i test con tabella decisionale. I test white box utilizzano tecniche come la copertura delle decisioni, la copertura delle condizioni e la copertura delle dichiarazioni.
Operazioni
Le metodologie di test black box si adattano a operazioni di test di livello superiore, come i test di sistema e i test di accettazione, mentre i test white box sono più adatti a operazioni di livello inferiore, come i test di unità e i test di integrazione.
Per questo motivo, i test white box vengono solitamente eseguiti prima della maggior parte delle forme di test black box.
2. Che cos’è il grey box testing?
Il grey box testing è una tecnica di testing del software utilizzata per testare prodotti e applicazioni software da parte di tester che possono avere una conoscenza parziale della struttura interna dell’applicazione, ma non completa.
I test grey box possono combinare elementi sia dei test black box che dei test white box per consentire a sviluppatori e tester di identificare i difetti nel codice e individuare gli errori specifici del contesto.
I test grey box combinano le caratteristiche dei test black box e dei test white box. I tester devono avere una certa conoscenza del funzionamento interno del sistema, come nei test white box, ma utilizzano questa conoscenza per creare casi di test ed eseguirli a livello di funzionalità, come avviene nei test black box.
I test grey box offrono molti dei vantaggi dei test black box e white box, oltre a essere relativamente efficienti in termini di tempo e flessibili.
Quali sono le differenze tra white box e grey box?
Poiché il grey box testing offre alcune delle stesse funzionalità del black box testing, ci sono alcune differenze sostanziali tra il grey box testing e il white box testing, anche se forse non così tante come nel caso del black box testing.
Alcune delle principali differenze tra i test grey box e i test white box sono:
Conoscenza strutturale
Nei test white box, il progetto interno e la struttura del codice devono essere completamente noti alla persona che esegue il test. Nei test grey box, la struttura interna del codice è solitamente nota solo in parte.
Persone coinvolte
I test white box sono eseguiti quasi esclusivamente da sviluppatori e ingegneri del software, mentre i test grey box possono essere eseguiti da utenti finali, tester e sviluppatori.
Efficienza
Il test white box è considerato il tipo di test del software che richiede più tempo, mentre il test grey box prende in prestito alcune delle efficienze del test black box per ridurre il tempo necessario per eseguire i test.
Funzionamento
Nei test white box, gli sviluppatori scrivono semplicemente del codice per implementare i test white box e lo eseguono. Nei test grey box, come nei test black box, i tester eseguono test funzionali per valutare il funzionamento del sistema all’esterno.
Copertura
I test white box sono il tipo di test più esaustivo, mentre la copertura dei test grey box può variare a seconda che il tipo di casi di test eseguiti sia basato sul codice o sull’interfaccia grafica.
Conclusione:
Scatola bianca vs scatola nera vs. test Grey box
White box testing, black box testing e grey box testing sono termini utilizzati per indicare diverse tecniche di test del software. In linea di massima, ogni tipo di test può essere definito in base alla misura in cui i tester devono conoscere la base di codice e l’implementazione del codice:
1. Test a scatola nera:
La struttura interna del codice è sconosciuta.
2. Test white box:
La struttura interna del codice è nota.
3. Test della scatola grigia:
La struttura interna del codice è parzialmente nota.
Durante il test del software, tutti e tre i tipi di test sono importanti per verificare il funzionamento e l’integrità del software. Mentre il white box testing ci dice di più sulla struttura sottostante del codice, il grey box testing e il black box testing possono verificare come funziona il sistema e se questo soddisfa i requisiti dell’utente finale.
Forse le maggiori differenze tra questi tre tipi di test riguardano chi li esegue, i requisiti del test stesso e ciò che comporta.
I test white box hanno la più alta barriera all’ingresso perché vengono eseguiti da sviluppatori con una conoscenza dettagliata del codice base stesso e perché sono il tipo di test più lungo e spesso costoso.
Al contrario, il black box testing è il più semplice da realizzare e può essere eseguito da tester che non conoscono il codice sottostante.
Tipi di test white box
Esistono diversi tipi di test white box, ognuno dei quali può essere utilizzato per verificare aspetti leggermente diversi della struttura interna del codice.
Di seguito sono riportati alcuni dei tipi più comuni di test white box utilizzati oggi.
1. Test del percorso
Il path testing è un tipo di test white box basato sulla struttura di controllo di un programma. Gli sviluppatori utilizzano la struttura di controllo per creare un grafico del flusso di controllo e testare diversi percorsi nel grafico.
I test di percorso sono un tipo di test che dipende dalla struttura di controllo del programma, il che significa che i tester devono avere una conoscenza approfondita di questa struttura.
Ad esempio, se un sistema deve contattare i clienti con messaggi prestabiliti in determinati punti dell’imbuto di vendita, il test del percorso consiste nel garantire che segua i passi giusti in base alle condizioni stabilite dai dati.
2. Test del loop
Il test dei loop è uno dei tipi più importanti di test white box che verifica i loop all’interno del codice del programma. I loop sono implementati negli algoritmi all’interno del codice e il test dei loop verifica la loro validità.
Il test dei loop può valutare se esistono vulnerabilità all’interno di specifici loop ed evidenziare le aree in cui gli sviluppatori potrebbero dover correggere il codice per garantire che il loop funzioni come dovrebbe.
Un esempio di test del loop consiste nel seguire il loop con una serie specifica di punti dati che spingono il loop a continuare, come il rifiuto di accettare alcuni termini e condizioni, prima di inserire un dato che interrompe specificamente il loop. Se il ciclo si comporta come previsto, il test ha successo.
3. Test condizionati
Il test condizionale è un tipo di test white box che verifica se le condizioni logiche per i valori all’interno del codice sono vere o false.
Il test condizionale è una forma importante di test white box che indica agli sviluppatori se il codice è logico e soddisfa i requisiti della logica di programmazione.
Un esempio di test condizionale è rappresentato da una piattaforma di contabilità. Inserendo una serie di spese e di entrate si ottengono i giusti totali di esercizio e il software fornisce risultati accurati per tutta la durata del test.
4. Test unitari
Il test delle unità è una fase importante del test del software in cui gli sviluppatori testano i singoli componenti e moduli e verificano che funzionino come previsto prima di integrare le diverse unità tra loro.
Gli ingegneri del software utilizzano i metodi di test white box nei test unitari per testare piccoli pezzi di codice alla volta. In questo modo è facile identificare bug ed errori quando si verificano durante i test.
Un esempio di unit testing si ha all’inizio dello sviluppo, quando un’azienda crea un semplice pulsante su un sito web che porta l’utente a un’altra pagina. Se l’unità funziona come previsto, allora ha successo, e gli sviluppatori apportano modifiche finché non funziona.
5. Test di mutazione
Il test di mutazione è un tipo di test che analizza le alterazioni e le mutazioni. Nei test di mutazione, gli sviluppatori apportano piccole modifiche al codice sorgente per verificare se ciò può rivelare bug nel codice.
Se il caso di test passa, significa che c’è qualche problema con il codice, perché non dovrebbe passare dopo che sono state apportate le modifiche. Idealmente, nei test di mutazione, tutti i casi di test falliscono.
Un esempio di test di mutazione è quello dell’apprendimento automatico. I programmi di apprendimento automatico “mutano” automaticamente in base a nuove informazioni, quindi testare questi programmi in modo coerente per lo standard di “mutazione” informa gli sviluppatori se il software funziona come previsto.
6. Test di integrazione
Il test di integrazione è una fase importante del test del software, durante la quale i tester verificano se i diversi moduli funzionano correttamente quando sono integrati con altri moduli.
Le tecniche di white box testing vengono utilizzate durante i test di integrazione per verificare che il codice funzioni anche quando più moduli, spesso codificati da sviluppatori diversi, lavorano insieme.
Quando un database attinge informazioni da una fonte online, ad esempio, i test di integrazione assicurano che i dati estratti siano accurati e si aggiornino a una velocità ragionevolmente costante.
7. Test di penetrazione
Il test di penetrazione è un tipo di test white box che può essere utilizzato per simulare specifici attacchi informatici al sistema.
Nei test di penetrazione, i tester hanno accesso ai dati completi della rete e del sistema, come le password e le mappe di rete. Quindi cercano di accedere o distruggere i dati all’interno del sistema tentando il maggior numero possibile di vie di attacco.
I test di penetrazione sono un aspetto importante dei test di sicurezza che dovrebbero essere eseguiti su tutte le versioni del software.
Una piattaforma HR, ad esempio, completerà i test di penetrazione e cercherà le vulnerabilità nel codice per assicurarsi che la piattaforma sia abbastanza sicura da contenere i dati dei dipendenti.
Tecniche di test white box
Esistono diverse tecniche di test white box che possono essere utilizzate per eseguire i test white box sopra elencati. Come sempre, tecniche diverse sono più adatte a testare aspetti diversi del codice, ma tutte le tecniche white box elencate di seguito sono importanti.
1. Copertura della dichiarazione
Una delle caratteristiche che definiscono i test white box è che i tester devono cercare di coprire la maggior parte possibile del codice sorgente quando eseguono i test white box.
La copertura del codice è una misura importante di questo aspetto e la copertura delle dichiarazioni è una tecnica che i tester white box possono utilizzare per aumentare la copertura delle dichiarazioni all’interno del codice.
La copertura delle istruzioni è una metrica che misura il numero di istruzioni eseguite diviso per il numero totale di istruzioni e moltiplicato per 100. I tester white box dovrebbero puntare a un’elevata copertura delle dichiarazioni.
2. Copertura del ramo
La copertura dei rami, come la copertura delle dichiarazioni, riflette l’ampiezza della copertura di particolari elementi del codice nei test white box. Le diramazioni sono equivalenti alle istruzioni “IF” nella logica, dove il codice si suddivide in opzioni vere e false che hanno un impatto sul risultato dell’operazione.
Quando si utilizzano le tecniche di branch coverage, i tester white box controllano se ogni ramo viene elaborato almeno una volta e verificano che entrambi i rami funzionino correttamente.
3. Copertura del percorso
Le tecniche di copertura dei percorsi valutano i percorsi all’interno di un’applicazione software. Massimizzare la copertura dei percorsi di test significa garantire che tutti i percorsi all’interno del programma siano esplorati almeno una volta. È un tipo di tecnica di test simile alla branch coverage, ma è considerata più approfondita ed efficace.
I test di copertura del percorso sono solitamente considerati più adatti per testare applicazioni complete piuttosto che build parziali.
4. Copertura decisionale
La copertura decisionale è una delle tecniche white box più importanti perché fornisce dati sui risultati veri e falsi delle espressioni booleane nel codice sorgente.
I test di copertura delle decisioni convalidano il codice sorgente assicurando che ogni marca di ogni potenziale decisione venga percorsa almeno una volta durante i test.
I punti di decisione comprendono tutte le occasioni in cui esiste la possibilità di due o più esiti diversi.
5. Copertura delle condizioni
La copertura delle condizioni è nota anche come copertura delle espressioni. Questa tecnica di white box valuta le sottovariabili delle dichiarazioni condizionali all’interno del codice per verificare il risultato di ciascuna condizione logica.
Questo tipo di test considera solo le espressioni con operandi logici, mentre i test di copertura delle decisioni e i test di copertura dei rami vengono utilizzati per garantire altre operazioni logiche.
6. Copertura di più condizioni
Nei test di copertura a condizioni multiple, i tester verificano diverse combinazioni di condizioni e valutano la decisione che il codice prende per ogni combinazione.
I casi di test per la copertura di condizioni multiple possono essere molti e diversi, a causa dell’enorme numero di combinazioni di condizioni esistenti, per cui questo tipo di test è spesso molto dispendioso in termini di tempo.
7. Copertura della macchina a stati finiti
La copertura delle macchine a stati finiti è un tipo di test importante, ma anche uno dei modi più difficili per ottenere un’elevata copertura del codice nei test white box. Lavora sulla funzionalità del progetto e richiede agli sviluppatori di contare il numero di volte che uno stato viene visitato o transitato durante il processo di test, nonché il numero di sequenze che ogni sistema a stati finiti contiene.
8. Test del flusso di controllo
Il test del flusso di controllo è una tecnica di test white box che cerca di stabilire l’ordine di esecuzione del programma utilizzando una semplice struttura di controllo.
Gli sviluppatori costruiscono i casi di test del flusso di controllo scegliendo una sezione specifica del programma e costruendo un percorso di test. Il test del flusso di controllo viene solitamente utilizzato nei test unitari.
Il ciclo di vita dei test white box
nello sviluppo di software
Il test white box è una fase importante del ciclo di vita dello sviluppo del software, anche se non ha un “posto” preciso nel ciclo.
Gli sviluppatori possono eseguire i test white box quando hanno bisogno di verificare il funzionamento del codice e alcuni sviluppatori possono essere più scrupolosi di altri nel controllare il codice appena scritto per assicurarsi che sia pulito e privo di linee inutili.
Tuttavia, i test white box sono più comunemente eseguiti durante i test unitari e i test di integrazione. Sia i test unitari che quelli di integrazione vengono eseguiti dagli sviluppatori durante la fase di sviluppo.
Si svolgono prima dei test funzionali, come il test di sistema e il test di accettazione, e danno agli sviluppatori la possibilità di identificare, localizzare e correggere i principali bug già nella fase di test, prima di consegnare il prodotto al team QA.
Test white box manuali o automatizzati?
Come per altri tipi di test del software, è possibile automatizzare i test white box. Può essere manuale o automatizzato, anche se nella maggior parte dei casi è più facile automatizzare i test white box che quelli black box.
Poiché i test white box sono un tipo di test che richiede molto tempo, l’automazione sta diventando sempre più popolare tra i team software.
Test manuali white box: vantaggi, sfide e processi
Il white box testing manuale significa eseguire manualmente i test white box e richiede che gli sviluppatori abbiano le competenze e il tempo per scrivere singoli casi di test per verificare ogni riga di codice in una build del software. Ciò può richiedere molto tempo, ma consente di ottenere i risultati e gli output più completi.
Alcuni dei vantaggi dell’esecuzione manuale dei test white box includono:
1. Profondità
I test manuali consentono ai tester di esplorare il codice del software in modo più approfondito rispetto ai test automatici, se lo desiderano, ad esempio leggendo tutto il codice sorgente di un’applicazione piuttosto che limitarsi ad automatizzare attività che toccano la funzionalità superficiale.
2. Posizione degli insetti
I test manuali facilitano l’individuazione di bug e difetti, perché gli sviluppatori dovrebbero essere in grado di individuare esattamente la riga di codice in cui è presente il bug.
Ad esempio, se si nota che un’immagine non viene caricata, si esamina il codice alla ricerca di linee che comportano il caricamento di immagini e si restringe significativamente la causa.
3. Velocità
I test manuali di solito richiedono più tempo di quelli automatizzati, ma se gli sviluppatori vogliono eseguire solo uno o due test veloci è probabilmente più rapido eseguirli manualmente che impostare l’automazione.
Ad esempio, il test unitario consiste nell’esaminare una funzione e vedere se funziona, piuttosto che raccogliere grandi quantità di dati automatizzando il processo. Tuttavia, i test manuali white box presentano anche degli svantaggi.
Alcune delle sfide del white box testing manuale includono:
1. La precisione
I test manuali possono consentire agli sviluppatori di coprire un’ampia gamma di codici, ma i tester umani sono sempre più inclini agli errori rispetto ai programmi informatici, il che significa che i test manuali sono spesso considerati meno accurati dei test automatizzati.
2. Il tempo
I test manuali richiedono più tempo di quelli automatizzati e i test manuali white box sono tra i più dispendiosi in termini di tempo. Questo aumenta i tempi di consegna e può rendere più difficile rispettare le scadenze di sviluppo.
3. Costo
A causa della quantità di manodopera e risorse coinvolte nei test manuali white box, questi sono spesso più costosi per i team di sviluppo rispetto ai test automatizzati, che di solito richiedono meno sviluppatori e meno tempo.
4. Scalabilità
I test manuali sono adatti solo per il collaudo di piccole applicazioni o di singoli componenti di applicazioni più grandi. Per le applicazioni più grandi, come un database ospitato nel cloud con migliaia di input al minuto, i test automatizzati sono di gran lunga preferibili come metodo di simulazione dei carichi standard.
Test automatizzati white box: vantaggi,
sfide e processi
La tecnologia di automazione rende ogni giorno più facile automatizzare gli aspetti del test del software. Lo spostamento del settore verso l’iperautomazione è in parte dovuto all’efficienza e ai risparmi sui costi che l’automazione offre ai team di sviluppo che si sentono sempre sotto pressione.
Il white box è uno dei tipi di test più appropriati e adatti all’automazione, perché è relativamente facile da automatizzare e il risparmio di tempo e di costi dell’automazione dei test white box può essere significativo.
L’automazione dei test white box può coinvolgere gli sviluppatori che scrivono da soli gli script di test, oppure il processo può essere accelerato con l’uso di strumenti full-stack come ZAPTEST, che forniscono una tecnologia di test del software end-to-end all’avanguardia.
Tra i vantaggi dell’automazione dei test white box vi sono:
1. La precisione
I test basati sul computer eliminano il rischio di errori perché i computer non si stancano e non commettono errori.
2. Il tempo
I test white box automatizzati sono molto più veloci di quelli manuali e liberano tempo che gli sviluppatori possono dedicare ad altre attività, come la correzione di bug o la scrittura di patch di aggiornamento.
3. Scala
I test automatizzati sono molto più scalabili di quelli manuali, quindi se la vostra applicazione software cresce o se volete eseguire test su larga scala in una sola volta, l’automazione è l’opzione migliore.
Ad esempio, l’aumento dell’inserimento dei dati comporta la richiesta di più input nell’automazione, rispetto all’assunzione di più personale nei test manuali.
4. Costo
Il costo del testing automatizzato è solitamente, una volta totalizzato, inferiore al costo del testing manuale, grazie al numero di ore di lavoro risparmiate dall’automazione. Il ROI 10x di ZAPTEST dimostra come l’automazione possa far risparmiare denaro agli sviluppatori e portare a rendimenti più elevati. Tuttavia, l’automazione non è priva di inconvenienti.
Alcune delle sfide dell’automazione dei test white box includono:
1. Tracciamento dei bug
L’automazione non sempre facilita l’individuazione dei bug nel codice, a seconda del modo in cui gli sviluppatori automatizzano i test o degli strumenti di test utilizzati, soprattutto se confrontati con i test manuali white box in cui i tester possono vedere il codice che viene eseguito ogni volta che emerge un bug.
2. Competenze
Non tutti gli sviluppatori sanno come automatizzare i test o come utilizzare gli strumenti di test automatizzati, quindi il passaggio all’automazione può richiedere un investimento nella formazione di competenze importanti, come la codifica nel linguaggio di quella specifica piattaforma di test e l’utilizzo di competenze di analisi dei dati per comprendere la causa dei problemi in un test white box.
Conclusione: Test manuale della scatola bianca
o l’automazione dei test white box?
Nel complesso, i test white box nell’ingegneria del software sono uno dei tipi di test più adatti ad essere adattati ai test automatizzati, soprattutto a causa della natura complessa e dispendiosa in termini di tempo dei test white box manuali.
I test white box automatizzati sono più veloci, più economici, più efficienti e più accurati dei test manuali, soprattutto quando si lavora con applicazioni di grandi dimensioni.
Ove possibile, gli sviluppatori di software dovrebbero automatizzare i test white box per aumentare l’affidabilità dei test e coprire con i test un’area più ampia di applicazioni più grandi di quanto sia praticamente possibile eseguendo i test manualmente. Ciò è dovuto ai costi significativi e alle competenze richieste quando si completano i test white box con metodi esclusivamente manuali.
Di cosa avete bisogno per iniziare
test white box?
Prima di iniziare i test white box, assicuratevi di avere tutto il necessario per iniziare. A seconda che si eseguano test white box manuali o automatizzati, non sono necessarie molte risorse oltre al tempo e al denaro.
Tuttavia, dovrete assicurarvi che il vostro team abbia le conoscenze e gli strumenti adeguati per eseguire correttamente i test white box.
1. Comprensione del codice sorgente
I test white box sono quelli eseguiti da sviluppatori e ingegneri del software che conoscono perfettamente il codice sorgente e la struttura interna del software.
Se siete un tester QA senza queste conoscenze, dovrete passare il software a qualcun altro prima di poter iniziare il test white box.
2. Casi di test
È necessario scrivere i casi di test prima di eseguire i test white box. I casi di test sono singoli insiemi di istruzioni che descrivono le azioni che i tester o gli sviluppatori possono eseguire per verificare le funzioni e il funzionamento di un sistema.
Nei test white box, i casi di test sono progettati da persone con una conoscenza completa della struttura interna del sistema e creati per verificare se questo funziona come dovrebbe.
3. Strumenti di test white box
Sono disponibili molti strumenti per il test white box che supportano l’accesso al codice sorgente e ai documenti di progettazione oltre a completare l’automazione dei test. Sono inoltre disponibili a diversi livelli di prezzo per gli utenti, come le versioni ZAPTEST FREE e ZAPTEST ENTERPRISE che offrono una maggiore flessibilità.
Scegliete gli strumenti che volete utilizzare prima di iniziare i test, assicurandovi che abbiano le funzionalità giuste, come il funzionamento multipiattaforma e la tecnologia Computer Vision, in modo da vedere ciò che vedono i test automatici.
Assicuratevi che tutti gli sviluppatori e gli ingegneri coinvolti nei test sappiano come e quando usarli.
Il processo di test white box
I test white box implicano una conoscenza molto più approfondita del funzionamento di un sistema rispetto ai test black box e alcune fasi dei test white box sono leggermente diverse.
I tester white box devono innanzitutto identificare le caratteristiche o i componenti del sistema che vogliono verificare prima di tracciare i possibili percorsi da testare e scrivere i casi di test da eseguire.
Il processo di white box testing può variare anche a seconda della tecnica di white box utilizzata. Seguite i passaggi seguenti per scoprire come eseguire i test white box massimizzando la copertura del percorso.
Fase 1: Identificazione delle caratteristiche da testare
Prima di eseguire i test white box, considerate esattamente cosa volete testare e come lo farete. In genere si tratta di concentrarsi su un piccolo insieme di funzioni o caratteristiche e di creare una serie di casi di test solo per verificarli.
Questa fase verrà ripetuta più volte per diverse aree del sistema per massimizzare la copertura dei test, ma è importante suddividere le diverse aree in test individuali.
Quanto più ristretto è l’obiettivo, tanto più affidabili e precisi possono essere i test.
Fase 2: tracciare tutti i possibili percorsi in un diagramma di flusso
Una parte significativa del lavoro di preparazione al test white box consiste nel tracciare tutti i possibili percorsi da testare in un diagramma di flusso.
Questo passaggio può aiutare a massimizzare la copertura dei percorsi e a garantire la verifica di tutti i percorsi possibili in ogni caso di test creato. Disegnate un diagramma di flusso che copra tutti i possibili percorsi per ogni funzione o componente che state testando, ad esempio delineando i vari percorsi che si presentano quando vengono immessi valori diversi.
Fase 3: Identificare tutti i percorsi possibili
Osservate il vostro diagramma di flusso e identificate tutti i possibili percorsi che gli utenti possono intraprendere, partendo dal primo passo del diagramma di flusso e arrivando all’ultimo passo.
Più rami e decisioni sono presenti nel diagramma di flusso, maggiore sarà il numero di percorsi unici. Capire quanti percorsi unici possibili esistono può aiutare ad assicurarsi che i casi di test coprano ogni possibilità.
Passo 4: Creare i casi di test
La fase successiva del test white box consiste nello scrivere casi di test che verifichino tutti i percorsi individuati in precedenza.
È importante assicurarsi che i casi di test coprano tutti i percorsi possibili e delineino chiaramente le azioni che i tester o gli sviluppatori devono compiere per eseguire ciascun caso di test.
Per ogni caso di test, includere l’ID e il nome del caso di test, una breve descrizione e i risultati attesi di ciascun test.
Passo 5: Esecuzione dei casi di test
Ora è il momento di eseguire i casi di test, che è ciò che la maggior parte delle persone considera come l’esecuzione del test white box stesso.
I tester eseguono i casi di test seguendo la breve serie di istruzioni delineate in ogni caso di test e riportando il risultato di ogni caso di test. Questo può essere confrontato con i risultati attesi delineati nel test case per verificare se ogni test white box è stato superato o meno.
Fase 6: Ripetere il ciclo se necessario.
Come altre forme di test del software, il white box testing consiste nel confrontare il funzionamento effettivo del sistema con le aspettative che i tester hanno su come il sistema dovrebbe funzionare.
Se i tester scoprono che il sistema non si comporta nel modo previsto, ciò può significare che il test white box è fallito e gli sviluppatori devono correggere le linee di codice prima di condurre ulteriori test.
Ripetere il processo sopra descritto per eseguire ulteriori test white box fino a quando il sistema non è stato testato a fondo e gli eventuali errori sono stati corretti.
Le migliori pratiche per i test white box
Le best practice per i test white box dipendono dal tipo di test che si sta eseguendo e dalla fase del processo di test in cui ci si trova.
Poiché la maggior parte dei test white box si svolge durante i test unitari e di integrazione, la maggior parte delle best practice dei test white box si applica a queste fasi.
1. Massimizzare la copertura dei test
Per definizione, è importante massimizzare la copertura dei test quando si eseguono i test white box per garantire che un’alta percentuale del software venga testata durante questa fase.
È possibile farlo massimizzando la copertura dei percorsi e dei rami e scrivendo casi di test che esplorino tutti i possibili percorsi e risultati durante la fase di preparazione.
2. Verificare il comportamento e le prestazioni
Quando si scrivono i casi di test nel white box testing, si vogliono creare casi di test che verifichino che il sistema funzioni come ci si aspetta, nonché casi di test che verifichino le prestazioni del sistema.
Ad esempio, oltre a verificare che determinate azioni portino a determinati risultati, si può anche verificare la velocità con cui il sistema è in grado di eseguire determinate operazioni o come le prestazioni siano influenzate da diverse variabili.
3. Scrivere i casi di test indipendentemente l’uno dall’altro
Se si vogliono verificare due caratteristiche distinte, ad esempio se una classe di codice dipende da un particolare database, creare un’interfaccia astratta che rifletta la connessione al database e implementare un’interfaccia con un oggetto mock per testare questa connessione.
In questo modo si garantisce che i casi di test verifichino le connessioni che si desidera verificare e non qualcos’altro.
4. Coprire tutti i percorsi e i loop
Massimizzare la copertura dei test significa coprire tutti i percorsi possibili, considerando i loop condizionali e altri tipi di loop nel codice.
Assicuratevi di progettare casi di test che esplorino completamente i percorsi possibili e verificate che i loop si comportino come vi aspettate, indipendentemente dall’input.
7 errori e insidie quando
Implementazione dei test White box
Quando si inizia a eseguire i test white box, è importante essere consapevoli di alcune delle insidie più comuni in cui gli sviluppatori spesso cadono quando eseguono i test white box. I comuni errori di white box testing possono causare ritardi e imprecisioni che potrebbero danneggiare la qualità e la tempistica del rilascio del software.
1. Pensare che i test white box non siano necessari
Alcuni tester pensano che i test white box non siano necessari, perché i test black box verificano tutti gli output esterni del software e se questi funzionano correttamente si presume che anche il funzionamento interno del sistema funzioni.
Tuttavia, i test white box possono aiutare gli sviluppatori a individuare problemi e bug che non sempre emergono nei test black box e sono essenziali per verificare la sicurezza dei sistemi software.
Ad esempio, se un programma ha una perdita di memoria che causa un degrado delle prestazioni per lunghi periodi di tempo e che i test black box non sono in grado di esaminare, i test white box sono l’unica opzione per esaminare il codice e trovare il problema prima di un rilascio pubblico.
2. Esecuzione manuale di tutti i test white box
Alcuni sviluppatori potrebbero pensare che sia altrettanto facile eseguire i test white box che quelli black box.
Tuttavia, i test white box richiedono molto più tempo e gli sviluppatori che cercano di eseguire i test white box in modo completamente manuale possono scoprire che è impossibile eseguire i controlli manuali secondo gli standard desiderati o massimizzando la copertura dei test.
3. Assegnazione dei tester per l’esecuzione dei casi di test
I test white box devono essere eseguiti completamente da sviluppatori, ingegneri del software e persone che conoscono a fondo il funzionamento interno del sistema software.
Alcuni sviluppatori pensano di poter passare i test white box ai tester QA dopo aver scritto loro stessi i casi di test, ma questo si tradurrà solo in una cattiva esecuzione e ridurrà la qualità della documentazione.
4. Affrettare i test
Il test del software è un processo lungo e dispendioso in termini di tempo e alcuni sviluppatori possono essere tentati di superare in fretta il test white box per passare alla fase successiva dello sviluppo. È importante allocare tempo e risorse sufficienti ai test white box per garantire che gli sviluppatori non si sentano affrettati e che abbiano tempo sufficiente per massimizzare la copertura dei test.
5. Scarsa documentazione
La conservazione di un’adeguata documentazione prima, durante e dopo il collaudo assicura che tutti coloro che partecipano allo sviluppo e al collaudo del software abbiano accesso alle informazioni corrette al momento giusto.
Assicuratevi che ogni membro del team di sviluppo sappia come scrivere una documentazione chiara e come riportare i risultati dei test white box.
6. Utilizzo improprio degli strumenti di automazione
Gli strumenti di automazione possono semplificare l’esecuzione dei test white box, ma è importante assicurarsi che tutto il team comprenda quali strumenti di automazione si stanno utilizzando e come usarli.
Strumenti diversi sono adatti a tipi diversi di test, quindi è importante scegliere strumenti di automazione appropriati per i test white box e imparare a usarne correttamente le funzionalità.
Ad esempio, alcuni strumenti non integrano l’automazione e si concentrano invece sulla raccolta di informazioni e sull’organizzazione dei ticket, che sono tutt’altro che ideali per i test automatizzati. Al contrario, strumenti full-stack come ZAPTEST coprono l’intero processo di test grazie a funzionalità come l’automazione di qualsiasi attività, rendendoli adatti a un lavoro più efficace di white box testing.
7. Non lavorare con il team QA
Il fatto che i test white box siano pianificati ed eseguiti dagli sviluppatori non significa che il team QA non debba essere coinvolto in alcun modo.
È importante trasmettere i risultati dei test white box al team QA, in modo che capisca cosa è stato testato finora e come i risultati dei test white box possano influenzare il modo in cui il team QA affronta i test black box.
Non coinvolgendo il team QA, si crea un potenziale scollamento tra i diversi reparti, che porta a una scarsa comunicazione e a un feedback peggiore in fase di test. Il risultato finale è un livello di qualità significativamente inferiore nel prodotto finale.
Tipi di output dei test white box
Quando si esegue un test software white box, si ricevono vari output a seconda dei risultati dei test eseguiti. La comprensione di questi risultati dei test white box può aiutare a capire quali sono i passi successivi da compiere.
1. Risultati del test
I risultati dei test white box vi diranno se è necessario proseguire con ulteriori test, se ci sono difetti da correggere e se ogni singolo caso di test è stato superato o meno. Una documentazione accurata è necessaria perché aiuta sviluppatori e tester a comprendere i risultati dei test white box.
2. Difetti
I difetti possono essere identificati nei test white box e talvolta i risultati dei test white box saranno difetti e bug.
Se il sistema software non si comporta come ci si aspetta durante il test white box, ciò può indicare che il programma presenta gravi difetti che devono essere corretti prima di continuare lo sviluppo e il collaudo.
3. Rapporti di prova
I rapporti di prova sono rapporti compilati da sviluppatori e tester durante e dopo il collaudo del software.
Contengono i dettagli dei risultati del test, compresi i casi di test superati e non superati, gli eventuali difetti riscontrati durante il test e le raccomandazioni per i passi successivi.
Gli sviluppatori utilizzano i rapporti di prova per comunicare con altri sviluppatori il cui compito può essere quello di risolvere i bug e gli errori riscontrati durante i test.
Esempi di test white box
I test white box consentono agli sviluppatori di verificare che la struttura interna del sistema software funzioni come dovrebbe, indipendentemente dai risultati e dagli output esterni del sistema.
Gli esempi che seguono illustrano come i test white box possono aiutare gli sviluppatori a verificare le funzioni interne del software.
1. Esempio di pagina di registrazione per il commercio elettronico
Un esempio di white box testing riguarda il modo in cui gli sviluppatori testano le funzioni di un sito web. Se state cercando di testare la pagina di registrazione di un sito web di e-commerce, i test white box possono consentire agli sviluppatori di capire se le funzioni e le classi coinvolte nella registrazione funzionano come dovrebbero quando la funzione di registrazione viene eseguita.
Questo include specificamente tutte le informazioni che un utente inserisce e valuta i parametri che stanno dietro al modulo, comprese le date che sono o non sono valide e ciò che il modulo considera come un indirizzo e-mail legittimo.
Il team inserisce quindi una serie di stringhe che mettono alla prova il modulo, con alcune progettate per fallire e altre per avere successo, prima di valutare i risultati rispetto a quelli previsti.
I test black box, invece, si limitano a verificare se la pagina funziona, senza ulteriori analisi del perché o del come.
2. Esempio di calcolatrice
I calcolatori di applicazioni forniscono un altro esempio di test white box.
Se state creando una calcolatrice che viene utilizzata come parte di un’applicazione, i tester della scatola nera verificheranno semplicemente se l’output della calcolatrice è corretto quando si utilizza la calcolatrice come previsto.
I tester della scatola bianca controllano i calcoli interni della calcolatrice per verificare come è stato calcolato l’output e se questo è corretto. È più utile per i calcoli più complessi con diverse fasi, come ad esempio le imposte. I tester esaminano il codice per vedere i passaggi che il calcolatore compie e l’ordine in cui si svolgono, prima di vedere il risultato dopo ogni fase.
Se l’input della calcolatrice è (7*4) – 6 e l’output è 22, questo è corretto e il test della scatola nera lo supererà. Tuttavia, ciò è dovuto al fatto che 7*4 = 28, e 28 – 6 fa 22. I test white box potrebbero rivelare che il software ha trovato questo risultato eseguendo 7*4 = 32 e 32 – 6 = 22, nessuno dei due casi è corretto.
Questa maggiore comprensione mostra che il calcolo è accurato dopo ogni fase specifica, individua la fase in cui potrebbe non essere accurato e risolve il problema più rapidamente, poiché il tester può vedere chiaramente dove si verifica il problema.
Tipi di errori e bug nei test white box
Durante i test white box, è possibile identificare e localizzare i bug che possono influenzare il funzionamento dei sistemi sotto il cofano. Questi bug possono riguardare funzioni esterne o influire sulle prestazioni o sull’affidabilità.
Di seguito sono elencati alcuni dei tipi più comuni di errori e bug che si verificano durante i test white box.
1. Errori logici
Gli errori logici si verificano nei test white box perché i test white box evidenziano le aree in cui il programma non funziona logicamente o in cui le funzioni e le condizioni sono utilizzate in modo improprio all’interno del codice del software.
Gli errori logici possono presentarsi come guasti del sistema o semplicemente dare luogo a comportamenti e risultati inattesi.
2. Errori di progettazione
I test white box possono aiutare gli sviluppatori a identificare gli errori di progettazione nel codice. Gli errori di progettazione si verificano quando c’è una differenza tra il flusso logico del software e la sua effettiva implementazione. Possono causare comportamenti imprevisti ed errori di prestazione.
3. Errori tipografici
Gli errori tipografici e i difetti di sintassi sono errori dovuti a un errore umano, ad esempio perché uno sviluppatore ha digitato male una particolare frase o ha aggiunto la punteggiatura sbagliata a una riga di codice. Piccoli errori di questo tipo possono causare l’interruzione di funzioni e dichiarazioni che il software non è in grado di leggere, causando gravi errori nel sistema.
Metriche comuni per i test white box
Quando si eseguono test white box, le metriche di test comuni possono aiutare a misurare il successo e la completezza dei test white box e a capire la qualità del lavoro degli sviluppatori.
Le metriche di test informano il processo di sviluppo perché possono identificare aree di miglioramento o guidare il processo di test in futuro.
1. Copertura del codice
Una delle caratteristiche principali dei test white box è che devono coprire la maggior parte del codice possibile e si può misurare quanto codice è stato coperto con le metriche di copertura del codice.
Le metriche di copertura del codice mostrano quanta parte del codice totale dell’applicazione è stata verificata utilizzando i test white box. In genere, gli sviluppatori mirano a coprire il più possibile il 100% del codice del software attraverso i test white box.
La copertura del codice può essere distinta in metriche distinte, tra cui la copertura dei percorsi, dei segmenti, delle dichiarazioni e dei rami.
La copertura delle condizioni composte è un altro tipo di metrica di copertura del codice che verifica che ogni condizione all’interno di un insieme sia stata controllata insieme a più percorsi e combinazioni di percorsi.
2. Metriche dei difetti
Le metriche dei difetti riflettono il numero di difetti riscontrati, l’efficacia dei test white box nell’identificare i difetti e le percentuali di codice che passano o falliscono i test white box.
Le metriche dei difetti possono essere presentate come numero di difetti per mille linee di codice o come numero di difetti totali nel programma. Sebbene un basso numero di difetti possa sembrare positivo, gli sviluppatori devono assicurarsi che non sia dovuto al fatto che i difetti non vengono rilevati durante i test.
3. Esecuzione del test
Le metriche di esecuzione dei test possono aiutare gli sviluppatori a vedere rapidamente quale percentuale dei test totali è stata eseguita finora e quanti test non sono ancora stati eseguiti. Le metriche di esecuzione del testo aiutano i team software a capire a che punto sono i progressi dei test white box e se i test software automatizzati vengono eseguiti come previsto.
Tuttavia, è possibile che si verifichino sia falsi positivi che falsi negativi, il che può influire sull’accuratezza di questa metrica.
4. Durata del test
Le metriche di durata dei test ci dicono quanto tempo ci vuole per eseguire i test automatizzati, il che è particolarmente importante nei test white box perché l’automazione è essenziale per massimizzare l’efficienza e la copertura dei test.
La durata dei test è spesso un collo di bottiglia nello sviluppo agile del software, quindi capire quanto tempo impiegano i test del software per essere eseguiti può aiutare i team di sviluppo ad accelerare il processo di sviluppo.
Tuttavia, è importante ricordare che le metriche sulla durata dei test non dicono nulla sulla qualità dei test che si stanno eseguendo.
Strumenti di test white box
Gli strumenti e la tecnologia possono rendere i test white box molto più accurati, efficienti e completi. Gli strumenti per i test white box possono aiutare gli ingegneri del software ad automatizzare i test white box, a registrare e documentare il processo di test white box e a gestire i test white box dall’inizio alla fine.
5 migliori strumenti gratuiti per i test white box
Se non volete ancora investire in costosi strumenti di white box testing, potete provare una serie di strumenti di white box testing gratuiti online senza pagare nulla.
Gli strumenti di test gratuiti non sempre offrono tutte le stesse funzionalità degli strumenti aziendali, ma sono un buon punto di partenza per i principianti del white box testing e possono aiutare i team di sviluppo a comprendere meglio quali strumenti e tecnologie sono necessari.
1. ZAPTEST edizione gratuita
ZAPTEST è uno strumento di test del software e un software di automazione dei processi robotici che consente agli sviluppatori e ai tester QA di automatizzare sia i test white box che i test black box.
La versione gratuita di ZAPTEST consente di avere più utenti virtuali, più iterazioni e il supporto di un forum di utenti. L’applicazione funziona con fonti di dati locali ed esterne e si integra con HP ALM, Rally e JIRA. Gli utenti che apprezzano l’offerta gratuita di ZAPTEST e vogliono vedere di più di ciò che l’azienda offre, possono anche chiedere di passare all’edizione enterprise una volta pronta.
2. Bugzilla
Bugzilla è uno strumento open source molto popolare per il testing del software che consente agli sviluppatori di tenere traccia di bug e difetti all’interno del software e di gestire il ciclo di vita dei bug.
Bugzilla semplifica l’assegnazione dei bug agli sviluppatori, la definizione delle priorità e la verifica dei bug e la loro chiusura una volta risolti. Bugzilla è un ottimo strumento per i team che stanno ancora cercando di standardizzare il loro approccio alla segnalazione dei bug ed è completamente gratuito.
3. OpenGrok
OpenGrok è un browser di codice open source e un motore di ricerca per codebase. È compatibile con il codice scritto in Java, C++, JavaScript, Python e altri linguaggi di programmazione.
Se volete essere in grado di navigare rapidamente in una base di codice di grandi dimensioni durante i test white box, OpenGrok è completamente gratuito e facile da usare.
4. Mappa SQL
SQLmap è un altro strumento open source considerato quasi essenziale nei test white box. SQLmap regola il flusso di sfruttamento e rilevamento dei bug SQL injection.
Autodefinitosi “strumento di penetrazione”, SQLmap può aiutare i tester white box a identificare e localizzare gli errori di sicurezza nel codice sorgente e a correggerli prima di proseguire.
5. Emma
Emma è un toolkit open-source in grado di misurare la copertura del codice se si lavora in Java. È un modo rapidissimo per accertare rapidamente la copertura del codice e per tenere traccia di quanto codice ha coperto ogni membro del team di sviluppo su base individuale.
Emma supporta la copertura di classi, metodi, linee e blocchi di base ed è completamente basato su Java.
5 migliori strumenti di test white box per le aziende
Se siete alla ricerca di strumenti che offrano maggiori funzionalità o un supporto migliore, gli strumenti di test white box aziendali potrebbero essere più adatti al vostro team di sviluppo.
1. ZAPTEST edizione ENTERPRISE
L’edizione enterprise di ZAPTEST è la versione potenziata di ZAPTEST gratuito. In questa versione, gli utenti possono usufruire di infiniti modelli OCR, infinite iterazioni e infiniti script VBScript e JavaScript.
L’edizione enterprise di ZAPTEST offre una suite più completa di strumenti per i team di sviluppo che desiderano passare all’automazione, e la versione enterprise viene anche fornita con un supporto esperto per assicurarsi che il team ottenga il massimo dalla tecnologia di automazione del testing del software e RPA di ZAPTEST.
2. Violinista
Fiddler è una suite di strumenti di Telerik realizzata per il test white box delle applicazioni web. Fiddler può registrare tutto il traffico HTTP tra il sistema e Internet e valutare i breakpoint impostati, nonché regolare i dati in uscita e in entrata. È disponibile in diversi formati a seconda del budget e delle esigenze, quindi c’è un’edizione di Fiddler per quasi tutte le squadre.
3. Fortificare gli HP
HP Fortify, precedentemente noto come Fortify, è un altro strumento per i test di sicurezza che offre soluzioni di sicurezza complete per i test white box. La suite di strumenti Fortify include lo strumento Fortify Source Code Analysis, che analizza automaticamente il codice sorgente alla ricerca di vulnerabilità che potrebbero esporre l’applicazione ad attacchi informatici.
4. Unità ABAP
La versione enterprise di ABAP Unit consente agli sviluppatori di software di eseguire test unitari manuali e automatici in modo rapido e semplice. Gli sviluppatori scrivono test unitari all’interno dell’applicazione ABAP e utilizzano questi test per verificare le funzioni del codice e identificare gli errori nell’ambito dei test unitari.
I team di software che vogliono provare questo strumento possono iniziare con la versione gratuita di ABAP Unit prima di passare all’edizione enterprise.
5. LDRA
LDRA è una suite proprietaria di strumenti che possono essere utilizzati per la copertura degli enunciati, la copertura dei rami e la copertura delle decisioni durante l’esecuzione di test white box. È uno strumento eccellente se volete verificare che il vostro codice sorgente soddisfi i requisiti standard di conformità, tracciamento e igiene del codice.
Quando si dovrebbe usare l’impresa
contro gli strumenti di test freemium white box?
Sia gli strumenti di test del software aziendali che quelli freemium hanno il loro posto in qualsiasi team di sviluppo software moderno. Man mano che il vostro team cresce e i test automatizzati diventano più importanti per il vostro approccio ai test white box, è probabile che vogliate passare dal lavorare principalmente con strumenti di test gratuiti a strumenti aziendali che offrono maggiori funzionalità e usi illimitati.
Tuttavia, ci sono scenari specifici in cui gli strumenti freemium possono essere più adatti di quelli enterprise.
Molti sviluppatori scelgono di iniziare con strumenti freemium quando sperimentano nuove funzionalità e tecnologie, principalmente per valutare se queste tecnologie sono adatte al loro team prima di investire in tecnologie enterprise.
Potreste anche provare le versioni gratuite di strumenti aziendali come ZAPTEST, in modo da provarli prima di acquistarli e scoprire cosa offrono gli strumenti aziendali.
Infine, alcuni strumenti freemium come Emma e Bugzilla sono specializzati in funzioni di nicchia ma importanti, che offrono vantaggi continui anche ai team di software disposti a pagare per le tecnologie aziendali.
Test white box: lista di controllo, suggerimenti e trucchi
Quando siete pronti a eseguire i test white box, assicuratevi di avere tutto ciò che vi serve prima di iniziare. Di seguito è riportato un elenco di cose da ricordare prima di iniziare i test white box per massimizzare la copertura dei test e migliorare l’accuratezza dei risultati dei test white box.
1. Utilizzare gli strumenti di automazione
Gli strumenti di automazione possono accelerare enormemente il processo di esecuzione dei test white box, riducendo il tasso di errore e aumentando l’accuratezza complessiva.
Quasi tutti i team di software oggi utilizzano un certo livello di automazione per eseguire i test white box, quindi sperimentare vari strumenti e tecnologie di automazione prima di iniziare i test white box può aiutarvi a scegliere gli strumenti da utilizzare prima dell’inizio dei test.
2. Puntare a una copertura del 100% dei test
Probabilmente non raggiungerete l’obiettivo del 100% di copertura dei test, ma è meglio avvicinarsi il più possibile a questa cifra quando si eseguono test white box.
Utilizzate gli strumenti di copertura dei test per tracciare e misurare le singole metriche, come la copertura dei percorsi e la copertura delle diramazioni, e assicuratevi che tutti i percorsi e le diramazioni più importanti del vostro software siano stati coperti durante i test white box.
3. Produrre rapporti di prova chiari
Come nel caso di altre forme di test del software, assicuratevi che il vostro team sappia come compilare rapporti di test accurati e chiari dopo ogni fase di test.
Un rapporto di prova deve essere scritto in un formato di facile comprensione e deve includere i dettagli dell’approccio di prova, nonché un riepilogo degli output e dei risultati di ciascun caso di prova eseguito. Il rapporto finale deve giustificare i passi compiuti e formulare raccomandazioni per le fasi successive.
4. Misurare il successo con le metriche di test
Le metriche di test aiutano i team software a tracciare e registrare i progressi dei test white box e offrono informazioni preziose che possono informare i futuri processi di sviluppo.
È importante che gli sviluppatori utilizzino le metriche per capire quanto siano efficaci i test che stanno eseguendo e quanto sia pulito il loro codice iniziale, in modo da poter migliorare il loro lavoro in futuro.
Test white box:
Conclusione
Il test white box nell’ingegneria del software è un tipo essenziale di test del software che verifica la struttura interna e la logica del codice sorgente di un’applicazione software.
Insieme ai test black box, i test white box accertano non solo che il software funzioni come previsto, ma anche che il codice interno sia logico, pulito e completo.
I test white box sono condotti più frequentemente nei test di unità e di integrazione e sono sempre eseguiti da sviluppatori e ingegneri del software con una conoscenza completa del codice interno del software.
Sebbene alcuni test white box possano essere eseguiti manualmente, oggi molti test white box sono automatizzati grazie ai miglioramenti in termini di velocità, efficienza e copertura offerti dall’automazione dei test white box.
FAQ e risorse
Se volete saperne di più sui test white box, ci sono molte risorse online gratuite che potete consultare. Potete utilizzare video, libri e altre risorse per imparare a eseguire i test white box e assicurarvi che i vostri standard di test white box seguano le best practice.
1. I migliori corsi sull’automazione dei test white box
Se volete saperne di più sull’automazione dei test white box, potete seguire un corso sul testing del software e sui test white box. Alcuni di questi corsi sono accreditati e offrono qualifiche formali, mentre altri sono corsi online informali progettati per aiutare gli sviluppatori e i tester di software che vogliono migliorare la loro conoscenza di un particolare argomento.
Alcuni dei migliori corsi di white box testing disponibili online oggi includono:
2. Quali sono le cinque principali domande di intervista sull’automazione dei test white box?
Se vi state preparando per un colloquio in cui potreste discutere di white box testing, tecniche di white box e strumenti di automazione, è importante che lo sappiate.
- Qual è la differenza tra white box testing e black box testing?
- Perché i test white box sono importanti?
- Quali sono i diversi approcci che si possono adottare per i test white box?
- Quali sono i processi coinvolti nel white box testing e come possiamo migliorarli?
- Quali sono gli strumenti e le tecnologie che potreste utilizzare per rendere i test white box più veloci o più accurati?
3. I migliori tutorial di YouTube sui test white box
Se volete saperne di più sui test white box, guardare i tutorial di YouTube può aiutarvi a capire come funzionano i test white box e a vedere le spiegazioni visive dei processi e degli approcci coinvolti nei test white box.
Tra i tutorial di YouTube più informativi che si possono trovare online ci sono:
- Udacity: Esempio di test white box
- Guru99: Che cos’è il White Box Testing?
- Test a scatola bianca e test a scatola nera
- Tecniche di test white box
- Mentore di test del software: Che cos’è il White Box Testing?
4. Come mantenere i test white box
La manutenzione dei test software garantisce che, di volta in volta, i test eseguiti siano accurati e adatti allo scopo. È importante mantenere tutti i tipi di test del software, sia in blackbox che in whitebox, perché il codice su cui si eseguono i test cambia costantemente a ogni riparazione e iterazione del bug. Ciò significa che gli script di test devono cambiare insieme ad esso.
Il mantenimento dei test white box implica l’aggiornamento del framework di automazione dei test e l’applicazione di processi volti a garantire che i test e i casi di test vengano aggiornati regolarmente.
Si può fare questo con:
Inserire la manutenzione nella progettazione dei test:
Considerare il futuro dei test white box quando si costruiscono e si progettano i test white box renderà più facile la manutenzione dei test in futuro.
Consentire una comunicazione chiara tra i team:
Assicuratevi che tutti i membri del team di sviluppo abbiano più canali di comunicazione, in modo che le modifiche apportate al codice si riflettano rapidamente nei test.
Essere adattabili:
A volte può capitare di apportare al codice modifiche che non erano state previste. Assicuratevi che il vostro team sappia adattarsi rapidamente a questi cambiamenti e che abbia le competenze per seguirli nei test.
Rivalutare costantemente i protocolli di analisi:
I protocolli di test implementati all’inizio della sperimentazione potrebbero non essere più adatti una volta che il software è stato sottoposto a varie modifiche e miglioramenti. Rivalutate i vostri protocolli di test a intervalli regolari per verificare se sono ancora adatti.
5. I migliori libri sui test white box
I test white box sono una materia profonda che può richiedere anni per essere padroneggiata. Se volete diventare esperti di white box testing moderno nel testing del software, potete leggere libri sul white box testing scritti da sviluppatori, accademici e ingegneri.
Tra i migliori libri sui test white box e sull’automazione dei test vi sono i seguenti:
- L’arte di testare il software, terza edizione di Glenford J. Myers, Corey Sandler, Tom Badgett, Todd M. Thomas
- Test del software: Un approccio artigianale, quarta edizione, di Paul C. Jorgensen
- Come rompere il software: Guida pratica ai test di James Whittaker
- L’automazione del test del software appena sufficiente di Dan Mosley e Bruce Posey
Dovreste essere in grado di trovare questi libri in alcune librerie e biblioteche, oltre che online. È inoltre possibile trovare altri materiali di lettura e risorse di apprendimento negli elenchi di lettura di buoni corsi e programmi di test del software.
