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. realista. A pesar de que este objetivo objetivo fundamental 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 inte intens nsiv ivas as en los los sist sistem emas as OO. OO. La verd verdad ad es just justo o lo cont contra rari rio. o. Bind Binder er lo analiza, cuando afirma que: 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. objetos . La prueb prueba a de los los sist sistem emas as OO pres present entan an un nuevo nuevo conj conjunt unto o de reto retos s al ingeniero del software. La definición de pruebas debe ser ampliada para incluir técnicas técnicas que descubran descubran errores errores (revisiones (revisiones técnicas técnicas formales), formales), aplicadas aplicadas para los modelos modelos de AOO y DOO. La integridad, integridad, compleción compleción y consistenc consistencia ia de las representaciones OO deben ser evaluadas conforme se construyen. Las prueba pruebas s de unidad unidad pierden pierden mucho mucho de su signif significa icado, do, y las estrateg estrategias ias de integr integrac ación ión cambi cambian an de modo modo signif significa icativ tivo. o. En resumen resumen,, las estrat estrategi egias as 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 usos (des (desar arro roll llad ados os como como part parte e del del mode modelo lo de anál anális isis is OO) OO) se usan usan para para descubrir errores en el software a nivel de validación. En conc concre reto to se dise diseña ñan n y docu docume ment ntan an un conju conjunto nto de caso casos s de prueb pruebas as,, diseña diseñados dos para para probar probar clases clases,, sus colab colabora oracio ciones nes y compo comporta rtamie miento ntos, s, se definen los resultados esperados y se registran los resultados reales.
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 revisi revisione ones s técnic técnicas as formal formales es para para examin examinar ar la exacti exactitud tud y consis consistenc tencia ia de ambos modelos de análisis y diseño.
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.
Consistencia de los modelos de AOO 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.
Estrategias de Pruebas Orientadas a Objetos La estrategia clásica para la prueba de software de ordenador, comienza con “probar lo pequeño” y funciona hacia fuera haciendo “probar lo grande”. Entonces, se comienza con las pruebas de unidad, después se progresa hacia
las pruebas de integración y se culmina con las pruebas de validación del sistema. En aplicaciones convencionales, las pruebas de unidad se centran en las unidades de programa compilables más pequeñas –el subprograma (por ejemplo, módulo, subrutina, procedimiento, componente) –. Una vez que cada una de estas unidades han sido probadas individualmente, se integran en una estructura de programa, mientras que se ejecutan una serie de pruebas de regresión para descubrir errores, debidos a las interfaces entre los módulos y los efectos colaterales producidos por añadir nuevas unidades. Por último, el sistema se comprueba como un todo para asegurarse de que se descubren los errores en requisitos.
Las pruebas de unidad en el contexto OO Cuando se considera el software orientado a objetos, el concepto de unidad cambia. La encapsulación conduce a la definición de clases y objetos. Esto significa que cada clase y cada instancia de una clase (objeto), envuelven atributos (datos) y operaciones (también conocidos como métodos o servicios), que manipulan estos datos. En vez de probar un módulo individual, la unidad más pequeña comprobable es la clase u objeto encapsulado. Ya que una clase puede contener un número de operaciones diferentes, y una operación particular debe existir como parte de un número de clases diferentes, el significado de la unidad de prueba cambia drásticamente. No se puede probar más de una operación a la vez (la visión convencional de la unidad de prueba), pero sí como parte de una clase. La prueba de clases para el software OO es el equivalente de las pruebas de unidad para el software convencional. A diferencia de las pruebas de unidad del software convencional que tienden a centrarse en el detalle algorítmico de un módulo y de los datos que fluyen a través de la interfaz del módulo, la prueba de clases para el software OO se conduce mediante las operaciones encapsuladas por la clase y el comportamiento de la clase.
Las pruebas de integración en el contexto OO Ya que el software orientado a objetos no tiene una estructura de control jerárquico, las estrategias convencionales de integración descendente (topdown) y ascendente (bottom-up) tienen muy poco significado. En suma, la integración de operaciones una por una en una clase (la aproximación de la integración incremental convencional), a menudo es imposible por la “interacción directa e indirecta de los componentes que conforman la clase”. Existen dos estrategias diferentes para las pruebas de integración de los sistemas OO. El primero, las pruebas basadas en hilos, integran el conjunto de clases requeridas, para responder una entrada o suceso al sistema. Cada hilo se integra y prueba individualmente. Las pruebas de regresión se aplican para asegurar que no ocurran efectos laterales.
La segunda aproximación de integración, la prueba basada en el uso, comienza la construcción del sistema probando aquellas clases (llamadas clases independientes), que utilizan muy pocas (o ninguna) clases servidoras. Después de que las clases independientes se prueban, esta secuencia de pruebas por capas de clases dependientes continúa hasta que se construye el sistema completo. A diferencia de la integración convencional, el uso de drivers y stubs como operaciones de reemplazo, debe evitarse siempre que sea posible. La prueba de agrupamiento es una fase en las pruebas de integración de software OO. Aquí, un agrupamiento de clases colaboradoras (determinadas por la revisión de los modelos CRC y objeto-relación), se prueba diseñando los casos de prueba, que intentan revelar errores en las colaboraciones.
Las pruebas de validación en el contexto OO Al nivel de sistema o de validación, los detalles de conexiones de clases desaparecen. Así como la validación convencional, la validación del software OO se centra en las acciones visibles al usuario y salidas reconocibles desde el sistema. Para ayudar en la construcción de las pruebas de validación, el probador debe utilizar los casos de uso, que son parte del modelo de análisis. Los casos de uso proporcionan un escenario, que tiene una gran similitud de errores con los revelados en los requisitos de interacción del usuario. Los métodos de prueba convencionales de caja negra pueden usarse para realizar pruebas de validación. Además, los casos de prueba deben derivarse del modelo de comportamiento del objeto y del diagrama de flujo de sucesos, creado como parte del AOO.
Importante •
•
•
La prueba de software OO es equivalente al módulo de pruebas unitarias para el software convencional. No es recomendable comprobar operaciones por separado. La estrategia de integración de pruebas OO se centra en grupos de clases que colaboran o se comunican de la misma manera. Aparentemente, todos los métodos de pruebas de caja negra son aplicables a la OO.
Diseño de Casos de Prueba para Software OO Los métodos de diseño de casos de prueba para software orientado a objetos continúan evolucionando. Sin embargo, una aproximación global al diseño de casos de prueba OO ha sido definida por Bernard: 1. Cada caso de prueba debe ser identificado separadamente, y explícitamente asociado con la clase a probar. 2. Debe declararse el propósito de la prueba. 3. Debe desarrollarse una lista de pasos a seguir, como consecuencia de la prueba, pero además debe contener: a. Definición de una lista de estados, específicos para el objeto a probar.
b. Una lista de mensajes y operaciones, que se ejercitarán como consecuencia de las pruebas. c. Una lista de excepciones, que pueden ocurrir conforme el objeto se comprueba. d. Una lista de condiciones externas (por ejemplo, los cambios en el ambiente externo al software, e. que debe existir para conducir apropiadamente las pruebas). f. Información adicional, que ayudará a la comprensión e implementación de la prueba. A diferencia del diseño de pruebas convencional, que se conduce mediante una visión entrada-proceso-salida de software, o el detalle algorítmico de los módulos individuales, la prueba orientada a objetos se enfoca en las secuencias de operaciones de diseño apropiadas para probar los estados de una clase.
Aplicabilidad de los métodos convencionales de diseño de Casos de Prueba Los métodos de “caja blanca” pueden aplicarse a las operaciones definidas para una clase. Técnicas como el camino básico, pruebas de bucle o técnicas de flujo de datos pueden ayudar a asegurar que se ha probado cada sentencia de la operación. De cualquier modo, la estructura concisa de muchas operaciones de clase provoca que algunos defiendan que el esfuerzo aplicado a la prueba de “caja blanca” debe ser redirigido adecuadamente a las pruebas, a un nivel de clase. Los métodos de prueba de “caja negra” son tan apropiados para los sistemas OO, como lo son para los sistemas desarrollados utilizando los métodos convencionales de ingeniería de software. Como se dijo anteriormente, los casos de uso pueden proporcionar datos útiles en el diseño de pruebas de “caja negra2, y pruebas basadas en estados.
Pruebas basadas en errores El objetivo de las pruebas basadas en errores dentro de un sistema OO, es diseñar pruebas que tengan una alta probabilidad de revelar fallos. Ya que el producto o sistema debe adaptarse a los requerimientos del cliente, la planificación preliminar requerida para llevar a cabo la prueba basada en fallos comienza con el modelo de análisis. El probador busca fallos posibles (por ejemplo, los aspectos de implementación del sistema que pueden manifestarse en defectos). Para determinar si existen estos fallos, los casos de prueba se diseñan para probar el diseño o código. La estrategia consiste en hacer hipótesis de una serie de posibles fallos, y luego conducir las pruebas para comprobar las hipótesis.
