Imparare a indagare sui bug [chiuso]

Non sono nemmeno sicuro di come definire questa difficoltà. Mi ricorda il test che un paio di potenziali impiegati mi hanno fatto prima di trovare un lavoro. Avrebbero scelto un oggetto nella stanza e poi mi sarebbe stato permesso di porre domande per aiutarmi a determinare quale fosse quell'oggetto (proprio come 20 domande). Sono stato ridicolmente bravo in questo (no, non ho mai ottenuto punti alti per l'umiltà), quindi ho pensato che sarei davvero bravo a risolvere i bug ...

Ma ecco la cosa che ho capito di recente. Sono davvero bravo in quella situazione perché è davvero facile vedere tutto ciò che è nella stanza, quindi posso affrontare il mio problema con un concetto dei suoi componenti. In sostanza "so cosa non so". Ma con la programmazione mi imbatto in molte situazioni in cui il problema è completamente sconosciuto per me. So che è rotto, ma non ho idea di come potrebbe essere rotto. Ho seguito tutte le istruzioni, conosco abbastanza bene la tecnologia ...

Se sono onesto, mi sento come se stessi facendo fatica a immaginare cose che potrebbero essere sbagliate in modo da poterle testare e, si spera, trovare una soluzione.

Come posso sviluppare questa abilità? Cosa devo fare per aiutare la mia, apparentemente, immaginazione limitata a trovare modi in cui il mio progetto potrebbe essere rotto? Ci sono esercizi (forse puzzle?) Che possono rendermi migliore in questo? Sono consapevole che probabilmente la cura più grande è solo l'esperienza ... ma spero di aiutare ad accelerare il processo se posso. Fissare lo schermo del mio computer in bianco per alcune ore alla volta non è nemmeno divertente ...

Ogni difetto nel software è in definitiva dovuto a una discrepanza tra ipotesi e realtà. Insetti insidiosi sono semplicemente discrepanze tra ipotesi particolarmente radicate e realtà. La capacità di diagnosticare i bug dipende dalla tua capacità di mettere in discussione le tue assunzioni, e ciò richiede effettivamente la consapevolezza di non conoscere certe cose, le hai appena assunte e fino ad ora erano corrette.

Ovviamente gli strumenti del commercio, i file di registro, i debugger ecc. Sono utili per scoprire tali ipotesi e riallineare il tuo modello mondiale con il sistema reale. Ma fino a quando non sarai pronto a mettere in discussione l'assunto cruciale, ad es. "Non può essere un input errato perché abbiamo un controllo di input completo", trascorrerai tutto il tuo tempo a controllare le parti sbagliate del sistema o semplicemente non sapendo dove altro cercare. innanzitutto.

Cosa devo fare per aiutare la mia, apparentemente, immaginazione limitata a trovare modi in cui il mio progetto potrebbe essere rotto?

Nella maggior parte dei casi, non direi assolutamente nulla. Non dovresti cercare di inventare cose che potrebbero causare l'interruzione del programma. Dovresti determinare sistematicamente ciò che sta causando la sua rottura.

Dovresti andare nel processo di debug con le seguenti informazioni:

• i passaggi che sono stati effettuati e i valori immessi per produrre il bug;
• cosa dovrebbe fare il programma quando viene dato quei passaggi e input;
• cosa sta facendo il programma quando vengono dati questi passaggi e input.

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

Se non è visualizzato un messaggio di errore sul front-end, controllare i log in cui l'applicazione scrive 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 si è verificata un'eccezione che viene gestita lungo il percorso che sta eliminando il risultato finale e producendo una voce nei registri. Cerca quelli, fai lo stesso sopra e identifica esattamente cosa significano.

Se ci sono stacktraces forniti con eccezioni generate dal tuo codice (e dovrebbero esserci), guarda le righe 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. Ciò non indica esattamente la linea che causa il problema, ma in genere ti dice quale variabile non ha il valore che ti aspetti, quindi puoi guardare qualsiasi riferimento / assegnazione a quella variabile per determinare che il valore non viene impostato o che il valore non è impostato correttamente.

Se nulla di tutto ciò ha aiutato, avvia il tuo debugger. Se l'hai ridotto a una sezione del codice che sai che sta causando il problema, ma non sai esattamente quale linea (e) - passa attraverso quello. In caso contrario, basta passare attraverso l'intera cosa. Qui è dove devi sapere esattamente cosa dovrebbe fare il programma con determinati input, perché devi guardare ogni valore dopo ogni riga e determinare esattamente dove si sta deviando da ciò che ti aspetti che faccia.

Non hai ancora idea di quale sia il problema? Chiedi aiuto a qualcuno . Un collega, un amico, una comunità online. Mostra loro tutto quel lavoro che hai appena fatto. Mostra loro i messaggi di errore, gli stacktrace, spiega cosa fa il programma in termini generali (se non lo sanno già), cosa dovrebbe fare in questo caso particolare (es. Restituendo il valore 4), cosa sta realmente facendo (es. restituendo il valore 5). Se l'hai ridotto 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 qualche ora a guardare in bianco lo schermo non è sicuramente divertente, ma non c'è motivo per cui dovresti farlo. Se si verifica un problema con il codice, è necessario leggere o scorrere il codice.

In una certa misura, è come indagare su un procedimento penale o un puzzle da capogiro.

Innanzitutto, hai la vittima. Dopo aver approfondito un po 'il 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.

Capita di tanto in tanto di entrare in un vicolo cieco (gioco di parole previsto). Fa parte di esso, e non c'è nulla di sbagliato in esso, a condizione che riesci a rimetterti in carreggiata il più rapidamente possibile. La chiave è, per pensare sempre a quale informazione necessiti dopo, che fornisce la tua ipotesi (e ti fornisce ulteriori informazioni), o dimostra che è sbagliata. Quindi trova un modo per ottenere tali informazioni in modo efficiente, trarre le tue conclusioni e andare avanti, fino a quando non sarai finalmente in grado di condannare i colpevoli.

E a volte ti rendi conto che tutti i fatti e le indicazioni necessari per individuare il colpevole stavano già aspettando davanti a te mezz'ora fa. Anche se fastidioso, è tra le parti più interessanti, perché se fai una revisione critica delle tue azioni ed errori, potresti essere in grado di imparare e migliorare . Ponetevi domande come:

• Come avrei potuto evitare questa perdita di tempo?
• Cosa ho trascurato in primo luogo, e perché?
• Su quali ipotesi non convalidate e / o sbagliate ho fatto affidamento?

Questo allenerà le tue abilità. Svilupperà anche il tuo istinto , quindi col tempo impari a notare automaticamente tutte quelle cose minori che sono troppo facilmente trascurate, conducendoti più rapidamente alla risposta giusta. Alla fine, si tratta di pratica deliberata .

Infine, non ultimo, ricorda sempre cosa ci ha insegnato Sherlock Holmes: quando hai eliminato l'impossibile, tutto ciò che rimane, per quanto improbabile, deve essere la verità.

Cosa devo fare per aiutare la mia, apparentemente, immaginazione limitata a trovare modi in cui il mio progetto potrebbe essere rotto?

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 corretto nel prodotto insieme a un'analisi di come il bug è stato trovato, 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 tassonomie di bug.

Questo ti darà una buona panoramica delle cose che vanno male nel tuo prodotto. Se sei interessato più in generale a ciò che non va in tutti i tipi di software, in particolare con un'enfasi sui difetti che incidono sulla sicurezza, ti suggerisco di leggere l'elenco CWE: http://cwe.mitre.org/data/index.html

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 indagare sul prodotto per vedere se il prodotto funziona in quelle circostanze, ad esempio: cosa succede se inserisco caratteri speciali nel nostro iscriviti alla password della pagina archiviata o cosa succede se chiudo con forza il programma mentre sta scrivendo sul database. Questi casi sono davvero difficili da pensare.

Lo sviluppo del software negli ultimi 10 anni (Agile / XP / TDD ecc.) Ha raggiunto il valore soddisfacendo solo i requisiti espliciti e dichiarando quindi la funzionalità terminata e non trovando tutti i modi possibili per interrompere qualcosa (ci sono possibili eccezioni, se lo sei lavorare per la NASA o fare la sicurezza del cappello bianco, ma anche in questo caso è necessario creare tali elementi nei criteri di accettazione della user story).

Quindi, se le tue funzionalità elencano esplicitamente come criteri di accettazione ciò di cui i sistemi hanno bisogno, ad esempio come gestire l'input, le caratteristiche delle prestazioni, le azioni del flusso di lavoro dell'utente, ecc., Hai un elenco completo di ciò che i test devono verificare. 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 quadranti dei test Agile .

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

Tuttavia apprezzo il fatto che non sembri che stai contemplando un nuovo progetto in cui puoi impostare le tue best practice di sviluppo prima di iniziare e invece arrivano dopo che il software è stato scritto e viene chiesto di "testarlo". Questo è davvero più impegnativo ma si applicano gli stessi principi, puoi testarlo solo dopo aver saputo cosa doveva fare. Se non esiste un elenco completo di requisiti che il team di sviluppo ha soddisfatto per farti lavorare da allora, porre le domande è la soluzione migliore. A seconda del team, potrebbe essere necessario eseguire questa operazione delicatamente poiché le persone che non hanno elencato esplicitamente le proprie esigenze prima di creare un sistema software non amano ricordare ciò che hanno perso, ma è essenziale eseguire bene questo compito.

Una volta trovato un requisito - deve essere solido / deve essere sicuro, quindi provare a scavare più a fondo e scoprire quanto deve essere sicuro o quanti guasti sono accettabili, c'è sempre un limite, non molte persone hanno una prova NSA livello di sicurezza come requisito per la loro applicazione o vorrebbe pagare per quello. Più scavi, più chiaro dovrebbe essere su quali tipi di attacchi alla sicurezza devi difendere o di facile utilizzo a cui stai mirando. Alcune conoscenze di dominio sono quindi utili, in termini di sicurezza, design, prestazioni ecc., Dove è possibile porre ancora più domande agli esperti che è possibile trovare nel proprio team, oppure qui su SE o su google / books.