Test della scatola nera e della scatola bianca

StackOverflow https://stackoverflow.com/questions/402161

Domanda

Quale tipo di test diresti dovrebbe essere l'enfasi (per tester / QA) e perché?

Una rapida serie di definizioni da Wikipedia:

Test della scatola nera

  • utilizza una prospettiva esterna dell'oggetto test per derivare casi di test. Questi test possono essere funzionali o non funzionali, sebbene di solito funzionali. Il progettista del test seleziona input validi e non validi e determina l'output corretto. Non si conosce la struttura interna dell'oggetto di test.

Test della casella bianca

  • utilizza una prospettiva interna del sistema per progettare casi di test basati sulla struttura interna. Richiede capacità di programmazione per identificare tutti i percorsi attraverso il software. Il tester sceglie gli input del test case per esercitarsi attraverso il codice e determina gli output appropriati. Nel test dell'hardware elettrico, ogni nodo in un circuito può essere sondato e misurato; un esempio è il test in-circuit (ICT).

modifica: solo per chiarire un po 'di più, mi rendo conto che entrambi sono importanti, ma di solito sono separati tra dev e QA.

La conoscenza interna è importante per il tester / QA? Ho sentito argomentazioni secondo cui testare con queste conoscenze in mente consente loro di testare meglio i problemi, ma ho anche sentito argomentazioni secondo cui queste conoscenze possono distrarre dalle esigenze funzionali e promuovere "testare nel codice" piuttosto che alla soluzione prevista.

È stato utile?

Soluzione

  • I test sulla scatola nera dovrebbero essere l'enfasi per i tester / QA.
  • I test in white box dovrebbero essere l'enfasi per gli sviluppatori (ovvero i test unitari).
  • Le altre persone che hanno risposto a questa domanda sembravano aver interpretato la domanda come che è più importante, test su scatola bianca o test su scatola nera . Anch'io credo che siano entrambi importanti ma potresti voler dare un'occhiata a questo IEEE article che afferma che i test in white box sono più importanti.

Altri suggerimenti

Il White Box Testing equivale al Software Unit Test. Lo sviluppatore o un tester del livello di sviluppo (ad esempio un altro sviluppatore) garantisce che il codice che ha scritto funzioni correttamente in base ai requisiti di livello dettagliati prima di integrarlo nel sistema.

Il test Black Box equivale al test di integrazione. Il tester garantisce che il sistema funzioni secondo i requisiti a livello funzionale.

A mio avviso entrambi gli approcci di test sono ugualmente importanti .

Un test unitario completo rileverà i difetti nella fase di sviluppo e non dopo che il software è stato integrato nel sistema. Un test black box a livello di sistema assicurerà che tutti i moduli software si comportino correttamente quando integrati insieme. Un test unitario in fase di sviluppo non rileverebbe questi difetti poiché i moduli sono generalmente sviluppati indipendentemente l'uno dall'altro.

Black Box

1  Si concentra sulla funzionalità del sistema  Si concentra sulla struttura (programma) del sistema

2  Le tecniche utilizzate sono:

& # 183; Partizionamento di equivalenza

& # 183; Analisi del valore limite

& # 183; Errore durante l'ipotesi

& # 183; Condizioni di gara

& # 183; Rappresentazione grafica causa-effetto

& # 183; Test di sintassi

& # 183; Test di transizione statale

& # 183; Matrice grafica

Il tester può essere non tecnico

Aiuta a identificare la vaghezza e la contraddizione nelle specifiche funzionali

White Box

Le tecniche utilizzate sono:

& # 183; Test del percorso di base

& # 183; Notazione del diagramma di flusso

& # 183; Test della struttura di controllo

  1. Test delle condizioni

  2. Test del flusso di dati

& # 183; Test ad anello

  1. Simple Loops

  2. Cicli nidificati

  3. Loop concatenati

  4. Loop non strutturati

    Il tester dovrebbe essere tecnico

    Aiuta a identificare i problemi logici e di codifica.

Il QA dovrebbe concentrarsi sul test della scatola nera . L'obiettivo principale del QA è testare ciò che fa il sistema (le funzionalità soddisfano i requisiti?), Non come lo fa.

Ad ogni modo, dovrebbe essere difficile per il QA fare test in white box poiché la maggior parte dei ragazzi del QA non sono tecnici, quindi di solito testano le funzionalità attraverso l'interfaccia utente (come gli utenti).

Un ulteriore passo, penso che anche sviluppatori dovrebbero concentrarsi sul test della scatola nera . Non sono d'accordo con questa associazione diffusa tra test unitari e test in scatola bianca, ma potrebbe essere solo una domanda un vocabolario / scala. Alla scala di un test unitario, il System Under Test è una classe / metodo che ha contratto (attraverso la sua firma) e il punto importante è testare ciò che fa, non come. Inoltre, i test sulla scatola bianca implicano che tu sappia come il metodo riempirà il suo contratto, che mi sembra incompatibile con TDD.

IMHO se il tuo SUT è così complesso da dover eseguire test su white box, di solito è tempo di refactoring.

" Both " è stato affermato sopra, ed è la risposta ovvia ... ma IMO, i test su scatola bianca vanno ben oltre i test delle unità di sviluppo (anche se suppongo che potrebbe dipendere da dove si traccia il confine tra bianco e nero). Ad esempio, l'analisi della copertura del codice è un approccio a scatola bianca comune, ovvero eseguire alcuni scenari o test ed esaminare i risultati alla ricerca di buchi nei test. Anche se i test unitari hanno il 100% di cc, la misurazione di cc in scenari di utenti comuni può rivelare il codice che potrebbe richiedere potenzialmente ancora più test.

Un altro posto in cui il test del riquadro bianco aiuta è l'esame dei tipi di dati, delle costanti e di altre informazioni per cercare confini, valori speciali, ecc. Ad esempio, se un'applicazione ha un input che accetta un input numerico, potrebbe essere necessario un approccio solo bb il tester per "indovinare" a quali valori andrebbero bene per i test, mentre un approccio wb potrebbe rivelare che tutti i valori tra 1-256 sono trattati in un modo, mentre i valori più grandi sono trattati in un altro modo ... e forse il numero 42 ha ancora un altro percorso di codice.

Quindi, per rispondere alla domanda originale, sia bb che wb sono essenziali per un buon test.

Nella mia esperienza, la maggior parte degli sviluppatori migra naturalmente verso i test in white box. Dato che dobbiamo garantire che l'algoritmo sottostante sia "corretto", tendiamo a concentrarci maggiormente sugli interni. Ma, come è stato sottolineato, è importante testare sia la scatola bianca che quella nera.

Pertanto, preferisco che i tester si concentrino maggiormente sui test della Black Box, per coprire il fatto che la maggior parte degli sviluppatori non lo fa davvero e spesso non è molto bravo a farlo.

Questo non vuol dire che i tester dovrebbero essere tenuti al buio su come funziona il sistema, solo che preferisco che si concentrino maggiormente sul dominio del problema e su come gli utenti reali interagiscono con il sistema, non se la funzione SomeMethod ( int x) genererà correttamente un'eccezione se x è uguale a 5.

È un po 'una porta aperta, ma alla fine entrambi sono ugualmente importanti.

Cosa c'è di peggio?

  1. software che fa ciò che deve fare, ma internamente ha problemi?

  2. software che dovrebbe funzionare se si guardano le fonti, ma no?

La mia risposta: Nessuno dei due è totalmente accettabile, ma non è possibile dimostrare che il software sia privo di bug al 100%. Quindi dovrai fare dei compromessi. L'opzione due è più direttamente evidente per i clienti, quindi avrai problemi con quello prima. A lungo termine, l'opzione 1 sarà problematica.

Test di Black Box: il test di Black Box è solo osservazione, non è necessaria alcuna conoscenza interna o struttura del prodotto software. semplicemente inserendo dati validi e non validi e aspettandosi il risultato corretto. qui il tester trova il difetto ma non è in grado di trovare la posizione del test defect.black box eseguito a tutti i livelli di test.

Le tecniche di test della scatola nera sono: 1. Partizione di equivalenza 2. Analisi del valore limite 3. Tabella delle decisioni 4. Diagramma di transizione statale 4. Usa il diagramma dei casi

Test della scatola bianca: la scatola bianca sta testando richiede la conoscenza della logica interna e della struttura del prodotto software. qui controlleremo il ciclo, le condizioni e il ramo. qui troviamo non solo il difetto ma anche e la posizione del difetto.

Tecniche di test in scatola bianca: 1. Copertura delle dichiarazioni 2. Copertura delle decisioni 3. Copertura delle filiali 4. Copertura del percorso.

  • Di solito il test in white box non è possibile per i tester. Pertanto l'unica risposta praticabile per i tester è quella di enfatizzare l'approccio "scatola nera".

  • Tuttavia, con la programmazione orientata all'aspetto e la metodologia di progettazione per contratto, quando gli obiettivi del test sono programmati nel codice target come contratti (visti dalla vista statica di un programma) e / o quando il il test della logica temporale è programmato nel codice come cross-cut (vista dinamica della logica del test), il test in white box diventerebbe non solo possibile ma anche un approccio preferito per i tester. Detto questo, dovrà essere un approccio che richiede esperienza, i tester devono essere non solo buoni tester, ma anche buoni programmatori o più che bravi programmatori.

Il Black Box Testing è un metodo di test del software in cui la struttura interna / progettazione / implementazione dell'articolo in prova NON è nota al tester. Il White Box Testing è un metodo di test del software in cui la struttura interna / progettazione / implementazione dell'articolo testato è nota al tester.

Che cosa costituisce, "quotazione interna?" Sapere che un tale algoritmo è stato usato per risolvere un problema è valido o il tester deve vedere ogni riga di codice perché sia ??"interno?"

Penso che in ogni caso di test, ci dovrebbero essere risultati attesi forniti dalla specifica utilizzata e non determinati da come il tester decide di interpretare la specifica in quanto ciò può portare a problemi in cui ognuno ritiene che siano giusti e incolpano l'altro per il problema.

  • * Test della scatola nera: è il test a livello di sistema per verificare la funzionalità del sistema, per garantire che il sistema svolga tutte le funzioni per cui è stato progettato, principalmente per scoprire i difetti riscontrati nel punto utente. È meglio assumere un tester professionale per rendere la scatola nera il tuo sistema ', perché lo sviluppatore di solito verifica con la prospettiva che i codici che aveva scritto siano buoni e soddisfino i requisiti funzionali dei clienti in modo da poter perdere molte cose (io non significa offendere nessuno)
  • Whitebox è il primo test che viene eseguito nell'SDLC, per scoprire bug come errori di runtime ed errori di compilazione Può essere eseguito dai tester o dallo sviluppatore stesso, ma penso che sia sempre meglio che la persona che ha scritto il il codice lo verifica. Li capisce più di un'altra persona. *

Ecco i miei 5 centesimi:

Come sviluppatore, scrivo principalmente test per metodi (in una classe) come test in white box, semplici perché non voglio che il mio test si interrompa solo perché cambio i lavori interni del mio codice.

Voglio solo interrompere i test se il comportamento del mio metodo cambia (ad es. restituisce un risultato diverso rispetto a prima).

Negli ultimi 20 anni di sviluppo, mi sono semplicemente stancato di fare un doppio lavoro solo perché i miei test unitari erano fortemente legati al codice e ho bisogno di mantenere sia il codice dell'applicazione che il codice di test.

Penso che creare il disaccoppiamento del codice (anche quando si eseguono i test del codice) sia una buona pratica.

Altri 5 centesimi: non uso quasi mai i framework di derisione, perché quando trovo necessariamente di deridere qualcosa preferisco invece disaccoppiare il mio codice - e sì in molti casi è molto possibile (soprattutto se non stai lavorando in un codice legacy ) :-)

* Test Black-Box: Se il codice sorgente non è disponibile, i dati di test si basano sulla funzione del software indipendentemente da come è stato implementato. -strong testo Esempi di test in black box sono: test del valore limite e partizionamento di equivalenza.

* Test su scatola bianca: Se il codice sorgente del sistema in prova è disponibile, i dati del test si basano sulla struttura di questo codice sorgente. -Esempi di test in white box sono: test del percorso e test del flusso di dati.

Semplice ... Il test Blackbox è altrimenti noto come test di integrazione o test dello schermo di fumo. Ciò viene applicato principalmente in un ambiente distribuito che si basa su un'architettura basata sugli eventi. Si verifica un servizio basato su un altro servizio per vedere tutti i possibili scenari. Qui non è possibile prevedere completamente tutto l'output possibile perché ogni componente dell'app SOA / Enterprise deve funzionare in modo autonomo. Questo può essere definito test di alto livello

, mentre

Il test in scatola bianca si riferisce al test unitario. dove tutti gli scenari e gli output previsti possono essere effettivamente previsti. vale a dire input e output previsti, che possono essere definiti test di basso livello

Sono solo parzialmente d'accordo con la risposta più votata per questa domanda. Quale tipo di test diresti dovrebbe essere l'enfasi (per tester / QA) e perché?

  1. Sono d'accordo che: " I test sulla scatola nera dovrebbero essere l'enfasi per tester / QA ".
  2. Sono d'accordo sul fatto che i test in scatola bianca dovrebbero essere l'enfasi per sviluppatori, ma non concordo sul fatto che i test su White Box siano solo unità test.

Sono d'accordo con la definizione qui che afferma che il metodo di test della scatola bianca è applicabile al seguenti livelli di test del software:

  • Test unitari: per testare percorsi all'interno di un'unità
  • Test di integrazione: per testare percorsi tra unità
  • Test di sistema: per testare percorsi tra sottosistemi
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top