INGENIERIA DE SOFTWARE Tema 5. Métodos de Prueba

15/06/2010
Contenido
1.
2.
INGENIERIA DE SOFTWARE
Tema 5. Métodos de Prueba
3.
4.
5.
Presenta: David Martínez Torres
6.
Universidad Tecnológica de la Mixteca
7.
Introducción
Métodos de prueba
Pruebas de caja blanca
Pruebas de caja negra
Diseño de casos de prueba
Conclusiones
Referencias
[email protected]
Cubo 37
1
2
1. Introducción
„
„
„
... 1. Introducción
La prueba es uno de los pasos de la I.S.
destructivos(psicológ.)
La prueba del software: Elemento crítico
para la garantía de la calidad del software,
representa la revisión final de las
especificaciones, diseño y codificación
(normalmente muy cara esta etapa)
Mito, si fuéramos realmente buenos
programando no habría errores que buscar
„
„
Objetivos de la prueba
„ Proceso de ejecución de un programa
para descubrir un error
„ Buen caso de prueba, tiene una
probabilidad alta de descubrir un error
hasta entonces
„ Tiene éxito si descubre un error hasta
entonces.
No puede asegurar la ausencia de
defectos, solo puede demostrar que
existen defectos
3
Principios de la prueba
1.
2.
3.
4.
5.
6.
Facilidad de prueba
A todas las pruebas se les debería poder hacer
un seguimiento hasta los requisitos del cliente
Debería planificarse mucho antes de que
empezasen
El p
principio
p de Pareto es aplicable
p
a la prueba
p
del software
Deberían empezar por lo “pequeño” y progresar
a lo “grande”
No son posibles las pruebas exhaustivas
Para ser más efectivas, deberían ser conducidas
por un equipo independiente
5
„
Características que llevan a un software fácil de probar
„
„
„
„
„
„
„
Operatividad –Cuanto mejor funcione, más
eficientemente se puede probar
Observabilidad -lo que ves es lo que pruebas
Controlabilidad –Cuanto mejor se pueda controlar el Sw,
más se puede automatizar y optimizar
Capacidad
p
de descomposición
p
–p
permite aislar los
problemas más
á rápidamente
á
y llevar a
cabo mejores pruebas de regresión
Simplicidad – Cuanto menos haya que probar, más
rápido se puede probar
Estabilidad – Cuanto menos cambios, menos
interrupciones en la prueba
Facilidad de comprensión –Cuanto más info. se tenga,
más inteligentes serán las pruebas
6
1
15/06/2010
2. Métodos de prueba del software
„
Prueba de caja blanca Heztel[HET84]
„
“A pequeña escala”
Estructura del control del programa
Prueba del camino básico
P b d
Prueba
de condiciones
di i
y del
d l flujo
fl j de
d datos
d t
„
„
„
„
„
4. Técnica de pruebas de caja blanca
Prueba de caja negra (s/la interfaz del Sw)
“A gran escala”
Validan los requisitos funcionales sin fijarse en el
funcionamiento interno de un programa
Se centran en el ámbito de info. de un programa
„
„
„
Prueba del camino básico
„ La técnica de Tom McCabe[MCC76], permite al
diseñador de casos de prueba obtener una
medida de la complejidad lógica de un diseño
procedimental y usar esa medida como guía
para la definición
ó de un conjunto básico
á
de
caminos de ejecución (complejidad
ciclomática)
„ El camino básico, define el número de caminos
independientes del conjunto básico de un
programa
7
Complejidad Ciclomática
„
„
Complejidad Ciclomática
La complejidad de un programa puede ser
medido por el número ciclomático del grafo de
flujo (diagrama de flujo).
El número ciclomático puede ser calculado de 3
maneras:
„ Basado-grafo de flujo
„
8
„
Basado-código
„
V(G) = 1 + d
„ d: número de nodos predicados
„
V(G) = e - n + 2
„ e: número de aristas (ramas y ciclos)
„ n: número de nodos (bloques de
(nodos con grado
grado-salida
salida mas de 1)
d: representa el número de loops
en el grafo, o el número de puntos
de decisión en el programa
código secuencial)
„
V(G) = Número de regiones
9
Complejidad ciclomática
Ejemplo: Basado-código
Por grafo
v(G) = e – n + 2
v(G) = 7 – 6 + 2
v(G) = 3
1
2
R1 3
4
1
#include <stdio.h>
main()
2
R3
{
3
R2
int a;
4 R1 5
scanf(“%d”, &a);
6
if (a>= 10)
8
if (a < 20)
printf(“10 < a < 20 %d\n”, a);
else
printf(“a >= 20 %d\n”, a);
else
printf(“ a <= 10 %d\n”, a);
}
R2 5
R3
6
e: # aristas
n: # de nodos
Por código
g
v(G) = 1 + d
v(G) = 1 + 2
v(G) = 3
Por regiones
v(G) = # de regiones
v(G) = 3
11
7
Por código
v(G) = 1 + d
v(G) = 1 + 2
v(G) = 3
grafo
Por g
v(G) = e – n + 2
v(G) = 9 – 8 + 2
v(G) = 3
Por regiones
v(G) = # de
regiones
v(G) = 3
12
2
15/06/2010
Ejemplo: Basado-Grafo
5. Diseño de casos de prueba
Por grafo
v(G) = e – n + 2
v(G) = 15 – 12 +
2
v(G) = 5
9
El diseño de casos de prueba es obtener un
conjunto de pruebas que tengan la mayor
probabilidad de descubrir los defectos del
software
Por código
v(G) = 1 + d
v(G) = 1 + 4
v(G) = 5
Por regiones
v(G) = # de
regiones
v(G) = 5
13
14
Obtención de casos de prueba
„
„
1.
2.
3.
4.
Ej: Grafo del flujo del
procedimiento media
El método del camino básico se puede aplicar a un
diseño procedimental detallado o a un código
fuente
Pasos:
A partir de un diseño o código se dibuja el grafo de
fl j
flujo
Se determina la complejidad ciclomática
Se determinar un conjunto básico de caminos
linealmente independientes
1.
Importante identificar nodos predicados
Preparar los casos de prueba que forzarán la
ejecución de cada camino del conjunto básico
1
2
3
10
4
12
11
6
13
8
16
‹Cálculo de la complejidad
ciclomática
… Ej. Diseño de casos de prueba
V(G)=No. Regiones = 6
V(G)=1+d=1+5=6
V(G)=e-n+2 = 17-13+2=6
1
7
9
15
Grafo del flujo del
procedimiento media
5
„
Diseño de casos de prueba
2
R1
10
R6
12
R2
11
3
5
R3 6
13
8
‹Ej. Conjunto básico
4
R4
9
R5
7
Camino
Camino
Camino
Camino
Camino
...
Camino
2-...
1:
2:
3:
4:
5:
1-2-10-11-13
1-2-10-12-13
1-2-3-10-…
1-2-3-4-5-8-9-2-...
1-2-3-4-5-6-8-9-2-
6: 1-2-3-4-5-6-7-8-917
18
3
15/06/2010
6. Conclusiones
„
„
„
„
„
7. Referencias
Es una fase de gran utilidad sobre todo para los
desarrolladores
Permite corroborar con los casos de prueba, que
los resultados dados por el sw son los esperados
Fase de g
gran importancia
p
debido a que
q valida
que el producto realmente cumpla con sus
especificaciones y por tanto asegura la calidad de
sw.
Se usa también para mejorar el rendimiento del
sw
También cabe recordar que la fase de pruebas
nunca terminan.
19
1.
2.
3.
Pressman, S Roger (1998) “Ingeniería del
Software: Un enfoque práctico,” 4a edición
McGraw-Hill.
Somerville, Ian (2002) “Ingeniería de software,”
6a edición
edición. Addison Wesley.
Wesley
Braude Eric J. (2003) “Ingeniería de Software
Una perspectiva orientada a objetos,” Alfaomega
20
¿Preguntas?
„ Gracias!
„
21
4