Tema 6 Pruebas

Ingeniería del Software
Tema 6. Pruebas del Software

Bibliografía
 [BOL07] Bolaños, Sierra, Alarcón. Pruebas del
software y JUnit. Prentice Hall 2007
 [MUS07] Mustafa, K. Khan, R.A., Software Testing.
Concepts and Practices. Alpha Science 2007
 [PIA02] Piattini et al., Aplicaciones informáticas de
gestión. Ra-Ma 2002
 [PRE10] Pressman, R.S. Ingeniería del Software.
Un enfoque práctico. Mc Graw Hill 2010
 Métrica v3:
http://www.csi.map.es/csi/metrica3/index.html
 [SOM06] Sommerville, I. Ingeniería de Software.
Addison Wesley 2006
Tema 6. Pruebas del Software 2
Índice
 Introducción
 Enfoque estructural
 Enfoque funcional
 Herramientas
 Estrategias de prueba del software

Prueba del software
 Proceso que ayuda a identificar la corrección,

completitud, seguridad y calidad del software
desarrollado
 Prueba es el proceso de ejecutar un conjunto de
elementos software con el fin de encontrar errores
 Probar no es demostrar que no hay errores en el
programa ni únicamente mostrar que el programa
funciona correctamente
 El objetivo de las pruebas es descubrir errores y fallos
cometidos durante las fases anteriores del desarrollo

Prueba del software
 Verificación:
Proceso de evaluación de un sistema para determinar si
los productos de una fase dada satisfacen las condiciones
impuestas al comienzo de la misma
¿estamos construyendo correctamente el producto?
 Validación:
Proceso de evaluación de un sistema durante o al final del
proceso de desarrollo para determinar si satisface los
requisitos marcados por el usuario
¿estamos construyendo el producto correcto?

Prueba del software
DEFINICIONES
 Pruebas (test): una actividad en la cual un sistema o uno de sus
componentes se ejecuta en circunstancias previamente
especificadas, los resultados se observan y registran y se realiza una
evaluación de algún aspecto
 Caso de prueba (test case): un conjunto de entradas, condiciones
de ejecución y resultados esperados desarrollados para un objetivo
particular
 Defecto (defect, fault, bug): un defecto en el software como, por
ejemplo, un proceso, una definición de datos o un paso de
procesamiento incorrectos en un programa
 Fallo (failure): La incapacidad de un sistema o de alguno de sus
componentes para realizar las funciones requeridas dentro de los
requisitos de rendimiento especificados
 Error (error): La diferencia entre un valor calculado, observado o
medido y el valor verdadero, especificado o teóricamente correcto

Prueba del software

Prueba del software
La prueba exhaustiva del software es impracticable (no se
pueden probar todas las posibilidades de su funcionamiento
ni siquiera en programas sencillos)
El objetivo de las pruebas es la detección de defectos en el
software (descubrir un error es el éxito de una prueba)
Mito: un defecto implica que somos malos profesionales y que
debemos sentirnos culpables
 El descubrimiento de un defecto significa un éxito para la

mejora de la calidad

Prueba del software
RECOMENDACIONES
 El programador debe evitar probar sus propios
programas.
 Al generar casos de prueba, se deben incluir tanto
datos de entrada válidos y esperados como los no
válidos e inesperados
 Las pruebas deben centrarse en dos objetivos ( es
habitual olvidar el segundo):
1. Probar si el software hace lo que debe hacer
2. Probar si el software no hace lo que no debe
hacer, es decir, si provoca efectos secundarios
adversos
Prueba del software
RECOMENDACIONES
 Se deben evitar los casos desechables, es decir, los no
documentados ni diseñados con cuidado (suele ser
necesario probar muchas veces el software y por tanto
hay que tener claro qué funciona y qué no)
 No deben hacerse planes de prueba suponiendo que,
prácticamente, no hay defectos en los programas y, por
lo tanto, dedicando pocos recursos a las pruebas
 La experiencia parece indicar que donde hay un
defecto hay otros, es decir, la probabilidad de descubrir
nuevos defectos en una parte del software es
proporcional al número de defectos ya descubiertos
Prueba del software
 ¿Labor destructiva y rutinaria? Este es el mito, aunque

en realidad es una tarea tanto o más creativa que el
desarrollo del software
 Objetivos de las pruebas:
1. La prueba es el proceso de ejecución de un
programa con la intención de descubrir un error
2. Un buen caso de prueba es aquel que tiene una alta
probabilidad de descubrir un error no encontrado
hasta entonces
3. Una prueba tiene éxito si descubre un error no
detectado hasta entonces

Prueba del software
 Índice de la fiabilidad del software:
“La prueba no puede asegurar la ausencia de
defectos: sólo puede demostrar que existen defectos
en el software”.
 No es una actividad secundaria:
 30-40% del esfuerzo de desarrollo
 En aplicaciones críticas (p.ej. control de vuelo,
reactores nucleares),
¡de 3 a 5 veces más que el resto de pasos juntos de
la ingeniería del software!

Diseño de casos de prueba
 Seguridad total: prueba exhaustiva

(no practicable)
 Objetivo: conseguir confianza aceptable en que se
encontrarán todos los defectos existentes, sin
consumir una cantidad excesiva de recursos
 Diseñar las pruebas que tengan la mayor probabilidad
de encontrar el mayor número de errores con la
mínima cantidad de esfuerzo y tiempo posible

Tareas básicas
1. Diseño del plan de pruebas
Se lleva a cabo en las etapas de Análisis y Diseño.
Consta de:
• Planificación temporal de las pruebas (cuándo, cómo,
quién va llevarlas a cabo)
• Estrategia de pruebas (ascendente, descendente,...)
• Procedimiento a seguir cuando no es satisfactoria
• Asignación de responsabilidades...
2. Diseño de casos de prueba
3. Prueba
4. Comparación y evaluación de resultados
5. Localización del error

Diseño de casos de prueba.
Enfoques principales

Diseño de casos de prueba.
Enfoques principales
a) Enfoque estructural o de caja blanca (transparente):
 se centra en la estructura interna del programa para
elegir los casos de prueba

 la prueba exhaustiva consistiría en probar todos los
posibles caminos de ejecución

 nº caminos lógicos  ( buscar los más importantes)
b) Enfoque funcional o de caja negra:

 para derivar los casos de prueba, se estudia la
especificación de las funciones, la entrada y la salida
¡No son excluyentes!

Prueba de caja blanca (Estructural)
Se conoce la estructura interna del código a probar

 Evaluación: Medida de la “cobertura”
 Problema: Algunos errores pueden quedar sin
detectar:
 No se prueba la especificación
 No se detectan ausencias

Prueba de caja negra (Funcional)
Se centra en los requisitos funcionales del software,

ignorando la estructura interna del código
 Pruebas conducidas por las entradas y salidas

 Evaluación: Comportamiento de acuerdo a las
especificaciones
 Problema: Infinitas posibilidades para las entradas

Prueba de caja blanca.
Criterios de cobertura lógica
Menos
riguroso
(más barato)
 Cobertura de sentencias
 Cobertura de decisiones
 Cobertura de condiciones
 Criterio de decisión/condición
 Criterio de condición múltiple
 Criterio de cobertura de caminos
Más riguroso
(más caro)

Cobertura de sentencias
Generar casos de prueba que permitan probar

cada sentencia del código al menos una vez.
Para el ejemplo:
A=2, B=0, X=3
PERO: Es un criterio muy débil.

¿Qué pasaría si por error, el programador se
confunde y en vez de un AND escribe un OR?
¿Y que pasaría si en la segunda tuviese que ser
X>0 en vez de X>1?

Cobertura de Decisiones (Cob. de ramas)
Escribir los suficientes casos de prueba para que

cada decisión del código tome los valores
CIERTO y FALSO al menos una vez.
Es un criterio más fuerte que el de cobertura de
sentencias, de hecho, lo incluye.
Para el ejemplo, con los casos de prueba:

A=3, B=0, X=3
A=1, B=1, X=1
se cubriría el 100% de las decisiones
¿Qué pasaría si en la segunda decisión, la condición
X>1 tuviese que ser X<1?
Cobertura de condiciones
Encontrar los casos de prueba que hagan que

cada condición de una decisión tome todos los
posibles valores al menos una vez.
Suele ser un criterio de cobertura superior a los
anteriores.
Para el ejemplo, hay que escribir casos de prueba
que cumplan que:
A>1 y A1
B=0 y B0
A=2 y A  2
X>1 y X1

>>SIGUE>>
Por tanto, bastará con encontrar 2 casos de prueba
que cumplan:
1º) A=2 (A>1), B=0 y X>1
2º) (A  2) A1, B  0 y X<=1
A B X A>1 B=0 A=2 X>1

2 0 4 C C C C
1 1 1 F F F F
NOTA: hay más posibilidades, las condiciones para la
B y la X pueden intercambiarse entre el 1º) y el 2º)
¿Incluye este criterio el criterio de cobertura de
decisiones?
¿Incluye este criterio el criterio de cobertura de
sentencias?

Cobertura de decisión/condición
Cumplir los criterios de decisión y condición: al menos
una vez durante la ejecución del programa, todas las
decisiones tienen que tomar el valor CIERTO y FALSO
y todas las condiciones tienen que tomar el valor
CIERTO y FALSO.
Para el ejemplo, hay que conseguir casos de prueba que
hagan que cada una de las 4 condiciones existentes:
A>1
B=0
A=2
X>1
sea CIERTA y FALSA al menos una vez y que cada una de
las decisiones:
A>1 AND B=0
A=2 OR X>1
sea CIERTA y FALSA al menos una vez.
>>sigue>>
Por ejemplo, con los casos de prueba se
lograría una cobertura completa de
condición/decisión:
A B X A>1 B=0 A=2 X>1 A<1 AND B=0 A=2 OR X>1
2 0 4 C C C C C C
1 1 1 F F F F F F
Aparentemente, parece que este criterio ejercita

todas las combinaciones de las condiciones.
Pero...no es así.
¿Qué pasaría si la operación lógica tuviese que
ser OR en vez de AND?
Cobertura de múltiple condición
Probar todas las posibles combinaciones de las
condiciones en cada decisión.
Incluye los criterios de cobertura de decisiones, cobertura
de condiciones y cobertura de condición/decisión.
Hay que conseguir casos de prueba que cumplan cada una
de las siguientes combinaciones:
1) A>1, B=0
2) A>1, B 0
3) A1, B=0
4) A1, B 0
5) A=2, X>1
6) A=2, X1
7) A 2, X>1
8) A 2, X1
>>sigue>>
Con 4 casos de prueba se puede alcanzar la cobertura
completa de múltiple condición:
A=2, B=0, X=4 cubre 1) y 5)
A=2, B=1, X=1 cubre 2) y 6)
A=1, B=0, X=2 cubre 3) y 7)
A=1, B=1, X=1 cubre 4) y 8)
Problema: En ocasiones es imposible cubrir todas las
combinaciones. Por ejemplo, para la decisión (A>2 AND
A<10) se tendrían que encontrar casos de prueba que
cumpliesen:
A>2, A<10
A>2, A10
A2, A<10
A2, A10 =>IMPOSIBLE
Prueba de bucles (Beizer 90)
 Bucles simples (“n” es el nº máx. de iteraciones):

 Pasar por alto totalmente el bucle
 Pasar una sola vez por el bucle
 Pasar dos veces por el bucle
 Hacer m pasos por el bucle, con m<n
 Hacer n-1, n y n+1 pasos por el bucle
 Bucles no estructurados:
 rediseñar primero

Prueba de bucles (Beizer 90)
 Bucles anidados (para evitar progresión geométrica):

 Llevar a cabo las pruebas de bucles simples con el
bucle más interior. Configurar el resto de bucles

con sus valores mínimos (forzar entrada)
 Progresar hacia fuera, llevando a cabo pruebas
para el siguiente bucle, manteniendo los bucles

externos en sus valores mínimos y los internos en
sus valores “típicos” (forzar la No entrada)

Prueba de caja blanca. Prueba del camino
básico (Mc Cabe 76)
Objetivos:
1. Obtener una medida de la complejidad lógica de
un diseño procedimental
 Complejidad ciclomática de Mc Cabe
2. Usar esa medida como guía para la definición de un
conjunto básico de caminos de ejecución (caminos
de prueba)
 Los casos de prueba obtenidos garantizan que
durante la prueba se ejecuta al menos una vez cada
sentencia del programa (cobertura de sentencias) y
que cada condición y cada decisión toman valor cierto
y falso (cobertura de decisión/condición)
básico.
Pasos a seguir para aplicar esta técnica:
1. Construir el grafo de flujo a partir del programa

2. Calcular la complejidad “ciclomática”
3. Determinar los caminos de prueba
4. Derivar los casos de prueba que fuerzan la ejecución de
cada camino de prueba
5. Determinar la salida esperada para cada caso de prueba
6. Ejecutar el programa con los casos de prueba y comparar
la salida obtenida con la esperada

Prueba de caja blanca. Notación de grafo de
flujo
Las condiciones compuestas (decisiones) se

separan en varios nodos:

Prueba de caja blanca. Grafo de flujo

básico. Definiciones
 Camino: secuencia de sentencias encadenadas desde la sentencia
inicial del programa hasta su sentencia final
 Camino de prueba: un camino que atraviesa, como máximo, una vez
el interior de cada bucle que encuentra.
(Algunos autores recomiendan pasar 3 veces:
una sin entrar en su interior
otra entrando una vez
otra entrando dos veces)
 Camino linealmente independiente de otros: introduce por lo
menos un nuevo conjunto de sentencias de proceso o una nueva
condición
 en términos del grafo de flujo, introduce una nueva arista
(arco) que no haya sido recorrida anteriormente a la definición del
camino

Complejidad de Mc Cabe
 Métrica del software que da una medida cuantitativa de la

complejidad lógica (estructural) de un programa
 Indica el número de caminos independientes del programa
 Se obtiene a partir del grafo:
V(G) = a - n + 2
(“a”, nº de arcos del grafo; “n”, nº de nodos)
V(G) = r
(“r”, nº de regiones cerradas del grafo)
V(G) = c +1 (“c”, nº de nodos de condición)
(Los nodos de condición “Case” no cuentan como 1
sino como su número de salidas -1)
Complejidad
de Mc Cabe. Ejemplo
V(G)=arcos-nodos+1= 14-11+2 = 5
V(G)=nº de regiones cerradas = 5
(contar la región exterior)
V(G)= nodos de condición + 1 = 4+1 = 5

Determinar los caminos de prueba
 Un camino independiente es cualquier camino del programa que
introduce, por lo menos, un nuevo conjunto de sentencias de
proceso o una condición, respecto a los caminos existentes
 En términos del diagrama de flujo, un camino independiente está
constituido por lo menos por una arista que no haya sido recorrida
anteriormente a la definición del camino
 En la identificación de los distintos caminos de un programa para
probar se debe tener en cuenta que cada nuevo camino debe
tener el mínimo número de sentencias nuevas o condiciones
nuevas respecto a los que ya existen. De esta manera se intenta
que el proceso de depuración sea más sencillo
 El conjunto de caminos independientes de un grafo no es único.
No obstante, algunas heurísticas para identificar dichos caminos
son:

Determinar los caminos de prueba
a. Elegir un camino principal que represente una función válida que
no sea un tratamiento de error. Debe intentar elegirse el camino
que atraviese el máximo número de decisiones en el grafo
b. Identificar el segundo camino mediante la localización de la
primera decisión en el camino de la línea básica alterando su
resultado mientras se mantiene el máximo número de decisiones
originales del camino inicial
c. Identificar un tercer camino, colocando la primera decisión en su
valor original a la vez que se altera la segunda decisión del
camino básico, mientras se intenta mantener el resto de
decisiones originales
d. Continuar el proceso hasta haber conseguido tratar todas las
decisiones, intentando mantener como en su origen el resto de
ellas

Caminos de prueba.
Ejemplo
C1: 1-2-3-4-5-6-7-9-4-10-2-11
C2: 1-2-3-4-5-6-8-9-4-10-2-11
C3: 1-2-3-4-5-10-2-11
C4: 1-2-3-4-10-2-11
C5: 1-2-11

Derivación de casos de prueba
 El último paso es construir los casos de prueba que
fuerzan la ejecución de cada camino
 Además, se debe dar la salida esperada para cada
caso de prueba para poderla comparar con la real
cuando se ejecute el programa. Una forma de
representar el conjunto de casos de prueba es como se
muestra en la tabla siguiente:
Caminos de prueba Casos de prueba Salida esperada

Complejidad ciclomática. Conclusiones
Según Beizer 90:

 V(G) marca un límite mínimo del nº de casos de prueba,
contando cada condición de decisión como un nodo
individual
 Parece que cuando V(G) es mayor que 10 la probabilidad
de defectos en el módulo crece bastante (si dicho valor
alto no se debe a sentencias CASE)
(en ese caso, es recomendable replantearse el diseño
modular)

Prueba de caja negra (Funcional)
 Estas pruebas se basan en la especificación del programa o módulo a
probar para elaborar los casos de prueba. El módulo se ve como una
“Caja Negra” cuyo comportamiento sólo puede ser determinado
estudiando sus entradas y las salidas obtenidas a partir de ellas
 Como el estudio de todas las posibles entradas y salidas de un
programa sería impracticable se selecciona un conjunto de ellas sobre
las que se realizan las pruebas
 Dado que la prueba exhaustiva es imposible, el objetivo final es
encontrar una serie de datos de entrada cuya probabilidad de
pertenecer al conjunto de entradas que causan un comportamiento
erróneo sea lo más alto posible
 Para confeccionar los casos de prueba de Caja Negra existen distintos
criterios. Algunos de ellos son:
 Particiones de Equivalencia
 Análisis de Valores Límite

Particiones o clases de equivalencia
 Este método divide el dominio de entrada de un programa en un
número finito de clases de equivalencia, de tal modo que se pueda
asumir razonablemente que una prueba realizada con un valor
representativo de cada clase es equivalente a una prueba realizada
con cualquier otro valor de dicha clase.
 Si el caso de prueba correspondiente a una clase de equivalencia
detecta un error, el resto de los casos de prueba de dicha clase de

equivalencia deben detectar el mismo error
 Si un caso de prueba no ha detectado ningún error, es de esperar
que ninguno de los casos de prueba correspondientes a la misma

clase de equivalencia encuentre ningún error
 Método de diseño, dos pasos:
1. Identificación de clases de equivalencia
2. Creación de los casos de prueba correspondientes

Paso 1. Identificar las clases de equivalencia
1.1. Identificar las condiciones de las entradas del programa
1.2. A partir de ellas, se identifican las clases de equivalencia:
 De datos válidos
 De datos no válidos
1.3. Algunas reglas para identificar clases:
1. Por cada rango de valores, se especifica una clase válida y dos
no válidas
Ejemplo:
(válida) 1  número  49
(no válidas) número < 1, número > 49
2. Si se especifica un nº de valores, se creará una clase válida y dos

no válidas
Ejemplo:
(válida) num propietarios = 3;
(no válidas) num propietarios < 3, num propietarios > 3
3. Si se especifica una situación del tipo “debe ser” o booleana, se
identifica una clase válida y una no válida
Ejemplo:
(válida) “El primer carácter es una letra”
(no válida) “El primer carácter no es una letra”
(válida) “X es un número”
(no válida) “X no es un número”

4. Si se especifica un conjunto de valores admitidos, y el
programa trata de forma distinta cada uno de ellos, se crea una
clase válida por cada valor, y una no válida
Ejemplo:
Tres tipos de inmuebles: (válidas) “pisos”, “unifamiliares”,
“locales comerciales”
(no válida) “jkllñ”
5. En general, si los elementos de una clase de equivalencia se

tratan de diferente forma por el programa, se debe dividir la
clase en otras más pequeñas para cada tipo de elementos

Paso 2. Identificar los casos de prueba
2.1. Asignación de un número único a cada clase de

equivalencia
2.2. Hasta que todas las clases de equivalencia hayan
sido cubiertas por casos de prueba, se tratará de
escribir un caso que cubra tantas clases válidas no
incorporadas como sea posible
2.3. Hasta que todas las clases de equivalencia no válidas
hayan sido cubiertas por casos de prueba, escribir un
caso para una ÚNICA clase no válida sin cubrir

Ejemplo
Ejemplo: Aplicación bancaria en la que el operador debe
proporcionar un código, un nombre y una operación
Habría que diseñar casos de prueba que cubran todas las clases de
equivalencia, tanto para las válidas como para las no válidas, y
para éstas en casos de prueba distintos
Casos de prueba
Para clases válidas
Caso de prueba (clases cubiertas) Salida esperada
200, reinte, cheque (1, 5, 8)
200, reinte, depósito (1, 5, 9)
200, reinte, pago factura (1, 5, 10)
200, reinte, retirada de fondos (1, 5, 11)
Para clases no válidas
Caso de prueba (clases cubiertas) Salida esperada
199, reinte, cheque (2)
1000, reinte, cheque (3)
A, reinte, cheque (4)
200, re, cheque (6)
200, reintegro, cheque (7)
200, reinte, actualizar libreta (12)
Análisis de Valores Límite (AVL)
 Los casos de prueba que exploran las condiciones

límite (los valores de los márgenes de las clases de
equivalencia) producen mejores resultados
“Los defectos del software se acumulan en las
situaciones límite”
 Diferencias de AVL con particiones de equivalencia:
 No se elige “cualquier elemento” de la clase de
equivalencia, sino uno o más de manera que los

márgenes se sometan a prueba
 Los casos de prueba se generan considerando
también el espacio de salida

Análisis de Valores Límite.
Reglas para identificar casos
1. Si una condición de entrada especifica un rango delimitado por
los valores a y b, se deben generar casos para a y b y casos no
válidos justo por debajo de a y justo por encima de b
2. Si una condición de entrada especifica un número de valores, se
deben desarrollar casos de prueba que ejerciten los valores
máximo y mínimo, uno más el máximo y uno menos el mínimo.
3. Aplicar las directrices 1 y 2 a las condiciones de salida.
 Los valores límite de entrada no generan necesariamente los
valores límite de la salida
 No siempre se pueden generar resultados fuera del rango de
salida (pero es interesante considerarlo)
4. Si las estructuras de datos internas tienen límites preestablecidos,
hay que asegurarse de diseñar un caso de prueba que ejercite la
estructura de datos en sus límites.

Análisis de Valores Límite.
Reglas para identificar casos
1. Si una condición de entrada especifica un rango delimitado por los valores a y b,
se deben generar casos para a y b y casos no válidos justo por debajo de a y justo
por encima de b
 Rango de entrada: [-1.0, 1.0]
 Casos de prueba para –1.0, +1.0, -0.9, +1.001 (si se
admiten 3 decimales)
2. Si una condición de entrada especifica un número de valores, se deben
desarrollar casos de prueba que ejerciten los valores máximo y mínimo, uno más
el máximo y uno menos el mínimo
 “El fichero de entrada tendrá de 1 a 255 registros”
 Casos para 0, 1, 255, 256 registros
3. Aplicar las directrices 1 y 2 a las condiciones de salida
 “El programa podrá mostrar de 1 a 4 listados”
 Casos para intentar generar 0, 1, 4 y 5 listados
Conjetura de Errores
Se enumera una lista de posibles equivocaciones típicas que

pueden cometer los desarrolladores y de situaciones propensas a
ciertos errores:
 El valor cero es una situación propensa a error tanto en la salida
como en la entrada
 En situaciones en las que se introduce un número variable de
valores, conviene centrarse en el caso de no introducir ningún valor
y en el de un solo valor. También puede ser interesante un lista que
tiene todos los valores iguales
 Es recomendable imaginar que el programador pudiera haber
interpretado algo mal en la especificación
 También interesa imaginar lo que el usuario puede introducir como
entrada a un programa
 ...
Enfoque práctico recomendado para el
diseño de casos de prueba
Se propone un uso más apropiado de cada técnica (caja blanca y negra)
para obtener un conjunto de casos útiles:
 En todos los casos, usar el análisis de valores límite para añadir casos
de prueba
 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
 Utilizar la técnica de conjetura de errores para añadir nuevos casos,
referidos a valores especiales
 Ejecutar los casos generados hasta el momento y analizar la cobertura
obtenida
 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

Enfoque práctico recomendado para el
diseño de casos de prueba
Una cuestión importante es ¿por qué son necesarias las pruebas de
caja blanca si comprobamos que las funciones se realizan
correctamente?
 Los errores lógicos y las suposiciones incorrectas son inversamente

proporcionales a la probabilidad de que se ejecute un camino del
programa (a menor probabilidad de ejecutarse un camino, mayor
número de errores)
 Se suele creer que un determinado camino lógico tiene pocas
posibilidades de ejecutarse cuando, de hecho, se puede ejecutar
regularmente
 Los errores tipográficos son aleatorios; pueden aparecer en cualquier
parte del programa (sea muy usada o no)
 La probabilidad y la importancia de un trozo de código suele ser
calculada de forma muy subjetiva
Estrategia de prueba del software. Niveles
de prueba
1. Prueba de unidad: es la prueba de cada módulo (clase), que

normalmente realiza el propio personal de desarrollo en su entorno
2. Prueba de integración: con el esquema del diseño del software, los
módulos probados se integran para comprobar sus interfaces en el
trabajo conjunto
3. Prueba de validación: el software totalmente ensamblado se
prueba como un todo para comprobar si cumple los requisitos
funcionales y de rendimiento, facilidad de mantenimiento,
recuperación de errores, etc.
4. Prueba del sistema: el sw. ya validado se integra con el resto del
sistema (rendimiento, seguridad, recuperación y resistencia)
5. Prueba de aceptación: el usuario comprueba en su propio entorno
de explotación si lo acepta como está o no
Relación entre productos de desarrollo y
niveles de prueba
Requisitos de Pruebas de
usuario aceptación
Especificación de
Pruebas de sistema
requisitos
Diseño modular Pruebas de integración
Especificación
Pruebas de unidad
lógica del módulo
Código
Prueba de unidad
 Hablamos de una unidad de prueba para referirnos a uno o más

módulos (clases) que cumplen las siguientes condiciones [IEEE,
1986a]:
 Todos son del mismo programa
 Al menos uno de ellos no ha sido probado
 El conjunto de módulos es el objeto de un proceso de prueba
 Se trata de las pruebas formales que permiten declarar que un

módulo está listo y terminado (no las informales que se realizan
mientras se desarrollan los módulos)
 La prueba de unidad puede abarcar desde un módulo hasta un
grupo de módulos (incluso un programa completo)
 Estas pruebas suelen realizarlas el propio personal de desarrollo,
pero evitando, si es posible, que sea el propio programador del
módulo

Prueba de unidad en desarrollo OO
 Aunque en código OO los métodos son las unidades mínimas de
ejecución, las clases constituyen el marco fundamental de la
prueba, ya que:
 Al probar un método de un objeto es necesario conocer el
estado del objeto

 Los métodos de un objeto no pueden ser probados (invocados)
en cualquier orden ya que la ejecución de un método puede

cambiar el estado del objeto del que depende otro u otros
métodos
 Se suele crear una clase de prueba para cada clase que se quiere
probar (clase objetivo). Contendrá el código necesario para la
ejecución de los diferentes casos de prueba definidos para probar
la clase objetivo
 La clase de pruebas instanciará la clase a probar

Elementos a probar:
 Constructores
 Métodos get y set
 Métodos “convencionales”

Prueba de constructores:
 Carecen de valor de retorno
 No es fácilmente observable el resultado de su ejecución.
La prueba consistiría en invocar al constructor y comparar
el objeto obtenido con el objeto esperado, pero ¿cómo se
obtiene el objeto esperado si no es mediante su
constructor?
 Debe hacerse mediante la técnica de caja blanca. Basta
con invocar al constructor con una serie de valores y
comparar el valor de tales propiedades con dichos valores.
Para ello se suelen utilizar los métodos get (prueba de los
métodos get a la vez del constructor)
Prueba de métodos get y set:
1. Se instancia un objeto de la clase

2. Se almacena un valor en el atributo con el método set de acuerdo al
caso de prueba
3. Se obtiene el valor del atributo con el método get
4. Se comparan ambos valores
 Si se dispone del código (caja blanca) y los métodos get y set acceden
directamente (sin ninguna “traducción” intermedia), la prueba descrita
anteriormente parece absurda, solo puede fallar si falla la plataforma
(compilador,...)
 Aun así, no es descartable esta prueba. La razón es la mantenibilidad
preventiva, si la implementación de los métodos get y set cambia, el
software de pruebas estaría preparado para ello

Prueba de métodos “convencionales”
Factores que condicionan la ejecución de un método:

 Parámetros de entrada
 Estado interno del objeto
 Estado de otros objetos con los que colabora
 Entidades externas que constituyen el entorno de ejecución

Consecuencias posibles de la ejecución de un método:

 Valor de retorno del método
 Efectos producidos sobre los parámetros
 Excepciones lanzadas por el método
 Cambio del estado interno del objeto
 Efectos externos al objeto (objetos colaboradores)

De lo expuesto anteriormente se deduce que la generación

de los casos de prueba dependerá del tipo concreto de
método que se desee probar
 Método sin parámetros de entrada: los casos de prueba

definidos deberán centrarse en aquellos otros factores que
condicionan su ejecución
 Método sin valor de retorno: la prueba deberá enfocarse
sobre aquellos otros efectos observables de su ejecución

Prueba de integración
 Implican una progresión ordenada de pruebas que van

desde los componentes o módulos y que culminan en el
sistema completo
 El orden de integración elegido afecta a diversos
factores, como los siguientes:
 La forma de preparar casos
 Las herramientas necesarias
 El orden de codificar y probar los módulos
 El coste de la depuración
 El coste de preparación de casos

Prueba de integración
Tipos fundamentales de integración
 Integración incremental. Se combina el siguiente módulo

que se debe probar con el conjunto de módulos que ya han
sido probados
 ascendente. Se comienza por los módulos hoja
 descendente. Se comienza por el módulo raíz
 Integración no incremental. Se prueba cada módulo por

separado y luego se integran todos de una vez y se prueba el
programa completo
 Habitualmente las pruebas de unidad y de integración se

solapan y mezclan en el tiempo (con integración incremental)
Integración Incremental Ascendente
Proceso:
1. Se combinan los módulos de bajo nivel en grupos que realicen

una función o subfunción específica (o quizás, si no es
necesario, individualmente) de este modo reducimos el número
de pasos de integración
2. Se escribe para cada grupo un módulo “impulsor” o “conductor”
(“test driver”) de este modo permitimos simular la llamada a los
módulos, introducir datos de prueba y recoger resultados
3. Se prueba cada grupo mediante su impulsor
4. Se eliminan los módulos impulsores y se sustituyen por los
módulos de nivel superior en la jerarquía

Supongamos esta estructura:

1ª fase, se definen los impulsores para nodos hoja y se
ejecutan:

2ª fase, pruebas de unidad (B y C) y de integración (B con
E y C con F y G):
Impulsor de Impulsor de
B C

3ª fase, pruebas de integración (A con B, C y D):

Integración Incremental Descendente
 Comienza por el módulo de control principal y va
incorporando módulos subordinados progresivamente
 No hay un orden establecido de integración, pero unos
consejos son los siguientes:
 Si hay secciones críticas (especialmente complejas) se
deben integrar lo antes posible
 El orden de integración debe incorporar cuanto antes los
módulos de entrada/salida para facilitar la ejecución de
pruebas
 Existen dos formas básicas de hacer esta integración:
 Primero en profundidad: Se van completando ramas del
árbol (en el ejemplo anterior A B E C F G D)
 Primero en anchura: Se van completando niveles de
jerarquía (A B C D E F G)
UN PASO INTERMEDIO EN LA INTEGRACION
DESCENDENTE PRIMERO EN PROFUNDIDAD DEL
EJEMPLO

UN PASO INTERMEDIO EN LA INTEGRACION
DESCENDENTE PRIMERO EN ANCHURA DEL
EJEMPLO

Etapas:
1. El módulo raíz es el primero: Se escriben módulos “ficticios”
(“test stub”) que simulan a los subordinados
2. Una vez probado el módulo raíz (sin detectarse ya ningún
defecto), se sustituye uno de los subordinados ficticios por el
módulo correspondiente según el orden elegido
3. Se ejecutan las correspondientes pruebas cada vez que se
incorpora un módulo nuevo
4. Al terminar cada prueba, se sustituye un ficticio por su
correspondiente real
5. Conviene repetir algunos casos de prueba de ejecuciones
anteriores para asegurarse de que no se ha introducido
ningún defecto
Módulos ficticios subordinados (“test stub”)
- complejidad
 Módulos que sólo muestran un mensaje de traza
 Módulos que muestran los parámetros recibidos
 Módulos que devuelven un valor que no depende
de los parámetros recibidos
 Módulos que, en función de los parámetros
recibidos, devuelven un valor de salida que se
corresponde con dicha entrada
+ complejidad

Módulos ficticios subordinados. Mock Objects
 Un Objeto Mock (en OO el módulo equivale a un objeto) es un

tipo de módulo ficticio para programas en Java (simula a otros
objetos a través de la adopción de su interfaz pública)
 Son fácilmente instanciables (no tienen otra misión que la de
hacerse pasar por los objetos a los que simulan)
 Son “irrompibles”, es decir, no pueden fallar ya que no
realizan ninguna tarea susceptible de fallo
 Pueden ser generados automáticamente mediante el uso de
herramientas (de código abierto www.jmock.org o
www.easymock.org )

Integración No Incremental
Cada módulo que se va a probar necesita lo siguiente:
 Un módulo impulsor, que transmite o “impulsa” los

datos de prueba al módulo y muestra los resultados
de dichos casos de prueba
 Uno o más módulos ficticios que simulan la función de
cada módulo subordinado llamado por el módulo que
se va a probar
Una vez probado cada módulo por separado, se

ensamblan todos de una vez y se prueban en conjunto

Integración No Incremental
Prueba de un módulo en integración no incremental

Comparación tipos de Integración
Ventajas de la no incremental:
 Requiere menos tiempo de máquina para las pruebas, ya que se
prueba de una sola vez la combinación de los módulos
 Existen más oportunidades de probar módulos en paralelo
Ventajas de la incremental:
 Requiere menos trabajo, ya que se escriben menos módulos
impulsores y ficticios
 Los defectos y errores en las interfaces se detectan antes, ya que
se empieza antes a probar las uniones entre los módulos
 La depuración es mucho más fácil, ya que si se detectan los
síntomas de un defecto en un paso de la integración hay que
atribuirlo muy probablemente al último módulo incorporado
 Se examina con mayor detalle el programa, al ir comprobando
cada interfaz poco a poco

Ventajas Integración ascendente:
 Es un método ventajoso si aparecen grandes fallos en la
parte inferior del programa, ya que se prueba antes
 La entradas para las pruebas son más fáciles de crear, ya
que los módulos inferiores tienen funciones más específicas
 Es más fácil observar los resultados de la prueba, ya que es
en los módulos inferiores donde se elaboran los datos (los
superiores suelen ser módulos de control)
Inconvenientes Integración ascendente :

 Se requieren módulos impulsores que deben codificarse
 El programa, como entidad, solo aparece cuando se integra
el último módulo
Ventajas Integración descendente:
 Es ventajosa si aparecen grandes defectos en los niveles

superiores del programa, ya que se prueban antes
 Una vez incorporadas las funciones de entrada/salida, es
fácil manejar los casos de prueba
 Permite ver antes una estructura previa del programa, lo
que facilita el hacer demostraciones

Inconvenientes Integración descendente :
 Se requieren módulos ficticios que peden ser complejos de crear

 Antes de incorporar la entrada/salida resulta complicado el
manejo de los casos de prueba
 Las entradas para las pruebas pueden ser difíciles o imposibles
de crear, puesto que, a menudo, se carece de los módulos
inferiores que proporcionan los detalles de operación
 Es más difícil observar la salida, ya que los resultados surgen de
los módulos inferiores
 Pueden inducir a diferir la terminación de la prueba de ciertos
módulos

Automatización de pruebas unitarias: JUnit
 JUnit (http:www.junit.org) es un framework de código
abierto que permite automatizar las pruebas unitarias de
clases Java
 Algunos IDEs ya tienen integrado JUnit (por ejm JBuilder)
 Hay herramientas similares para otros lenguajes como
C++, .Net, Delphi, ASP,, PHP, etc

Automatización de pruebas unitarias: JUnit
Aportaciones de JUnit:
 Ayuda a resolver tareas repetitivas asociadas al proceso
de pruebas como son la organización de las clase de
prueba y el manejo de las situaciones de error
 Proporciona un conjunto de métodos (métodos assert)
que facilitan la tarea de comprobación de las condiciones
contenidas en los casos de prueba
 Proporciona un mecanismo para ejecutar los casos de
prueba de forma ordenada a la vez que mantiene
información en tiempo de ejecución de los defectos
encontrados. Esta información se muestra al usuario al
final del proceso

Prueba del sistema
Es el proceso de prueba de un sistema integrado de
hardware y software para comprobar lo siguiente:
 Cumplimiento de todos los requisitos funcionales,

considerando:
 El producto software final al completo en un entorno de
sistema
 El funcionamiento y rendimiento en las interfaces
hardware, software, de usuario y de operador

 Ejecución y rendimiento en condiciones límite y de
sobrecarga
 Adecuación de la documentación de usuario

Prueba de aceptación
Es la prueba planificada y organizada formalmente para
determinar si se cumplen los requisitos de aceptación
marcados por el cliente
Características principales:
 Participación del usuario

 Está enfocada hacia la prueba de los requisitos de usuario
especificados
 Está considerada como la fase final del proceso para crear
una confianza en que el producto es el apropiado para su
uso en explotación

Prueba de aceptación
Recomendaciones generales:
 Debe contarse con criterios de aceptación previamente

aprobados por el usuario
 No hay que olvidar validar también la documentación y los
procedimientos de uso (por ejemplo,mediante una
auditoría)
 Las pruebas se deben realizar en el entorno en el que se
utilizará el sistema (lo que incluye al personal que lo
maneja)

Herramientas
Existen multitud de herramientas de apoyo para llevar a cabo la
tarea de pruebas. Algunas ya han aparecido en transparencias
anteriores, como JUnit, JMock y EasyMock. A continuación
nombramos algunas más (realmente son extensiones de JUnit, de
código libre) a título de ejemplo:
 JTestCase (http:jtestcase.sourceforge.net). Separa los datos

definidos para los casos de prueba (en formato XML) y el código
de la prueba
 Mejora la mantenibilidad. Cambiar o añadir nuevos casos de
prueba supone únicamente cambiar ficheros XML, por tanto no

es necesario volver a compilar código
 El diseñador de los casos de prueba puede mantenerse al
margen de la creación del código de prueba (puede ser incluso

otra persona)
Herramientas
 DBUnit (http:dbunit.sourceforge.net)
 Facilita las pruebas de software que interactúa con una base de
datos. Emula la BD con la que trabaja el código a probar
 XMLUnit (http:xmlunit.sourceforge.net)
 Facilita las pruebas de código que maneja y genera archivos XML
 HttpUnit/HtmlUnit/JWebUnit (http:httpunit.sourceforge.net,
http:htmlunit.sourceforge.net, http:jwebunit.sourceforge.net)
 Facilita las pruebas de aplicaciones web
 JFunc/JUnitPerf/JMeter (http:jfunc.sourceforge.net,
http:clarkware.com/software/JUnitPerf.html,
http:jakarta.apache.org/jmeter/)
 Facilita las pruebas de funcionalidad

Pruebas dentro del desarrollo del Sw
¿En qué etapa o etapas del desarrollo del Sw aparece trabajo relacionado
con las pruebas de Sw?
 NO solo el la etapa de Implementación
 Abarca las etapas de Análisis, Diseño y Construcción (e Implantación)
 Según Métrica:
 Actividad ASI 10: Especificación del plan de pruebas
 Actividad DSI 10: Especificación técnica del plan de pruebas
 Actividad CSI 3: Ejecución de las pruebas unitarias
 Actividad CSI 4: Ejecución de las pruebas de integración
 Actividad CSI 5: Ejecución de las pruebas del sistema
 Actividad IAS 5: Pruebas de Implantación del sistema
 Actividad IAS 6: Pruebas de aceptación del sistema

Actividad ASI 10:
Especificación del plan de pruebas
 Se inicia la definición del plan de pruebas, el cual sirve como guía
para la realización de las pruebas
 El plan de pruebas es un producto formal que define los objetivos
de la prueba de un sistema, establece y coordina una estrategia
de trabajo, y provee del marco adecuado para elaborar una
planificación paso a paso de las actividades de prueba.
 El plan se inicia en el proceso Análisis del Sistema de Información
(ASI), definiendo el marco general, y estableciendo los requisitos
de prueba de aceptación, relacionados directamente con la
especificación de requisitos.
 Dicho plan se va completando y detallando a medida que se
avanza en los restantes procesos del ciclo de vida del software,
Diseño del Sistema de Información (DSI), Construcción del
Sistema de Información (CSI) e Implantación y Aceptación del
Sistema (IAS).

Actividad ASI 10:
Especificación del plan de pruebas
 Se plantean los siguientes niveles de prueba:
 Pruebas unitarias
 Pruebas de integración
 Pruebas del sistema
 Pruebas de implantación
 Pruebas de aceptación
 En esta actividad también se avanza en la definición de las

pruebas de aceptación del sistema. Con la información disponible,
es posible establecer los criterios de aceptación de las pruebas
incluidas en dicho nivel, al poseer la información sobre los
requisitos que debe cumplir el sistema, recogidos en el catálogo
de requisitos

Actividad DSI 10:
Especificación técnica del plan de pruebas
 En esta actividad se realiza la especificación de detalle del plan de
pruebas del sistema de información para cada uno de los niveles
de prueba establecidos en el proceso Análisis del Sistema de
Información (Pruebas unitarias, de integración, del sistema, de
implantación y de aceptación)
 Para ello se toma como referencia el plan de pruebas, que recoge
los objetivos de la prueba de un sistema, establece y coordina una
estrategia de trabajo, y provee del marco adecuado para planificar
paso a paso las actividades de prueba
 El catálogo de requisitos, el catálogo de excepciones y el diseño
detallado del sistema de información, permiten la definición de las
verificaciones que deben realizarse en cada nivel de prueba para
comprobar que el sistema responde a los requisitos planteados
 La asociación de las distintas verificaciones a componentes,
grupos de componentes y subsistemas, o al sistema de
información completo, determina las distintas verificaciones de
cada nivel de prueba establecido
Actividad CSI 3: Ejecución de las pruebas
unitarias
 En esta actividad se realizan las pruebas unitarias de
cada uno de los componentes del sistema de
información, una vez codificados, con el objeto de
comprobar que su estructura es correcta y que se
ajustan a la funcionalidad establecida
 En el plan de pruebas se ha definido el entorno
necesario para la realización de cada nivel de prueba,
así como las verificaciones asociadas a las pruebas
unitarias, la coordinación y secuencia a seguir en la
ejecución de las mismas y los criterios de registro y
aceptación de los resultados

de integración
 El objetivo de las pruebas de integración es verificar si
los componentes o subsistemas interactúan
correctamente a través de sus interfaces, tanto
internas como externas, cubren la funcionalidad
establecida, y se ajustan a los requisitos especificados
en las verificaciones correspondientes
 La estrategia a seguir en las pruebas de integración se
establece en el plan de pruebas
 Esta actividad se realiza en paralelo a la actividad
Ejecución de las Pruebas Unitarias (CSI 3). Sin
embargo, es necesario que los componentes objeto de
las pruebas de integración se hayan verificado de
manera unitaria

del sistema
 El objetivo de las pruebas del sistema es comprobar la
integración del sistema de información globalmente,
verificando el funcionamiento correcto de las
interfaces entre los distintos subsistemas que lo
componen y con el resto de sistemas de información
con los que se comunica
 En la realización de estas pruebas es importante
comprobar la cobertura de los requisitos, dado que su
incumplimiento puede comprometer la aceptación del
sistema por el equipo de operación responsable de
realizar las pruebas de implantación del sistema, que
se llevarán a cabo en el proceso Implantación y
Aceptación del Sistema
Actividad IAS 5: Pruebas de implantación
del sistema
 La finalidad de las pruebas de implantación es doble:
 Comprobar el funcionamiento correcto del mismo en el entorno
de operación
 Permitir que el usuario determine, desde el punto de vista de
operación, la aceptación del sistema instalado en su entorno
real, según el cumplimiento de los requisitos especificados
 Para ello, el responsable de implantación revisa el plan de pruebas de
implantación y los criterios de aceptación del sistema, previamente
elaborados
 Las pruebas las realizan los técnicos de sistemas y de operación, que
forman parte del grupo de usuarios técnicos que ha recibido la
formación necesaria para llevarlas a cabo
 Una vez ejecutadas estas pruebas, el equipo de usuarios técnicos
informa de las incidencias detectadas al responsable de implantación,
el cual analiza la información y toma las medidas correctoras que
considere necesarias para que el sistema dé respuesta a las
especificaciones previstas
Actividad IAS 6: Pruebas de aceptación
del sistema
 Las pruebas de aceptación tienen como fin validar que el sistema
cumple los requisitos básicos de funcionamiento esperado y permitir
que el usuario determine la aceptación del sistema
 Por este motivo, estas pruebas son realizadas por el usuario final que,
durante este periodo de tiempo, debe plantear todas las deficiencias o
errores que encuentre antes de dar por aprobado el sistema
definitivamente
 Los Directores de los Usuarios revisan los criterios de aceptación,
especificados previamente en el plan de pruebas del sistema, y dirigen
las pruebas de aceptación final que llevan a cabo los usuarios
expertos. A su vez, éstos últimos deben elaborar un informe que los
Directores de los Usuarios analizan y evalúan para determinar la
aceptación o rechazo del sistema

Tema 6 Pruebas

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tema 6 Pruebas

Uploaded by

Copyright:

Available Formats

Ingeniería del Software

Tema 6. Pruebas del Software

Tema 6. Pruebas del Software 3

 Proceso que ayuda a identificar la corrección,

Tema 6. Pruebas del Software 4

Tema 6. Pruebas del Software 5

Tema 6. Pruebas del Software 6

Tema 6. Pruebas del Software 7

 El descubrimiento de un defecto significa un éxito para la

Tema 6. Pruebas del Software 8

 ¿Labor destructiva y rutinaria? Este es el mito, aunque

Tema 6. Pruebas del Software 11

 En aplicaciones críticas (p.ej. control de vuelo,

Tema 6. Pruebas del Software 12

 Seguridad total: prueba exhaustiva

Tema 6. Pruebas del Software 13

Tema 6. Pruebas del Software 14

Tema 6. Pruebas del Software 15

elegir los casos de prueba

posibles caminos de ejecución

b) Enfoque funcional o de caja negra:

especificación de las funciones, la entrada y la salida

¡No son excluyentes!

Se conoce la estructura interna del código a probar

Tema 6. Pruebas del Software 17

Se centra en los requisitos funcionales del software,

 Pruebas conducidas por las entradas y salidas

Tema 6. Pruebas del Software 18

Tema 6. Pruebas del Software 19

Generar casos de prueba que permitan probar

PERO: Es un criterio muy débil.

Tema 6. Pruebas del Software 20

Cobertura de Decisiones (Cob. de ramas)

Escribir los suficientes casos de prueba para que

Para el ejemplo, con los casos de prueba:

Encontrar los casos de prueba que hagan que

Tema 6. Pruebas del Software 22

A B X A>1 B=0 A=2 X>1

Tema 6. Pruebas del Software 23

A B X A>1 B=0 A=2 X>1 A<1 AND B=0 A=2 OR X>1

Aparentemente, parece que este criterio ejercita

 Bucles simples (“n” es el nº máx. de iteraciones):

 Pasar una sola vez por el bucle

 Pasar dos veces por el bucle

 Hacer m pasos por el bucle, con m<n

 Hacer n-1, n y n+1 pasos por el bucle

Tema 6. Pruebas del Software 28

 Bucles anidados (para evitar progresión geométrica):

bucle más interior. Configurar el resto de bucles

para el siguiente bucle, manteniendo los bucles

Tema 6. Pruebas del Software 29

1. Construir el grafo de flujo a partir del programa

Tema 6. Pruebas del Software 31

Las condiciones compuestas (decisiones) se

Tema 6. Pruebas del Software 32

Tema 6. Pruebas del Software 33

Tema 6. Pruebas del Software 34

 Métrica del software que da una medida cuantitativa de la

Tema 6. Pruebas del Software 36

Tema 6. Pruebas del Software 37

Tema 6. Pruebas del Software 38

Tema 6. Pruebas del Software 39

Caminos de prueba Casos de prueba Salida esperada