compendio de ingeniería del softwarecotana.informatica.edu.bo/downloads/estrategias de...
TRANSCRIPT
3.2 ESTRATEGIAS DE PRUEBA
MODULO III
Ingeniería de Software INF - 163
Resumen preparado por Miguel Cotaña 25/10/2012 1
Una estrategia proporciona un
mapa que describe los pasos que
se darán como parte de la
prueba, indica cuándo se
planean y cuándo se dan estos
pasos, además de cuánto
esfuerzo, tiempo y recursos
consumirán. 2
Cualquier estrategia de prueba
debe incorporar:
La planeación de pruebas;
El diseño de casos de
prueba;
La ejecución de pruebas;
La recolección y evaluación
de datos resultantes. 3
4
La prueba es un conjunto de
actividades que se planean con
anticipación y se realizan de
manera sistemática.
La estrategia proporciona al
desarrollador una plantilla para
pruebas y todas tienen las
siguientes características:
Enfoque estratégico para la prueba del Sw.
5
Para realizar pruebas
efectivas un equipo de Sw
debe efectuar revisiones
técnicas formales;
La prueba comienza al nivel
de componentes y trabaja
“hacia afuera”; 6
Diferentes técnicas de prueba
son apropiadas en diferentes
momentos;
La prueba la dirige el
desarrollador;
La prueba y la depuración
son actividades diferentes. 7
La prueba del Sw es un
elemento de VyV:
Verificación: conjunto de
actividades que aseguran que el
Sw implemente correctamente
una función específica;
Validación: aseguran que el Sw
corresponde con los requisitos.
Verificación y Validación
8
La VyV abarca actividades de
aseguramiento de la calidad:
Revisiones técnicas formales;
Auditorias de calidad y de
configuración;
Monitoreo del desempeño;
Simulación;
9
Factibilidad;
Revisión de la
documentación;
Análisis de algoritmos;
Pruebas de desarrollo;
De facilidad de uso;
Calificación y de instalación.
10
La calidad se incorpora al Sw en
todo el proceso de ingeniería.
La aplicación apropiada de
métodos y herramientas, las
revisiones técnicas, junto con
una administración y una
medición aportan la calidad, que
se confirma durante las pruebas. 11
El desarrollador siempre será el
responsable de probar los
componentes. En muchos casos,
también aplica la prueba de
integración. Después lo hará GIP.
No se puede probar la calidad!!!
La calidad se confirma durante la
prueba!!! 12
La definición de prueba debe
ampliarse para incluir técnicas de
descubrimiento de errores que se
aplican para analizar y diseñar
modelos.
El grado al que se han completado y
la consistencia de representaciones
OO deben evaluarse a medida que se
construyen.
Estrategia de prueba para arquitecturas orientada a objetos
13
Al pensar en el Sw OO cambia el
concepto de unidad. La
encapsulación orienta la
definición de clases. Cada clase
e instancia de una clase (objeto)
empaqueta atributos (datos) y
las operaciones (funciones) que
manipulan estos datos.
Arquitectura arientada a objetos: Prueba de unidad
14
Una clase encapsulada suele ser el
eje de las pruebas de unidad. Las
unidades de prueba más pequeñas
son las operaciones dentro de la
clase. Una clase puede contener
varias operaciones y a que una
operación determinada puede
existir como parte de varias clases
diferentes. 15
Existen 2 estrategias:
Prueba basada en
subprocesos: integra el
conjunto de clases requerido
para responder a una entrada.
Cada subproceso se integra y
prueba individualmente.
Arquitectura arientada a objetos: Prueba de integración
16
Prueba basada en el uso:
empieza la construcción, con la
prueba de esas clases. Después
de probar las clases
independientes, se prueba la
siguiente capa de clases (clases
dependientes) que usan las
clases independientes. 17
¿Cuándo hemos terminado las
pruebas?
“nunca se termina de aplicar una
prueba”
La carga se desplaza del
desarrollador al cliente. Cada vez
que el cliente, el usuario, o ambos,
ejecutan un programa, éste se está
probando.
Criterios para completar la prueba
18
Empiezan tras la culminación de
la prueba de integración, cuando
se han ejercitado los
componentes individuales, se ha
terminado de ensamblar el
software como paquete y se han
descubierto y corregido los
errores de interfaz.
Pruebas de Validación
19
En el nivel de validación
desaparece la distinción entre
Sw convencional y OO.
La prueba se concentra en las
acciones visibles para el usuario
y en la salida que éste puede
reconocer. 20
Los usuarios finales son quienes
aplican la prueba alfa en el lugar
de trabajo del desarrollador.
El Sw se utiliza en un entorno
natural mientras el desarrollador
“mira sobre el hombro” de los
usuarios típicos y registra los
errores y los problemas de uso.
Pruebas alfa
21
Se aplican en el lugar de trabajo
de los usuarios finales.
Por lo general el desarrollador no
está. Esta prueba es una
aplicación “en vivo” del Sw en un
entorno que no controla el
desarrollador.
Pruebas beta
22
El usuario final registra todos los
problemas (reales o imaginarios)
que encuentra durante la prueba
y los informa de manera regular
al desarrollador.
Los IS lo modifican y luego
preparan la liberación del
producto. 23