Estrategias de búsqueda de errores?

Question

Digamos que tiene un error que se encontró en las pruebas funcionales de una parte bastante compleja del software. Podría deberse a datos incorrectos/inesperados en la base de datos, código de nivel medio o algo en el front-end.

Bien. Todos hemos estado allí.

Tienes pruebas de unidad para escribir & de ejecución, depuración declaraciones/de registro para insertar, sentencias SQL para escribir & plazo, las cosas que desea comprobar con FireBug, etc.

Digamos que el primer paso es llegar a una lista de posibles causas que desea investigar.

Ahora usted tiene que decidir qué orden para hacer las cosas de

¿Te:.

1. investigar las causas en un orden basado en la sensación de la tripa?
2. ¿Investigar las causas en orden desde la más rápida hasta la más lenta?
3. Supongamos que el error es específico de esta función e investigamos desde el código más específico de la función hasta el código específico de la característica mínima.
4. ¿Asume que es culpa de otra persona, e investiga desde el código más general hasta tu código específico?
5. ¿Algo más que no he mencionado?

Tengo la sensación de que la primera estrategia es la más utilizada. Tal vez solo porque no trabajo con muchos desarrolladores junior, y los desarrolladores más experimentados tienden a tener una buena intuición. O tal vez solo pensamos que tenemos una intuición decente, pero en realidad deberíamos usar un enfoque más sistemático.

¿Alguna idea?

Answer 1

Encuentro que la estrategia Rubber Duck Debugging también funciona bien.

Answer 2

Yo diría que no importa, siempre y cuando sea documentado y metódico. Es una pequeña perogrullada extraña en la programación que a veces hacer las cosas en orden aleatorio es más eficiente que pasar mucho tiempo tratando de descubrir la "mejor" manera.

Nunca subestimes la sensación de tripa; esa es la experiencia que te da un aviso. Casi siempre empiezo con lo que probablemente consideres que es mi sensación "instintiva". Miro el error y verifico los pasos que creo que pueden causar ese tipo de problema.

Answer 3

Mi primer paso en una situación como esa suele ser comprobar las cosas en el orden en que se reducirá más rápidamente el número de cosas que quedan por verificar. Casi podría pensar en ello como hacer una búsqueda binaria del error: "Bueno, los parámetros POST se ven bien, así que puedo descartar todo antes del envío del formulario", etc.

Dicho esto, si tengo un fuerte Sintiendo que el problema podría estar en un lugar en particular, lo verificaré primero.

Answer 4

Tiendo a ir con la sensación visceral, y un enfoque de dividir y vencer; aislando trozos de código de tamaño decreciente donde creo que es "el error".

Esto no funciona si no sabes o no entiendes la base de código, si ese es el caso, busca a alguien que sí lo haga y ve con sus entrañas.

Answer 5

Primero trato de entender el error, luego hago todo lo que sugiere, en orden basado en la intuición. Esto es realmente una compensación de la certeza que tiene de una causa específica y de lo fácil que es probarla.

Además, cuando investigo una causa intento agregar directamente los cheques muy rápidas ya que estoy revisando el código de todos modos (añadir algunas declaraciones de salida de depuración temporales, añadir afirma y tal)

Answer 6

En mi experiencia, probablemente sea mejor ir con la sensación visceral (1) durante 30 minutos más o menos.

Si nada sale de eso, hable con otra persona al respecto.

Es bastante sorprendente cómo hablar con alguien más (incluso si no son técnicos), puede ayudar.

Answer 7

Mi pedido:

1. mirar el código de 1-2 causas más probables (elegidos en base a primera impresión).
2. Si no encuentra nada, ejecute el código en el depurador (o si no es posible, inserte las instrucciones de depuración/registro en el código).
3. Si no se encuentra nada, llame a otra persona y repita los pasos 1 y 2 junto con él/ella.

Answer 8

1. Reproducir el error en un entorno de depuración.
2. Examine el estado del sistema en el punto en que se produce el error para encontrar los elementos de estado inconsistentes/incorrectos/inesperados que, de forma directa, conducen visiblemente a la aparición del error. A menudo, solo mirando el código y la pila de llamadas de inmediato te dirán cuál es el problema.
3. Agregue pruebas a todos los puntos donde este estado se puede crear/mutar dentro del flujo de control normal.
4. Al tratar las fallas de estas pruebas como un nuevo error, regrese al paso dos.

Enjuague, haga espuma, repita hasta que se encuentre la causa inicial del problema. Tedioso y mecánico, pero te llevará allí.

Excepto ... ocasionalmente las pruebas en una iteración del paso 3 no fallan; más comúnmente, debido a que algún sistema no relacionado corrompe la memoria es lo que conduce al estado inválido, o porque el problema depende de enhebrar/cronometrar/datos no inicializados e introducir las pruebas altera los tiempos o el diseño de los datos lo suficiente como para alterar u ocultar los síntomas. En este punto, al menos para este póster, el proceso se vuelve más intuitivo, alternando entre reemplazar las pruebas de cordura con formas menos intrusivas y deshabilitar selectivamente los módulos para descartar las fuentes de corrupción.

Answer 9

Aquí hay algunos consejos útiles:

• Si utiliza un lenguaje que tiene genera un seguimiento de pila de excepciones comienzan a partir de ahí.
• Obtenga una copia de los datos originales que causaron el problema si es posible.
• Utilice un buen depurador.
• Si usted tiene acceso a uno hay cosas como el ODB para varios lenguajes que pueden ser útiles por lo que le permite adelantar o retroceder rápidamente a través de la ejecución después de que el evento se produce
• Excluir lo imposible y se le dejó con la ¡solución!

Answer 10

escuchar cómo el software de depuración expertos en la radio Ingeniería de Software:

Dave Thomas habla de software archaeology que tiene algunos muy buenos consejos sobre la depuración.

Andreas Zeller aparece en un episode dedicada a la depuración.

Answer 11

En general, comienzo con un subconjunto de hipótesis que considero los culpables más probables y luego clasifico ese subconjunto de hipótesis por lo fácil que es refutar cada una, y empiezo por la más fácil.

Independientemente del orden, lo importante es lo que haces con tu hipótesis. empezar a tratar de refutar cada hipótesis en lugar de a verificarla y podrás cubrir más terreno (ver Psychology of Intelligence Analysis por Richards J. Heuer, Jr., PDF gratuito).

Answer 12

estoy con @moonshadow, pero voy a añadir que en cierta medida depende de lo que es el fracaso. Es decir, algunos tipos de fallas tienen causas bastante conocidas, y yo comenzaría con la causa conocida

Por ejemplo, en los sistemas Windows, los errores de "Violación de acceso" casi siempre se deben al intento de usar o mirar (acceso) memoria no asignada. Para encontrar la fuente de tal error, es una buena idea mirar todos los lugares donde la memoria está (o no) asignada.

Si se sabe que el "problema" se debe a los malos datos, entonces la solución puede requerir cambios en la validación de datos o adquisición, incluso una vez que el error se remonta a análisis.

Un punto más, mientras que el pensamiento a través del fallo es a menudo vale la pena el esfuerzo para tratar de crear un pequeño programa para la creación de la misma.

Answer 13

hago normalmente esto:

1) Añadir un nuevo caso de prueba funcional (s) al sistema de ensayo de regresión automatizado. normalmente comienzo un proyecto de software con un sistema de pruebas de regresión propia con

• biblioteca de Excel VBA + C para controlar SCSI/IDE/interfaz de dispositivo (hace 13 años), Informe de la prueba es speadsheet Excel.
• TCL Expectativas para pruebas complejas del sistema de enrutadores de red. El informe de prueba es página web. (Hace 6 años)
• Hoy uso Python/Expect. El informe de prueba es XML + analizador XML basado en python.

Este objetivo para todo esto es asegurarse de que una vez que se encuentra un error, nunca vuelva a aparecer en el código de registro o en el sistema de producción. También es más fácil reproducir los problemas aleatorios y de largo plazo.

No marque en ningún código a menos que vaya una prueba de regresión automatizada.

Normalmente escribo una relación de 1: 1 entre el código de producto vs.código de prueba. 20k líneas de TCL expert para 20K líneas de código C++. (Hace 5 años). Por ejemplo:

• El código C implementaría un proxy de reenvío de conexión tcp de túnel de instalación.
• Casos de prueba de TCL: (a) Configure las conexiones para asegurarse de que los datos pasen. (b) Configure las conexiones con diferentes elementos de red. (c) Haga eso 10, 100, 1000 veces y verifique si hay pérdida de memoria y problemas de recursos del sistema, etc.
• Haga esto para cada función en el sistema, se puede ver por qué la ración 1: 1 en el programa de prueba codifica.

No quiero que el equipo de QA haga una prueba automática con mi sistema de prueba, ya que todo mi código de registro debe pasar las pruebas. Por lo general, realizo una prueba de regresión de 2 semanas a largo plazo antes de dar el código al equipo de control de calidad.

Los casos de prueba manual del equipo QA running también aseguran que mi programa tenga suficiente información de diagnóstico incorporada para capturar cualquier error futuro. El objetivo es tener suficiente información de diagnóstico para resolver el 95% de los errores en < 2 horas. Pude hacer eso en mi último proyecto. (Equipo de red de video en RBG Networks.)

2) Agregue la rutina de diagnóstico (base web hoy en día) para obtener toda la información interna. (Estado actual, Registros, etc.). > 50% de mi código (c/C++, especialmente) son códigos de diagnóstico.

3) Agregue más detalles al registro del área de problemas que no entiendo.

4) Analice la información.

5) Intente corregir el error.

6) Ejecutar durante la noche/durante las pruebas de regresión de fin de semana. Cuando estaba en R & D, generalmente solicito al menos 5-10 sistemas de prueba para ejecutar continuamente pruebas de regresión 24x7. Eso normalmente ayuda a ID y resuelve la memoria, los recursos y el problema de rendimiento a largo plazo antes de que el código llegue a SQA.

Una vez que un sistema incrustado falla, inicie el arranque en el indicador de Linux de vez en cuando. Agregué un caso de prueba que apaga el ciclo del sistema con una salida programable una y otra vez y se asegura de que pueda "ver" el símbolo del sistema y comenzar a ejecutar la prueba de la noche a la mañana. Pudimos identificar rápidamente el problema del código FPGA y asegurarnos de que el sistema esté siempre activo después de 5000 ciclos de encendido. Se agregó un caso de prueba y todo se compila un nuevo código Verilog codein/FPGA. Este caso de prueba se ejecutó. Nunca más fue un problema.

Answer 14

Sugiero leer Debugging By Thinking.

Andreas Zeller también ha trabajado en estudios de depuración sistemática.