PDF de programación - Programación II Introducción a las Pruebas de Programas

Programación II

Introducción a las Pruebas de

Programas
Ángel Lucas González
Ángel Lucas González

Jaime Ramírez
Guillermo Román

DLSIIS. Facultad de Informática
Universidad Politécnica de Madrid

Definiciones(I)

• VERIFICAR: Comprobar que el sistema cumple

fielmente con lo especificado
fielmente con lo especificado

• VALIDAR: Comprobar que no hay errores
• ERROR:

Incorrección dentro de un módulo
software que conduce a un resultado incorrecto
• FALLO: Es la manifestación de un error en el

ftsoftware

• DEFECTO: Es una desviación en el valor

esperado para una cierta característica

2

•03/06/2010

•1

•03/06/2010

Definiciones(II)

• PRUEBA: Proceso en el que se ejecuta un

sistema con el objetivo de detectar fallos
sistema con el objetivo de detectar fallos

• DEPURACIÓN: Es el proceso en el que se
localiza el error que es la causa de un fallo, se
determina la forma de corregirlo, se evalúa el
efecto de la corrección y se lleva a cabo la
corrección
corrección.
– Después del proceso de depuración HAY QUE

REPETIR LAS PRUEBAS

3

Objetivo

• Realizar un barrido exhaustivo de todo el código es

impracticable por el coste que supone

• El coste de detectar un error suele ser mayor que el

de corrección

• Es fundamental seleccionar las pruebas
• Sólo las pruebas que revelen errores son las que

merecen la pena
El objeti o es ENCONTRAR ERRORES
• El objetivo es ENCONTRAR ERRORES
– Una prueba que no detecta un error es un

fracaso

– Una prueba que detecta errores es exitosa

4

•2

•03/06/2010

Proceso

Configuración
del software

Evaluación
Evaluación

Prueba

Depuración

Configuración
de la prueba

Resultado
Esperado

Pasar de nuevo
todas las pruebas

5

Características de una Prueba

• Ha de tener una alta probabilidad de encontrar

un fallo
un fallo.

• Debe centrarse en dos objetivos:

– Buscar si el software no hace lo que debe hacer
– Buscar si el software hace lo que no debe hacer

• No debe ser redundante.
• Una buena prueba no debería ser ni demasiado

sencilla ni demasiado compleja.

i d

i d

l

j

ill

• Las pruebas deben pasarse de manera
independiente unas de otras, para evitar
enmascarar errores.

6

•3

Tipos de prueba

• Las pruebas se realizan a lo largo de todo el

desarrollo del sistema:
– Prueba modular o unitaria
– Prueba de integración

• Top-down
• Bottom-up

– Prueba del sistema
– Prueba de aceptación
– Prueba de regresión

• Otros tipos de pruebas

– Pruebas de estrés
– Pruebas de carga

7

Tipos de prueba

Pruebas unitarias o modulares

• Prueban el correcto funcionamiento de un

módulo de código
módulo de código

• Características:
– Automatizable
– Repetibles o Reutilizables
– Completas
– Independientes
di

I d

t

• Deben estar correctamente documentadas

– Debe describir qué verifica y valida la prueba

8

•03/06/2010

•4

•03/06/2010

Diseño de Pruebas

• El diseño de las pruebas se dividen en dos:

– Técnicas de caja negra:

• Se centran en la funcionalidad del sistema.

– Técnicas de caja blanca:

• Se fundamentan en cómo está hecho el sistema.
Se utiliza el conocimiento sobre cómo está
Se utiliza el conocimiento sobre cómo está
codificado para definir las pruebas.

9

Pruebas de Caja Negra(I)

• La selección de los casos de prueba se basa en

cómo funciona el sistema
cómo funciona el sistema

• Las pruebas de caja negra exhaustiva son
inviables, se requiere una prueba por cada
combinación de los valores de entrada

• El caso bien elegido es el que reduce la
cubriendo un
cubriendo un

casos
casos,

necesidad de otros
necesidad de otros
conjunto extenso de estos

11

•5

Pruebas de Caja Negra(III)

/**
* Calcula el factorial de un número
* <br><B>PRE:</B> n > = 0
* <br><B>PRE:</B> n > = 0
* <br><B>POST:</B> res = n!
* @param n
* @return n!
*/
public static long factorial1 (int n) {
if (n < 0) throw new IllegalArgumentException();
if (n <= 1 )
return 1;
else
return n * factorial1 (n-1);

}

12

Pruebas de Caja Negra(II)

• Para probar el factorial:
t d

i bl h

I

l

l

– Inviable hacerlo con todos los números naturales.
– Debería probar con un i < 0, i =0, i > 0

ú

t

l

• Si i = 0 → 1
• Si i > 0 i!
• Si i < 0 → IllegalArgumentException

Entradas correctas

Entradas
incorrectas

¿Es necesario?

13

•03/06/2010

•6

•03/06/2010

Pruebas de Caja Negra(VII)

• Los métodos para seleccionar los casos de

prueba son:
prueba son:
– Método de clases de equivalencia
– Análisis de valores frontera o valores límite
– Adivinación de errores

17

Pruebas de Caja Negra(VIII)

(Clases de Equivalencia(I))

• Consiste en dividir las posibles entradas en

clases de equivalencia, de tal forma que todos
los miembros de una clase prueben las mismas
propiedades del sistema.

q

• Sólo es necesario seleccionar un elemento de

cada clase para realizar las pruebas.

,

q

• Las etapas son:

– Identificación de clases de equivalencia
– Crear los casos de prueba

q

18

•7

•03/06/2010

Pruebas de Caja Negra(VIII)

(Clases de Equivalencia(II))

• Para la identificación de clases haremos:

Las precondiciones para las entradas nos darán
– Las precondiciones para las entradas nos darán
dos o más grupos (ejemplo: números positivos
entre 2 y 99)

– También hay que considerar las restricciones en

• Válidas: Los valores cumplen las restricciones o

precondiciones de entrada

• No válidas: Entradas erróneas, no cumplen las

restricciones o precondiciones de entrada

las salidas

– Habrá dos tipos de clases:

19

Pruebas de Caja Negra(IX)

(Análisis de Valores Límite(I))

• “Los errores se esconden en los rincones y se

aglomeran en los límites”
aglomeran en los límites .

• Consiste en seleccionar como casos de prueba
aquellos que caen en la frontera de las clases
de equivalencia (situados en los márgenes de la
clase).

• Los casos de prueba que exploran las
• Los casos de prueba que exploran las

condiciones límite, producen mejores resultados
a la hora de detectar defectos.

25

•8

•03/06/2010

Pruebas de Caja Negra(IX)

(Análisis de Valores Límite(II))

• Diferencias con clases de equivalencia:

Se seleccionan los márgenes de la clase como
– Se seleccionan los márgenes de la clase como
casos de prueba.

– Han de comprobarse también los valores límite

de las salidas.

• La selección de los valores límite es heurística

es decir se basa en la experiencia

• Para determinarlos nos basamos en las

restricciones de las entradas y de las salidas.

26

Pruebas de Caja Negra(X)

(Adivinación de Errores)

• Consiste en “tratar” de imaginar cuáles son los

errores que se pueden haber cometido con
errores que se pueden haber cometido con
mayor probabilidad.

• No existen directivas, la técnica se basa en la

intuición de casos especiales.

• La experiencia ayuda a “predecir” los fallos más

probables de un sistema
probables de un sistema

28

•9

•03/06/2010

Pruebas de Caja Blanca (I)

• La elección de los casos de prueba se basa en
el conocimiento que se tenga acerca de la
estructura del módulo (diseño detallado, código
fuente, ...)

q

g

• La prueba ideal o exhaustiva consiste en

recorrer todas las secuencias de sentencias o
caminos dentro del programa

• En la mayoría de los casos las pruebas

exhaustivas son impracticables, porque el
l
número de caminos puede ser muy grande

ti bl

h

ti

i

29

Pruebas de Caja Blanca (II)

• Ejemplo: Un programa de 50 líneas con 25 “if”
en secuencia 225=33’5 millones de sucesiones
en secuencia 225=33 5 millones de sucesiones
o caminos distintos

• Sin embargo, pueden probarse ciertos caminos

o secuencias, elegidos según un criterio de
cobertura.

30

•10

•03/06/2010

Pruebas de Caja Blanca (III)

• Criterios:

-

– Cobertura de sentencia
– Cobertura de decisión de ramificación
– Cobertura de condición
– Cobertura de bucle

c
o
s
t
e

y


c
a
m
i
n
o
s

a

t
r
a
t
a
r

+

-

C
o
n
f
i
a
n
z
a

+

31

Pruebas de Caja Blanca (IV)

(Cobertura de Sentencias (I))

• Se utilizan los casos de prueba suficientes para

que cada sentencia se ejecute al menos una
que cada sentencia se ejecute al menos una
vez (if ... else ... es una sentencia)

• Es un criterio pobre y de escasa utilidad
• Un defecto en el cuerpo de un “IF” podría no ser

detectado (en alguna de las ramas)
g

• Puede detectar fragmentos de código

g

inaccesible (inútil)

32

•11

•03/06/2010

Pruebas de Caja Blanca (IV)

(Cobertura de Sentencias (II))

private boolean esValida() {
switch (this.mes) {// SW

Bastaría con que se ejecutara
una rama del switch

case ENERO: case MARZO: case MAYO: case JULIO:
case AGOSTO: case OCTUBRE: case DICIEMBRE: // Meses de 31 días

case FEBRERO:

if (this.dia >= 1 && this.dia <= 31) return true;
else return false;
if (esBisiesto()&& this.dia >= 1 && this.dia <= 29)
return true;
else
if (this.dia >= 1 && this.dia <= 28) return true;
else return false;

case ABRIL:
case JUNIO:
case SEPTIEMBRE:

}// SW
return false;
}

return this.dia >= 1 && this.dia <= 30;

33

Pruebas de Caja Blanca (V)
(Cobertura de Decisión de Ramificación(I))

• Se han de determinar casos suficientes como
para que cada decisión sea evaluada al menos
para que cada decisión sea evaluada al menos
una vez como verdadera y otra como falsa

• Es un criterio débil. Un error en un elemento de

la condición puede no ser detectado, ya que
para que una condición sea cierta o falsa no es
preciso evaluar todos los elementos de ésta.

34

•12

•03/06/2010

Pruebas de Caja Blanca (V)
(Cobertura de Decisión de Ramificación(II))

private boolean esValida() {
switch (this.mes) {// SW

Habría que probar con: Enero,
Febrero y Abril

case FEBRERO:

case ENERO: case MARZO: case MAYO: case JULIO:
case ENERO: case MARZO: case MAYO: case JULIO:
case AGOSTO: case OCTUBRE: case DICIEMBRE: // Meses de 31 días

if (this.dia >= 1 && this.dia <= 31) return true;
else return false;
Con “día >=1 y dia <= 31” y
Con día > 31
if (esBisiesto()&& this.dia >= 1 && this.dia <= 29)
return true;
else
if (this.dia >= 1 && this.dia <= 28) return true;
else return false;
e se
a s