Come approccio alla correzione di un bug non riproducibile / che si verifica casualmente?

Il primo passo è provare e caratterizzare ciò che può causare questo tipo di problema. Poiché questo è legato alla selezione della lingua corretta per le sezioni del codice, iniziare considerando quanto segue:

• In che modo viene rilevata la lingua? Si basa sulle informazioni della richiesta HTTP? Si basa sulle informazioni di sessione? O si basa sui campi del database? In sostanza, può essere un problema legato al modo in cui l'app seleziona la lingua per ciascuna sezione?
• Come viene visualizzata la lingua? Stai prelevando da un file di proprietà o da un database? È possibile che il riferimento alla lingua corretta si perda un po 'come? Il linguaggio misto è sempre predefinito per il sito?
• Esiste una correlazione con l'ambiente client? Questo è correlato al primo punto, ma va un po 'oltre. Ho avuto strani problemi di rendering a causa di proxy di cache in downstream. In genere questi tipi di problemi sono un'intera pagina che è obsoleta o che serve la pagina di una persona ad altri utenti (il che era imbarazzante).
• Stai utilizzando un valore Locale di Thread? Se una richiesta viene gestita da più di un thread, il valore locale del thread avrà informazioni diverse in base al thread che sta funzionando al momento. In un ambiente di server Web, non è possibile presumere che il thread su cui è stata avviata l'elaborazione sia lo stesso thread su cui è stata completata l'elaborazione, a meno che non faccia parte delle specifiche per la piattaforma. I produttori di server hanno scoperto che se riutilizzano un piccolo pool di thread e multiplex lavorano su blocchi, possono gestire più richieste contemporaneamente. Anche se si dispone di un thread dall'inizio alla fine di una richiesta, il server può eseguire il multiplexing di altre richieste su quel thread nello stesso momento. Invece dei locali dei thread, prendi in considerazione la possibilità di legare quel valore agli attributi della sessione o della richiesta.

Ora, una volta che hai caratterizzato le possibilità di ciò che può andare storto, è il momento di assicurarti di avere i dati necessari per provare e scoprire cosa ha sbagliare.

• Utilizzare la registrazione profusa per le aree problematiche. Questo è un posto dove uno strumento come Log4J o Log4Net può davvero brillare. Quel framework di registrazione, e altri simili, ti permettono di aumentare la registrazione per certe categorie, mantenendo il rumore per tutto il resto, tutto cambiando un file di configurazione. Si desidera introdurre nuove dichiarazioni di registrazione per capire se ciò che si sospetta possa essere il problema. Assicurati inoltre che i log di accesso HTTP contengano tutte le informazioni che desideri su ogni richiesta (cookie, parametri dell'intestazione http, ecc.)
• Tentativo di simulare il problema. Dal momento che ciò accade sporadicamente, qual è il carico del server nel momento in cui si verifica? Sei colpito da un numero di richieste simultanee da un mix di lingue? In tal caso, provare a simulare quel tipo di carico nell'ambiente di test. Uno strumento simile a JMeter potrebbe essere quello che ti serve. Dovrai anche essere in grado di falsificare gli indirizzi IP per i tuoi falsi clienti. Ricorda che gli indirizzi IP sono suddivisi in porzioni in modo da poter capire quale paese / regione l'IP è basato sui primi due segmenti dell'indirizzo.
• Il problema sarà altrettanto sporadico nel tuo ambiente di test, ma quando ti restringerai nella tua vera causa, puoi distorcere i risultati per far sì che succeda più spesso di quanto non faccia in natura. Inoltre, puoi rivedere più facilmente i file di registro e provare a imparare da loro.
• È un processo iterativo, quindi sii paziente. Devi indurre il tipo di carico che pensi riprodurrà il bug, controllare i log e perfezionare i test in base a ciò che trovi. L'importante è identificare il problema , quindi resisti all'impulso di fare alcune semplici correzioni che potrebbero solo far accadere il vero problema meno spesso.

Infine, una volta ridotto il problema al punto in cui sai come riprodurlo e a cosa lo causa, scrivi il test automatico più piccolo che puoi per forzare il problema nel codice. Se hai ridotto il problema a una classe, o se una coppia di classi non funziona correttamente, riproducila a quel livello. Non dovresti generare 100 thread per farlo, basta fare il test più piccolo che può causare il problema per il 100% delle volte.

Ora puoi sistemarlo ed essere ragionevolmente sicuro che non tornerà più a morderti.

Il bug non è irreprodabile. Non hai ancora trovato il modo di riprodurlo ancora.

Nessun bug è casuale a meno che tu non stia generando un'eccezione basata sul valore di ritorno di qualche istruzione Random ().

So che potrebbe sembrare una semantica, ma è rassicurante mentalmente dirlo a te stesso.

È molto difficile e frustrante scoprire come riprodurre un errore che si verifica solo a causa di condizioni di gara complesse o simili.

Per sapere come trovarlo, accendo / aggiungo alcune registrazioni all'applicazione in luoghi che potrebbero darti maggiori informazioni.

Dì di seguito alle persone che stanno vedendo il bug (indipendentemente dal fatto che siano Devs, QA, utenti finali) da segnalare non appena lo vedono con l'ora in cui è successo e quindi consultano i tuoi registri. Chiedete loro altre informazioni e il bug può accadere solo a causa dell'interazione di diversi sistemi o a causa di una condizione di competizione

Spero che sarai in grado di trovare un vantaggio.

Puoi provare a trovare posti nel tuo codice dove puoi riconoscere che il problema si è verificato (parametri inconsistenti in un metodo per esempio), aggiungere i controlli al tuo codice e lasciare che aggiungano informazioni extra al log di debug (come una pila traccia, oggetti aggiunti alla sessione, ecc.)

Facendo questo con un po 'di fortuna puoi acquisire informazioni sulle occorrenze e dedurre la tua strada verso il problema.

L'automazione dovrebbe aiutare, se è la stessa procedura da riprodurre che a volte fallisce, automatizzarla e inserirla in un ciclo. Esegui in 50.000 volte ed è molto probabile che si verifichi.

prova a trovare schemi per definire le condizioni che causano la manifestazione di questo problema. Questo dovrebbe indirizzarti verso le sezioni del tuo codice che falliscono (o si comportano in modo incoerente).

Riesci a rilevare quando si verifica il problema ? In tal caso, è possibile scaricare in modo affidabile le informazioni sullo stato del sistema in quel punto?

Se la risposta a entrambe queste domande è sì, imponi al tuo codice di accedere a quante più informazioni possibile quando si verifica effettivamente l'errore, quindi attendi.

Questo non è un sostituto di quello che altri hanno suggerito (devi ancora ragionare su come il codice può entrare nello stato che stai vedendo), ma finché non riesci a riprodurre il bug a piacimento, è una buona idea non sprecare le occasioni in cui appare.