PRUEBAS ORIENTADAS A

OBJETOS
INTEGRANTES
FLORA CASTELLANOS LOPEZ
INES HERNANDEZ OJEDA
MIGUELINA HERNANDEZ DE AQUINO
ADRIANA TRUJILLO CHICUELLAR
JOSE GIL JACOME MUNGUIA.
 INTRODUCCION
EL objetivo de las pruebas, expresado de forma
sencilla, es encontrar el mayor número posible de
errores con una cantidad razonable de esfuerzo,
aplicado sobre un lapso de tiempo realista.

La prueba de los sistemas O0 presentan un nuevo

conjunto de retos al ingeniero del software.
 AMPLIACION DE LA VISION DE LAS
PRUEBAS
Debido a la naturaleza evolutiva del paradigma de
ingeniería de software , estos modelos
comienzan como representaciones, relativamente
informales, de los requisitos del sistema, y
evolucionan en modelos detallados de clases,
Conexiones y relaciones de clases, el diseño del
sistema y el diseño de objetos.
 PRUEBAS DE LOS MODELOS DE
AOO Y DOO
Exactitud de los modelos de AOO y DOO

Durante el análisis y diseño, la exactitud

semántica
Debe juzgarse basada en la conformidad de
modelo
con el dominio del problema en el mundo real.
Si el modelo refleja con exactitud el mundo real ,
entonces es semánticamente correcto.
 CONSISTENCIA DE LOS MODELOS
DE AOO Y DOO

La consistencia de los modelos de A 0 0 y DO0 debe

juzgarse «considerando las relaciones entre
Entidades dentro del modelo. Un modelo
inconsistente tiene representaciones en una parte,
que no se reflejan correctamente en otras partes
del modelo»
ESTRATEGIAS DE PRUEBAS
ORIENTADAS A OBJETOS
 LAS PRUEBAS DE UNICIDAD EN EL CONTEXTO DE LA OO

•El concepto de unidad cambia cuando el software es orientado a

objetos

•La encapsulación conduce ala definición de clases y objetos

•Cada clase y cada instancia de una clase(objeto) ven atributos (Datos) y

operaciones (también conocido como métodos o servicios),que manipulan
estos datos

•La unicidad mas pequeña comprobable es la clase objeto encapsulado

LAS PRUEBAS DE INTEGRACION EN EL CONTEXTO OO

Ya que el software orientado a objetos no tiene una estructura de control

Jerárquico, las estrategias convencionales de integración descendente y es
accedente, tienen muy poco significado .en suma la integración de
operaciones una por una en una clase (la aproximación de la integración
incrementa convencional),a menudo es imposible por la interacción directa e
indirecta de los componentes que conforman la clase[BER93].
Existen dos estrategias diferentes para las pruebas de integración de los
sistemas OO{BIN94A}.
Pruebas de validación en un contexto OO

Al nivel de sistema o de validacion,los detalles de conexiones de clases desaparecen,

así como la validación con vencional,la validación del software OO se centra en las
acciones visibles al usuario y salidas reconocibles desde el sistema. para ayudar en la
construcción de las pruebas de validación ,el probador debe utilizar los casos de uso ,
que son parte del modelo de analisis.los casos de uso proporcionan un esenario,que
tiene una gran similitud de errores con los revelados en los requisitos de interacción
del usuario.

Los métodos de prueba convencionales de caja negra pueden usarse para realizar
pruebas de validación. Además los, casos de prueba deben derivarse del modelo de
comportamiento del objeto y del diagrama de flujo de sucesos, creado como parte del
AOO
Diseño de casos de prueba para
software oo.
1.-Cada caso de prueba debe ser identificado
separadamente, y asociado con la clase a probar.

2.- Debe declarar el propósito de la prueba.

3.-Debe de desarrollarse una lista de pasos a seguir, como

consecuencia de la prueba.
Pero además…
*Definición de una lista de estados.

*Una lista de mensajes y operaciones.

*Una lista de excepciones.

*Una lista de condiciones externas.

*Información adicional.
Implicaciones de los conceptos de O0
al diseño de casos de prueba.

La clase es el objetivo del diseño

de casos prueba.
Aplicabilidad de los métodos convencionales de
diseño de casos de prueba

Técnicas como el camino básico, pruebas de bucle o

técnicas de flujo de datos pueden ayudar a asegurar
que se ha probado cada sentencia de la operación.
Pruebas basadas en errores

El objetivo de las pruebas basadas en errores dentro de

un sistema 00, es diseñar pruebas que tengan una alta
probabilidad de revelar fallos
 23.4.5. Casos de prueba y
jerarquía de clases

Aunque se haya comprobado una clase base,

tendrá que comprobarse las clases derivadas
de ella.
 Pruebas OO

Caracteristicas:

Arquiectura software OO: subsistemas organizados por capas que

encapsulan capas que interaccionan entre si.

Necesario probar el sistemas OO en diferentes niveles.

Los modelos de análisis y diseño son similares
en estructura y contenido al programa OO, por
tanto las pruebas comienzan con la revisión de
estos modelos.
 
Paso inicial: verificación de modelos de análisis y
diseño
 Para los modelos de análisis y diseño hay que
comprobar:

Consistencia
Compleción
Exactitud
 23.4.6 Diseño de pruebas
basadas en el escenario
Las pruebas basadas en los errores no localizan
dos tipos de errores:
(1) especificaciones incorrectas y
(2) interacción entre subsistemas.
Las pruebas basadas en el escenario se concentran
en lo que el usuario hace, no en lo que el producto
hace.

Los escenarios revelan errores de interacción.

 23.5 Metodos de prueba
aplicables al nivel de clases
•Identificar cada caso de prueba y asociarlo explícitamente
con la clase a probar.
• Declarar el propósito de la prueba.
• Desarrollar una lista de pasos a seguir.
oDeclarar una lista
oLista de mensajes
oLista de excepciones
o Lista de condiciones
o Información adicional
 Metodos de prueba. A nivel
de clase
Verificación al azar: consiste en probar en orden
aleatorio diferentes secuencias válidas de
operaciones.
 Pruebas de partición:
Partición basada en estados: clasifica las
operaciones de clase en base a su habilidad de
cambiar el estado de la clase.
Partición basada en atributos: clasifica las
operaciones basada en los atributos que usa.
Partición basada en categorías: clasifica las
operaciones de acuerdo a la función genérica
que llevan a cabo.
 Pruebas de unidad

¿cuál es el concepto más parecido a módulo en OO?

Las pruebas de unidad en OO se realizan:
•Nivel de clase
•Nivel de de método
¿cómo se prueban las clases?

¿qué es un caso de prueba?

•Construcción de una instancia de la clase que se va
probar.
• Ejecución de una serie de servicios sobre ésta.
•Comprobación del resultado.
 Valores interesantes
Para diseñar correctamente los casos de prueba,
éstos deberán usar “valores interesantes”.
 Técnicas de obtención de valores
“interesantes”.

Existen técnicas para proponer valores realmente Interesantes

 
•Clases de equivalencias
A una clase de equivalencia pertenecen todos los valores que
provocan el mismo comportamiento de la clase bajo prueba

•Valores límite
Complementa a la anterior
23.6 Diseño de Casos de Prueba
Interclases
23.6.1. Prueba de múltiples clases
Kirani y Tsai [KIR94] sugieren la secuencia siguiente de
pasos, para generar casos de prueba aleatorios para
múltiples clases:
1.- Para cada clase cliente, utilice la lista de operaciones de
clase, para generar una serie de secuencias de pruebas al
azar. Las operaciones enviarán mensajes a las otras
clases servidoras.
2.- Para cada mensaje que se genere, determine la clase
colaboradora y la operación correspondiente en el objeto
servidor.
3.- Para cada operación en el objeto servidor (invocada por
mensajes enviados por el objeto cliente), determine los mensajes
que transmite.

4.- Para cada uno de los mensajes, determine el siguiente nivel

de operaciones que son invocadas, e incorpore éstas a la
secuencia de pruebas.

Ejemplo:

Aplicación Clases
Bancaria
[ KIR94]

Clases
 23.6.2 Prueba derivada de los modelos
de comportamiento
El DTE (Diagrama de transición de estados) para una
clase puede usarse para ayudar a derivar una secuencia
de pruebas, que ejercitarán el comportamiento dinámico
de la clase.

Representan:
Estados