¿Cómo reducir el tiempo dedicado a las pruebas?

Question

Acabo de revisar el proyecto que casi terminó recientemente y encontré un problema muy serio. Pasé la mayor parte del tiempo del banco probando el código, reproduciendo las diferentes situaciones que "pueden" provocar errores de código.

¿Tiene alguna idea o experiencia para compartir sobre cómo reducir el tiempo dedicado a las pruebas, por lo que hace que el desarrollo sea mucho más sencillo?

Intenté seguir el concepto de pruebas controladas para todo mi código, pero me pareció muy difícil de lograr, realmente necesito un poco de ayuda de los muchachos aquí.

Gracias

Re: todos

Gracias por las respuestas anteriores aquí, en un principio mi pregunta fue cómo reducir el tiempo en las pruebas en general, pero ahora, el problema se debe a la forma de escribir el Automatizar eficiente código de prueba.

Intentaré mejorar mis habilidades sobre cómo escribir el traje de prueba para reducir esta parte del tiempo.

Sin embargo, todavía tengo dificultades para reducir el tiempo que gasto en reproducir los errores, por ejemplo, un proyecto de blog estándar será fácil de reproducir, las situaciones pueden causar errores, pero un sistema interno complicado puede "nunca" "puede probarse fácilmente, ¿es valioso? ¿Tiene alguna idea sobre cómo construir un plan de prueba en este tipo de proyecto?

Gracias por las siguientes respuestas.

Answer 1

El diseño controlado por prueba no se trata de pruebas (aseguramiento de la calidad). Ha sido mal llamado desde el principio.

Se trata de tener suposiciones ejecutables por máquina y las especificaciones del comportamiento del programa y es realizado por los programadores durante la programación para garantizar que las suposiciones sean explícitas.

Dado que esas tareas deben realizarse en algún momento del ciclo de vida del producto, es simplemente un cambio del trabajo. Si es más o menos eficiente es un debate para otro momento.

A lo que te refieres no llamaría testing. Tener un TDD fuerte significa que la fase de prueba no tiene que depender demasiado de los errores que se atraparían mucho antes de llegar a una versión de prueba (como lo son con los programadores de experiencia con una buena especificación y partes interesadas receptivas en un entorno no TDD). ambiente).

Si cree que las pruebas iniciales (especificación ejecutable) es un problema grave, supongo que todo se reduce a la cantidad de trabajo que se espera que las etapas relativas de desarrollo cuesten en tiempo y dinero.

Answer 2

No hay nada inherentemente incorrecto en pasar mucho tiempo probando si está probando productivamente. Tenga en cuenta que el desarrollo basado en pruebas significa primero escribir las pruebas (en su mayoría automatizadas) (esto puede demorar legítimamente mucho tiempo si usted escribe un conjunto de pruebas completo). Ejecutar las pruebas no debería tomar mucho tiempo.

Answer 3

El equipo de Subversion ha desarrollado algunos pretty good test routines, mediante la automatización de todo el proceso.

He comenzado a usar este proceso yo mismo, por ejemplo escribiendo pruebas antes de implementando las nuevas funciones. Funciona muy bien y genera pruebas consistentes a través de todo el proceso de programación.

SQLite también tiene un sistema de prueba decente con algunos very good documentation acerca de cómo se hace.

Answer 4

Parece que su problema es que no está haciendo pruebas automáticas. El uso de unidades unitarias y pruebas de integración puede reducir en gran medida la cantidad de tiempo que pasa probando.

Answer 5

En mi experiencia con el desarrollo impulsado por pruebas, el ahorro de tiempo se produce mucho después de haber escrito las pruebas, o al menos después de haber escrito los casos de prueba base. La clave aquí es que realmente tiene que escribir nuestras pruebas automáticas. La forma en que formuló su pregunta me lleva a creer que en realidad no estaba escribiendo pruebas automáticas. Después de que le hagan las pruebas escritas, puede regresar fácilmente más tarde y actualizar las pruebas para cubrir los errores que no encontraron anteriormente (para una mejor prueba de regresión) y puede refactorizar su código fácil y relativamente rápido con la tranquilidad de que el código sigue funcionando como se esperaba después de haberlo cambiado sustancialmente.

Answer 6

Una de las cosas más difíciles de cualquier proyecto de gran tamaño es diseñar la arquitectura subyacente y la API. Todo esto está expuesto a nivel de pruebas unitarias. Si está escribiendo sus pruebas primero, ese aspecto del diseño ocurre cuando codifica sus pruebas, en lugar de la lógica del programa. Esto se ve agravado por el esfuerzo adicional de hacer que el código sea comprobable. Una vez que tienes tus pruebas, la lógica del programa suele ser bastante obvia.

Dicho esto, parece que hay algunos constructores de prueba automatic interesantes en el horizonte.

Answer 7

En primer lugar, es bueno que usted reconoce que necesita ayuda - ahora ir a buscar algunos :)

La idea es utilizar las pruebas para ayudarle a pensar acerca de lo que el código debe hacer, que son parte de tu tiempo de diseño.

También debe pensar en el costo total de propiedad del código. ¿Cuál es el costo de un error al pasar a la producción en lugar de ser corregido primero? Si está en un banco, ¿hay implicaciones serias acerca de obtener los números incorrectos? A veces, lo correcto solo toma tiempo.

Answer 8

Creo que entiendo. Por encima del nivel de prueba del desarrollador, tienes el nivel de prueba del cliente, y parece que, en ese nivel, encuentras muchos errores.

Por cada error que encuentre, debe detenerse, quitarse el sombrero de prueba, ponerse el sombrero de reproducción y descubrir una estrategia de reproducción precisa. Luego debe documentar el error, tal vez ponerlo en un sistema de seguimiento de errores. Entonces tienes que ponerte el sombrero de prueba. Mientras tanto, has perdido la configuración en la que estabas trabajando y perdiste la pista de dónde estabas en el plan de prueba que estabas siguiendo.

Ahora, si eso no tenía que pasar, si tenía muchos errores, podría pasar por las pruebas, ¿verdad?

Es dudoso que la automatización de pruebas de conducción GUI ayude con este problema. Pasará una gran cantidad de tiempo registrando y manteniendo las pruebas, y esas pruebas de regresión tomarán bastante tiempo para devolver la inversión. Inicialmente, irá mucho más lento con las pruebas orientadas al cliente de GUI-Driving.

Entonces (lo presento) que lo que realmente podría ayudar es una calidad superior/inicial/de código que surja de las actividades de desarrollo. Las micropruebas, también llamadas pruebas de desarrollador o desarrollo basado en pruebas en el sentido original, realmente podrían ayudar con eso. Otra cosa que puede ayudar es la programación de pares.

Suponiendo que no se puede agarrar a otra persona para emparejar, me gustaría pasar una hora mirando su sistema de seguimiento de errores. Me gustaría ver los últimos 100 defectos y tratar de categorizarlos en causas raíz. "Problema de entrenamiento" no es una causa, pero podría ser "un error".

Una vez que los haya categorizado y contado, colóquelos en una hoja de cálculo y ordene. Cualquiera que sea la causa raíz, la causa más común es la que previene primero. Si realmente quieres ser elegante, multiplica la causa raíz por un número que sea la cantidad de dolor que causa. (Ejemplo: si en esos 100 errores tiene 30 errores tipográficos en los menús, que son fáciles de corregir y 10 errores de JavaScript difíciles de reproducir, es posible que desee corregir primero el problema de javascript.)

Esto supone que puede aplica alguna "solución" mágica a cada una de esas causas raíz, pero vale la pena intentarlo. Por ejemplo: los íconos transparentes en IE6 pueden deberse a que IE6 no puede procesar fácilmente archivos .png. De modo que tenga un activador de control de versión que rechace el archivo .gif al registrarse y el problema esté solucionado.

Espero que ayude.

Answer 9

Usted escribió:

"Gracias por las respuestas anteriores aquí, inicialmente mi pregunta era cómo a reducir el tiempo en las pruebas en general, pero ahora, el problema se debe a la forma de escribir el prueba de automatización eficiente código. "

Un método que ha demostrado en múltiples estudios empíricos que funciona extremadamente bien para maximizar la eficacia de las pruebas es la realización de pruebas combinatorias. En este enfoque, un probador identificará QUÉ TIPOS de cosas se deben probar (y lo ingresará en una herramienta simple) y la herramienta identificará CÓMO probar la aplicación. Específicamente, la herramienta generará casos de prueba que especifiquen qué combinaciones de condiciones de prueba deben ejecutarse en qué script de prueba y el orden en que se ejecutará cada script de prueba.

En el August, 2009 IEEE Computer article I co-wrote with Dr. Rick Kuhn, Dr. Raghu Kacker, and Dr. Jeff Lei, por ejemplo, destacamos un proyecto de 10 estudio dirigí donde un grupo de probadores utilizó sus métodos de diseño de prueba estándar y un segundo grupo de probadores, probando la misma aplicación, usó un generador de caso de prueba combinatorio para identificar casos de prueba para ellos. Los equipos que usan el generador de casos de prueba combinatoria encontraron, en promedio, más del doble de defectos por hora de prueba. Esa es una fuerte evidencia de eficiencia. Además, los evaluadores combinatorios encontraron un 13% más de defectos en general. Esa es una fuerte evidencia de calidad/minuciosidad.

Esos resultados no son inusuales. Se puede encontrar información adicional sobre este enfoque en http://www.combinatorialtesting.com/clear-introductions-1 y en nuestra herramienta con información general here. Contiene capturas de pantalla y una explicación de cómo nuestra herramienta hace que las pruebas sean más eficientes al identificar un subconjunto de pruebas que maximizan la cobertura.

también la versión gratuita de nuestro generador de caso de prueba Hexawise se puede encontrar en www.hexawise.com/users/new