Le grandi categorie secondo me sarebbero:
Test su scatola nera . Non riesci a vedere il codice e stai solo testando alla cieca in una certa misura poiché ciò che è nell'applicazione o nel sistema ti è nascosto. Pertanto, in questo caso le persone non conoscono tutti i casi di errore e devono indovinare con varie condizioni al contorno che possono essere o meno ovvie per trovare tutti i casi.
Test su scatola bianca . È possibile visualizzare il codice e verificare quali percorsi del codice vengono utilizzati in modo che la copertura del codice possa essere utilizzata come metrica per garantire che tutta la logica venga utilizzata nel sistema. L'idea qui è di sapere come appare il codice per guidare i test in modo che non sia così misterioso come i test in scatola nera.
Il test della scatola grigia è un ibrido dei due precedenti.
I casi limite tendono ad essere qualcosa che si può vedere nei test in white box poiché ci sono varie condizioni da vedere nel codice in cui si scrivono i test da eseguire, ad esempio se si dispone di un programma che richiede un numero e qualcuno inserisce X come viene gestito dovrebbe essere visto da qualche parte nel codice.
Le classificazioni generali dei test sarebbero:
Test unitari . Questi sono generalmente i test più piccoli che testano qualcosa di piuttosto specifico, ad esempio questo metodo gestisce questo caso limite? Si noti che l' iniezione di dipendenza può essere utilizzata qui per casi che coinvolgono oggetti simulati per ridurre eventuali dipendenze per i test.
Test di integrazione . Questi sono test in cui sono collegati un paio di componenti e vengono eseguiti test per assicurarsi che i componenti funzionino bene insieme. Si noti che mentre i test unitari possono funzionare in modo indipendente, è qui che viene eseguito il test di quanto bene si uniscono le cose in quanto potrebbe esserci una comunicazione errata tra i livelli che rendono questi test utili per catturare vari gotcha. Il termine test end-to-end viene utilizzato per test di integrazione in cui viene testata una catena completa di componenti da "un endpoint dell'applicazione all'altro" (qualunque cosa significhi).
Test di regressione . Questi sarebbero test eseguiti in passato e ripetuti per garantire che ciò che è stato corretto rimanga fisso e che i bug non vengano reintrodotti nel codice.
Test di usabilità . Questi sarebbero test effettuati per vedere come gli utenti finali possono lavorare con il software per completare varie attività. Dove potrebbe essere automatizzato qualcosa per rendere qualcosa più veloce o regolare l'interfaccia utente in modo che qualcosa sia più facile da usare.
Test di accettazione dell'utente . Questi sarebbero test eseguiti dagli utenti finali in modo che possano vedere in prima persona come funziona qualcosa e concordare che il software soddisfa le esigenze aziendali che lo hanno richiesto in primo luogo.
I test funzionali sono tutti i tipi di test basati sulle specifiche funzionali del software in prova. Questi sono sempre test in scatola nera.
Test delle prestazioni. Questi sarebbero test eseguiti per garantire che un sistema sia in grado di gestire un determinato carico senza rallentare troppo. Ad esempio, testare una nuova web farm di server in grado di gestire 100 utenti colpendo un sito allo stesso tempo sarebbe un esempio di test delle prestazioni. Questi possono anche essere chiamati "test di carico" o "stress test", in quanto l'idea qui è di spingere il sistema al limite o verificare che il sistema sia in grado di gestire alcune proiezioni da un altro reparto. La logica di questi test è che spesso ci sono numerose impostazioni di configurazione da ottimizzare che possono richiedere più di un po 'di lavoro per scoprire i colli di bottiglia e risolvere i problemi con questo. Il collo di bottiglia qui potrebbe essere memoria, I / O, CPU o larghezza di banda di rete che impedisce al sistema di rispondere come previsto.
Test Driven Development è una metodologia che non fa riferimento a un tipo specifico di test ma piuttosto che i test sono scritti prima del codice in modo che i test siano ciò che guida lo sviluppo piuttosto che il comportamento , il dominio o la funzionalità siano alcuni altri esempi in termini di processi.
L'integrazione continua è una pratica di esecuzione periodica di alcuni test come unità, integrazione e test di regressione in modo che se una modifica interrompe un test, questo viene intercettato il prima possibile.