Qualunque cosa deve essere più corretta.

Seriamente, i test white-box (cioè testare gli interni del codice) dovrebbero idealmente essere fatti con i test unitari dallo sviluppatore che ha scritto il codice. I test unitari dovrebbero essere costruiti nel tempo e parte del processo di costruzione in modo da non sprecare il tempo del tester scadente con il codice che sappiamo non funziona come dovrebbe. Il test unitario diventa più importante quanto più piccola è la tua squadra, soprattutto perché non hai un esercito di tester per scuotere i problemi.

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

Tutti i test devono essere priorizzati sulla criticità di una funzione per il prodotto finito. Se la missione è fornire uno strumento per fare X e il prodotto non fa X, è un grosso problema.

Black

Test black-box per verificare le funzionalità. Test della white-box, se necessario, in caso di problemi. Se tutti i test black-box passano e la copertura è buona, il test white-box non è necessario.

Casella nera.

I componenti della scatola bianca sono solitamente dipendenti dai componenti della scatola nera, quindi vorrei prima testare la scatola nera e poi passare alla scatola bianca.

Per prima cosa fai test bianchi pensando a programmatore / sviluppatore per assicurarti che le cose funzionino bene. Poi fai i test black box 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.

Se vuoi avere un buon ciclo di test, dovresti avere persone diverse che fanno Entrambi :

• Uno sviluppatore focalizzato principalmente sui test white-box sa cosa è cambiato recentemente nel codice, quali aree sono più complesse (e quindi suscettibili di rottura), ecc. e possono concentrare gli sforzi in modo appropriato in queste aree che probabilmente introdurranno nuovi difetti.

• D'altro canto, un tester di QA focalizzato sui test black-box può facilmente avvicinarsi 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 diverse parti della soluzione. Verranno individuati bug che lo sviluppatore potrebbe aver trascurato o regressioni da modifiche al codice che hanno interrotto accidentalmente altre aree dell'applicazione.

Per rispondere alla tua domanda, il test white-box dovrebbe essere fatto prima. Ma hai davvero bisogno di avere una persona diversa che faccia il test della scatola nera se vuoi che sia efficace.

Mi piace iniziare con i 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 è dipende . Probabilmente mi immergerò presto nel codice (o almeno prima) se eseguirò i test delle API, ma molto più tardi se il mio obiettivo è guardare alcuni grandi scenari end-to-end.

Direi prima Black Box test, semplicemente perché come proponente di TDD, i test sono scritti prima che il codice (o la casella) esistano comunque:)

White Box (per quanto ho capito) è più utile in una mentalità di debug.

Test della scatola nera, perché stai scrivendo dei test prima che il codice esista. Il tester deve sviluppare test automatici che richiedono molto tempo in parallelo con il codice di scrittura dello sviluppatore per essere efficiente su un piccolo team.

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

Nessuno dei due. Cerco di scrivere buoni test usando il mio BICEP destro , tenendo presente condizioni al contorno CORRETTE indipendentemente dall'ordine in cui vengono in mente. Questi sono entrambi gli acronimi proposti in Test delle unità pragmatiche .

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

Per prima cosa esegui il test della casella bianca .

Secondo tentativo di black box.

> Black Box Testing

I. Il tester dovrebbe verificare il funzionamento dell'applicazione, come casella di testo, pulsante di opzione, casella di riepilogo, pulsante di comando, ... ecc. ,

II. Il tester dovrebbe verificare non funzionali dell'applicazione, come logo, immagine, ortografia, ecc. ,

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

Nota: Per controllare le condizioni positive e negative.