CAPÍTULO 22 PRUEBAS ORIENTADAS A OBJETOS

Para probar adecuadamente los sistemas OO, deben hacerse tres cosas:
1. La definición de las pruebas debe ampliarse para incluir técnicas de detección de errores
aplicados a los modelos de DOO y AOO
2. La estrategia para las pruebas de unidad e integración deben cambiar significativamente
3. El diseño de casos de prueba debe tener en cuenta las características propias del software
orientado a objetos.

22.1. AMPLIANDO LA VISIÓN DE LA REALIZACIÓN DE LA PRUEBA

Un problema en la definición de atributos de clases no descubierto durante el análisis provocará
efectos colaterales que pudieran ocurrir si el problema no se descubriera hasta el diseño o
codificación (o incluso hasta la próxima iteración del análisis).
Si el problema permanece sin detectar durante el diseño y se pasa a la actividad de codificación, se
realizará un esfuerzo y desgaste de energía considerable para generar el código que implemente un
atributo innecesario.
Durante las etapas posteriores de su desarrollo, los modelos de AOO y DOO proporcionan
información sustancial acerca de la estructura y comportamiento del sistema. Por esta razón, estos
modelos deberán ser sometidos a una revisión rigurosa, previa a la generación de código.
Todos los modelos orientados a objetos deberán probar su corrección (exactitud), compleción y
consistencia dentro del contexto de la sintaxis del modelo, semántica y pragmática.

22.2. MODELOS DE PRUEBAS AOO Y DOO

Los modelos de análisis y diseño no pueden probarse en el sentido convencional, pues no pueden
ejecutarse. Sin embargo, pueden usarse las revisiones técnicas formales para examinar la corrección
(exactitud) y consistencia de ambos modelos.

22.2.1. CORRECCIÓN (EXACTITUD) DE LOS MODELOS DE AOO Y DOO

La notación y sintaxis usada para representar los modelos de análisis y diseño estará vinculada el
método específico de análisis y diseño elegidos para el proyecto.
Para determinar si el modelo realmente refleja el mundo real, deberá ser presentado a los expertos
del dominio, quienes examinarán las definiciones de clases y jerarquías en busca de omisiones y
ambigüedades. Se evalúan las relaciones de clases (conexiones de instancias) para determinar si
reflejan exactamente las conexiones de objetos del mundo real.

22.2.2. CONSISTENCIA DE LOS MODELOS DE AOO Y DOO

La consistencia de los modelos de AOO y DOO pueden juzgarse a través de una “consideración 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”.
Para valorar la consistencia, deberán examinarse cada clase y sus conexiones a otras clases. Puede
usarse el modelo clase-responsabilidad-colaboración (CRC) y un diagrama de objeto-relación para
facilitar esta actividad.
El modelo objeto-relación aporta una representación gráfica de las conexiones entre clases.

22.3. ESTRATEGIAS DE PRUEBAS ORIENTADAS A OBJETOS

La estrategia clásica para ejecutar pruebas sobre software de computadora comienza con la “prueba
a pequeña escala” y trabaja moviéndose hacia la “prueba a gran escala”. Comenzamos con la prueba
de unidad, y culminamos con la de validación y prueba del sistema.

22.3.1. PRUEBA DE UNIDAD EN EL CONTEXTO OO

Al considerar el software orientado a objetos, cambia el concepto de unidad. En vez de módulos
individuales, la menor unidad a probar es la clase y objeto encapsulado. 1
No podemos probar con detalle una operación aisladamente sino como parte de una clase.
A diferencia de la prueba de unidad del software convencional, el cual tiende a centrarse en el
detalle algorítmico de un módulo y los datos que fluyen a lo largo de la interfaz de este, la prueba
de clase para software OO está dirigido por las operaciones encapsuladas por la clase y el estado del
comportamiento de la clase.

22.3.2. PRUEBA DE INTEGRACIÓN EN EL CONTEXTO OO

Debido a que el software orientado a objetos no tiene una estructura de control jerárquica, la
integración una a una, de operaciones en una clase (enfoque convencional) es a menudo imposible
debido a “las interacciones directas e indirectas de las componentes que conforman la clase”.
Existen dos estrategias diferentes para pruebas de integración en sistemas OO:
Pruebas basadas en hilos: integra el conjunto de clases necesario para responder a una entrada o
evento del sistema. Cada hilo de se integra y prueba individualmente.
Pruebas basadas en uso: comienza con la construcción del sistema probando aquellas clases
(llamadas clases independientes) que usan muy pocas (si alguna) de las clases servidor. Después de
probar las clases independientes, se comprueba la próxima capa de clases, llamadas clases
dependientes, que usan las clases independientes. Esta secuencia de capas de pruebas de clases
dependientes continúa hasta construir el sistema por completo.

22.3.3. PRUEBA DE VALIDACIÓN EN UN CONTEXTO OO

Como en el caso del soft convencional, la validación del soft orientado a objetos se centra en las
acciones visibles del usuario y las salidas del sistema reconocibles por éste. El ejecutor de la prueba
debe basarse en los casos de uso.
Los métodos convencionales de prueba de caja negra pueden usarse para dirigir las pruebas de
validación. Adicionalmente, se pueden derivar casos de prueba a partir del modelo objeto-
comportamiento y del diagrama de flujo de eventos como parte del AOO.

22.4. DISEÑO DE CASOS DE PRUEBA PARA SOFTWARE OO

Enfoque general para el diseño OO de casos de prueba:
1. Cada paso de prueba debe estar identificado unívocamente y asociado explícitamente con la
clase a probar.
2. Debe establecer el propósito de la prueba
3. Desarrollar una lista de pasos de prueba para cada prueba.
A diferencia del diseño de caos de prueba convencionales, que se orienta a través de una visión
entrada-procesamiento-salida del software o por el detalle algorítmico de los módulos individuales,
la prueba orientada a objetos se centra en el diseño de secuencias de operaciones apropiadas para
ejercitar el estado de una clase.

22.4.1. IMPLICACIONES DE LOS CONCEPTOS OO PARA EL DISEÑO DE CASOS DE

PRUEBA
La clase OO es el objetivo para el diseño de casos de prueba. Debido al encapsulamiento de
atributos y operaciones, la prueba de operaciones fuera de la clase es en general improductivo.
La herencia múltiple complica adicionalmente la prueba aumentando el número de contextos para
los cuales la prueba es necesario.

22.4.2. APLICABILIDAD DE MÉTODOS CONVENCIONALES DE DISEÑO DE CASOS

DE PRUEBA
Los métodos de caja-blanca pueden aplicarse a las operaciones que se definen para una clase.
También técnicas de camino básico, pruebas de bucle, o flujo de datos pueden ayudar a asegurar que
han sido probada cada sentencia de una operación. La concisa estructura de muchas operaciones de
clase provocan que algunos argumenten que el esfuerzo aplicado en la prueba de tipo caja-blanca
pudieran redirigirse mejor hacia pruebas a nivel de clase. 2
Los métodos de prueba de caja-negra son tan apropiados para sistemas OO como para métodos
convencionales.

22.4.3. PRUEBAS BASADAS EN FALLOS

El objetivo de la prueba basada en fallos dentro de sistemas OO es el diseñar pruebas que posean
una alta probabilidad en la detección de errores posibles. Comienza con el modelo de análisis. El
ejecutor de la prueba debe buscar la aparición de errores posibles. Para determinar si estos fallos
existen, se diseñan casos de prueba para ejercitar el diseño o el código.

22.4.4. EL IMPACTO DE LA PROGRAMACIÓN OO EN LA REALIZACIÓN DE

PRUEBAS
Existen varias formas en las que la programación orientada a objetos impacta en la realización de
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 más posibles(importando para lo que se pruebe).
 Aparecen nuevos tipos de errores.
La prueba de operaciones de clases OO es análoga a probar código que toma una función parámetro
y después la invoca. La herencia es una vía conveniente para la producción de operaciones
polimórficas. Por otra parte donde se llama, lo que interesa no es la herencia, sino el polimorfismo.
La herencia no hace la búsqueda de requisitos de la prueba más directa.

22.4.5. CASOS DE PRUEBA Y JERARQUÍA DE CLASES

La herencia no obvia la necesidad de ejecución de pruebas completas en todas las clases derivadas.
De hecho, esto puede complicar el proceso de prueba.
Una clase base contiene operaciones heredada y redefinida.
Una clase derivada redefine a redefinida para que sirva en un contexto local.
Base :: redefinida () y derivada :: redefinida () son dos operaciones diferentes con diferentes
especificaciones e implementaciones. Cada una tendrá un conjunto de requisitos de prueba. Estos
requisitos de prueba verifican la existencia de errores posibles: errores de integración, de condición
y casos extremos. Pero las operaciones parecen ser similares. Sus conjuntos de requisitos se
solaparán. Mientras mejor sea el diseño OO, mayor será este solapamiento. Se necesitaran derivar
nuevas pruebas solamente para aquellos requisitos de derivada :: redefinida() que no sean
satisfechos por las pruebas de base :: redefinida()

22.4.6. DISEÑOS 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.
Las pruebas basadas en escenarios se concentran en lo que el usuario hace, no en lo que hace el
producto. Esto significa capturar las tareas (a través de casos de uso) que el usuario debe realizar, y
después aplicarlas a sus variantes como pruebas.
Los escenarios descubren errores de interacción. Las pruebas basadas en escenarios tiende a utilizar
varios subsistemas en una prueba simple (los usuarios no se limitan a sí mismos al uso de un solo
subsistema en un momento)

22.4.7. PROBANDO LA ESTRUCTURA SUPERFICIAL Y LA ESTRUCTURA PROFUNDA

La estructura superficial se refiere a la estructura externamente observable de un programa OO,
esto es, la estructura inmediatamente obvia al usuario final. Antes que ejecutar funciones, a los
usuarios de muchos sistemas OO se les dan objetos que deben manipular de alguna manera. Pero
cualquiera sea la interfaz, las pruebas aún se basan en tareas de usuario.
La estructura profunda se refiere a los detalles técnicos internos de un programa OO. Esto es,
3 la
estructura que aparece a través del examen del diseño y/o código. La prueba de la estructura en
profundidad se diseña para ejercitar dependencias, comportamientos, y mecanismos de
comunicación. Los modelos de análisis y diseño se usan como base para la prueba de la estructura
profunda.

22.5. MÉTODOS DE PRUEBA APLICABLES AL NIVEL DE CLASE

La realización de pruebas desde lo más elemental para sistemas OO se centran en una clase simple y
los métodos encapsulados por ella. Las pruebas aleatorias y el particionamiento son métodos que
pueden usarse para ejercitar una clase durante las pruebas OO.

22.5.1. PRUEBAS ALEATORIAS PARA CLASES OO

Existen muchas permutaciones de las operaciones. El mínimo comportamiento de la historia de vida
de una instancia de una clase representa la secuencia mínima de prueba. Pudieran ocurrir una
amplia variedad de comportamientos dentro de una secuencia.
Puede generarse aleatoriamente una amplia variedad de secuencias de operaciones. Se ejecutarán
estas pruebas de orden aleatorio para ejercitar las historias de vida de diferentes instancias de clase.

22.5.2. PRUEBAS DE PARTICIÓN AL NIVEL CLASE

Las pruebas de partición reducen al mínimo el número de casos de prueba necesarios para ejercitar
una clase. Las entradas y salidas están categorizadas, y los casos de prueba están diseñados para
ejercitar cada categoría.
Las particiones basadas en estados categorizan las operaciones de clase basándose en su habilidad
para cambiar el estado de la clase.
Las pruebas se diseñan de manera tal que se ejerciten por separado las operaciones que cambian de
estado y las que no lo hacen.
Las partición basada en los atributos categoriza las operaciones de clase basándose en los atributos
que usan. Se diseñan entonces secuencias de pruebas para cada partición. La partición basada en
categorías categoriza las operaciones de clases basándose en las funciones genéricas que cada una
realiza.

22.6. DISENO DE CASOS DE PRUEBA INTERCLASES

El diseño de casos de prueba se torna más complicado cuando comienza la integración del sistema
OO. Es en esta etapa cuando deben comenzar las pruebas de las colaboraciones entre clases.
Como en la prueba de clases individuales, las pruebas de colaboraciones entre clases pueden
realizarse a través de la aplicación de métodos aleatorios y de particionamiento, así como pruebas
basadas en escenarios y pruebas de comportamiento.

22.6.1. PRUEBAS DE CLASES MÚLTIPLES

El enfoque para pruebas de partición de clases múltiples es similar al usado para la prueba de
partición de clases individuales. Sin embargo, la secuencia de prueba se expande para incluir
aquellas operaciones que se invocan a través de los mensajes a las clases colaboradoras. Un enfoque
alternativo divide las pruebas basándose en las interfaces a una clase particular.

22.6.2. PRUEBAS DERIVADAS DE 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 ejercitan el comportamiento dinámico de la clase (y aquellas clases que
colaboran con ella)
Las pruebas a diseñar deberán ser capaces de abarcar todos los estados.
Se podrán derivar aún más casos de prueba para asegurar que se han ejercitado de manera adecuada
todos los comportamientos de la clase. En situaciones en las cuales el comportamiento de la clase
consiste en colaborar con una o más clases, se usan múltiples DTE para registrar el flujo4 de
comportamiento del sistema.