-
8/3/2019 Modelo y Metodo de Prueba
1/26
1
INTRODUCCION
El presente trabajo est basado en los principales mtodos de
prueba de
software. Describe los objetivos que se persiguen al realizar la
prueba y
los principios de la prueba.
Un producto puede probarse de acuerdo al conocimiento de la
funcin especfica
para la que fue diseado el producto (caja negra). Con la
aplicacin de esta
tcnica se adquieren pruebas que disminuyen el numero de casos de
prueba.
La prueba del mtodo de la caja de cristal frecuentemente es ms
eficaz para
descubrir errores debido a que los programas sutiles ocurren en
la interfaz de sub-
programas.
Estrategias de prueba del software
Una estrategia de prueba del software integra los mtodos de
diseo de caso de
pruebas del software en una serie bien planeada de pasos que
desembocara en
la eficaz construccin de software.
La estrategia proporciona un mapa que describe los pasos que se
darn como
parte de la prueba indica cuando se planean y cuando se dan
estos pasos,adems de cuanto esfuerzo, tiempo y recursos consumiran.
Por tanto, cualquier
estrategia de prueba debe incorporar la planeacin de pruebas, el
diseo de caso
de pruebas, la ejecucin de pruebas y la recoleccin y evolucin de
los datos
resultantes.
Una estrategia de prueba del software debe ser lo
suficionetemente flexible como
para promover un enfoque perzonalizado al mismo tiempo debe ser
lo
adecuadamente rigido como para promover una planeacin razonable
y un
seguimiento administrativo del avanze del proyecto.
Qu es?
El software se prueba para descrubrir errores cometidos sin
darse cuenta al
realizar su diseo y construccin.
pero como se realizan las pruebas? Debe desarrollarse un plan
formal para las
pruebas? debe probase el programa como un lodo o solo deben
aplicarse
pruebas a una parte pequena? deben volver a realizarse las
pruebas ejecutadas
a medida que se agregan nuevos componentes a un sitemas de gran
tamano?
-
8/3/2019 Modelo y Metodo de Prueba
2/26
2
Cundo debe pedirse la participacin del cliente? Estas y muchas
otras
preguntas se respondern cuando desarrolle una estrategia de
prueba del
software.
Quin lo hace?
El jefe de proyecto, los ingenieros del software o los
especialistas en pruebas son
quienes desarrollan la estrategia para la prueba del
software
Por qu es importante?
Con frecuencia, la prueba requiere una mayor cantidad del
esfuerzo dedicado al
proyecto que cualquier otra actividad de ingeniera del
software.
Si se realiza sin un plan, se desperdicia tiempo se dedica un
esfuerzo innecesarioy, aun peor, es posible que aun no se detecten
errores. Por tanto la razonable
seria establecer una estrategia sistemtica para probar el
software
Cules son los pasos?
La prueba empieza por lo pequeo y avanza hacia lo grande esto
significa que en
las primeras etapas la prueba se concentra en un solo componente
o un grupo
pequeo de componentes relacionados y se aplica para descubrir
errores en la
lgica de datos y de procesamiento que se a encapsulado en el
componente una
ves probados los componentes deben integrarse hasta que todo el
sistema se
haya construido. En este punto se ejecuta una serie de pruebas
de alto nivel para
descubrir errores en la satisfaccin de los requisitos dl cliente
a medida que se
descubren, lo errores deben diagnosticarse y corregirse
empleando un proceso
llamado depuracin.
Cul es producto obtenido?
Una especificacin de la prueba documenta el enfoque que aplico
el equipo de
software a la prueba al definir un plan que detalla una
estrategia general y un
procedimiento que describe los pasos especficos y se darn en las
pruebas que
abran de realizarse.
Cmo puedo estar seguro de que lo he hecho correctamente?
Al revisar la especificacin de la prueba antes de realizarla se
evalua si estn
completos los casos y las tareas de prueba. Un plan y un
procedimiento de
-
8/3/2019 Modelo y Metodo de Prueba
3/26
3
prueba efectivos llevaran a la construccin ordenada del software
y al
descubrimiento de errores en cada etapa de proceso de
costruccion.
Una estrategia global
-
8/3/2019 Modelo y Metodo de Prueba
4/26
4
Prueba de Unidad
El proceso de verificacin se centra en la menor unidad de diseo
del software.
Se aplica sobre la descripcin del diseo procedimental.
Usa tcnica de prueba de caja blanca.
Se puede realizar en paralelo para diferentes mdulos.
mbito de Prueba
La interfaz del mdulo.
El impacto de los datos globales sobre el mdulo.
Las estructuras de datos locales.
Las condiciones lmite.
Los caminos de ejecucin de la estructura de control.
Los caminos de manejo de errores.
Procedimiento de Prueba
Para cada prueba, se debe desarrollar un software que controle
y/o
resguarde.
Un controlador es un programa principal que acepta los datos del
caso de
prueba, pasa los datos al mdulo e imprime los resultados.
Un resguardo es un subprograma que reemplaza a los mdulos
subordinados, realiza alguna manipulacin de datos, imprime
una
verificacin de entrada y devuelve el control.
-
8/3/2019 Modelo y Metodo de Prueba
5/26
5
La prueba de Integracin
Es una tcnica sistemtica para construir la estructura del
programa y detectar
errores asociados con la interaccin.
La integracin no incremental no es recomendable.
La integracin incremental puede ser descendente o
ascendente.
Se necesitan pruebas de regresin.
Integracin descendente
-
8/3/2019 Modelo y Metodo de Prueba
6/26
6
Los mdulos subordinados al mdulo de control principal se van
incorporando a
la estructura primero-en-profundidad, o primero en anchura.
Se usa el mdulo de control principal como controlador de la
prueba,
disponiendo de resguardos para todos los mdulos directamente
subordinados.
Se sustituyen los resguardos subordinados uno a uno por los
mdulos.
Se llevan a cabo pruebas cada vez que se integra un mdulo.
Tras terminar las pruebas se reemplaza otro resguardo con el
mdulo real
-
8/3/2019 Modelo y Metodo de Prueba
7/26
7
Integracin Ascendente
Empieza la construccin y la prueba con los mdulos atmicos
eliminando la
necesidad de resguardos.
Se combinan los mdulos de bajo nivel en grupos que realicen una
sub
funcin especfica.
Se escribe un controlador para coordinar la entrada y la salida
de los
casos de prueba.
Se prueba el grupo.
Se eliminan los controladores y combinan los grupos movindose
hacia
arriba por la estructura del programa.
Enfoque combinado
La Prueba de validacin
-
8/3/2019 Modelo y Metodo de Prueba
8/26
8
Comprueba que el software, una vez ensamblado, funciona de
acuerdo con las
expectativas razonables del cliente.
Se satisfacen los requerimientos funcionales.
Se alcanzan los requisitos de rendimiento.
La documentacin es correcta e inteligible.
Se alcanzan otros requerimientos (compatibilidad, recuperacin
de
errores...)
Usa tcnicas de caja negra
Revisin de la configuracin
Comprobar, para todos los elementos de la configuracin del
software que:
se han desarrollado apropiadamente,
se han catalogado, y
estn suficientemente detallados para soportar la fase de
mantenimiento.
Pruebas alfa y Beta
Son pruebas de aceptacin que permiten que el cliente valide los
requisitos.
Las pruebas alfa se llevan a cabo en un entorno controlado.
Las pruebas beta se llevan a cabo en el lugar de trabajo del
cliente.
Pueden durar semanas o meses
La Prueba del Sistema
El objetivo es verificar que se han integrado adecuadamente
todos los elementos
del sistema y que realizan las funciones apropiadas.
La responsabilidad es de todos los creadores de cada uno de los
elementos del
sistema.
Medidas Preventivas
Disear caminos de manejo de errores que prueben toda la
informacin
procedente de otros elementos del sistema.
Realizar pruebas que simulen datos en mal estado u otros
problemas de la
interfaz del software.
-
8/3/2019 Modelo y Metodo de Prueba
9/26
9
Registrar los resultados de las pruebas.
Participar en la planificacin y el diseo de casos de prueba
Tipos de Prueba
Prueba de Recuperacin
Fuerza el fallo del software de varias formas y verifica que la
recuperacin se
produce adecuadamente.
Si la recuperacin es automtica hay que evaluar la correccin de
la
inicializacin, de los mecanismos de recuperacin del estado del
sistema,
de la recuperacin de los datos y del proceso de rearranque.
-
8/3/2019 Modelo y Metodo de Prueba
10/26
10
Si la recuperacin no es automtica, hay que evaluar los tiempos
medios
de reparacin para determinar si estn dentro de unos lmites
aceptables
Un sistema tolerante a fallos evita que cese el funcionamiento
de todo el sistema
cuando se produce un fallo del proceso.
Prueba de Seguridad
Verifica que los mecanismos de proteccin incorporados protegern
al sistema.
Intenta conseguir las claves de acceso de cualquier forma.
Ataca con software a medida.
Bloquea el sistema.
Provoca errores del sistema entrando durante su recuperacin.
Un sistema que maneje informacin que pueda afectar de forma
inapropiada a las
personas es un posible objetivo para entradas ilegales.
Prueba de resistencia
Enfrenta al programa con situaciones atpicas, esto es, ejecuta
el sistema de
forma que demande recursos en cantidad, frecuencia o volmenes
anormales.
Incrementa las frecuencias de datos de entrada.
Ejecuta casos que requieran el mximo de memoria.
Buscar demasiados datos que residan en disco.
Realiza pruebas de sensibilidad intentando descubrir
combinaciones de
datos dentro de una clase de entrada vlida que pueda
producir
inestabilidad o un proceso incorrecto
Prueba de Rendimiento
Prueban el rendimiento del software en tiempo de ejecucin dentro
del
contexto de un sistema integrado.
Requiere de instrumentacin tanto software como hardware para
los
procesos de monitorizacin y medicin.
Se lleva a cabo durante todos los pasos de prueba.
Los sistemas de tiempo real y los sistemas empotrados se tienen
que ajustar a
los requisitos de rendimiento.
-
8/3/2019 Modelo y Metodo de Prueba
11/26
11
Tcnicas de prueba
El desarrollo de Sistemas de software implica la realizacin de
una serie de
actividades predispuestas a incorporar errores (en la etapa de
definicin de
requerimientos, de diseo, de desarrollo, ...).
Debido a que estos errores se deben a nuestra habilidad innata
de provocar
errores, tenemos que incorporar una actividad que garantice la
calidad del
software.
En este captulo estudiaremos:
Fundamentos de la prueba del software, que definen los
objetivos
fundamentales de la fase de prueba.
Diseo de casos de prueba, que se centra en un conjunto de
tcnicas
para que satisfagan los objetivos globales de la prueba.
1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE
En la etapa de prueba del software se crean una serie de casos
de prueba que
intentan "destruir" el software desarrollado.
La prueba requiere que se descarten ideas preconcebidas sobre la
"calidad o
correccin" del software desarrollado.
1.1. Objetivos de la prueba
La prueba es un proceso de ejecucin de un programa con la
intencin de
descubrir un error
Un buen caso de prueba es aquel que tiene una alta probabilidad
de
mostrar un error no descubierto hasta entonces
Una prueba tiene xito si descubre un error no detectado hasta
entonces
El objetivo es disear casos de prueba que, sistemticamente,
saquen a la luz
diferentes clases de errores, hacindolo con la menor cantidad de
tiempo y de
-
8/3/2019 Modelo y Metodo de Prueba
12/26
12
esfuerzo.
La prueba no puede asegurar la ausencia de errores; slo puede
demostrar
que existen defectos en el software.
1.2. Proceso de prueba
-
8/3/2019 Modelo y Metodo de Prueba
13/26
13
El proceso de prueba tiene dos entradas:
Configuracin del software: Incluye la especificacin de
requisitos del
software, la especificacin del diseo y el cdigo fuente
Configuracin de prueba: Incluye un plan y un procedimiento
de
prueba
Si el funcionamiento del software parece ser correcto y los
errores encontrados
son fciles de corregir, podemos concluir con que:
La calidad y la fiabilidad del software son aceptables, o
que
Las pruebas son inadecuadas para descubrir errores serios
1.3. Diseo de casos de prueba
Se trata de disear pruebas que tengan la mayor probabilidad de
encontrar el
mayor nmero de errores con la mnima cantidad de esfuerzo y de
tiempo.
Cualquier producto de ingeniera se puede probar de dos
formas:
Pruebas de caja negra: Realizar pruebas de forma que se
compruebe que cada funcin es operativa.
Pruebas de caja blanca: Desarrollar pruebas de forma que se
asegure que la operacin interna se ajusta a las
especificaciones, y
que todos los componentes internos se han probado de forma
adecuada.
En la prueba de la caja negra, los casos de prueba pretenden
demostrar que
las funciones del software son operativas, que la entrada se
acepta de forma
adecuada y que se produce una salida correcta.
En la prueba de caja blanca se realiza un examen minucioso de
los detalles
procedimentales, comprobando los caminos lgicos del
programa,comprobando los bucles y condiciones, y examinado el
estado del programa en
varios puntos.
-
8/3/2019 Modelo y Metodo de Prueba
14/26
14
A primera vista, la prueba de caja blanca profunda nos llevara a
tener
"programas 100 por cien correctos", es decir:
Definir todos los caminos lgicos
Desarrollar casos de prueba para todos los caminos lgicos
Evaluar los resultados
Pero esto supone un estudio demasiado exhaustivo, que
prolongara
excesivamente los planes de desarrollo del software, por lo que
se har un
estudio de los caminos lgicos importantes.
2. PRUEBA DE LA CAJA BLANCA
La prueba de la caja blanca es un mtodo de diseo de casos de
prueba que
usa la estructura de control del diseo procedimental para
derivar los casos de
prueba.
-
8/3/2019 Modelo y Metodo de Prueba
15/26
15
Las pruebas de caja blanca intentan garantizar que:
Se ejecutan al menos una vez todos los caminos independientes
de
cada mdulo
Se utilizan las decisiones en su parte verdadera y en su parte
falsa
Se ejecuten todos los bucles en sus lmites
Se utilizan todas las estructuras de datos internas
2.1. Prueba del camino bsico
El mtodo del camino bsico (propuesto por McCabe) permite obtener
una
medida de la complejidad de un diseo procedimental, y utilizar
esta medida
como gua para la definicin de una serie de caminos bsicos de
ejecucin,
diseando casos de prueba que garanticen que cada camino se
ejecuta al
menos una vez.
2.1.1. Notacin del grafo de flujo o grafo del programa
Representa el flujo de control lgico con la siguiente
notacin:
-
8/3/2019 Modelo y Metodo de Prueba
16/26
16
A continuacin se muestra un ejemplo basado en un diagrama de
flujo que
representa la estructura de control del programa.
-
8/3/2019 Modelo y Metodo de Prueba
17/26
17
En el grafo de flujo
Cada nodo representa una o ms sentencias procedimentales
Un solo nodo puede corresponder a una secuencia de pasos del
proceso y a una decisin
Las flechas (aristas) representan el flujo de control
Cualquier representacin del diseo procedimental se puede
traducir a un grafo
de flujo.
Si en el diseo procedimental se utilizan condiciones compuestas,
la
generacin del grafo de flujo tiene que descomponer las
condiciones
compuestas en condiciones sencillas, tal y como muestra la
figura siguiente.
-
8/3/2019 Modelo y Metodo de Prueba
18/26
18
2.1.2. Complejidad ciclomtica
Es una medida que proporciona una idea de la complejidad lgica
de un
programa.
La complejidad ciclomtica coincide con el nmero de regiones del
grafo de
flujo
La complejidad ciclomtica, V(G), de un grafo de flujo G, se
define como
V(G) = Aristas - Nodos + 2
La complejidad ciclomtica, V(G), de un grafo de flujo G, tambin
se define
como
V(G) = Nodos de predicado + 1
A partir del grafo de flujo de la figura 4, la complejidad
ciclomtica sera:
Como el grafo tiene cuatro regiones, V(G) = 4
Como el grafo tiene 11 aristas y 9 nodos, V(G) = 11 - 9 - 2 =
4
Como el grafo tiene 3 nodos predicado, V(G) = 3 + 1 = 4
A partir del valor de la complejidad ciclomtica obtenemos el
nmero de
caminos independientes, que nos dan un valor lmite para el nmero
de
pruebas que tenemos que disear.
En el ejemplo, el nmero de caminos independientes es 4, y los
caminos
independientes son:
1-11
1-2-3-4-5-10-1-11
1-2-3-6-7-9-10-1-11
1-2-3-6-8-9-10-1-11
2.1.3. Pasos del diseo de pruebas mediante el camino bsico
Obtener el grafo de flujo, a partir del diseo o del cdigo del
mdulo
Obtener la complejidad ciclomtica del grafo de flujo
Definir el conjunto bsico de caminos independientes
Determinar los casos de prueba que permitan la ejecucin de cada
uno delos caminos anteriores
Ejecutar cada caso de prueba y comprobar que los resultados son
los
-
8/3/2019 Modelo y Metodo de Prueba
19/26
19
esperados
2.2. Prueba de bucles
Los bucles son la piedra angular de la inmensa mayora de los
algoritmos
implementados en software, por lo que tenemos que prestarles una
atencin
especial a la hora de realizar la prueba del software.
La prueba de bucles es una tcnica de prueba de caja blanca que
se centra en
la validez de las construcciones de los bucles.
Se pueden definir cuatro tipos de bucles diferentes:
Bucles simples
Bucles concatenados
Bucles anidados
Bucles no estructurados
-
8/3/2019 Modelo y Metodo de Prueba
20/26
20
2.2.1. Bucles simples
A los bucles simples (de n iteraciones) se les tiene que aplicar
el conjunto de
pruebas siguientes:
Saltar el bucle
Pasar slo una vez por el bucle
Pasar dos veces por el bucle
Hacer mpasos del bucle con m < n
Hacer n-1, ny n+1 pasos por el bucle
2.2.2. Bucles anidados
Si extendisemos el conjunto de pruebas de los bucles simples a
los bucles
anidados, el nmero de pruebas crecera geomtricamente, por lo que
Beizer
sugiere el siguiente conjunto de pruebas para bucles
anidados:
Comenzar con el bucle ms interno, estableciendo los dems
bucles
a los valores mnimos
Llevar a cabo las pruebas de bucles simples para el bucle ms
interno, conservando los valores de iteracin de los bucles
ms
externos a los valores mnimos Progresar hacia fuera en el
siguiente bucle ms externo, y
manteniendo los bucles ms externos a sus valores mnimos
-
8/3/2019 Modelo y Metodo de Prueba
21/26
21
Continuar hasta que se hayan probado todos los bucles
2.2.3. Bucles concatenados
Probar los bucles concatenados mediante las tcnicas de prueba
para bucles
simples, considerndolos como bucles independientes.
2.2.4. Bucles no estructurados
Redisear estos bucles para que se ajusten a las construcciones
de la
programacin estructurada.
Ejemplo
Construir el Grafo de Flujo correspondiente a la siguiente
especificacin del
software en LDP.
-
8/3/2019 Modelo y Metodo de Prueba
22/26
22
Solucin
-
8/3/2019 Modelo y Metodo de Prueba
23/26
23
Ejemplo
Construir el Grafo de Flujo correspondiente al siguiente cdigo
de un programa
Solucin
-
8/3/2019 Modelo y Metodo de Prueba
24/26
24
3. PRUEBA DE LA CAJA NEGRA
Las pruebas de caja negra se llevan a cabo sobre la interfaz del
software,
obviando el comportamiento interno y la estructura del
programa.
Los casos de prueba de la caja negra pretenden demostrar
que:
Las funciones del software son operativas
La entrada se acepta de forma correcta
Se produce una salida correcta
La integridad de la informacin externa se mantiene
A continuacin se derivan conjuntos de condiciones de entrada que
utilicen
todos los requisitos funcionales de un programa.
Las pruebas de caja negra pretenden encontrar estos tipos de
errores:
Funciones incorrectas o ausentes
Errores en la interfaz
Errores en estructuras de datos o en accesos a bases de
datos
externas
Errores de rendimento
Errores de inicializacin y de terminacin
Los tipos de prueba de cana negra que vamos a estudiar son:
Prueba de particin equivalente
Prueba de anlisis de valores lmites
3.1. Prueba de particin equivalente
Este mtodo de prueba de caja negra divide el dominio de entrada
de un
programa en clases de datos, a partir de las cuales deriva los
casos de prueba.
Cada una de estas clases de equivalencia representa a un
conjunto de estadosvlidos o invlidos para las condiciones de
entrada.
-
8/3/2019 Modelo y Metodo de Prueba
25/26
25
3.1.1. Identificacin de las clases de equivalencia
Se identifican clases de equivalencia vlidas e invlidas con la
siguiente tabla
Condiciones externasClases de equivalencia
vlidas
Clases de equivalencia
invlidas
-
8/3/2019 Modelo y Metodo de Prueba
26/26
A continuacin se siguen estas directrices:
Si una condicin de entrada especifica un rango de valores
(p.e, entre 1 y 999), se define una CEV (1
