Ciclo de Pruebas de Software

Planificación y Diseño de Pruebas de software

Diseño de casos de prueba

Pruebas Basadas en Requerimientos

Ejemplo:Consideremos los requerimientos de un sistema de biblioteca universitaria.•El usuario será capaz de buscar en un conjunto inicial de bases de datos o bien seleccionar en un subconjunto de estas.•El sistema proporcionara vistas apropiadas para que el usuario pueda leer los documentos almacenados.•Cada petición debería contener un único identificador (ORDER_UD) que el usuario deberá ser capaz de copiar en el área de peticiones de almacenamiento permanente.

El usuario considera cada requerimiento y deriva un conjunto de pruebas para cada uno de ellos, las pruebas basadas en requerimientos son pruebas de validación en lugar de pruebas de defectos

Pruebas de particiones

Diseño de casos de prueba

Los datos de entrada y los resultados de salida de un programa normalmente se pueden agrupar en varias clases diferente que tienen características comunes

Debido a este comportamiento equivalente, estas clases de denominan a menudo particiones de equivalencia o dominios (Beizer, 1990).

Una buena práctica para la selección de casos de prueba es elegir casos de pruebas en los límites de las particiones junto con casos de prueba cercanos al punto medio

Las pruebas se derivan a partir de conocimiento de la estructura e implementación del software(caja blanca).

Diseño de casos de prueba Pruebas estructurales

Pruebas de Caminos

Diseño de casos de prueba

Son una estrategia de pruebas estructurales cuyo objetivo es probar cada camino de ejecución independiente en un componente o programa, ejecutándose todas las sentencias en el componente al menos una vez

Enfoque práctico recomendado para el diseño de casos

1. Si la especificación contiene combinaciones de condiciones de entrada, comenzar formando grafos de causa-efecto (ayudan la comprensión de dichas combinaciones).

2. En todos los casos, usar análisis de valores limites para añadir casos de pruebas: elegir límites para dar valores a las causas en los casos generados asumiendo que cada causa es una clase de equivalencia.

3. Identificar las clases válidas y no válidas de equivalencia para la entrada y la salida, y añadir los casos no incluidos anteriormente.

4. Utilizar la técnica de conjetura de errores para añadir nuevos casos, referidos a valores especiales.

5. Ejecutar los casos generados hasta el momento y analizar la cobertura obtenida.6. Examinar la lógica del programa para añadir los casos precisos (de caja blanca) para

cumplir el criterio de cobertura elegido si los resultados de la ejecución del punto anterior indican que no se ha satisfecho el criterio de cobertura elegido

Documentación del diseño de pruebas

Los distintos documentos de trabajo de las pruebas según el estándar IEEE std. 829 :

Plan de Pruebas:Señalar el enfoque, los recursos y el esquema de actividades de prueba, así como los elementos a probar, las características, las actividades de prueba, el personal responsable y los riesgos asociados

Especificación del Diseño de PruebasEspecificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e identificar las características que se deben probar con este diseño de pruebas

Especificación de Caso de PruebasDefinir uno de los casos de prueba identificando por una especificación del diseño de las pruebas

Especificaciones del Procedimiento de PruebaEspecificar los pasos para la ejecución de un conjunto de casos de prueba o, más generalmente, los pasos utilizados para analizar un elemento software con el propósito de evaluar un conjunto de características del mismo.