La prueba es la ejecución de un programa con la intención de encontrar un error.

Objetivos

• Descubrir un error.
• Una buena prueba es la que tiene una alta probabilidad de detectar un error.
• Una prueba tiene éxito si descubre un error no detectado hasta entonces.

Principios de la prueba

• Hacer un seguimiento de las pruebas hasta los requisitos. Los errores más graves son aquellos que impiden que el software cumpla con los requisitos del cliente.
• Planificar las pruebas desde antes que comiencen.
• Aplicar el principio de Pareto. El 20% de las instrucciones provocan el 80% de los errores.
• Comenzar las pruebas por lo pequeño (módulos individuales) y terminar en lo grande (todo el sistema).
• No hacer pruebas exhaustivas.
• Las pruebas deben ser conducidas por un grupo independiente.

Diseño de pruebas

• Pruebas de caja blanca.
  • Examinan los detalles procedimentales.
  • Comprueban los caminos lógicos.
  • Examinan el estado del programa en varios puntos.
• Pruebas de caja negra.
  • No toma en cuenta la estructura lógica.
  • Examinan si las entradas se aceptan de forma adecuada y si se produce un resultado correcto.
  • Revisa la integridad de la información externa (archivos).

Pruebas de caja blanca.

Prueba del camino básico

Genera casos de prueba que garanticen que se ejecuta, por lo menos una vez, cada instrucción del programa.

1. Usando el código dibujar el grafo de flujo.
2. Obtener la complejidad ciclomática V(G).
   V(G) = aristas - nodos + 2, o
   V(G) = nodos predicado + 1
   
3. Especificar un conjunto básico de caminos linealmente independientes. Un camino independiente está constituido por lo menos por una arista que no haya sido recorrida anteriormente a la definición del camino.
4. Preparar los casos de prueba que forzarán la ejecución de cada camino del conjunto básico.

Prueba de condición

Construye pruebas que ejecuten las condiciones lógicas.

Prueba de flujo de datos

Busca caminos de prueba de acuerdo a la definición y uso de las variables el programa. Si se limita el uso de variables globales, se puede eliminar estas pruebas.

Prueba de ciclos

Busca validar los ciclos.

• Ciclos independientes. Hacer casos de prueba para:
  • Pasar por alto el ciclo.
  • Entrar una sola vez.
  • Entrar dos veces.
  • Entrar m veces, con m < n.
  • Entrar n - 1, n y n + 1 veces.
• Ciclos anidados.
  • Aplicar las pruebas de ciclos independientes al ciclo más interno dejando los ciclos externos con sus valores mínimos.
  • Seguir hacia afuera, dejando los ciclos externos con sus valores mínimos y los internos con valores "típicos".
  • Continuar hasta probar todos los ciclos.
• Ciclos dependientes. Aplicar el enfoque usado para los ciclos anidados.

Pruebas de caja negra.

Partición equivalente.

Divide el dominio de la entrada del módulo en clases de datos de las cuales se pueden derivar casos de pruebas. Las clases se pueden derivar de acuerdo a cada variable de entrada:

• Si es un rango, se define una clase válida y dos no válidas.
• Si es un valor específico, se define una clase válida y dos no válidas.
• Si es miembro de un conjunto, se define una clase válida y una no válida.
• Si es booleana, se define una clase válida y una no válida.

Pruebas de valores límite

Desarrollar pruebas para ejercitar los valores límite en las entradas y salidas (p.e. generar el número máximo o mínimo de datos a desplegar).

Prueba de la interface gráfica de usuario (GUI)

Hacer casos de prueba para revisar:

• Ventanas.
  • Accesabilidad de los componentes dentro de la ventana.
  • Funciones operativas de la ventana (cerrar, mover, ajuste del tamaño).
  • Nombre de cada ventana.
  • Colores de la ventana de acuerdo a la especificación.
• Menús.
  • Contexto adecuado de los menús.
  • Nombres claros de las opciones.
  • Checar cada opción.
  • Checar los short-cuts.
  • Fuente y tamaño de texto adecuada.
  • Ayuda sensible al contexto.
• Entradas de datos.
  • Validación de los datos de entrada.
  • Mensajes de error adecuados.