Existen tres enfoques principales para el diseño de casos o pruebas
1.- El enfoque estructural o de caja blanca. Se centra en la estructura interna del programa (analiza los caminos de ejecución).
2.- El enfoque funcional o de caja negra. Se centra en las funciones, entradas y salidas.
3.- El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadísticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba
CRITERIOS DE COBERTURA LÓGICA
- Cobertura de sentencias. Se trata de generar los casos de prueba necesarios para que cada sentencia o instrucción del programa se ejecute al menos una vez.
- Cobertura de decisiones. Consiste en escribir casos suficientes para que cada decisión tenga, por lo menos una vez, un resultado verdadero y, al menos una vez, uno falso. (Incluye a la cobertura de sentencias)
- Cobertura de condiciones. Se trata de diseñar tantos casos como sea necesario para que cada condición de cada decisión adopte el valor verdadero al menos una vez y el falso al menos una vez. (No incluye cobertura de condiciones)
- Criterio de decisión/condición. Consiste en exigir el criterio de cobertura de condiciones obligando a que se cumpla también el criterio de decisiones.
- Criterio de condición múltiple. En el caso de que se considere que la evaluación de las condiciones de cada decisión no se realiza de forma simultánea, se puede considerar que cada decisión multicondicional se descompone en varias condiciones unicondicionales.
- Criterio de cobertura de caminos. Se recorren todos los caminos (impracticable).
PRUEBAS FUNCIONALES
Se centran en las funciones, entradas y salidas
Es impracticable probar el software para todas las posibilidades. De nuevo hay que tener criterios para elegir buenos casos de prueba
Un caso de prueba funcional es bien elegido si se cumple que:
Reduce el número de otros casos necesarios para que la prueba sea razonable. Esto implica que el caso ejecute el máximo número de posibilidades de entrada diferentes para así reducir el total de casos.
*Cubre un conjunto extenso de otros casos posibles, es decir, no indica algo acerca de la ausencia o la presencia de defectos en el conjunto específico de entradas que prueba, así como de otros conjuntos similares.
PRUEBAS ALEATORIAS
En las pruebas aleatorias simulamos la entrada habitual del programa creando datos de entrada en la secuencia y con la frecuencia con las que podrían aparecer en la Práctica (de manera repetitiva). Para ello habitualmente se utilizan generadores automáticos de casos de prueba.
Suscribirse a:
Enviar comentarios (Atom)
No hay comentarios:
Publicar un comentario