Pruebas de Sistema

1. Pruebas de Caja Blanca

1.1. Prueba del camino básico

1.1.1. Notación de grafo de flujo

1.1.2. Complejidad ciclomática

1.1.3. Obtención de casos de prueba

1.1.4. Matrices de grafos

1.2. Prueba de la estructura de control

1.2.1. Prueba de condición

1.2.2. Prueba del flujo de datos

1.2.3. Prueba de bucles

1.2.3.1. Buques Simples

1.2.3.2. Buques Concatenados

1.2.3.3. Buques Anidados

1.2.3.4. Buques no Estructuraados

2. Pruebas de Caja Negra

2.1. Métodos de prueba basados en grafos

2.1.1. Modelado del flujo de transacción

2.1.2. Modelado de estado finito

2.1.3. Modelado del flujo de datos

2.1.4. Modelado de planificación

2.2. Partición equivalente

2.3. Análisis de valores límite

2.4. Prueba de comparación

2.5. Prueba de la tabla ortogonal

3. Prueba de Entornos Especializados, Arquitecturas, Aplicaciones

3.1. Prueba de interfaces gráficas de usuario

3.2. Prueba de arquitectura cliente/servidor

3.3. Prueba de la documentación y facilidades de ayuda

3.4. Prueba de sistemas de tiempo-real

3.4.1. Prueba de tareas

3.4.2. Prueba intertareas

3.4.3. Prueba del sistema

4. Principios de las Pruebas

4.1. A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente.

4.2. Las pruebas deberían planificarse mucho antes de que empiecen.

4.3. El principio de Pareto es aplicable a la prueba del software..

4.4. Las pruebas deberían empezar por «lo pequeño» y progresar hacia «lo grande».

4.5. No son posibles las pruebas exhaustivas.

4.6. Las pruebas deberían empezar por «lo pequeño» y progresar hacia «lo grande».

5. Objetivos de las Pruebas

5.1. La prueba es el proceso de ejecución de un programa con la intención de descubrir un error.

5.2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.

5.3. Una prueba tiene éxito si descubre un error no detectado hasta entonces.

6. Definición

6.1. Esta constituida por una serie de pruebas diferentes, todas ellas trabajan para verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.

6.2. El ingeniero crea una serie de casos de prueba que intentan «demoler» el software construido. De hecho, las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente) como destructivo en lugar de constructivo.