Pruebas Orientadas o Objetos

Prueba de Integracion en el Contexto OO:

Puesto que el software orientado a objetos no tiene una estructura de control jerárquica, las estrategias de integración tradicionales, descendente y ascendente, tienen poco significado. Además, integrar operaciones una a la vez en una clase (el enfoque de integración incremental convencional) con frecuencia es imposible debido a las “interacciones directas e indirectas de los componentes que constituyen la clase”.

Existen dos diferentes estrategias para la prueba de integración de los sistemas OO. La primera, 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 efectos colaterales. El segundo enfoque de integración, prueba basada en uso, comienza la construcción del sistema al probar aquellas clases (llamadas independientes) que usan muy pocas clases de servidor (si es que emplean alguna). Después de probar las clases independientes, se examina la siguiente capa de clases que usan las clases independientes, llamadas dependientes. Esta secuencia de pruebas para las capas de clases dependientes continúa hasta que se construye todo el sistema. A diferencia de la integración convencional, cuando sea posible debe evitarse el uso de controladores y representantes como operaciones de reemplazo. La prueba de grupo es un paso en la prueba de integración del software OO. En ella, se ejercita un grupo de clases colaboradoras (determinadas al examinar el CRC y el modelo objeto-relación) al diseñar casos de prueba que intentan descubrir errores en las colaboraciones.

Pruebas de Validación en un Contexto OO:

En el nivel de validación o de sistema, desaparecen los detalles de las conexiones de clase. Como la validación convencional, la del software OO se enfoca en las acciones visibles para el usuario y en las salidas del sistema reconocibles por él mismo. Para auxiliar en la derivación de pruebas de validación, el examinador debe recurrir a casos de uso que sean parte del modelo de requerimientos. El caso de uso proporciona un escenario que tiene una alta probabilidad de descubrir errores en los requerimientos de interacción de usuario. Los métodos convencionales de prueba de caja negra  pueden usarse para activar pruebas de validación. Además, puede elegirse derivar casos de prueba del modelo de comportamiento del objeto y de un diagrama de flujo de evento creado como parte del AOO.

Métodos de Prueba Orientados a Objetos:

La arquitectura del software orientado a objetos da como resultado una serie de subsistemas en capas que encapsulan clases colaboradoras. Cada uno de estos elementos de sistema (subsistemas y clases) realiza funciones que ayudan a lograr requerimientos de sistema. 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 las capas arquitectónicas.

Los métodos de diseño de casos de prueba para el software orientado a objetos siguen evolucionando.

Sin embargo, Berard sugiere un enfoque global en el diseño de casos de

prueba OO:

1. Cada caso de prueba debe identificarse de manera única y explícita asociado con la clase que se va a probar.
2. Debe establecerse el propósito de la prueba.
3. Debe desarrollarse una lista de pasos de prueba para cada una de ellas, que debe contener:

• Una lista de estados especificados para la clase que se probará
• Una lista de mensajes y operaciones que se ejercitarán como consecuencia de la prueba
• Una lista de excepciones que pueden ocurrir conforme se prueba la clase
• Una lista de condiciones externas (es decir, con la finalidad de realizar adecuadamente las pruebas, cambios en el entorno externo al software que debe existir)
• Información complementaria que ayudará a comprender o a implementar la prueba

A diferencia del diseño convencional de casos de prueba, que se activan mediante una visión entrada-proceso-salida del software o con el detalle algorítmico de módulos individuales, la prueba orientada a objetos se enfoca en el diseño de secuencias apropiadas de operaciones para ejercitar los estados de una clase.

REFERENCIAS:

• Pressman, R. S., & Troya, J. M. (1988). Ingeniería del software.