Pruebas Orientadas a

Objeto

Objetivo

El objetivo general de las pruebas orientadas a objeto

es encontrar el nmero mximo de errores con el
mnimo esfuerzo; El cual es idntico al objetivo de
las pruebas de software convencional.Pero la
estrategia y tctica difiere significativamente en las
pruebas OO.

Indicaciones para realizar pruebas

La definicin de las pruebas deben ampliarse
para incluir tcnicas de deteccin de errores
aplicados a los modelos AOO y DOO.
La estrategia para las pruebas de unidad e
integracin deben cambiar significativamente.
El diseo de casos de prueba deben tener en
cuenta las caractersticas propias del software
orientado a objeto.

Problemas comunes de anlisis

evitables

Se puede crear subclases especiales para acomodar el

atributo innecesario o sus excepciones.
Una mala interpretacin de la definicin de las clases
puede conducir a relaciones de clases incorrectas o
innecesarias.
El comportamiento del sistema o sus clases puede
ser impropiamente caracterizado para acomodar el
atributo extrao.

Problemas en el desarrollo
predecidles en el anlisis

Puede ocurrir una asignacin impropia de clases a

subsistemas y/o tareas durante el diseo del sistema.
Se realizara un esfuerzo de trabajo no necesario para
crear el diseo procedimental de las operaciones
relacionadas con el atributo innecesario.
El modelo de intercambio de mensajes seria
incorrecto (puesto que los mensajes deben disearse
para las operaciones que son extraas).

Modelos de pruebas AOO y DOO

Correccin (exactitud) de los modelos de AOO y

DOO:
-La notacin y sintaxis usada para representar los modelos de anlisis y
diseo estar vinculada al mtodo especifico de anlisis y diseo elegidos
para el proyecto .

Consistencia de los modelos de AOO y DOO:

-Esto puede juzgarse a travs de una << consideracin de las relaciones
entre entidades en el modelo. Un modelo inconsistente tiene
representaciones que por una parte no son correctamente reflejadas en
otras partes del modelo>> .

Estrategias de pruebas orientadas a

objeto

Prueba de unidad en el contexto OO:

-En vez de mdulos individuales, la menor unidad a probar es la clase u objeto
encapsulado.Una clase puede contener un cierto numero de operaciones, y una
operacin particular puede existir como parte de un nmero de clases diferentes.
Prueba de integracin en el contexto OO:
-Debido a que el software orientado a objeto no tiene una estructura de control
jerrquica, las estrategias convencionales de integracin ascendente y descendente
poseen un significado muy pequeo.Utiliza dos nuevas pruebas : las basadas en
hilos y las basadas en uso.
Prueba de validacin en un contexto OO:
-En el nivel de validacin o del sistema , los detalles de conexiones de clases
desaparecen . La validacin del software se centra en las acciones visibles de
usuario y salidas del sistema reconocidas por el.

Diseo de casos de prueba para el software

OO

Implicaciones de los conceptos OO para el diseo de casos de prueba:

-Como ya hemos visto, la clase OO es el objetivo para el diseo de los
casos de prueba. Debido al encapsulamiemto de atributos y operaciones
complica un poco la elaboracin de dichas pruebas.
Aplicabilidad de mtodos convencionales de diseo de casos de
prueba:
-Los mtodos de caja-blanca y caja-negra pueden aplicarse a las
operaciones que se definen en una clase.
Pruebas basadas en fallo:
-El objetivo de la prueba basada en fallos dentro de sistemas OO es el
disear pruebas que posean una alta probabilidad en la deteccin de
errores posibles .

Diseo de casos de prueba para el software

OO

El impacto de la programacin OO en la realizacin de pruebas:

-Existen varias formas en las que la programacin orientada a objetos impacta en la
realizacin de las pruebas. Dependiendo del enfoque de la POO: algunos tipos de
errores se tornan menos posibles (no importa para lo que se pruebe), algunos tipos
de errores se tornan mas posibles (importando para lo que se pruebe), aparecen
nuevos tipos de errores .
Casos de prueba y jerarqua de clases:
- La herencia no obvia la necesidad de ejecucin de pruebas completas en todas las
clases derivadas. De hecho esto puede complicar el proceso de prueba.
Diseo de pruebas basadas en escenarios:
- Los resultados de pruebas basadas en errores no capturan dos tipos principales de
errores: (1) especificaciones incorrectas, y (2)interacciones entre
subsistemas.Cuando ocurren errores asociados con especificaciones incorrectas, el
producto no hace lo que desea el cliente. Puede hacer lo incorrecto, o pude omitir
alguna funcionalidad importante.

Mtodos de pruebas aplicables al

nivel de clase

Pruebas aleatorias para clases OO:

- Estas pruebas deben atacar una clase especifica a la vez identificando
todos los mtodos asociados con el fin de realizar diferentes secuencias de
casos de prueba para dichos mtodos.
Pruebas de particin a nivel clase:
-Las pruebas de particin reducen el numero de casos de prueba necesarios
para ejercitar la clase de la manera en la que lo hace la particin
equivalente para el software convencional.Las particiones basadas en
estados categorizan las operaciones de clases basndose en su habilidad
para cambiar de estados.

Diseo de casos de prueba

interclases

Pruebas de clases mltiples:

- Para cada clase cliente , usar la lista de operadores de clase para generar
una serie de consecuencias de pruebas aleatorias, generando mensajes.
- Para cada mensaje que se genera, determina la clase colaboradora y el
operador correspondiente en el objeto servidor.
- Para cada operador en el objeto servidor, determina los mensajes que
este transmite.
- Para cada uno de los mensajes, determina el prximo nivel de
operadores que se invocan e incorporarlos en la secuencia de prueba.
Pruebas derivadas de modelos de comportamiento:
-Se debe analizar el diagrama de transicin de estados como el modelo de
representar el comportamiento dinmico de una clase.