Imparare a investigare sui bug [chiuso]

Ogni difetto del software è in definitiva dovuto a una discrepanza tra le ipotesi e la realtà. Insidiosi bug sono semplicemente discrepanze tra ipotesi e realtà particolarmente radicate. La capacità di diagnosticare bug dipende dalla tua capacità di mettere in discussione i tuoi stessi presupposti, e ciò richiede in effetti la consapevolezza che non conosci alcune cose, le hai appena assunte e usato fino ad ora.

Ovviamente gli strumenti del commercio, file di log, debugger, ecc. sono utili per scoprire tali presupposti e riallineare il tuo modello mondiale con il sistema attuale. Ma finché non sei pronto a mettere in discussione l'assunto cruciale, ad es. "Non può essere un input negativo perché abbiamo un controllo completo degli input", passerai tutto il tuo tempo a controllare le parti sbagliate del sistema, o semplicemente a non sapere dove cercare in primo luogo.

What do I need to do to help my, apparently, limited imagination come up with ways that my project could possibly be broken?

Nella maggior parte dei casi, direi assolutamente nulla. Non dovresti cercare di immaginare cose che potrebbero causare la rottura del programma. Dovresti determinare sistematicamente cosa è causando la sua interruzione.

Dovresti entrare nel processo di debug con le seguenti informazioni:

• i passi che sono stati presi e i valori che sono stati inseriti per produrre il bug;
• che cosa deve fare il programma dovrebbe quando vengono dati quei passi e questi input;
• che cosa sta facendo il programma quando vengono dati quei passaggi e input.

Se c'è un messaggio di errore, prendi tutte le informazioni che puoi su di esso. Se il messaggio di errore non è chiaro e non sai cosa significa in pratica (alcuni messaggi di errore non sono sempre particolarmente utili), quindi utilizza Google, o StackOverflow o qualsiasi altra risorsa online per trovare informazioni su di esso .

Se non è visualizzato un messaggio di errore sul front-end, controllare i registri a cui l'applicazione scrive per i messaggi di errore durante il periodo di tempo in cui è stato riprodotto il bug. Il codice potrebbe essere stato eseguito fino al completamento, ma ha riscontrato un'eccezione che viene gestita nel modo in cui sta eliminando il risultato finale e producendo una voce nei log. Cerca quelli, fai lo stesso sopra e identifica esattamente cosa intendono.

Se ci sono stacktraces forniti con eccezioni lanciate dal tuo codice (e dovrebbe esserci), guarda le linee di codice menzionate. La linea stessa potrebbe non essere quella che sta effettivamente producendo il problema. Se ottieni una NullPointerException in un pezzo di codice Java, lo stacktrace ti dirà dove hai provato a usare qualcosa che era nullo quando ti aspettavi che non lo fosse. Questo non ti indica esattamente la linea che causa il problema, ma generalmente ti dice quale variabile non ha il valore che ti aspetti, così puoi guardare qualsiasi riferimento / assegnazione a quella variabile per determinare che il valore non viene impostato o il valore viene impostato in modo errato.

Se nessuno di questi ha aiutato, fai partire il tuo debugger. Se lo hai ristretto a una sezione del codice che sai causi il problema, ma non sai esattamente quale / i linea / e - allora attraversala. In caso contrario, basta passare attraverso l'intera cosa. Qui è dove devi sapere esattamente cosa il programma dovrebbe fare con gli input dati, perché devi controllare ogni valore dopo ogni riga e determinare esattamente dove si sta deviando da ciò che ti aspetti che faccia.

Ancora non hai idea di quale sia il problema? Chiedi aiuto a qualcuno . Un collega, un amico, una comunità online. Mostra loro tutto ciò che hai appena fatto. Mostra loro i messaggi di errore, gli stacktraces, spiega cosa fa il programma in termini generali (se non lo sanno già), cosa dovrebbe fare in questo istanza particolare (es. restituendo il valore 4), cosa sta facendo in realtà (es. restituendo il valore 5). Se lo hai ristretto a poche righe di codice nel debugger, dì "So che il problema è causato da queste righe nel codice, sta impostando il valore su X quando dovrebbe essere Y, ma non riesco a vedere perché sta succedendo ".

Trascorrere alcune ore a fissare in bianco lo schermo non è sicuramente divertente, ma non c'è motivo per cui dovresti farlo. Se c'è un problema con il tuo codice, devi leggere o passare il codice.

In una certa misura, è come investigare su un caso criminale o su un puzzle da capogiro.

In primo luogo, hai la vittima. Dopo aver scavato un po 'nel caso, hai identificato alcuni sospetti e hai anche sviluppato un'ipotesi di lavoro su come esattamente la vittima potrebbe essere stata uccisa. Continui a indagare, cercando informazioni più utili, avvicinandoti sempre di più alla vera fonte del problema.

Succede che di tanto in tanto entri in un vicolo cieco (gioco di parole). Questo fa parte di ciò, e non c'è niente di sbagliato in questo, fintanto che riesci a riportarti in pista il più rapidamente possibile. La chiave è, per pensare sempre a quale pezzo di informazione hai bisogno in seguito, che fornisca le tue ipotesi (e ti fornisca ulteriori informazioni), o lo provi male. Quindi trova un modo per ottenere quell'informazione in modo efficiente, fai le tue conclusioni e vai avanti, finché non sei finalmente in grado di condannare il colpevole.

E a volte capisci che tutti i fatti e le indicazioni necessari per individuare il colpevole ti stavano già aspettando mezz'ora prima. Anche se noioso, questa è una delle parti più interessanti, perché se fai una revisione critica delle tue azioni e dei tuoi errori, potresti essere in grado di imparare e migliorare . Porsi domande come:

• Come ho potuto evitare questa perdita di tempo?
• Che cosa ho trascurato in primo luogo e perché?
• Quali presupposti non convalidati e / o errati su cui ho fatto affidamento?

Questo allenerà le tue abilità. Svilupperà anche il tuo istinto di intestino , quindi con il tempo imparerai a notare automaticamente tutte quelle cose di minoranza che sono troppo facilmente trascurate, portandoti più velocemente alla risposta giusta. Alla fine, si tratta di pratica deliberata .

Non ultimo, ricorda sempre quello che Sherlock Holmes ci ha insegnato: Quando hai eliminato l'impossibile, qualunque cosa sia, per quanto improbabile, deve essere la verità.

What do I need to do to help my, apparently, limited imagination come up with ways that my project could possibly be broken?

Lascia che la storia sia la tua guida. Se il tuo progetto è ben gestito, dovresti avere un database di ogni bug che sia mai stato risolto nel prodotto insieme a un'analisi di come è stato trovato il bug, come è stato riprodotto, come è stato analizzato e come è stato risolto. Questo non è un database di sola scrittura. Leggi il database e molto presto inizieranno a verificarsi le tassonomie dei bug.

Ciò ti darà una buona panoramica del tipo di cose che non funzionano nel tuo prodotto. Se ti interessa più in generale in ciò che non funziona in tutti i tipi di software, in particolare con l'accento sui difetti che incidono sulla sicurezza, ti suggerisco di leggere l'elenco di CWE: link

Quindi, piuttosto che cercare di riprodurre e correggere un difetto specifico, credo che tu stia chiedendo di pensare a nuovi test che potresti usare per investigare il prodotto per vedere se il prodotto funziona in tali circostanze, ad esempio: cosa succede se entro in speciali caratteri inseriti nella password della nostra pagina di registrazione o cosa succede se richiudo forzatamente il programma mentre sta scrivendo nel database. Questi casi sono davvero difficili da inventare.

Lo sviluppo del software negli ultimi 10 anni (Agile / XP / TDD, ecc.) ha raggiunto il valore soddisfacendo solo i requisiti espliciti e quindi dichiarando la funzionalità completata e non trovando ogni possibile modo di rompere qualcosa (ci sono possibili eccezioni, se stai lavorando per la NASA o stai facendo la sicurezza dei cappelli bianchi, ma anche in questo caso c'è un caso da fare per chiamare queste cose nei criteri di accettazione della user story).

Quindi, se le vostre caratteristiche elencano esplicitamente come criteri di accettazione ciò che i sistemi devono fare come gestire l'input, le sue caratteristiche di performance, le azioni del flusso di lavoro dell'utente, ecc. allora avete un elenco completo di ciò che i test devono essere controllati. I test dovrebbero essere eseguiti per verificare che i requisiti siano stati soddisfatti e il modo migliore per farlo è elencare esplicitamente tutti i requisiti. Dai un'occhiata ai Agile Test Quadrants .

Alcune persone sostengono che questi test siano la dichiarazione esplicita dei requisiti, che devono essere scritti prima del codice, cioè Test First (o Test Driven Development).

Tuttavia apprezzo il fatto che non sembri che stai pensando a un nuovo progetto in cui puoi impostare le tue migliori pratiche di sviluppo prima di iniziare e sono invece in arrivo dopo che il software è stato scritto e viene chiesto di 'testarlo' . Questo è davvero più impegnativo, ma si applicano gli stessi principi, è possibile testarlo solo una volta che si sa cosa avrebbe dovuto fare. Se non c'è un elenco completo dei requisiti che il team di sviluppo ha incontrato per farti lavorare, allora il porre le domande è la soluzione migliore. A seconda del team, potrebbe essere necessario farlo con delicatezza, poiché le persone che non hanno elencato esplicitamente i loro requisiti prima di creare un sistema software non amano essere ricordati di ciò che hanno perso, ma è essenziale per svolgere bene questo compito.

Una volta trovato un requisito - deve essere robusto / deve essere sicuro, quindi provare a scavare più a fondo e scoprire quanto deve essere sicuro, o quanto fallimento è accettabile, c'è sempre un limite, non molte persone hanno un livello di sicurezza della NSA come requisito per la loro applicazione o vorrebbe pagare per questo. Più si scava il più chiaro dovrebbe essere su quali tipi di attacchi di sicurezza è necessario difendersi o facile da usare che si sta mirando. Alcune conoscenze di dominio sono quindi utili, in sicurezza, nella progettazione, nelle prestazioni, ecc., Che è dove poni ancora più domande agli esperti che puoi trovare nella tua squadra, o qui su SE, o su Google / libri.