Come isolare i bug difficili da riprodurre? [duplicare]

• Registrazione. Aggiungi un po 'di logging al modulo correlato, impostalo su debug e fai in modo che l'utente ti invii una copia del log quando l'errore si ripresenta.
• Se riesci a riprodurre l'errore, imposta il tuo registratore per andare alla console e prova a riprodurlo. Cerca le anomalie che si verificano solo quando il colore è sbagliato.
• Back track. Trova tutti i riferimenti trovare qualsiasi riga di codice che potrebbe causare questo problema. Quindi pensa se il codice sta facendo ciò che dovrebbe. Non credere che il tuo codice funzioni come credi. Sfida te stesso - "questa variabile dovrebbe essere impostata su x" ora prova che lo è. Imposta un punto di interruzione condizionale. O una linea di stampa. O un registro.
• Prendi un amico. Fai un paio di programmi, un altro paio di occhi può aiutarti.
• Google il frame funziona, chiedi su SO, guarda se altre persone hanno avuto un problema simile. Forse non è un bug nel framework, ma una trappola a cui la gente occasionalmente cade.
• Dipende dal framework, ma in WPF dovresti visualizzare l'output e cercare gli errori di binding.
• Dai un'occhiata ai tuoi clienti. Verifica se stanno utilizzando il programma in un modo diverso rispetto al modo in cui esegui il test. Forse possono riprodurlo ma non stanno documentando i loro passi. Forse stai assumendo un flusso di utilizzo diverso da quello che il client sta effettivamente facendo.
• Prendi appunti accurati, o ancora meglio esegui una programmazione di registrazione dello schermo. Una volta che il bug si verifica, riavvia l'app e segui esattamente ciò che hai fatto prima. se riesci a riprodurlo, sei a metà strada.

Tracciare problemi come questi sono una grande opportunità per applicare le asserzioni. Un'asserzione è semplicemente un controllo su alcune condizioni booleane: "l'insieme dovrebbe essere non vuoto quando viene chiamato pop ". Molti linguaggi di programmazione forniscono supporto diretto alle asserzioni: quando abilitato, le asserzioni annullano il programma o sollevano eccezioni quando falliscono; quando disabilitato, le asserzioni non sono altro che commenti di fantasia.

Questo richiederà un po 'di scavo e reingegnerizzazione da parte tua. Dovrai sparpagliare le parti rilevanti delle asserzioni del programma che ritieni vere. Potresti essere sorpreso nel vedere che alcune condizioni stanno fallendo, quando hai pensato che fosse vero. Quando un programma fa qualcosa del genere, introduce una infezione [nel senso di Andreas Zeller], che potrebbe quindi portare a ulteriori infezioni, che potrebbero infine manifestarsi come difetti [bug].

Per ulteriori suggerimenti, leggi le note di lezione di Zeller dal suo bel libro, Perché i programmi falliscono: link

Ed ecco un link alla sua discussione delle asserzioni .

Infine, dato che il tuo client lo incontra regolarmente, questo primo punto di partenza è con loro! Buona fortuna!

Usa un debugger di memoria come valgrind, o un allocatore di memoria di debug come Electric Fence, o su Mac OS X o l'iPhone Simulator (ma purtroppo non i veri dispositivi iOS), Guard Malloc.

Che linguaggio di programmazione stai usando? Se tu mi dicessi, forse potrei offrire un consiglio più utile.

Dicendoci che la piattaforma potrebbe essere d'aiuto. Ad esempio, i framework Apple per Mac OS X e iOS scrivono sulla console. Il client può utilizzare l'utilità di configurazione iPhone per acquisire i registri della console. Se stai chiamando erroneamente una delle API di Apple, è possibile che il tuo errore sia registrato.

Se la tua lingua è C o Objective-C, puoi usare l'analizzatore di codice sorgente statico CLANG. Ora è incorporato in Xcode e funzionerà su altre piattaforme come strumento da riga di comando, se lo crei dal sorgente.

Aumentare artificialmente il carico non è una cattiva idea, soprattutto perché se c'è un bug aumenterà le probabilità che appaia, ma poi devi assicurarti di registrare lo stato del programma costantemente per capire dove è andato storto.