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 AOO2. La estrategia para las pruebas de unidad e integración deben cambiar significativamente3. 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 PRUEBAUn 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 DOOLos 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 DOOLa 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

1

CAPÍTULO 22 PRUEBAS ORIENTADAS A OBJETOS

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.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 OODebido 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 OOComo 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 OOEnfoque 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 prueba3. 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 PRUEBALa 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 2

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.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 FALLOSEl 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 PRUEBASExisten 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 CLASESLa 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 ESCENARIOSLos 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 3

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, 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 CLASELa 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 OOExisten 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ÚLTIPLESEl 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 COMPORTAMIENTOEl 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)4

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 flujo de comportamiento del sistema.

5