¿Qué hacer con los insectos que no Repro?

Question

Tengo un probador que, si bien las pruebas tendrá que producirse un error (bien hasta ahora), pero luego con frecuencia informa de inmediato. Nosotros (los desarrolladores) y más tarde encontramos que el probador no ha tratado de reproducir el problema y (cuando se le pregunta) no puede encontrar una manera de hacer que suceda de nuevo.

Ahora bien, estos siguen siendo errores, no quiero hacer caso de ellos. Pero sin los pasos para reproducir estoy un poco atascado. A veces hay un seguimiento de la pila (aunque con frecuencia no es útil ya que este es el marco compacta y no hay números de línea). Pero cuando hay una que me quieren cogerán el seguimiento de la pila y abrir una grieta en el código y empezar a adivinar, pero que no conduce a "soluciones" comprobables.

¿Qué se hace en escenarios como este?

Answer 1

Un fallo sin contexto no es un error, es un golpe de suerte. El problema podría ser su código, podría ser una biblioteca de terceros, podría ser el hardware, o podría ser la radiación solar causando un solo bit para voltear por sí mismo. Si no puede reproducirlo con al menos algunos regularidad (aunque sólo "que ocurre una vez cada 10 o 20 veces hago X"), que no es mucho mejor que su probador que le dice "algo en alguna parte que salió mal de alguna manera -. arregles"

Es posible que tenga que explicar a su certificador de que su trabajo no es simplemente generar entrada hasta que algo se rompe. Si lo fuera, usted podría reemplazarlo con un generador de números aleatorios. Parte de su trabajo es identificar los errores, lo que implica la identificación de cómo producir ellos.

Answer 2

En última instancia si ni el desarrollador ni el probador puede reproducir el error debería estar cerrada, pero marcado como tal.

Sin embargo, el tiempo que le lleva al llegar a ese punto es discutible.

Algunas personas podrían argumentar que si no es inmediatamente reproducibles entonces debería ser inmediatamente cerrado.

Por lo general esfuerzo para tratar de obtener más información del originador del problema. Puede haber algo que se olvidó en el informe original. Tener una conversación acerca de los pasos que se requieren a menudo puede revelar la información que falta.

Una reflexión final - cerrado como "no-repro" no media fija. Si hay un problema real que se revelará tarde o temprano y tener toda la información que puede le ayudará cuando finalmente se puede reproducir el problema.

Answer 3

algunas sugerencias más:

1. Agregar registro (y no sólo un keylogger:}) al código de producto. "No se repro" errores pueden ser casualidades, sino que puede ser la memoria o el estado de corrupción que sólo se produce en un sistema sucio utilizado de manera imprevista (es decir, como una computadora clientes). Inicio de sesión o la información de seguimiento puede ayudar a averiguar lo que puede se han equivocado cuando el probador encontró el golpe de suerte.

2. Escanear el resto de los "Repro" no hay errores en la base de datos (o lo que sea que se utiliza para el seguimiento de errores). A menudo, las aletas se agrupan en un área del producto. Si se ve como uno de los componentes tiene la culpa, revisión de código del componente para su posible descamación, añadir registro adicional a ese componente. - o ambos

3. Tome la mitad de una hora o así y ver su prueba probador. Su enfoque le puede dar una idea de lo que salió mal (por ejemplo, "interesante - Yo no sabía que se podía llegar a ese diálogo de esa manera"). También puede encontrar que se saltan un paso de diálogo de configuración o involuntariamente. Vale la pena la inversión de tiempo para conseguir en su cabeza un poco.

Answer 4

hago de control de calidad en un gran código de comercio, este escenario hace llegar a irritar demasiado a menudo. Por lo general, es indicativo de no tener proceedures de acorazados para construir el binario en todas las plataformas que apoyamos. Así que si el desarrollador construye su propio código (que tiene que hacer para depurar y arreglar), y no sigue el mismo procedimiento de construcción de la carta, hay una posibilidad de que los errores dependientes del sistema aparecerán mágicamente a desaparecer (o parecer) . Por supuesto, estas cosas por lo general se cierran con "funciona para mí" en la base de datos de errores, y si no la próxima vez que se ejecuta un problema, el error puede ser reabierto. Cada vez que sospechas de un error puede ser dependiente del sistema, trato de probarlo en una variedad de plataformas y el informe de las condiciones en que se produce. A menudo un problema de corrupción de memoria onlt muestra arriba si los datos dañado es de una magnitud lo suficientemente grande como para causar un accidente. Algunas plataformas (HW y OS combinaciones) se puede bloquear más cerca de la fuente real de la corrupción, y esto puede ser muy valiosa para el pobre que tiene que depurarlo.

El probador tiene que hacer algún valor añadido, más allá de sólo un informe de que sus sistema muestra un error. Paso mucho tiempo descartar a falsos positivos -quizás la plataforma en cuestión estaba sobrecargado, o la red tenía un problema técnico. Y sí, a veces se puede conseguir algo que realmente está afectada por eventos aleatorios de tiempo, errores de hardware pueden ser a menudo como ejemplo proto: Si dos solicitudes de datos regresan una exactamente el mismo período de reloj, y la lógica de hardware para manejar el conflicto potencial es defectuoso, entonces el error sólo se mostrará de forma intermitente. Lo mismo sucede con el procesamiento en paralelo, a menos que por un cuidadoso diseño que ha limitado la solución a ser independiente de qué procesador pasó a ser más rápido, puede obtener errores que sólo suceden una vez en una luna azul, y su imporbablity estadística hace que la depuración de una pesadilla.

También nuestro código está en proceso de actualización, por lo general muchas veces al día, rastrear un número exacto código fuente para la revisión cuando se fue al sur puede ser una información muy útil para el esfuerzo de depuración. El probador no debe estar en una relación de confrontación con los depuradores y desarrolladores, que está allí como parte de un equipo para mejorar la calidad del producto.

Answer 5

Hay dos tipos de error que no son reproducibles:

1) Aquellos que un aparato (o usuario) se ha visto una vez, pero o bien no ha podido o no intento de reproducir.

En estas situaciones se debe:

• comprobar Muy brevemente el curso básico de las acciones que mostraban el defecto para asegurarse de que no es reproducible.

• hablar con el tester / usuario para ver si hay alguna otra información que pueda ayudar.

• Referencia cruzada con otros defectos que podrían estar relacionados para ver si tiene suficiente información para buscar en ellos basados ??en varias instancias. Es posible que éste tema no le da suficiente información para seguir adelante sin embargo, cuando se combina con una serie de otros problemas que puede sugerir que algo no está bien que está investigando la pena.

• Si todavía no tienes suficiente para seguir adelante entonces usted necesita para explicar al usuario / probador que no tienen suficiente información. Esquema para ellos cortésmente lo suficiente información se vería así y por qué se necesita.

2) Aquellos en los que no puede ser fiable reproducido, sin embargo, hay suficiente evidencia (en términos de ocurrencias repetidas) para sugerir que el defecto existe, entonces tienden a ver que estos son problemas del programador y que el desarrollador - soportada por el tester / usuario - para investigar las necesidades

.

Esto es probable que sea lento y doloroso, es muy probable que va a tener que caminar el código, añadir más tala, vistazo a los datos y hablar con los probadores / usuarios en profundidad, pero si hay suficiente evidencia para sugerir que es probable que haya un problema sí es necesario para tomar posesión de ella y hacer lo que hay que hacer para solucionarlo.

Answer 6

Parece que esto sucede con relativa frecuencia - que me pregunto, ¿es porque la mayoría de los errores son realmente difícil de repro, o es por alguna otra razón que no está tratando? Sabes ¿Por qué que no está tratando de reproducir el problema? ¿Es porque no se da cuenta de lo importante que es para usted? ¿O es que acaso él tiene otras presiones - un director de pruebas que sólo lo quiere conseguir a través de las pruebas asignadas de forma rápida y lanzar a los insectos por encima del muro, por ejemplo? O tal vez no es sólo seguro de cómo hacerlo?

Estoy de acuerdo con otras personas que trabajan en una mejor explotación forestal es una prioridad. Mientras tanto, si se sospecha que la falta de habilidad tester / confianza puede ser un problema, entonces me gusta mucho este artículo de Danny Faught el fallo de aislamiento - que podrían apuntar a lo que para un comienzo.

Si el problema resulta ser debido a la presión de gestión - que tiene mis simpatías, ya que es una pregunta difícil de crack, especialmente si los probadores y programadores reportan a diferentes gestores y los gerentes no están dispuestos a "ayudar a cabo" otra equipo.

Answer 7

Normalmente observo que no es reproducible, pero dejarlo abierto hasta ese lote de prueba o iteración es completa.

Si no se ha reproducido en ese momento que se cierra, pero puede ser reabierto si se encuentra de nuevo.

Answer 8

stick a keylogger on this tester's workstation!

Answer 9

Well, the first task is to have a reproducible test system. Your tester must have a well-defined process - automatic if at all possible.

Have these three conditions:

• Same binary
• Same steps
• Same machine

If the bug sporadically appears with the above 3 conditions, begin to isolate further. Consider each level of the system stack and its configuration.

One way to detect memory management errors is to run the program on multiple OSs with multiple compilers. Valgrind can also help.

However, typically parallel systems are liable to induce non-repro bugs. Things like buffer sizes and processing speeds, asynch io, database locks, variable memory write interleavings; all of those can generate issues. And so forth and so on.

Answer 10

First of all, you should have a rigorous testing procedure (but I understand you, in my company what you have described happens frequently).

Depending on the severity of the bug, you can invest some time on it or (better) ignore it until repro steps are provided.