Pruebas De Programas

Laboratorio de Programación

Pruebas de
Programas

Julio Villena Román
jvillena@it.uc3m.es

Introducción
Errores de software

Un error en un
programa puede ser
algo muy serio

http://www.wired.com/software/coolapps/news/2005/11/69355?currentPage=all
(http://www.elmundo.es/elmundo/2005/11/11/ciencia/1131725311.html)
http://www5.in.tum.de/~huckle/bugse.htmlhttp://www.cs.tau.ac.il/~nachumd/verify/horror.html
2

Introducción
¿Qué es probar?

Probar es descubrir el mayor número posible de
errores en un programa
¡Ojo! No es convencerse de que el programa
está bien...
Eso ya se hace en las fases anteriores del desarrollo
del programa (o lo intentan)

Probar un programa es buscarle fallos “a mala
leche”
El objetivo es poner en evidencia al programa

3Introducción
La prueba exhaustiva es imposible

Lo ideal sería probar el programa en todas las
situaciones posibles
Esto es imposible desde cualquier punto de
vista:
Humano
Económico
Incluso matemático: bucles infinitos

Explosivo número de combinaciones
Habría que probar todas las posibles
variaciones en los datos de entrada
No podemos alcanzar la perfección... pero algo
habrá quehacer
4

Introducción
Organización: Fases de prueba

Prueba de Unidades
Caja Blanca
Cobertura de segmentos
Cobertura de ramas
Cobertura de condición/decisión
Cobertura de bucles

Caja Negra
Cobertura de requisitos

Pruebas de Integración
Pruebas de Aceptación

5

Prueba de Unidades
Se trata de probar módulos sueltos
Fase informal previa:
Ejecutar pequeños ejemplos
Hayherramientas que analizan
automáticamente la sintaxis de los programas
(¡e incluso “opinan” sobre fuentes potenciales de
error!)

Fase de prueba sistemática:
Pruebas de caja blanca (o transparente): Se mira
con lupa la estructura del código escrito
Pruebas de caja negra: Se prueba la
funcionalidad del módulo sin atender a su
contenido
6

Prueba de Unidades
Caja blanca

Tambiénllamadas:
pruebas estructurales
pruebas de caja transparente

Su objetivo es probar exhaustivamente la
estructura del código
Cobertura: es una medida del porcentaje de
código que ha sido probado o “cubierto” con las
pruebas. Hay varios tipos:
Cobertura de segmentos
Cobertura de ramas
Cobertura de condición/decisión
Cobertura de bucles

7

Prueba de Unidades
Caja blanca

Cobertura desegmentos (o de sentencias)
Segmento: secuencia de sentencias sin puntos de
decisión
El nº de sentencias es finito. Hay que ser
precavido a la hora de elegir cuándo parar
No se suele pasar por todas las sentencias sino
por una mayoría elegida adecuadamente

Prueba de Unidades
Caja blanca

Cobertura de ramas
¿Qué ocurre con los segmentos opcionales?
if (condición) {
EjecutaEsto()
}Hay que probar cuándo la condición se cumple y
cuándo falla
Refinamiento: hay que recorrer todas las posibles
salidas de los puntos de decisión (y excepciones)

Prueba de Unidades
Caja blanca

Cobertura de condición/decisión
¿Qué ocurre cuando la expresión booleana es
más compleja?
if (condición1 || condición2) {
HazEsto()
}

Sólo 2 ramas, pero 4 posibles combinaciones
Hay quedefinir un criterio de cobertura sobre las
combinaciones

10

Prueba de Unidades
Caja blanca

Cobertura de bucles
Los bucles son una fuente inagotable de errores.
Pruebas para un bucle WHILE:
1. 0 ejecuciones
2. 1 ejecución
3. Más de 1 ejecución

Pruebas para un bucle DO/WHILE:
1. 1 ejecución
2. Más de 1 ejecución

Pruebas para un bucle FOR:
Son muy seguros: bastaejecutarlos una vez (si dentro
no se altera la variable de control o algo así)
… pero conviene examinarlos por si acaso

Prueba de Unidades
Caja blanca

¿Qué hacer en la práctica?
Acercarse al 100% de segmentos
Lograr una buena cobertura de ramas
La buena cobertura depende del tipo de programa:
Juegos basta con probar 60-80% del código
Aplicaciones críticas (sanitarias, centrales nucleares,...