Prueba de Aplicaciones Orientadas a ObjetoING. ALEJANDRA COLINA VARGASNOVIEMBRE, 2015

Ampliación de las Técnicas de Pruebas

NO, porque son distintas a los sistemas orientados a objetos debido a las característicasparticulares de cada uno.

No todas las pruebas se realizan sobre artefactos “software”, sino también sobre los modelos

En los sistemas software OO, las pruebas son:

› Unitarias

› de Integración

› de Validación

Si desarrollo un Software Orientado a Objetos puedo usar las mismastécnicas del desarrollo convencional???

Ampliación de las Técnicas de Pruebas

La naturaleza de los programas OO cambian las estrategias y tácticas de prueba

Reutilización, abstracción, conexiones y relaciones entre clases, diseño del sistema, diseño deobjetos… hasta su implementación.

¿Cómo es la Arquitectura del Software OO?

Subsistemas organizados por capas que encapsulan clases que colaboran entre sí

Necesario probar el sistema OO en diferentes niveles

En cada etapa los modelos pueden probarse para descubrir errores y evitar que sepropaguen a la siguiente iteración

Ampliación de las Técnicas de Pruebas

En 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

EN RESUMEN…

Ampliación de las Técnicas de Pruebas

› Antes que el código, se generan los modelos de análisis y diseño del sistema

› Estos son similares en estructura y contenido al programa OO, por tanto las pruebas

comienzan con la revisión de estos modelos

Como iniciar la verificación de modelos de Análisis y Diseño?

Ampliación de las Técnicas de Pruebas

› Exactitud

› ¿qué es? Cumpla con el dominio del problema

› ¿cómo se comprueba? Evaluación de los expertos en el tema

› Compleción

› ¿qué es? El modelo incluye todas las partes necesarias para su correcta definición (nombre de los métodos, tipos de datos, parámetros..)

› ¿cómo se comprueba? Evaluación de los expertos en el tema

› Consistencia

› ¿qué es? Las relaciones entre las entidades se respetan en todas las partes del modelo

› ¿cómo se comprueba? Listas de comprobación

Ampliación de las Técnicas de Pruebas

› La creación de 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 caracterizado no apropiadamente para acomodar el atributo extraño

› 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

Si no se comprueba los modelos que puede suceder???

Estrategias de Pruebas

Prueba de unidad en el contexto OO:

En vez de módulos individuales, la menor unidad a probar es la clase u objetoencapsulado.

Una clase puede contener un cierto numero de operaciones, y una operación particularpuede existir como parte de un número de clases diferentes.

¿Qué es un caso de prueba en este caso?

1. Construcción de una instancia de la clase que se va probar

2. Ejecución de una serie de servicios sobre ésta

3. Comprobación del resultado

Estrategias de Pruebas

Prueba de unidad en el contexto OO:

La prueba de clase para el software OO se activa mediante las operaciones encapsuladas por la clase y por el comportamiento de estado de la misma

Ejemplo 1:

Estrategias de Pruebas

Prueba de unidad en el contexto OO: A nivel de Métodos . (Prueba Caja Negra)

Estrategias de Pruebas

Prueba de unidad en el contexto OO: A nivel de Métodos . (Prueba Caja Blanca)

Para realizar el seguimiento del código fuente según se vanejecutando los casos de prueba

› Conocer cuánto código se ha recorrido

› Determinar un valor cuantitativo de la cobertura según el criterio usado según el criterio usado (sentencias, decisiones, condiciones,…)

› Encontrar fragmentos del programa que no son ejecutados por los casos de prueba

› Crear casos de prueba adicionales que incrementen la cobertura

Diseño de casos de pruebaImplicaciones de los conceptos OO para el diseño de casos de prueba:

-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 pruebaEn el diseño de casos de prueba deberán usarse “valores interesantes”

Se considera un valor interesante aquel que permita recorrer la mayor cantidad mayor cantidad posible de código fuente posible de código fuente

◦ En función del criterio de cobertura elegido

Obtención de valores interesantes

Para un ejemplo real, el conjunto de valores a probar para conseguir cobertura total de sentencias puede ser muy grande

Para proponer valores podemos ayudarnos de técnicas como

Clases de equivalencia • Dividir el dominio de entrada en clases de equivalencia con valores que provocan un mismo comportamiento

Valores límite • Complementa a la anterior, seleccionando valores límite en vez de cualquier valor de la clase de equivalencia

Diseño de casos de pruebaDado el siguiente código como determinarcasos de pruebas INTERESANTE?

POR EJEMPLO

¿Qué conjuntos de tres valores recorren todas lassentencias del método getTipo()?

Estrategias de PruebasPrueba de integración en el contexto OO:

Debido a que el software orientado a objeto NO tiene una estructura de control jerárquica, lasestrategias convencionales de integración ascendente y descendente poseen un significadomuy pequeño.

Nuevos paradigmas en OO:

Pruebas basadas en hilos

Integra las clases requeridas para responder a una entrada o suceso del sistema (diagramas desecuencia de UML)

Cada hilo se integra y prueba individualmente

Estrategias de Pruebas

Puede haber varias secuencias diferentes dependiendo, del estado inicial del sistema y de laentrada del actor• En el ejemplo. Si no hubiera facturas muchos mensajes no serían enviados• El caso de pruebas caso de pruebas que se deriva de un diagrama de secuencia debería que sederiva de un diagrama de secuencia debería describir cómo probar una secuencia interesante enel diagrama, tomando elestado inicial del sistema

Estrategias de PruebasPrueba de integración en el contexto OO:

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

Estrategias de PruebasPrueba 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 sistemareconocidas por el.

Los casos de prueba casos de prueba se obtienen a partir de los casos de uso (son parte delmodelo de análisis)

Ya que tienen una gran similitud de errores con los revelados en los requisitos de interaccióndel usuario

¿Qué métodos de prueba se utilizan?

Caja negra

Estrategias de PruebasHay que tener en cuenta:

1. Identificar cada caso de prueba y asociarlo explícitamente con la clase a probar

2. Declarar el propósito de la prueba

3. Desarrollar una lista de pasos a seguir

◦ Una lista de estados del objeto a probar

◦ Una lista de mensajes y operaciones que se ejecutarán

◦ Una lista de excepciones que pueden ocurrir

◦ Una lista de condiciones externas necesarias para conducir las pruebas

◦ Información adicional para facilitar la comprensión e implementación

Métodos de diseño de casos de prueba

A nivel de clases

◦ Verificación al azar

◦ Pruebas de partición

◦ Partición basada en estados

◦ Partición basada en atributos

◦ Partición basada en categorías

A nivel de interclases

◦ Verificación al azar

◦ Pruebas de partición

◦ Basadas en el escenario

◦ Pruebas de comportamiento

Métodos de diseño a nivel de clasePruebas aleatorias para clases OO:

Estas pruebas deben atacar una clase especifica a la vez identificando todos los métodosasociados con el fin de realizar diferentes secuencias de casos de prueba para dichosmétodos. Consiste en probar en orden aleatorio diferentes secuencias válidas deoperaciones

Ejemplo: Para un sistema bancario un orden aleatorio de operaciones sería abrir-configurar-depositar-retirar-cerrar

Pruebas de partición a nivel clase:

Las pruebas de partición reducen el numero de casos de prueba necesarios para ejercitarla clase de la manera en la que lo hace la partición equivalente para el softwareconvencional.

Las particiones basadas en estados categorizan las operaciones de clases basándose ensu habilidad para cambiar de estados.

Métodos de diseño de casos de pruebaPruebas de partición:

◦ Partición basada en estados: Clasifica las operaciones de clase en base a su habilidadde cambiar el estado de la clase

◦ Ejemplo: Para la clase cuenta de un sistema bancario, las operaciones depositar oretirar cambian el estado, las de consulta de saldo no

◦ Partición basada en atributos: Clasifica las operaciones basada en los atributos queusa

◦ Ejemplo: Operaciones que hacen uso del atributo “LimiteCredito” y las que no

◦ Partición basada en categorías: Clasifica las operaciones de acuerdo a la funcióngenérica que llevan a cabo

◦ Ejemplo: Operaciones de inicialización (abrir, configurar), operaciones de consulta(saldo, resumen)…

Pruebas de clases múltiples:

- Para cada clase cliente, usar la lista de operadores de clase para generar unaserie de consecuencias de pruebas aleatorias, generando mensajes.

- Para cada mensaje que se genera, determina la clase colaboradora y eloperador correspondiente en el objeto servidor.

- Para cada operador en el objeto servidor, determina los mensajes que estetransmite.

- Para cada uno de los mensajes, determina el próximo nivel de operadoresque 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 derepresentar el comportamiento dinámico de una clase.

Métodos de diseño de casos de prueba