En sentido estricto, no es justo hacer ningún reclamo hasta que se establezca la calidad del conjunto de pruebas. Pasar el 100% de las pruebas no tiene sentido si la mayoría de las pruebas son triviales o repetitivas entre sí.
La pregunta es: en la historia del proyecto, ¿alguna de esas pruebas descubrió errores? El objetivo de una prueba es encontrar errores. Y si no lo hicieron, fallaron como pruebas. En lugar de mejorar la calidad del código, es posible que solo le den una falsa sensación de seguridad.
Para mejorar sus diseños de prueba, puede usar (1) técnicas de caja blanca, (2) técnicas de caja negra y (3) pruebas de mutación.
(1) Aquí hay algunas buenas técnicas de caja blanca para aplicar a sus diseños de prueba. Una prueba de caja blanca se construye teniendo en cuenta el código fuente específico. Un aspecto importante de las pruebas de caja blanca es la cobertura del código:
- ¿Se llama a todas las funciones? [Cobertura funcional]
- ¿Se ejecuta cada declaración? [Cobertura del estado de cuenta: tanto la cobertura funcional como la cobertura del estado de cuenta son muy básicas, pero mejor que nada]
- Para cada decisión (como
ifo while), ¿tiene una prueba que lo obliga a ser cierto y otro que lo obliga a ser falso? [Cobertura de decisión]
- Para cada condición que es una conjunción (usos
&&) o disyunción (usos ||), ¿cada subexpresión tiene una prueba donde es verdadero / falso? [Condición de cobertura]
- Cobertura de bucle: ¿tiene una prueba que fuerce 0 iteraciones, 1 iteración, 2 iteraciones?
- ¿Está cada uno
breakde un bucle cubierto?
(2) Las técnicas de Blackbox se usan cuando los requisitos están disponibles, pero el código en sí no. Estos pueden conducir a pruebas de alta calidad:
- ¿Sus pruebas de blackbox cubren múltiples objetivos de prueba? Querrá que sus pruebas sean "gordas": no solo prueban la función X, sino que también prueban Y y Z. La interacción de diferentes funciones es una excelente manera de encontrar errores.
- El único caso en el que no desea pruebas "gordas" es cuando está probando una condición de error. Por ejemplo, prueba de entrada de usuario no válida. Si trató de lograr múltiples objetivos de prueba de entrada no válidos (por ejemplo, un código postal no válido y una dirección de calle no válida) es probable que un caso esté enmascarando al otro.
- Considere los tipos de entrada y forme una "clase de equivalencia" para los tipos de entradas. Por ejemplo, si su código prueba para ver si un triángulo es equilátero, la prueba que usa un triángulo con lados (1, 1, 1) probablemente encontrará los mismos tipos de errores que los datos de prueba (2, 2, 2) y (3, 3, 3) encontrará. Es mejor pasar su tiempo pensando en otras clases de aportes. Por ejemplo, si su programa maneja impuestos, querrá una prueba para cada tramo de impuestos. [Esto se llama partición de equivalencia.]
- Los casos especiales a menudo se asocian con defectos. Los datos de su prueba también deben tener valores límite, como los que se encuentran en, arriba o debajo de los bordes de una tarea de equivalencia. Por ejemplo, al probar un algoritmo de clasificación, querrá probar con una matriz vacía, una matriz de un solo elemento, una matriz con dos elementos y luego una matriz muy grande. Debe considerar los casos límite no solo para la entrada, sino también para la salida. [Este es un análisis de valor de límite de llamada.]
- Otra técnica es "Error al adivinar". ¿Tiene la sensación de que si prueba alguna combinación especial puede hacer que su programa se rompa? ¡Entonces solo pruébalo! Recuerde: su objetivo es encontrar errores, no confirmar que el programa es válido . Algunas personas tienen la habilidad de adivinar errores.
(3) Finalmente, suponga que ya tiene muchas buenas pruebas de cobertura de caja blanca y técnicas de caja negra aplicadas. ¿Qué más puedes hacer? Es hora de probar sus pruebas . Una técnica que puede usar es la prueba de mutación.
En las pruebas de mutación, realiza una modificación en (una copia de) su programa, con la esperanza de crear un error. Una mutación podría ser:
Cambiar una referencia de una variable a otra variable; Inserte la función abs (); Cambiar menor que mayor que; Eliminar una declaración; Reemplazar una variable con una constante; Eliminar un método de anulación; Eliminar una referencia a un súper método; Cambiar orden de argumento
Cree varias docenas de mutantes, en varios lugares de su programa [el programa aún tendrá que compilarse para realizar la prueba]. Si sus pruebas no encuentran estos errores, entonces necesita escribir una prueba que pueda encontrar el error en la versión mutada de su programa. Una vez que una prueba encuentra el error, has matado al mutante y puedes probar con otro.
Anexo : Olvidé mencionar este efecto: los errores tienden a agruparse . Lo que eso significa es que cuantos más errores encuentre en un módulo, mayor será la probabilidad de que encuentre más errores. Entonces, si tiene una prueba que falla (es decir, la prueba es exitosa, ya que el objetivo es encontrar errores), no solo debe corregir el error, sino que también debe escribir más pruebas para el módulo, utilizando el Técnicas anteriores.
Mientras encuentre errores a un ritmo constante, los esfuerzos de prueba deben continuar. Solo cuando haya una disminución en la tasa de nuevos errores encontrados, debe tener la confianza de que ha realizado buenos esfuerzos de prueba para esa fase de desarrollo.