Recentemente ho implementato il test fuzz su uno dei miei progetti. Sono emersi diversi bug, generalmente classificabili come bug di validazione degli input (oserei dire banali?) E li ho sistemati. In nessun caso finora le rotture hanno coinvolto la logica di business, che immagino sia ragionevole.
La mia domanda è la seguente: Quando ottengo una nuova richiesta di funzionalità per il progetto, di solito scrivo un test automatico per descrivere il comportamento desiderato (usando Lattuga , ad esempio). I bug del test fuzz appartengono a queste descrizioni del comportamento?
Io stesso ho determinato che il vantaggio di scrivere casi di test espliciti è verificare in modo deterministico contro regressioni. Il test fuzz tende a non essere deterministico, sebbene nel nostro caso i nostri test non abbiano un intero un sacco di casualità sorprendente in loro.
Allo stesso tempo, ne ho scritti alcuni e confrontati con altri test che descrivono sequenze di comando e risultati interessanti, i bug di sicurezza sono noiosi, al punto da creare rumore per il lettore. Considera la seguente forma di test:
Scenario: Some jerk user doesn't fill in the "home address" form field.
Given an otherwise correctly-filled form on my web page
And a "number of hats" field filled with string "banana"
When the user submits the form
The application should not crash
And the user should be redirected back to the form
And the form should display an error
[repeat for each of 10 fields that could have ridiculous input]
Devo lasciare questo tipo di controllo per il fuzzer che li sta già catturando attraverso incantesimi neri e opportunità casuali? O i miei test di regressione dovrebbero riflettere ogni errore che abbia mai fatto o pensato di fare?