¿Cómo reducir el tiempo empleado en las pruebas?

Question

Yo miraba hacia atrás a través del proyecto que casi terminado recientemente y encontré un problema muy serio. Pasé la mayor parte del tiempo en las pruebas de banco del código, reproduciendo las diferentes situaciones "pueden" causar errores de código.

¿Tiene usted alguna idea o experiencia para compartir sobre cómo reducir el tiempo empleado en las pruebas, por lo que hace el desarrollo mucho más suavemente?

He intentado seguir el concepto de guiado por pruebas de todo mi código, pero me pareció muy difícil de lograr esto, realmente necesitan la ayuda de los chicos mayores aquí.

Gracias

Re: todos

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

Voy a tratar de mejorar mis conocimientos sobre la forma de escribir el juego de prueba para reducir esta parte del tiempo.

Sin embargo, todavía les cuesta mucho con la forma de reducir el tiempo que pasé en reproducir los errores, por ejemplo, un proyecto de blog estándar será fácil de reproducir las situaciones pueden hacer que los errores sino un complican a medida sistema interno puede "nunca más" se puede probar throught con facilidad, es digno? ¿Tiene alguna idea sobre cómo construir un plan de pruebas para este tipo de proyecto?

Gracias por las respuestas aún más.

Answer 1

El diseño basado en pruebas no se trata de la prueba (control de calidad). Se ha mal llamado desde el principio.

Se trata de tener la máquina supuestos y especificaciones de comportamiento de los programas ejecutables y se realiza por los programadores durante la programación para asegurar que los supuestos son explícitos.

Dado que esas tareas tienen que ser hechas en algún momento de su ciclo de vida, es simplemente un cambio de la obra. Si se trata de más o menos eficiente es un debate para otro momento.

Lo que se hace referencia a que no lo llamaría pruebas. Tener una fuerte TDD quiere decir que la fase de prueba no tiene que ser considerada como un alto precio por los errores que pueden capturar mucho antes de que lleguen a una compilación de prueba (como lo están con experiencia programadores con una buena especificación y las partes interesadas que respondan en un no-TDD medio ambiente).

Si cree que las pruebas iniciales (SPEC) ejecutable es un problema serio, creo que todo se reduce a la cantidad de trabajo se espera que las etapas de desarrollo relativo al costo en tiempo y dinero?

Answer 2

Creo que entiendo. Por encima del nivel de la prueba desarrollador, usted tiene el nivel de prueba del cliente, y parece que, en ese nivel, usted está encontrando un montón de errores.

Para todos los errores que encuentre, usted tiene que parar, tomar su sombrero de las pruebas fuera, poner su sombrero en la reproducción, y encontrar una estrategia de reproducción precisa. Entonces usted tiene que documentar el error, tal vez lo puso en un sistema de seguimiento de bugs. Entonces usted tiene que poner el sombrero de pruebas en. Por el momento, todo lo que ha perdido la configuración que estaba trabajando y perdió la pista de dónde estabas en cualquier plan de pruebas estaban siguiendo.

Ahora - si eso no tienen que suceder - si ha tenido muy pocos errores - se podría comprimir a lo largo de la derecha a través de pruebas, a la derecha

Es dudoso que la automatización de pruebas interfaz gráfica de conducción contribuirá con este problema. Vas a pasar una gran cantidad de tiempo de grabación y el mantenimiento de las pruebas, y las pruebas de regresión se llevará una buena cantidad de tiempo para devolver la inversión. Inicialmente, irá mucho más lento con las pruebas de cara al cliente GUI-conducción.

Así que (someto) que lo que podría realmente ayuda es más alto / calidad / código inicial saliendo de las actividades de desarrollo. Micro-tests - también llamados desarrollador-tests o pruebas impulsado el desarrollo en el sentido original - en realidad podrían ayudar con eso. Otra cosa que puede ayudar es la programación en parejas.

Suponiendo que no puede agarrar a alguien más para emparejar, me gustaría pasar una hora buscando en su sistema de seguimiento de errores. Me gustaría ver los últimos 100 defectos y tratar de clasificarlas en causas fundamentales. "Formación tema" no es una causa, sino "fuera por un error" podría ser.

Una vez que tenga los clasificaron y contaron, ponerlos en una hoja de cálculo y tipo. Cualquiera que sea la causa de la raíz se produce con mayor frecuencia es la causa fundamental a evitar en primer lugar. Si realmente desea conseguir la suposición, multiplicar la causa por algún número que es la cantidad de dolor que causa. (Ejemplo:. Si en esos errores 100 tiene 30 errores tipográficos en menús, que tan fácil de solucionar, y 10 y difíciles de reproducir errores de javascript, es posible que desee para solucionar el problema Javascript primero)

Esto supone que se puede aplicar un poco mágica 'arreglo' a cada una de esas causas fundamentales, pero vale la pena un tiro. Por ejemplo: los iconos transparentes en IE6 pueden deberse a que IE6 no puede procesar fácilmente los archivos .png. Así que tienen un disparador de control de versiones que rechaza de .gif en el registro y el problema se soluciona.

Espero que ayude.

Answer 3

El equipo de Subversion ha desarrollado unas buenas rutinas de prueba , mediante la automatización de todo el proceso.

He comenzado a utilizar este proceso a mí mismo, por ejemplo escribiendo las pruebas antes la aplicación de las nuevas características. Funciona muy bien, y genera la prueba consistente a través de todo el proceso de programación.

SQLite también tienen un sistema de prueba decente con un poco de muy buena documentación sobre cómo se hace.

Answer 4

En mi experiencia con el desarrollo basado en pruebas, el ahorro de tiempo viene bien después de haber escrito a cabo las pruebas, o por lo menos después de haber escrito los casos de prueba de base. La clave aquí es que siendo que en realidad tiene que escribir nuestros sus pruebas automatizadas. La manera en que su formul la pregunta me lleva a creer que no estaban realmente escribir pruebas automatizadas. Después de haber escrito sus pruebas que puede fácilmente volver más tarde y actualizar las pruebas para cubrir los errores que no encontraron previamente (para una mejor prueba de regresión) y se puede refactorizar fácil y relativamente rápido el código con la facilidad de saber que el código se todavía funcionan como se esperaba después de haber cambiado sustancialmente la misma.

Answer 5

Usted escribió:

  

"Gracias por las respuestas anteriores aquí,   Inicialmente mi pregunta era cómo   reducir el tiempo de los ensayos generales,   pero ahora, el problema se debe a la forma de   escribir la prueba a automatizar eficiente   código ".

Un método que se ha demostrado en múltiples estudios empíricos para trabajar muy bien para maximizar la eficiencia de las pruebas es la prueba combinatoria. En este enfoque, un probador identificará qué tipo de cosas debe ser probada (y la entrada en una herramienta simple) y la herramienta identificará cómo poner a prueba la aplicación. Específicamente, la herramienta va a generar casos de prueba que especifican qué combinaciones de condiciones de prueba debe ser ejecutado en la que la escritura de prueba y el orden en que cada secuencia de comandos de prueba debe ser ejecutado en.

En el de agosto de 2009 IEEE Computer artículo que coescribió con el Dr. Rick Kuhn, el Dr. Raghu Kacker, y el Dr. Jeff Lei , por ejemplo, seleccionamos a un estudio de 10 proyectos me llevó donde un grupo de probadores de utilizar sus métodos de diseño de pruebas estándar y una segundo grupo de probadores, poniendo a prueba la misma aplicación, utiliza un generador de casos de prueba combinatoria para identificar casos de prueba para ellos. Los equipos que utilizan el generador de casos de prueba combinatoria encontraron, en promedio, más del doble de los defectos por hora tester. Esa es una fuerte evidencia de la eficacia. Además, los probadores combinatorias encontraron 13% más defectos en general. Esa es una fuerte evidencia de la calidad / minuciosidad.

Estos resultados no son inusuales. Información adicional acerca de este enfoque se puede encontrar en http://www.combinatorialtesting.com/clear-introductions -1 y nuestra visión general herramienta aquí . Contiene capturas de pantalla y la explicación de cómo y de nuestra herramienta hace que la prueba más eficiente mediante la identificación de 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/ nuevos

Answer 6

No hay nada inherentemente malo en pasar mucho tiempo de prueba si está probando productivamente . Tenga en cuenta, desarrollo basado en pruebas significa escribir las pruebas automatizadas (en su mayoría) primero (esto legítimamente puede llevar mucho tiempo si se escribe un conjunto de pruebas a fondo). Ejecutar las pruebas no debe tomar mucho tiempo.

Answer 7

Parece que su problema es que no están haciendo las pruebas automáticas. El uso de pruebas de unidad e integración automatizada puede reducir enormemente la cantidad de tiempo que pasa la prueba.

Answer 8

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

La idea es utilizar las pruebas para ayudarle a pensar acerca de lo que el código debe hacer, que son parte de su 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 por lo que es a través de la producción en lugar de estar fijo en primer lugar? Si estás en un banco, hay serias implicaciones sobre cómo obtener los números mal? A veces, la materia derecha sólo se necesita tiempo.

Answer 9

Una de las cosas más difíciles acerca de cualquier proyecto de tamaño significativo es el diseño de la archetecture subyacente, y la API. Todo esto se expone en el nivel de las pruebas unitarias. Si va a escribir sus primeras pruebas, entonces ese aspecto del diseño sucede cuando su codificación de sus pruebas, en lugar de la lógica del programa. Esto se ve agravado por el esfuerzo adicional de hacer que el código comprobable. Una vez que tenga sus pruebas, la lógica del programa suele ser bastante obvio.

Dicho esto, parece que hay algunos prueba automática constructores en el horizonte.