Pruebas de Integración orientadas a objetos

 

Pruebas de Integración orientadas a objetos

Las pruebas de integración orientadas a objetos se enfocan a la interacción entre unidades, suponiendo que cada una fue probada a nivel de unidad. A este nivel se mezclan aspectos estructurales que relacionan las maneras de interactuar de las unidades y también los aspectos típicamente funcionales.

Las pruebas de integración se ven dificultadas por el polimorfismo y la liga tardía al tiempo de ejecución. También, en sistemas distribuidos, el uso de objetos remotos resulta problemático (Fernández Peña, 2020).

Según Quiñones (2019) en las pruebas de integración se busca:

• Configuración (Mal control de versiones)
• Funciones faltantes
• Incompatibilidades por versiones
• Inconsistencias en archivos y bases de datos
• Violación de integridad
• Llamado a método equivocado
• Una unidad cliente envía un mensaje que viola la precondición del servidor

Cuando se desarrolla software orientado a objetos guiado por casos de uso, éstos se convierten en la unidad mínima de funcionalidad. Se recomienda incluir un diagrama para el caso típico exitoso y otro para un caso alterno, generalmente una falla típica.

Un diagrama de secuencia presenta varios elementos importantes para las pruebas de integración:

• El conjunto de clases (objetos) que interactúan.
• Las interacciones entre los objetos, mostradas como secuencias de mensajes que activan métodos.

Cada caso de uso ameritará varios casos de prueba; al menos uno por cada diagrama de secuencia que se haya preparado, pero usualmente más. El mayor número se origina por dos elementos:

• El estado de los diversos componentes del diagrama
• Los posibles valores que pueden tomar los diversos parámetros de los métodos invocados.

Debido a que el software orientado a objeto no tiene una estructura de control jerárquica, las estrategias convencionales de integración ascendente y descendente poseen un significado muy pequeño (Colina 2015).

Nuevos paradigmas en Orientación a Objetos:

Pruebas basadas en hilos

Integra las clases requeridas para responder a una entrada o suceso del sistema (diagramas de secuencia de UML). Cada hilo se integra y prueba individualmente

Pruebas basadas en el uso

• Se comienza probando las clases más independientes
• Se continúa con las más dependientes hasta probar todo el sistema

Pruebas de Pruebas de agrupamiento

• Se selecciona un agrupamiento de clases colaboradoras
• Se prueba diseñando las clases de pruebas que revelan errores en las colaboraciones

Las pruebas de caminos son una estrategia de pruebas estructurales cuyo objetivo es probar cada camino de ejecución independiente en un componente o programa. Si cada camino independiente, entonces todas las sentencias en el componente deben haberse ejecutado al menos una vez. Además, todas las sentencias condicionales comprueban para los casos verdadero y falso. En un proceso de desarrollo orientado a objetos, pueden utilizarse las pruebas de caminos cuando se prueban los métodos asociados a los objetos.

El número de caminos en un programa es normalmente proporcional a su tamaño. Puesto que los módulos se integran en sistemas, no es factible utilizar técnicas de pruebas estructurales. Por lo tanto, las técnicas de pruebas de caminos son principalmente utilizadas durante las pruebas de componentes.

Las pruebas de caminos no prueban todas las posibles combinaciones de todos los caminos en el programa. Para cualquier componente distinto de un componente trivial sin bucles, este es un objetivo imposible. Existe un número infinito de posibles combinaciones de caminos en los programas con bucles. Incluso cuando todas las sentencias del programa se han ejecutado al menos una vez, los defectos del programa todavía pueden aparecer cuando se combinan determinados caminos.

El punto de partida de una prueba de caminos es un grafo de flujo del programa. Este es un modelo del esqueleto de todos los caminos en el programa. Un grafo de flujo consiste en nodos que representan decisiones y aristas que muestran el flujo de control. El grafo de flujo se construye reemplazando las sentencias de control del programa por diagramas equivalentes. Si no hay sentencias goto en un programa, es un proceso sencillo derivar su grafo de flujo. Cada rama en una sentencia condicional (if-then-else o case) se muestra como un camino independiente. Una flecha que vuelve al nodo de la condición denota un bucle.

El objetivo de la prueba de caminos es asegurar que cada camino independiente en el programa se ejecuta al menos una vez. Un camino independiente del programa es aquel que recorre al menos una nueva arista en el grafo de flujo. En términos de programas, esto significa ejecutar una o más condiciones nuevas. Se deben ejecutar las ramas verdadera y falsa de todas las condiciones (Sommerville, 2005).

Videos:

Referencias bibliográficas

Colina, Alejandra. 2015. “Prueba de Aplicaciones Orientadas a Objeto.”

Fernández Peña, Juan Manuel. 2020. “Guía Mínima de Prueba de Software Orientado a Objetos.”

Quiñones, I. 2019. “Prueba Software Orientado a Objetos.” Retrieved November 24, 2022 (https://es.slideshare.net/IreneQuionesOsorio/prueba-software-orientado-a-objetos).

Sommerville, Ian. 2005. “(99+) Ingenieria de Software - Ian Sommerville 7a Edicion | Felipe Ariel Collipal Cruz - Academia.Edu.” Retrieved November 17, 2022 (https://www.academia.edu/15059886/Ingenieria_de_Software_Ian_Sommerville_7a_Edicion).