PRUEBAS ORIENTADAS A OBJETOS

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. A pesar de que este objetivo fundamental permanece inalterado para el
software orientado a objetos, la naturaleza de los programas OO cambian las estrategias y
las tácticas de prueba.

Puede argumentarse que, conforme el AOO y el DOO maduran, una mayor reutilización de
patrones de diseño mitigarán la necesidad de pruebas intensivas en los sistemas OO.

Cada reutilización es un nuevo contexto de uso y es prudente repetir las pruebas. Parece
probable que se necesitarán menos pruebas para obtener una alta fiabilidad en sistemas
orientados a objetos.

La prueba de los sistemas OO presentan un nuevo conjunto de retos al ingeniero del

software. La definición de pruebas debe ser ampliada para incluir técnicas que descubran
errores (revisiones técnicas formales), aplicadas para los modelos de AOO y DOO. La
integridad, compleción y consistencia de las representaciones OO deben ser evaluadas
conforme se construyen. Las pruebas de unidad pierden mucho de su significado, y las
estrategias de integración cambian de modo significativo. En resumen, las estrategias y
tácticas de prueba deben tomarse en cuenta para las características propias del software OO.

Las pruebas OO son estratégicamente similares a las pruebas de sistemas convencionales,

pero tácticamente diferentes. Ya que los modelos de análisis y diseño OO son similares en
estructura y contenido al programa OO, las pruebas comienzan con la revisión de estos
modelos. Una vez que se ha generado el código, las pruebas OO comienzan en lo pequeño,
con las pruebas de clases. Existen pruebas para probar las operaciones de las clases y
examinar si los errores existen cuando una clase colabora con otras. Por último, los casos
de usos (desarrollados como parte del modelo de análisis OO) se usan para descubrir
errores en el software a nivel de validación.
En concreto se diseñan y documentan un conjunto de casos de pruebas, diseñados para
probar clases, sus colaboraciones y comportamientos, se definen los resultados esperados y
se registran los resultados reales.

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.

PRUEBAS DE LOS MODELOS AOO Y DOO

Los modelos de análisis y diseño no pueden probarse en el sentido convencional, ya que no

pueden ejecutarse. Sin embargo, se pueden utilizar las revisiones técnicas formales para
examinar la exactitud y consistencia de ambos modelos de análisis y diseño.

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

La notación y sintaxis que se utiliza para representar los modelos de análisis y diseño se
corresponderá con el método específico de análisis y diseño, elegido para el proyecto. Por
consiguiente, la exactitud sintáctica se juzga en el uso apropiado de la simbología; cada
modelo se revisa para asegurarse de que se han mantenido las convenciones propias del
modelado.

Durante el análisis y diseño, la exactitud semántica debe juzgarse basada en la conformidad

del modelo con el dominio del problema en el mundo real. Si el modelo refleja con
exactitud el mundo real (al nivel de detalle apropiado a la etapa de desarrollo en la que se
revisa el modelo), entonces es semánticamente correcto. Para determinar si el modelo en
realidad refleja el mundo real, debe presentarse a expertos en el dominio del problema,
quienes examinarán las definiciones de las clases y sus jerarquías, para detectar omisiones o
ambigüedades. Las relaciones entre clases (conexiones de instancia) se evalúan para
determinar si reflejan con exactitud conexiones del mundo real.

2. CONSISTENCIA DE LOS MODELOS DE AOO Y DOO

La consistencia de los modelos de AOO y DOO 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.

Para evaluar la consistencia, se debe examinar cada clase y sus conexiones a otras clases.
Un modelo clase-responsabilidad-colaboración (CRC) y un diagrama objeto-relación
pueden utilizarse para facilitar esta actividad. El modelo CRC se compone de una tarjeta
índice CRC. Cada tarjeta CRC muestra el nombre de la clase, sus responsabilidades
(operaciones) y sus colaboradores (otras clases a las que se envían mensajes y de las cuales
depende para el cumplimiento de sus responsabilidades). Las colaboraciones implican una
serie de relaciones (por ejemplo, conexiones), entre clases del sistema OO. El modelo
objeto-relación proporciona una representación gráfica de las conexiones entre clases. Toda
esta información se puede obtener del modelo de AOO.

Una vez que se crea el modelo de DOO, deben llevarse a cabo también las revisiones del
diseño del sistema y del diseño de objetos. El diseño del sistema describe el producto
arquitectónico global, los subsistemas que componen el producto, la manera en que los
subsistemas se asignan a los procesadores, la asignación de clases a subsistemas y el diseño
de la interfaz de usuario. El diseño de objetos presenta los detalles de cada clase, y las
actividades de mensajería necesarias para implementar las colaboraciones entre clases.