MODULO III

Ingeniería de Software
INF - 163

3.2 ESTRATEGIAS DE PRUEBA

25/10/2012 Resumen preparado por Miguel Cotaña

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
Enfoque estratégico para la prueba del Sw.

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:
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
Verificación y Validación

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.
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
Estrategia de prueba para arquitecturas orientada a objetos

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.
13
Arquitectura arientada a objetos: Prueba de unidad

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.
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
Arquitectura arientada a objetos: Prueba de integración

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.
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
Criterios para completar la prueba

¿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.
18
Pruebas de Validación

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. 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
Pruebas alfa

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.
21
Pruebas beta

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.
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