Tema 10 T Cnicas De Pruebas Del Software Parte II

Introducción a la Ingeniería de
Software
Técnicas de prueba del Software
(Parte II)

Prueba de Aplicaciones
Orientadas a Objetos
•

Qué es?
– Es necesario probar un sistema OO en varios niveles diferentes con la intención de
descubrir errores que puedan ocurrir conforme las clases colaboran unas con otras y
conforme los subsistemas se comunican a través de capas arquitectónicas

•

¿Por qué esimportante?
– El programa tiene que ejecutarse antes de que llegue al cliente con la intención
específica de remover todos los errores, de modo que el cliente no experimente la
frustración que produce encontrarse con un producto de calidad pobre
– Con la finalidad de encontrar el mayor número posible de errores, las pruebas deben
realizarse de manera sistemática y los casos de prueba debendiseñarse usando técnicas
disciplinadas

•

¿Cuáles son los pasos?
–
–
–
–
–

Revisión de los modelos de análisis y diseño orientado a objetos
Pruebas de clase
Pruebas basadas en hebra, en uso y de grupo
Enfoques basados en fallo
Se usan casos de uso

Modelos de Prueba AOO y DOO
Exactitud de los modelos AOO y DOO
• La exactitud sintáctica se juzga mediante el uso adecuado de la simbología;
cada modelo serevisa para garantizar que se mantienen las convenciones de
modelado adecuadas
• La exactitud semántica puede valorarse con base en la conformidad del modelo
con el dominio de problemas del mundo real
• Si el modelo refleja con precisión el mundo real entonces es semánticamente
correcto
• Para determinar si el modelo verdaderamente refleja los requerimientos del
mundo real, debe presentarse aexpertos de dominio de problemas, quienes
examinarán las definiciones y jerarquía de clase en busca de omisiones y
ambigüedad
• Las relaciones de clase se evalúan para determinar si reflejan con precisión
conexiones de objetos en el mundo real

Modelos de Prueba AOO y DOO
•

Consistencia de los modelos orientados a objetos
– Puede juzgarse al considerar las relaciones entre entidades en el modelo
–Un modelo de análisis o diseño inconsistente tiene representaciones en una
parte del modelo que no se reflejan de manera correcta en otras porciones
– Debe examinarse cada clase y sus conexiones con otras clases
– A fin de facilitar esta actividad, puede usarse el modelo clase-responsabilidadcolaboración (CRC) o un diagrama de objeto-relación
– Para evaluar el modelo de clase, se recomienda seguirlos siguientes pasos:
1.
2.
3.
4.

5.

Vuelva a consultar el modelo CRC y el modelo objeto-relación
Inspeccione la descripción de cada tarjeta índice CRC para determinar si una
responsabilidad delegada es parte de la definición del colaborador
Invertir la conexión para garantizar que cada colaborador al que se solicita servicio recibe
solicitud de una fuente razonable
Al usar las conexionesinvertidas que se examinaron en el paso 3, se determina si es posible
requerir otras clases o si las responsabilidades se agrupan de manera adecuada entre las
clases.
Determinar si las responsabilidades de amplia solicitud pueden combinarse en una sola
responsabilidad

Estrategias de Pruebas
Orientadas a Objetos
Prueba de unidad en el contexto OO
• La encapsulación impulsa la definición de clases yobjetos
• Cada clase y cada instancia de una clase (objeto) encapsulan los
atributos (datos) y las operaciones (también conocidas como
métodos o servicios) que manipulan dichos datos
• La unidad comprobable más pequeña es la clase encapsulada
• No es posible probar una sola operación aislada, sino, más bien,
como parte de una clase
• La prueba de clase para el software OO se activa mediante lasoperaciones encapsuladas por la clase y por el comportamiento
de estado de la misma

Estrategias de Pruebas
Orientadas a Objetos
Prueba de integración en el contexto OO
• Prueba basada en hebra, integra el conjunto de clases requeridas para
responder a una entrada o evento del sistema. Cada hebra se integra y
prueba de manera individual. La prueba de regresión se aplica para
asegurar que no ocurran...