Pruebas Orientadas a Objeto

Objetivo El objetivo general de las pruebas orientadas a objeto es encontrar el número máximo de errores con el mínimo esfuerzo; El cual es idéntico al objetivo de las pruebas de software convencional.Pero la estrategia y táctica difiere significativamente en las pruebas OO.

Indicaciones para realizar pruebas La definición de las pruebas deben ampliarse para incluir técnicas de detección de errores aplicados a los modelos AOO y DOO. La estrategia para las pruebas de unidad e integración deben cambiar significativamente. El diseño de casos de prueba deben tener en cuenta las características propias del software orientado a objeto.

Problemas comunes de análisis evitables Se puede crear subclases especiales para acomodar el atributo innecesario o sus excepciones. Una mala interpretación de la definición de las clases puede conducir a relaciones de clases incorrectas o innecesarias. El comportamiento del sistema o sus clases puede ser impropiamente caracterizado para acomodar el atributo extraño.

Problemas en el desarrollo predecidles en el análisis Puede ocurrir una asignación impropia de clases a subsistemas y/o tareas durante el diseño del sistema. Se realizaría un esfuerzo de trabajo no necesario para crear el diseño procedimental de las operaciones relacionadas con el atributo innecesario. El modelo de intercambio de mensajes seria incorrecto (puesto que los mensajes deben diseñarse para las operaciones que son extrañas).

Modelos de pruebas AOO y DOO Corrección (exactitud) de los modelos de AOO y DOO: -La notación y sintaxis usada para representar los modelos de análisis y diseño estará vinculada al método especifico de análisis y diseño elegidos para el proyecto . Consistencia de los modelos de AOO y DOO: -Esto puede 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>> .

Estrategias de pruebas orientadas a objeto Prueba de unidad en el contexto OO: -En vez de módulos individuales, la menor unidad a probar es la clase u objeto encapsulado.Una clase puede contener un cierto numero de operaciones, y una operación particular puede existir como parte de un número de clases diferentes. Prueba de integración en el contexto OO: -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.Utiliza dos nuevas pruebas : las basadas en hilos y las basadas en uso. Prueba de validación en un contexto OO: -En el nivel de validación o del sistema , los detalles de conexiones de clases desaparecen . La validación del software se centra en las acciones visibles de usuario y salidas del sistema reconocidas por el.

Diseño de casos de prueba para el software OO Implicaciones de los conceptos OO para el diseño de casos de prueba: -Como ya hemos visto, la clase OO es el objetivo para el diseño de los casos de prueba. Debido al encapsulamiemto de atributos y operaciones complica un poco la elaboración de dichas pruebas. Aplicabilidad de métodos convencionales de diseño de casos de prueba: -Los métodos de caja-blanca y caja-negra pueden aplicarse a las operaciones que se definen en una clase. Pruebas basadas en fallo: -El 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 .

Diseño de casos de prueba para el software OO El impacto de la programación OO en la realización de pruebas: -Existen varias formas en las que la programación orientada a objetos impacta en la realización de las 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 mas posibles (importando para lo que se pruebe), aparecen nuevos tipos de errores . Casos de prueba y jerarquía de clases: - La 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. Diseño de pruebas basadas en escenarios: - Los resultados de pruebas basadas en errores no capturan dos tipos principales de errores: (1) especificaciones incorrectas, y (2)interacciones entre subsistemas.Cuando ocurren errores asociados con especificaciones incorrectas, el producto no hace lo que desea el cliente. Puede hacer lo incorrecto, o pude omitir alguna funcionalidad importante.

Métodos de pruebas aplicables al nivel de clase Pruebas aleatorias para clases OO: - Estas pruebas deben atacar una clase especifica a la vez identificando todos los métodos asociados con el fin de realizar diferentes secuencias de casos de prueba para dichos métodos. Pruebas de partición a nivel clase: -Las pruebas de partición reducen el numero de casos de prueba necesarios para ejercitar la clase de la manera en la que lo hace la partición equivalente para el software convencional.Las particiones basadas en estados categorizan las operaciones de clases basándose en su habilidad para cambiar de estados.

Diseño de casos de prueba interclases Pruebas de clases múltiples: - Para cada clase cliente , usar la lista de operadores de clase para generar una serie de consecuencias de pruebas aleatorias, generando mensajes. - Para cada mensaje que se genera, determina la clase colaboradora y el operador correspondiente en el objeto servidor. - Para cada operador en el objeto servidor, determina los mensajes que este transmite. - Para cada uno de los mensajes, determina el próximo nivel de operadores que se invocan e incorporarlos en la secuencia de prueba. Pruebas derivadas de modelos de comportamiento: -Se debe analizar el diagrama de transición de estados como el modelo de representar el comportamiento dinámico de una clase.