Metodologia per determinare la causa dell'errore specifico dell'utente

Question

Metodologia per determinare la causa dell'errore specifico dell'utente

#1 da (3 voti)
#2 da (1 voti)

3

Abbiamo software che per alcuni client non riesce a scaricare un file. Il software è sviluppato in Python e compilato in un eseguibile di Windows. La causa dell'errore è ancora sconosciuta, ma abbiamo stabilito che il client ha una connessione Internet attiva. Sospettiamo che la causa sia dovuta all'impostazione della rete dei client. Questo errore non può essere replicato in house.

Quale tecnica o metodologia dovrebbe essere applicata a questo tipo di errore specifico che non può essere replicato in casa. L'obiettivo finale è determinare la causa di questo errore in modo che possiamo passare alla soluzione.

Ad esempio;

Debug remoto: produrre una versione di debug del software e chiedere al client di inviare un file di output di debug. Ciò comporta un sacco di tempo (comunicazione avanti e indietro) e richiede al cliente di lavorare e agire in un maniero tempestivo per avere successo.
Debug interno: visitare il client e determinare la configurazione di rete, ecc. Possibilmente sviluppare una serie di test di script prima di eseguire il client sul computer client nella stessa rete.
Altre metodologie e tecniche di cui non sono a conoscenza?

debugging errors methodology

posta user3163629 28.05.2014 - 07:10

fonte

2 risposte

Leggi altre domande sui tag debugging errors methodology

Operatività ripetuta con eccezione generica Open-sourcing di una libreria proprietaria senza determinate caratteristiche

score 3 · Answer 1

Remote Debugging: Produce a debug version of the software and ask the client to send back a debug output file. This involves alot of time (back and forth communication) and requires the client to work and act in a timely manor to be successful.

L'idea generale qui è corretta, ma ci sono due cose da migliorare in questo.

Per prima cosa, non dovresti produrre una speciale "versione di debug" del tuo software - il tuo client dovrebbe essere in grado di eseguire la tua ultima versione dell'applicazione in una modalità di registrazione, senza la necessità di reinstallare la cosa - la funzione di registrazione dovrebbe essere sempre disponibile per lui se necessario.

In secondo luogo, è necessario migliorare i meccanismi di registrazione nel software, in modo da ridurre al minimo lo sforzo di comunicazione per il cliente. Quindi, anziché "aggiungi un po 'di logging qui, invia al client una versione diversa del tuo software, ti invia un log back, analizzi i log e cambia il software di nuovo", il ciclo dovrebbe essere "quando si verifica il problema , il client ti invia il log di base che viene sempre attivato e, se ciò non è sufficiente, attiva una registrazione estesa, ottieni un enorme file di registro che contiene ogni e qualsiasi cosa che potrebbe essere la causa del problema, e quindi hai abbastanza informazioni per riprodurre il problema o individuare la causa ". Naturalmente, in pratica potresti aver bisogno di più di un ciclo quando inizi con questo, ma l'obiettivo dovrebbe essere quello di portarlo a "uno".

C'è anche un buon strumento incluso in Windows da quando Win-7 registra ciò che l'utente fa davanti al client - il registratore di passi problematici (psr.exe). Vedi qui per ulteriori dettagli. Questo probabilmente non ti aiuterà molto se una configurazione del server è la vera causa del problema, ma forse è utile capire meglio cosa è successo sul sito del cliente, senza la necessità di visitare fisicamente il client.

score 1 · Answer 2

Debug remoto.

D'accordo, questo richiede molto tempo. Ma non aspettarti di trovare magicamente tale errore in un breve lasso di tempo senza alcuno sforzo.

D'accordo, ciò implica implicazioni da parte del cliente. Ma se il cliente non è interessato a risolvere il problema, ci sono possibilità che rimanga irrisolto.
Registrazione estensivamente dettagliata

Se disponi di un meccanismo che consente aggiornamenti frequenti, trasparenti per l'utente finale (proprio come fa Chrome), puoi spesso trasferire le modifiche con un numero sempre maggiore di registrazioni e individuare il problema in questo modo. Ciò comporta anche la possibilità di riavere i registri.

A seconda del prodotto, puoi forzarlo a scaricare un file (ad esempio, eseguire l'operazione problematica) quando l'applicazione viene caricata e a segnalare il risultato.
Debug sul sito (≠ debug interno).

Questo potrebbe essere il più difficile, ma potrebbe essere rilevante per alcune aziende. Invia uno dei tuoi sviluppatori al cliente per studiare il problema. Se gli viene concesso un accesso amministrativo alla macchina problematica, la risoluzione del problema potrebbe essere semplice e abbastanza breve, analogamente a se il problema è stato riprodotto internamente.