14

In un team molto piccolo, in cui il test della scatola nera e della scatola bianca viene eseguito dalla stessa persona, quale dovrebbe essere prima il tester?

testing

— Colonna di sale
fonte

1

Penso che questo dipenda dal contesto. Hai finito di implementare le specifiche principalmente e vuoi iniziare i test finali o stai parlando in generale in qualsiasi momento durante il ciclo di sviluppo? Come alcuni citano nelle risposte, i vostri implementatori di solito scriveranno unit test che possono essere considerati parte del vostro test a scatola bianca poiché questi programmatori comprendono il funzionamento interno e vogliono affermare la funzionalità della loro implementazione prima di impegnarsi.

— Chris,

11

Qualunque cosa debba essere la più corretta.

Scherzi a parte, i test in white box (ovvero test degli interni del codice) dovrebbero idealmente essere eseguiti con test unitari da parte dello sviluppatore che ha scritto il codice. I test unitari verrebbero accumulati nel tempo, e parte del processo di compilazione in modo da non perdere tempo con il codice che sappiamo che non funziona come dovrebbe. I test unitari diventano più importanti quanto più piccola è la tua squadra, in particolare perché non hai un esercito di tester per risolvere i problemi.

I test in black box (ovvero i test attraverso l'interfaccia utente / di sistema) sono in genere ciò che fanno la maggior parte dei tester.

Tutti i test devono avere la priorità su quanto sia importante una funzione per il prodotto finito. Se la missione è fornire uno strumento per eseguire X e il prodotto non esegue X, questo è un grosso problema.

— Berin Loritsch
fonte

1

Ben detto, la migliore risposta che ho letto finora.

— Chris,

5

Nero

Test in scatola nera per verificare le funzionalità. Test in bianco se necessario se le cose sono rotte. Se tutti i test della scatola nera superano e la copertura è buona, i test della scatola bianca non sono necessari.

— Steven A. Lowe
fonte

2

A meno che, naturalmente, i test della scatola nera non abbiano superato il test di un pezzo chiave di funzionalità o configurazione:}

— Alan,

3

@Alan: lo stesso argomento si applica ai test in white box, quindi la precisazione "la copertura è buona"

— Steven A. Lowe

1

D'accordo - Immagino che la mia dichiarazione dipenda dalla tua definizione di buona copertura.

— Alan,

1

@DocBrown Non vedo assolutamente come ciò che hai spiegato sia qualcosa di remoto come il test di whitebox. Il test di Whitebox consiste nel seguire i percorsi di diramazione di una determinata implementazione e nel scrivere casi di test che eserciteranno tutti i percorsi. Se non si dispone ancora di un'implementazione, non è possibile eseguire test whitebox per definizione. Con TDD e BDD scrivi i test della forma generale data-quando-allora. È possibile impostare i dati di input o lo stato precondizionato, attivare l'unità ed effettuare controlli sui dati di output o stato finale o chiamate di terzi. Questa è la definizione di test blackbox.

— Sammi,

1

@SamJudge: a mio avviso, quando si guarda all'interno del codice di implementazione e si utilizzano tali informazioni per progettare dati di test molto specifici (che vengono quindi passati attraverso l'interfaccia pubblica), è giustificato chiamare questo test white box. Tale test fallisce anche se il risultato non è quello che ci si aspetta. Se in seguito guardi solo il test, potresti non essere in grado di dire chiaramente "questo test è stato prodotto con un approccio scatola bianca (o scatola nera)", ovviamente.

— Doc Brown,

3

Scatola nera.

I componenti della scatola bianca di solito dipendono dai componenti della scatola nera, quindi vorrei prima provare la scatola nera e poi passare alla scatola bianca.

— Walter
fonte

2

Non sono sicuro di cosa intendi per "componenti della scatola nera" e "componenti della scatola bianca" - per me sono solo "componenti" (che possono essere testati con o senza conoscenza del codice o dell'architettura sottostante.

— Alan

Non capisco la relazione "dipendente" che stai suggerendo qui. La scatola bianca e nera non sono componenti, più che altro uno stile per testare qualsiasi componente, come menziona Alan. La differenza sta nell'approccio adottato per testare il componente in questione.

— Chris,

2

Prima fai dei test sui bianchi pensando come programmatore / sviluppatore per assicurarti che le cose funzionino bene. Quindi esegui il test della scatola nera di solito cercando di pensare come se fossi l'utente finale, senza pensare alla struttura interna del programma. A volte devi pensare come un programmatore / sviluppatore anche se stai facendo un test nero perché potresti testare un modulo interno che è stato scritto da un'altra persona e non hai accesso al codice.

— Enrique
fonte

2

Se vuoi avere un buon ciclo di test, dovresti avere persone diverse che fanno entrambe le cose :

Uno sviluppatore focalizzato principalmente sui test white-box sa cosa è cambiato di recente nel codice, quali aree sono più complesse (e quindi probabilmente si rompono), ecc. E può concentrare gli sforzi in modo appropriato in queste aree molto probabilmente per introdurre nuovi difetti.
D'altra parte, un tester QA incentrato sui test in scatola nera può avvicinarsi più facilmente ai test come un utente finale. Senza alcuna conoscenza interna del codice, possono adottare un nuovo approccio e non sono influenzati dalla conoscenza di come vengono implementate le diverse parti della soluzione. Cattureranno bug che lo sviluppatore potrebbe aver trascurato o regressioni da modifiche al codice che hanno accidentalmente rotto altre aree dell'applicazione.

Per rispondere alla tua domanda, il test in white box deve essere eseguito per primo. Ma devi davvero avere una persona diversa che esegue il test della scatola nera se vuoi che sia efficace.

— Justin Ethier
fonte

1

Mi piace iniziare con il test della scatola nera, quindi utilizzare le informazioni sulla copertura del codice o il debugger per capire cosa sto facendo e analizzare cosa sta succedendo.

Ma la vera risposta è che dipende . Probabilmente mi immergerò nel codice prima (o addirittura prima) se sto facendo test API, ma molto più tardi se il mio obiettivo è quello di esaminare alcuni scenari end-to-end di grandi dimensioni.

— Alan
fonte

1

Direi prima i test di Black Box , semplicemente perché come sostenitori di TDD, i test sono scritti prima che il codice (o box) esista comunque :)

I test di White Box (per quanto ho capito) sono più utili in una mentalità di debug.

— Matthieu M.
fonte

-1, TDD sta testando la scatola bianca. In TDD è essenziale sapere cosa fa il codice coinvolto nel test (e cosa no) per scrivere il test successivo. Test in scatola nera significa che qualcuno che non ha idea del codice (un tester, qualcuno che non ha nemmeno bisogno di sapere come programmare), progetta i test.

— Doc Brown,

1

Quindi non pratichiamo TDD allo stesso modo. TDD per me riguarda l'applicazione delle specifiche di una classe / funzione: i test sono scritti per verificare che la classe / funzione si comporti come specificato, ma potrebbe interessare meno il comportamento del codice dietro le quinte fintanto che tali specifiche sono confermate ... che è necessario dato che i test sono scritti prima della funzionalità.

— Matthieu M.,

1

Test della scatola nera, perché stai scrivendo test prima dell'esistenza del codice. Il tester deve sviluppare test automatici che richiedono molto tempo in parallelo con il codice di scrittura dello sviluppatore per essere efficienti in un piccolo team.

Se il codice è già stato scritto, ti suggerirei di dedicare un po 'di tempo a delineare la copertura del test da un punto di vista della scatola nera per assicurarti di avere un po' di tempo per il brainstorming prima di ingombrare il tuo cervello con il codice reale. Tuttavia, puoi quindi passare alla casella bianca e guardare il codice prima di andare troppo avanti con i test effettivi per avere un'idea delle aree a rischio e dare la priorità a quei test che hai fatto il brainstorming in precedenza (e aumentarli con nuovi test pensati da guardando parti del codice che sembrano complicate o discutibili).

— Ethel Evans
fonte

0

Né. Cerco di scrivere buoni test usando il mio BICEP destro , tenendo presente le CORRETTE condizioni al contorno, indipendentemente dall'ordine in cui vengono in mente. Questi sono entrambi gli acronimi proposti nel Pragmatic Unit Testing .

Il mio obiettivo è quello di concentrarmi sulla scrittura di buoni test e non su quale colore scrivere per primo.

— Steven Evers
fonte

"Bianco" e "nero" non sono termini di test unitari, quindi ovviamente non ti preoccupare. I test unitari sono di fatto una scatola bianca.

— Ethel Evans,

@Ethel Evans: non sono test a scatola bianca per definizione. La stragrande maggioranza dei test unitari sono test in scatola bianca, ma non è un requisito. Tutti i test che mappano il dominio degli input all'intervallo di output di una funzione sono unit test, ma non devono conoscere i dettagli dell'implementazione.

— Steven Evers,

0

Per prima cosa esegui il test della scatola bianca .

Secondo per il test della scatola nera.

> Test della scatola nera

I. Il tester dovrebbe controllare il funzionamento dell'applicazione, ad esempio casella di testo, pulsante di opzione, casella di riepilogo, pulsante di comando, ecc.

II. Il tester dovrebbe verificare il funzionamento non funzionale dell'applicazione, come logo, immagine, ortografia, ecc. Ecc. ,,

III. Il tester dovrebbe controllare l'intero flusso dell'applicazione.

Nota: per verificare le condizioni positive e negative.

Test della scatola nera o della scatola bianca - che cosa fai per primo?

Nero