UT 3 Diseño y realización de pruebas

OBJETIVOS
•Conocer la importancia de la realización de pruebas durante el proceso del
desarrollo de software
•Definir casos de prueba 1
Planificación de las pruebas
En el proceso de desarrollo de software, nos vamos a encontrar con un
conjunto de actividades, donde es muy fácil que se produzca un error humano.

Estos errores humanos pueden ser:

• una incorrecta especificación de los objetivos
• errores producidos durante el proceso de diseño
• errores que aparecen en la fase de desarrollo.

Mediante la realización de pruebas se software, se van a realizar las tareas de

verificación y validación del software.
 La verificación es la comprobación de que un sistema o parte de un sistema, cumple
con las condiciones impuestas. Con la verificación se comprueba si la aplicación se
está construyendo correctamente.
 La validación es el proceso de evaluación del sistema o de uno de sus componentes,
para determinar si satisface los requisitos especificados.

Para llevar a cabo el proceso de pruebas, de manera eficiente,

es necesario implementar una estrategia de pruebas. 2
Siguiendo el Modelo en Espiral, las pruebas empezarían con
• la prueba de unidad, donde se analizaría el código implementado
Seguiríamos con
• la prueba de integración, donde se prestan atención al diseño y la construcción de la
arquitectura del software.
El siguiente paso sería
• la prueba de validación, donde se comprueba que el sistema construido cumple con
lo establecido en el análisis de requisitos de software.
Finalmente se alcanza
• la prueba del sistema que verifica el funcionamiento total del software y otros
elementos del sistema.

3
Prueba de la unidad

En este nivel se prueba cada unidad o

módulo con el objetivo de eliminar
errores en la interfaz y en la lógica
interna. Esta actividad utiliza técnicas
de caja negra y caja blanca, según
convenga.

Se realizan pruebas sobre:

• La interfaz del módulo, para asegurar que la información fluye
adecuadamente.
• Las estructuras de datos locales, para asegurar que mantienen su
integridad durante todos los pasos de ejecución del programa.
• Las condiciones límite, para asegurar que funciona correctamente en los
límites establecidos durante el proceso.
• Todos los caminos independientes de la estructura de control, con el fin de
asegura que todas las sentencias se ejecutan al menos una vez. 4
• Todos los caminos de manejo de errores.
Prueba de integración

En este tipo de prueba se observa

cómo interaccionan los distintos
módulos, comprobando si funcionan
juntos.

Existen dos enfoques fundamentales:

• Integración no incremental o big bang: Se prueba cada módulo por
separado y luego se combinan todos de una vez y se prueba todo el
programa completo. En este enfoque se encuentran gran cantidad de errores
y la corrección se hace difícil.
• Integración incremental: El programa completo se va construyendo y
probando en pequeños segmentos, en este caso los errores son más fáciles
de localizar.

5
Prueba de validación
La validación se consigue cuando el software
funciona de acuerdo con las expectativas
razonables del cliente definidas en el documento de
especificación de requisitos del software.

Se llevan a cabo una serie de pruebas de caja

negra que demuestran la conformidad con los
requisitos.

Las técnicas a utilizar son:

• Prueba alfa: Se lleva a cabo por el cliente o usuario en el lugar de
desarrollo. El cliente utiliza el software de forma natural bajo la observación
del desarrollador que irá registrando los errores y problemas de uso.
• Prueba beta: Se lleva a cabo por los usuarios finales del software en su
lugar de trabajo. El desarrollador no está presente. El usuario registra todos
los problemas que encuentra, e informa al desarrollador en los intervalos
definidos en el plan de prueba. Como resultado de los problemas informados
el desarrollador lleva a cabo las modificaciones y prepara una nueva versión 6
del producto.
Prueba del sistema
Funcionales

Está formada por un conjunto de

pruebas cuya misión es ejercitar Interfaz
Seguridad
profundamente el software. gráfica

Stress Instalación
Son las siguientes:

Prueba de recuperación: se fuerza el fallo del software y se verifica que la

recuperación se lleva a cabo apropiadamente.
Prueba de seguridad: intenta verificar que el sistema está protegido contra
accesos ilegales.
Prueba de resistencia (stress): trata de enfrentar el sistema con situaciones que
demandan gran cantidad de recursos, por ejemplo, diseñando casos de prueba
que requieran el máximo de memoria, incrementando la frecuencia de datos de
7
entrada, que den problemas en un sistema operativo virtual, etc.
Técnicas de diseño de casos de prueba
El diseño de casos de prueba está condicionado por el hecho de que es
imposible probar exhaustivamente el software.
La idea fundamental para el diseño de casos de prueba es elegir una serie de
posibilidades de funcionamiento que se consideren representativas del resto.

Esto se puede ver con un sencillo ejemplo:

Pensemos en un programa que sume dos números enteros de 2 cifras (del 0 al
99). Si quisiéramos probar todos los valores válidos tendríamos que verificar
10.000 combinaciones distintas (100 del primer sumando y otras 100 del
segundo), y aún quedarían todas las posibilidades de error, como puede ser
introducir una letra en lugar de un número.
De modo que, si para un programa tan sencillo, hemos de realizar tantas
pruebas, pensemos en lo que supondría un programa medio.

Un caso de prueba es un conjunto de entradas, condiciones de ejecución y

resultados esperados, desarrollados para conseguir un objetivo particular o
condición de prueba.
Para llevar a cabo un caso de prueba es necesario definir las precondiciones y
postcondiciones, identificar unos valores de entrada y conocer el 8
comportamiento que debería tener el sistema ante dichos valores. Tras realizar
el análisis se observa si el comportamiento es el previsto o no y por qué.
Para resolver el problema de la elección de los casos de prueba hay, entre otros,
tres enfoques principales:

 Enfoque estructural o de caja blanca: Se

centra en la estructura interna del programa
(implementación) para elegir los casos de
prueba. La prueba ideal consistiría en probar
todos los posibles caminos de ejecución.

 Enfoque funcional o de caja negra: Estudia

la especificación de las funciones, la entrada y
la salida, para derivar casos de prueba. La
prueba ideal consistiría en probar todas las
posibles entradas y salidas del programa.

 Enfoque aleatorio: Se basa en modelos, en general estadísticos, que

representen las posibles entradas al programa para crear a partir de ellos los
casos de prueba. La prueba ideal sería probar todas las posibles entradas al
programa.
9
Pruebas de la caja blanca
También conocidas como pruebas estructurales o de caja de cristal, se basan
en un minucioso examen de los detalles procedimentales del código de la
aplicación.

Mediante esta técnica se pueden obtener casos de prueba que:

 Garanticen que se ejecutan al menos una vez todos los caminos
independientes de cada módulo (prueba de cobertura de sentencias)
 Ejecuten todas las sentencias la menos una vez.
 Ejecuten todas las decisiones lógicas en su parte verdadera y en su parte
falsa (prueba de cobertura de condición).
 Ejecuten todos los bucles en sus límites (prueba de bucles).
 Utilicen todas las estructuras de datos internas para asegurar su validez.

Una de las técnicas utilizadas para desarrollar los casos de prueba de la caja
blanca es la prueba del camino básico.

10
Prueba del camino básico
Esta técnica utiliza los conceptos de Grafo de flujo y Complejidad ciclomática.
Grafo de flujo: representa el flujo de control lógico mediante una notación
basada en flechas y círculos.
•Cada círculo del grafo de flujo se llama nodo. Representa una o más
sentencias procedimentales.
•Las flechas del grafo se denominan aristas o enlaces y representan el flujo
de control. Una arista termina en un nodo.
•Las áreas delimitadas por aristas y nodos se llaman regiones.
•El nodo que contiene una condición se llama nodo predicado y se
caracteriza porque de él salen dos o más aristas.

11
Aquí vemos un diagrama de flujo y el grafo que le correspondería.
Este grafo tiene 3 regiones, 8 aristas y 7 nodos. Hay 2 nodos predicado, el
representado por el número 2 y el representado por 3, 4, 5. Únicamente de estos
nodos pueden salir dos aristas.

12
Complejidad ciclomática V(G): número de caminos independientes del
conjunto básico de caminos de ejecución del programa, y por lo tanto, el número
de casos de prueba que se deben ejecutar para asegurar que cada sentencia
se ejecuta al menos una vez.
Un camino independiente es cualquier camino del programa que
introduce, por lo menos, un nuevo conjunto de sentencias de proceso o
una condición. 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.

La complejidad ciclomática es una medida del software que aporta una

valoración cuantitativa de la complejidad lógica de un programa. Además nos
aporta una cota superior para el número de casos de prueba.

A partir de un grafo de flujo, la complejidad ciclomática se puede calcular de tres

formas:
1. V(G) = a-n+2, siendo a el número de aristas del grafo y n el de nodos
2. V(G) = r, siendo r el número de regiones del grafo
3. V(G) = c+1, siendo c el número de nodos de condición
13
Las condiciones case con n alternativas, donde n>2 se cuentan como n-1
nodos de condición.
Ejemplo
public class Pruebas {
public static void MMM(int x, int y){
1. Grafo de flujo
System.out.println(“Valores actuales);
System.out.println(“x=“,x); 1
System.out.println(“y=“,y); 1
if (x>y) 2
x=x-y; 3 2
else v f
y=y-x; 4
System.out.println(“Valores finales);
System.out.println(“x=“,x); 5 3 R1 4
System.out.println(“y=“,y);
}
} 5

2. Complejidad ciclomática V(G) = 2

1) a-n+2=5-5+2=2 3. Caminos independientes
2) Nº R=2 C1  1-2-3-5
3) C+1= 1+1=2 C2  1-2-4-5 14