Pruebas: concepto y objetivos

 Comprobación del software

◼ Demostración (proof): manual o semiautomática
◼ Inspección manual del código
◼ Prueba o ensayo (testing): ejecutar y ver resultados
◼ Caso de prueba: ensayo individual
 Imposibilidad de pruebas exhaustivas
◼ Impracticable, demasiado costoso
◼ Imposible garantizar la ausencia de defectos
 Si se provocan fallos, seguro que hay defectos
 Si no aparecen fallos, puede que haya defectos, o no
Pruebas: concepto y objetivos

Pruebas de Software
Las pruebas es el proceso de ejercitar un programa con
la intención específica de encontrar errores previos a la
entrega al usuario final.
Pruebas: concepto y objetivos
 Objetivos de las pruebas
◼ Encontrar defectos en el software
◼ Una prueba tiene éxito si descubre un defecto
◼ Una prueba fracasa si hay defectos pero no los descubre
 Pruebas de Verificación
◼ Ver si cumple las especificaciones de diseño
 Pruebas de Validación
◼ Ver si cumple los requisitos del análisis
 Operabilidad: Operar limpiamente
 Observabilidad: El resultado de cada caso de prueba es
observable
 Controlabilidad: Grado con el cual las pruebas pueden ser
automatizadas y optimizadas
 Descomposición: Las pruebas pueden ser dirigidas
 Simplicidad: Reduce la lógica y arquitectura complejas para
simplificar las pruebas
 Estabilidad: Algunos cambios son requeridos durante las
pruebas
 Comprensibilidad: Del diseño
¿Qué muestran las pruebas?
errores

cumplimiento de requerimientos

desempeño

una indicación
de calidad
¿Quién prueba el software?

desarrollador probador independiente

Entiende el sistema Debe entender el sistema,
pero, es condescendiente pero, intentará provocar fallas,
y, es dirigido por el y, es dirigido por la calidad
“entregable”
Pruebas de Software

métodos de métodos de
caja blanca caja negra

Métodos

Estrategias
Pruebas de “caja blanca”
 Concepto y terminología
◼ Pruebas en que se conoce el código a probar
◼ Caja blanca (clear box: caja clara o transparente)
◼ Se procura ejercitar cada elemento del código
 Objetivo
◼ Asegurar que todas las sentencias y condiciones se ejecuten la menos
una vez.
 Algunas clases de pruebas
◼ Pruebas de cubrimiento
◼ Pruebas de condiciones
◼ Pruebas de bucles
Pruebas de “caja blanca”
 En esta prueba siempre se observa el código
que las pruebas se dedican a ejecutar con
ánimo de probarlo todo
 La noción de prueba total se formaliza en lo
que se llama “cobertura” y no es si nouna
media porcentual de ¿Cuánto hemos cubierto?
¿Porque se utilizan?
 A menudo creemos que un camino básico
tenga pocas posibilidades de ejecutarse.
 Los errores tipográficos son aleatorios
 Los errores lógicos y las suposiciones
incorrectas son inversamente proporcional a
la probabilidad de que se ejecute un camino
del programa.
Pruebas de “caja blanca”
 Notación de grafo de flujo
 Complejidad ciclomática
 Matrices de grafos.
Notación de grafo de flujo
 Representa el flujo de control lógico mediante
una notación ilustrada.
 Cada instrucción estructurada tiene su
correspondiente símbolo en el grafo de flujo.
Complejidad ciclomática
 Es una métrica del software que proporciona una medición
cuantitativa del complejidad lógica de un programa.
 Cuando se utiliza el contexto del camino básico, la
complejidad ciclomática define le numero de caminos
independientes del conjunto básico de un programa y nos da
el limite de pruebas que se le deben realizar
 Un camino independiente es cualquier camino de programa
que introduce, por lo menos, un nuevo conjunto de sentencias
de proceso o una nueva condición.
 Nodo predicado es donde dos o mas arista emergen de el.
Complejidad ciclomática
 La Complejidad ciclomática se puede calcular de
tres formas:
◼ El numero de regiones de un grafo de flujo coincide con
la complejidad ciclomática
◼ La Complejidad ciclomática, V(G), de un grafo de flujo G
se define como:
 V(G)=A-N+2
Donde A es el num. de aristas y N el num. De nodos
◼ La Complejidad ciclomática, V(G), de un grafo de flujo G
se define como:
 V(G)=P+1
Donde P es el num de nodos predicado contenidos en el grafo

MSI Eloisa Ruíz Gonzalez

Matrices de grafos
 Procedimiento para obtener el grafo de flujo
y la determinación de un conjunto de caminos
básicos.
 Es una matriz cuadrad cuyo tamaño
(filas&col) es igual al num. De nodos del
grafo de flujo y las entradas alas aristas entre
nodos.

MSI Eloisa Ruíz Gonzalez

Pruebas de cubrimiento
 Ejecutar al menos una vez cada sentencia
 Se necesitan varios casos de prueba
◼ Determinar posibles “caminos” independientes
◼ Cada condición debe cumplirse en un caso y en otro no. En
general, se necesitan tantos casos como condiciones, más uno
(número ciclomático)
 Puede ser imposible cubrir el 100%
◼ Código que nunca se ejecuta: condiciones imposibles
◼ Ejemplo: detección y notificación de errores internos en un
código sin errores

MSI Eloisa Ruíz Gonzalez

Cobertura de traza
 Debido a que en algunos programas sencillo
el numero de posibles trazas de ejecución es
muy limitado, es útil utilizar el número de
trazas observadas/numero de trazas posibles
como un índice de cobertura.
 Según se va consiguiendo observar mas y mas
trazas, se va acercando el proceso a una
cobertura del 100%
MSI Eloisa Ruíz Gonzalez
Cobertura de segmentos
 Nota:
◼ Segmento= secuencia de sentencias sin puntos de
decisión.
 Basta con escoger el código fuente e ir
contando.
 En la practica, el proceso de pruebas termina
antes de legar al 100% por ser laborioso y
costoso, provocar le paso por todas y cada una
de las sentencias,
MSI Eloisa Ruíz Gonzalez
Cobertura por ramas
 La cobertura por segmentos es engañosa en
presencia de segmentos opcionales.
 Cobertura por segmentos basta ejecutar una vez con
éxito al condición, para cubrir las sentencias
posibles.
 Es importante desde la lógica del programa el caso
de que al condición falle.
 Por lo que hay que ejecutar un programa al menos 2
veces una satisfaciendo la condición y otra no.
MSI Eloisa Ruíz Gonzalez
Cobertura por ramas
 Con este criterio se extiende las
construcciones que suponen elegir 1 entre
varias ramas.
 Ejemplo
◼ El CASE
 Se debe diseñar pruebas que ejerciten todas las ramas
del Case incluyendo ELSE.
 Se logra una ocbertura de ramas del 100%
MSI Eloisa Ruíz Gonzalez
Cobertura de decisiones
 LA cobertura de ramas es engañosa con el uso
de expresiones BOOLEANAS.
◼ If cond1 or cond2 then haz esto end
 La cond1 y cond2 puede tomar 2 valores cada
una, dando una combinación de 4 posibles
combinaciones.
 Ejemplo:

MSI Eloisa Ruíz Gonzalez

Cobertura de decisiones
 Cumplir o no cada parte de cada condición
 Se necesitan varios casos de prueba
◼ Determinar expresiones simples en las condiciones
◼ Una por cada operando lógico o comparación
◼ Cada expresión simple debe cumplirse en un caso y en otro no,
siendo decisiva en el resultado
 Puede ser imposible cubrir el 100%
◼ Expresiones simples no independientes

MSI Eloisa Ruíz Gonzalez

Cobertura de decisiones
 1.- Prueba 1: cond1=TRUE y cond2=FALSE
 2.- Prueba 2: cond1=FALSE y cond2=TRUE
 3.- Prueba 1: cond1=FALSE y cond2=FALSE
 4.- Prueba 2: cond1=TRUE y cond2=TRUE

MSI Eloisa Ruíz Gonzalez

Cobertura de bucles
 Los bucles no son mas que segmentos
controlados por decisiones.
 Un bucle ejecuta un cierto numero de veces,
pero ese numero de veces debe ser muy
precisa, lo más normal es que ejecutarlo una
vez de menos o una de mas tenga
consecuencias indeseables.

MSI Eloisa Ruíz Gonzalez

Pruebas de bucles
 Conseguir números de repeticiones especiales
 Bucles simples
◼ Repetir cero, una y dos veces
◼ Repetir un número medio (típico) de veces
◼ Repetir el máximo-1, máximo y ¡máximo +1!
 Bucles anidados
◼ Repetir un número medio (típico) los bucles internos, el
mínimo los externos, y variar las repeticiones del bucle
intermedio ensayado.
◼ Ensayarlo con cada nivel de anidamiento

MSI Eloisa Ruíz Gonzalez

Pruebas de bucles
 Para un bucle While hay que pasar 3 pruebas
◼ 0 ejecuciones
◼ 1 ejecución
◼ Mas de 1 ejecución

MSI Eloisa Ruíz Gonzalez

Pruebas de bucles
 Par un bucle REPEAT hay que pasar 2
pruebas
◼ 1 ejecución
◼ Mas de 1 ejecución

MSI Eloisa Ruíz Gonzalez

Pruebas de bucles
 Los bucles FOR en cambio son más seguros
pues en su cabeza esta definido el número de
veces que se va ejecutar.
 No hay que confiar por si se cambia algo
dentro de su variable de control.
 Ojo con las sentencias EXIT=BREAK
=RETURN, provocan terminaciones
anticipadas.
MSI Eloisa Ruíz Gonzalez
Recomendaciones
 Es imprescindible una buen cobertura de
segmentos.
 Una buena cobertura de ramas

MSI Eloisa Ruíz Gonzalez

Limitaciones

Las pruebas de caja blanca nos vencen de que

un programa hace bien lo que hace pero no
que haga lo que necesitamos.

MSI Eloisa Ruíz Gonzalez

Pruebas de caja negra
Requerimientos

Salida

Entrada Eventos

MSI Eloisa Ruíz Gonzalez

Pruebas de “caja negra”
 Concepto y terminología
◼ Pruebas en que se conoce sólo la interfaz
◼ Caja negra (black box: caja opaca)
◼ Se procura ejercitar cada elemento de la interfaz
◼ Se centra en los requerimientos funcionales del software
◼ Permite tener un conjunto de condiciones de entrada que
ejerciten completamente los requisitos funcionales del
programa
◼ Nos alternativa de caja blanca

MSI Eloisa Ruíz Gonzalez

 Algunas clases de pruebas
◼ Cubrimiento → invocar todas las funciones
(100%)
◼ Clases de equivalencia de datos
◼ Pruebas de valores límite

MSI Eloisa Ruíz Gonzalez

Pruebas de clases de equivalencia

consultas Formatos entrada

de Usuario de FK
toques salida prompts datos
con
ratón

MSI Eloisa Ruíz Gonzalez

Pruebas de clases de equivalencia
 Divide el dominio de entrada de un programa
en un conjunto de clase de datos de los que se
pueden derivar casos de pruebas.
 Si la entrada es un código formado por dos
partes, la primera un prefijo opcional de 3
dígitos, que empiece con 9 y la contraseña
que sea una cadena de hasta 6 caracteres que
empiece necesariamente con una letra y que
puede contener letras, dígitos y $
MSI Eloisa Ruíz Gonzalez
Pruebas de clases de equivalencia

MSI Eloisa Ruíz Gonzalez

Pruebas de clases de equivalencia
 Particiones de equivalencia
◼ Los datos se clasifican según las distinciones visibles en la
interfaz del programa.
◼ Ejemplo: EsPrimo: Entero → Booleano
 Clase 1: primo  2 (2, 3, 5, 7, 11, ...)
 Clase 2: no_primo  2 (4, 6, 8, 9, 10, ...)
 Clase 3: valores singulares (0, 1)
 Clase 4: no definido (-1, -2, ...)
 Casos de ensayo con datos de cada clase

MSI Eloisa Ruíz Gonzalez

Ejemplo de caso de prueba de caja
negra para Esprimo

MSI Eloisa Ruíz Gonzalez

Pruebas de valores límite
 Los errores se sitúan en los limites.
 Si la entrada se encuentra en un rango de a..b
entonces hay que probar con los valores:
a-1,a, a+1, b-a, b y b+1
 Si la entrada es un conjunto de valores
entonces hay que probar con los valores:
Max-1, max, max+1, min-1, min y min+1

MSI Eloisa Ruíz Gonzalez

Pruebas de valores límite
 Complemento a las particiones de equivalencia
 Varios casos de prueba por cada partición
◼ Valores típicos, intermedios
◼ Valores primero y segundo del rango
◼ Valores penúltimo y último
◼ Valores vecinos fuera del rango (en otra partición)
 Motivación
◼ Los programadores se equivocan con más frecuencia al tratar
los valores en la frontera (Ej: > en vez de )

MSI Eloisa Ruíz Gonzalez

Pruebas de valores límite

MSI Eloisa Ruíz Gonzalez

Pruebas en entornos y aplicaciones
especializadas
 Pruebas de interfaces graficas de usuarios
◼ Pruebas sobre ventanas
◼ Pruebas sobre menús y uso del ratón.
◼ Pruebas de entrada de datos
 Pruebas de documentación y ayuda

MSI Eloisa Ruíz Gonzalez

Caso de prueba de caja negra para
EsPrimo

MSI Eloisa Ruíz Gonzalez