Rigor en la captura de casos de prueba para pruebas de unidad

Question

Digamos que tenemos una simple función definida en un pseudo lenguaje.

List<Numbers> SortNumbers(List<Numbers> unsorted, bool ascending);

Pasamos una lista de seleccionados de números y un valor booleano que especifica de forma ascendente o descendente orden.En cambio, obtenemos una lista ordenada de números.

En mi experiencia, algunas personas son mejores en la captura de las condiciones de contorno que otros.La pregunta es, "¿Cómo sabe usted cuando usted está 'hecho' la captura de casos de prueba"?

Podemos empezar a hacer una lista de los casos ahora y alguna persona lista sin duda pensar en 'uno más' caso que no es cubierta por ninguna de las anteriores.

Answer 1

No pierdas demasiado tiempo tratando de pensar en cada boundry condición.Las pruebas no ser capaz de atrapar cada error la primera vez alrededor.La idea es tener pruebas de que son bastante bueno, y , a continuación, cada vez que un error ¿ superficie, escribir una nueva prueba específicamente para ese error, así que nunca se oye de nuevo.

Otra nota que desee hacer acerca de la cobertura de código herramientas.En un lenguaje como C# o Java, donde tiene muchos get/set y métodos similares, usted debe no fotos 100% de cobertura.Eso significa que usted está perdiendo demasiado tiempo escribiendo pruebas trivial de código.Usted sólo quiere el 100% de cobertura en el complejo de la lógica de negocio.Si tu código está más cerca del 70-80% de cobertura, usted está haciendo un buen trabajo.Si su herramienta de cobertura de código permite que múltiples métricas de cobertura, la mejor de todas es "bloque de cobertura' que mide la cobertura de los 'básicos'.Otros tipos son de la clase y el método de la cobertura (que no te dan la mayor cantidad de información) y la cobertura de la línea (que es demasiado grano fino).

Answer 2

¿Cómo saber cuando está 'hecho' la captura de casos de prueba?

No.Usted no puede conseguir el 100%, excepto para la mayoría de los casos triviales.También el 100% de cobertura (de líneas, rutas, condiciones...) no te he golpeado todas las condiciones de contorno.

Lo que es más importante, los casos de prueba no escribir-y-olvidar. Cada vez que usted encuentra un error, escribir un ensayo adicional. Verificación de falla con el programa original, verifique que pasa con el programa corregido y añadir a su conjunto de pruebas.

Un extracto de El Arte de Pruebas de Software por Glenford J.Myers:

1. Si una condición de entrada especifica un rango de valores, escribir casos de prueba para los extremos de la gama, y no válidos de entrada de casos de prueba para situaciones más allá de los extremos.
2. Si una condición de entrada especifica un número de valores, escribir casos de prueba para el número mínimo y máximo de los valores y uno por debajo y más allá de estos valores.
3. Uso de la guía 1 para cada condición de salida.
4. El uso de la pauta de 2 para cada condición de salida.
5. Si la entrada o la salida de un programa es un conjunto ordenado de centrar la atención en el primero y el último de los elementos del conjunto.
6. Además, el uso de su ingenio en la búsqueda de otras condiciones de contorno

(Sólo he pegado el mínimo por razones de copyright.)

Los puntos 3.y 4.de arriba son muy importantes.La gente tiende a olvidar las condiciones de contorno para las salidas.5.es ACEPTAR.6.realmente no ayuda :-)

Breve examen

Esto es más difícil de lo que parece.Myers ofrece esta prueba:

El programa lee los tres valores enteros a partir de un diálogo de entrada.Los tres valores representan las longitudes de los lados de un triángulo.El programa muestra un mensaje que indica si el triángulo es escaleno, isósceles o equilátero.

Recuerde que un triángulo escaleno es aquel donde no hay dos lados son iguales, mientras que un triángulo isósceles tiene dos lados iguales y un triángulo equilátero tiene tres lados de igual longitud.Por otra parte, los ángulos opuestos a los lados iguales de un triángulo isósceles también son iguales (se desprende también que los lados opuestos de la igualdad de los ángulos de un triángulo son iguales), y todos los ángulos en un triángulo equilátero son iguales.

Escribir los casos de prueba.¿Cuántos tienes?Myers pregunta 14 pregunta acerca de su conjunto de pruebas e informes que los profesionales altamente calificados de los programas de promedio de 7.8 de las 14 posibles.

Answer 3

Desde un punto de vista práctico, puedo crear una lista de las pruebas que yo creo que debe pasar antes de la aceptación.Puedo probar estos y automatizar en lo posible.Dependiendo de cuánto tiempo he estimado para la tarea o cuánto tiempo me has dado, quiero extender mi prueba de la cobertura para incluir los elementos que deben pasar antes de la aceptación.Por supuesto, la línea entre el debe y debería es subjetiva.Después de eso, me actualización de pruebas automatizadas como errores son descubiertos.

Answer 4

@Keith

Creo que lo habéis clavado, cobertura de código es importante tener en cuenta si usted desea ver cómo se "hace" que son, pero creo que el 100% es un poco irreal de un objetivo.Esfuerzo para el 75-90% le dará muy buena cobertura, sin pasar por la borda...no se prueba por el puro amor de llegar al 100%, porque en ese momento usted está perdiendo su tiempo.

Answer 5

Una buena herramienta de cobertura de código realmente ayuda.

100% de cobertura no significa que definitivamente está debidamente probado, pero es un buen indicador.

Para .Net NCover muy bueno, pero ya no es de código abierto.

---

@Mike Stone - Sí, tal vez debería haber sido "alta cobertura" - nuestro objetivo mínimo del 80%, pasando de aproximadamente el 95% es generalmente de rendimientos decrecientes, especialmente si usted tiene cinturón 'n' llaves de código.