Tema 10: Implementación y Pruebas...de la prueba de sistema 3. Implementación y Pruebas Implementación Visión general Requisitos Diseño Implementación Prueba Análisis Inicio

Tema 10: Implementación y Pruebas

Departamento de Lenguajes y Sistemas Informáticos II

www.kybele.urjc.es

Implementación y Pruebas www.kybele.urjc.es

Índice

Implementación

Visión general

Artefactos de Implementación

Actividades de Implementación

Pruebas

Introducción

Visión general

Artefactos de Pruebas

Actividades de Pruebas

2


ImplementaciónVisión general

El modelo de implementación describe cómo los elementos de diseño se implementan en componentes (ficheros de código fuente, de código binario, ejecutable, scripts)

Objetivo: Desarrollar la arquitectura y el sistema como un todo

Para ello:Planificar integraciones del sistema (enfoque incremental)Distribuir el sistema asignando componentes a nodos (despliegue) Se basa en las clases activas encontradas en diseño

Implementar clases y subsistemas (diseño) En particular las clases se implementan como componentes de fichero que

contienen código fuente

Probar componentes individualmente Integrarlos compilándolos y enlazándolos en uno o más ejecutables antes

de la prueba de sistema

3



Requisitos

Diseño

Implementación

Prueba

Análisis

Inicio Elaboración Construcción Transición

FasesFlujos de trabajo

Iteración(es)Inicial(es)

Iter. #1

Iter. #2

Iter. #3

Iter. #4

Iter. #5

Iter. #6

Iter. #7

(Adaptado de Jacobson, 1999)

4


Modelo de análisis

Modelo de diseño

Modelo de despliegue

Modelo de implementación

Modelo de pruebas

Modelo de casos de uso


5


Índice

ImplementaciónVisión generalArtefactos Componentes Subsistemas de implementación Interfaces Descripción de la arquitectura (vista del modelo de implementación) Plan de integración de construcciones

Actividades

PruebasIntroducciónVisión generalArtefactos de PruebasActividades de Pruebas

8


ImplementaciónArtefactos

Modelo de implementación:

*

Modelo de

implementación

*1

Sistema de implementación Subsistema de implementación

Componente Interfaz

* **

*

9



ComponentesEs el empaquetamiento físico de los elementos del modelo de diseño

Estereotipos estándar:

<<executable>>, <<file>>, <<library>>, <<table>>, <<document>>

Relación de traza con las clases de diseño

Un componente puede implementar varios elementos (ej., varias clases)

Proporcionan las mismas interfaces que los elementos que implementan

Puede haber dependencias de compilación entre componentes

TransferenciaTransferencia

<<file>>

TransferenciaEntreCuentas.java

Tranferencia

entre cuentas

Modelo de diseño Modelo de implementación

<<trace>>

<<executable>>

TransferenciaEntreCuentas.class

<<compilation>>

10



Subsistemas de implementación

Organizan los elementos del modelo de implementación

11

*

Subsistema de implementación

Componente Interfaz

**

*

►realizar



Subsistemas de implementaciónSe entienden como “mecanismos de empaquetamiento” concreto del lenguaje de implementación paquete en Java, proyecto en VisualBasic, directorio de ficheros

en C++, paquete en Rational Rose,...

Los subsistemas de implementación tienen una relación de traza 1 a 1 con los subsistemas de diseñoEl subsistema de implementación debe: Definir dependencias sobre otros subsistemas o interfaces de

otros subsistemas Proporcionar las interfaces que han de ser proporcionadas por el

sistema Definir qué componentes, u otros subsistemas de

implementación, deben proporcionar las interfaces proporcionadas por el subsistema.

12



Subsistemas de implementación

<<desing subsystem>> <<implementation subsystem>>

<<file>>

<<file>>

<<trace>> (1:1)

<<trace>>

α αβ β

13



InterfacesOperaciones implementadas por componentes y subsistemas de implementación

Dependencias de uso

Subsistema de implementación

Componente

Interfaz *

*realiza

realiza

14

package GestionDeCuentas;

// interfaces proporcionados:

public interface Transferencias{

public Cuenta Crear (Cliente propietario, Dinero saldo,

NumeroCuenta id_cuenta);

public void Depositar (Dinero cantidad, Cadena razon);

}



Descripción de la arquitectura

Descomposición del modelo en subsistemas, sus interfaces y dependencias entre ellos

Componentes clave:

Traza de las clases de diseño significativas para la arquitectura

Componentes ejecutables

Componentes generales y centrales de los que dependen muchos otros

15



Diagramas de componentes

Se utilizan para modelar la vista de implementación estática de un sistema

Contienen:

Componentes

Interfaces

Relaciones de dependencia, generalización, asociación y realización

Notas y restricciones

Paquetes o subsistemas

Diagrama de componentes que muestra la

versión ejecutable de un robot autónomo

Detalles del interfaz

exportado omitidos

16


Diagramas de despliegue (diseño):

Se utilizan para modelar los aspectos físicos de los sistemas orientados a objetos

Muestra la configuración de nodos que participan en la ejecución y de los componentes que residen en ellos

Contienen:

Nodos

Relaciones de dependencia y asociación

Notas y restricciones

Componentes que residen en algún nodo


Diagrama de despliegue de un sistema cliente/servidor

Multiplicidades explícitas

Nodos

estereotipados

servidoresclientes

17



Plan de integración de construccionesEl software se construye en pequeños incrementos o pasos para tener pequeños problemas de integración y pruebas. Concepto de “Construcción”: versión ejecutable del sistema Varias construcciones en una iteración Cada construcción se somete a pruebas de integración Control de versiones por si la construcción falla, volver a la anterior

Beneficios del enfoque incremental: Versión ejecutable muy pronto para enseñar y discutir Más fácil localizar defectos Pruebas de integración tienden a ser más minuciosas

Plan de integración describe construcciones necesarias en una iteración: Funcionalidad esperada: lista de casos de uso, escenarios o parte de ellos Requisitos adicionales Subsistemas y componentes necesarios para implementar la funcionalidad

18


Índice

ImplementaciónVisión generalArtefactosActividades Implementación de la arquitectura Integrar el sistema Implementar un subsistema Implementar una clase Realizar pruebas de unidad

PruebasIntroducciónVisión generalArtefactos de PruebasActividades de Pruebas

19


ImplementaciónActividades

Implementación de la arquitectura

Identificar componentes significativos arquitectónicamente

Asignar componentes ejecutables a nodos: clases activas

Modelo de diseño:nodo y sus objetos activos

Modelo de implementación: nodo y sus instancias de componentes

:Tranferencia

:Nombre del nodo

<<executable>>

:Transferencia

:Nombre del nodo

implica

20



Integrar el sistema

Objetivos:

Crear plan de integración de construcciones

Integrar cada construcción antes de pruebas de integración

Pasos:

Planificación de una construcción

Integración de una construcción

21



Integrar el sistemaPlanificación de una construcción

Criterios de creación de una construcción:• Debe añadir funcionalidad implementando casos de uso o escenarios.

• No debe incluir demasiados componentes nuevos o refinados

• Las construcciones deben expandirse hacia arriba y hacia los lados en la jerarquía de subsistemas La 1ª construcción debe empezar en las capas inferiores (intermedia y de software del sistema), después hacia las capas general de aplicación y específica de aplicación.

Para cada caso de uso:1. Considerar el diseño del caso de uso (traza)

2. Identificar subsistemas y clases de diseño que participan en la realización del caso de uso-diseño

3. Identificar subsistemas y componentes de implementación que siguen la traza de los de diseño.

4. Considerar el impacto de implementar estos subsistemas y componentes

22



Integrar el sistema

Integración de una construcción

Recopilar versiones correctas de subsistemas de implementación y componentes

Compilarlos y enlazarlos

La construcción pasa después a las pruebas de integración

23



Implementar un subsistema

Objetivos:

Asegurar que los requisitos (escenarios o casos de uso) implementados en la construcción se implementan correctamente por componentes u otros subsistemas

Pasos:

Cada clase implementada por un componente

Cada interfaz del subsistema de diseño debe ser proporcionada por el subsistema de implementación

Debe existir un componente que proporcione la interfaz

24



Implementar una claseObjetivos: Implementar una clase de diseño en un componente fichero/físico

Pasos: Esbozo de componente fichero <<file>> que contendrá el código fuente Generar código fuente a partir de la clase de diseño y de las relaciones en

que participa Implementar operaciones de la clase de diseño como métodos Asociaciones como referencias/atributos cuyo nombre es el nombre del rol

del extremo opuesto de la asociación La multiplicidad del extremo opuesto indica si es un puntero simple o una

colección de punteros Comprobar que el componente proporciona las mismas interfaces que la

clase de diseño Reparación de defectos

Importante Cuidar que el código de la clase cumple con el diagrama de estados

asociado (si existe)

25



Realizar prueba de unidadObjetivo: Probar los componentes implementados como unidades

individuales:

Tipos de pruebas Pruebas de especificación o caja negra: verifican el

comportamiento de la unidad observable externamente sin tener en cuenta como se implementa ese comportamiento Pruebas de estructura o caja blanca: verifican la implementación

interna de la unidad Otras pruebas: de rendimiento, utilización de memoria, carga y

capacidad

Pruebas posteriores De integración De sistema

26


Índice

ImplementaciónVisión generalArtefactos de ImplementaciónActividades de Implementación

PruebasIntroducción Conceptos previos. Prueba del software.

• Enfoque caja blanca.• Enfoque caja negra.• Conjetura de errores.• Enfoque aleatorio.

Visión generalArtefactos de PruebasActividades de Pruebas

27


Conceptos previos Verificación y Validación

Verificación del softwareDeterminar si los productos de una fase dada satisfacen las condiciones impuestas al inicio de la fase

¿Estamos construyendo correctamente el producto?

Validación del softwareEvaluar un sistema o uno de sus componentes, durante o al final de su desarrollo, para determinar si satisface los requisitos

¿Estamos construyendo el producto correcto?

Las pruebas permiter V & V el software

28


Conceptos previosDefecto/fallo/error

DefectoDefecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa

FalloEs la incapacidad de un sistema para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.

ErrorAcción humana que lleva a un resultado incorrecto

Un error del programador introduce un defecto y este defecto produce un fallo

29


Prueba del Software

¿Qué es la prueba del software?

Una actividad en la que un sistema, o uno de sus componentes, se ejecuta en circunstancias previamente planificadas. Los resultados se observan, se registran y se realiza una evaluación.

Es un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación.

30


Prueba del Software

PrincipiosPlanificación anterior a la realización (Plan de prueba).Imposibilidad de hacer unas pruebas exhaustivas.Empezar por lo pequeño y progresar a lo grande.Gran efectividad >> Realización de pruebas por equipos independientes.Se deben incluir tanto entradas correctas como incorrectas.Las pruebas se deben documentar detalladamente.

La mejor técnica es aquella que con menos casos de prueba me lo certifique

Caso de pruebaUn conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular como, por ejemplo, ejercitar un camino concreto de un programa o verificar el cumplimiento de un determinado requisito

Las pruebas no garantizan la ausencia de defectosProbar exhaustivamente un software es imposibleTécnicas para confeccionar casos de prueba eficientes

31


Diseño de pruebas

Enfoques para la construcción de casos de prueba:

Enfoque de caja blanca (Estructural)

Enfoque de caja negra (Funcional)

Enfoque aleatorio

32


Enfoque de caja blanca

Enfoque de caja blanca

Centrados en la estructura interna del programa

Probar caminos de ejecución

Criterios de cobertura lógica

Cobertura de sentencias

Cobertura de decisiones

Cobertura de condiciones

Criterio de decisión/condición

Criterio de condición múltiple

33


Enfoque de caja negra

Enfoque de caja negraConsiste en estudiar la especificación del software, del análisis de las funciones, la entrada y la salida para derivar los casos

Se utilizan particiones/clases de equivalencia. Ignora la estructura de control.

Se divide el dominio de los valores de entrada en diferentes clases/particiones.

Cada clase de equivalencia posee unos ciertos valores ->Estos valores dan resultados iguales ->Para realizar la prueba cogemos un único valor representante de cada clase. Análisis de valores límite (AVL).

34


Enfoque aleatorio

Enfoque aleatorio

Se crean datos que sigan las frecuencia y la secuencia que tendrían en la práctica.

Se simula la entrada de datos

Se usan generadores de prueba.

35


Índice

Implementación

Visión general

Artefactos de Implementación

Actividades de Implementación

Pruebas

Introducción

Visión general

Artefactos de Pruebas


36


PruebaVisión general

37

Requisitos

Diseño

Implementación

Prueba

Análisis

FasesFlujos de trabajo

Iteración(es)Inicial(es)

Iter. #1

Iter. #2

Iter. #3

Iter. #4

Iter. #5

Iter. #6

Iter. #7

(Adaptado de Jacobson, 1999)

Inicio Elaboración Construcción Transición


Visión general

Verificar el resultado de la implementación probando cada construcción, incluyendo

Construcciones internas Construcciones intermediasVersiones finales del sistema a entregar

Objetivos:Planificar las pruebas necesarias en cada iteración: De integración, en cada construcción dentro de la iteración De sistema, al final de la iteración

Diseñar e implementar las pruebas: Crear casos de prueba, procedimientos y componentes

Realizar las pruebas y manejar sus resultados Las construcciones en las que se detectan defectos, se prueban y

devuelven al flujo de trabajo para ser arreglado

38


Modelo de análisis

Modelo de diseño

Modelo de despliegue

Modelo de implementación

Modelo de pruebas

Modelo de casos de uso

PruebaVisión general

39


Requisitos

Pruebas

Implementación

Diseño

Análisis

Modelo de

Despliegue

Modelo de

Análisis

Modelo de

Diseño

Modelo deImplementación

Modelo dePruebas

Modelo deCasos de Uso

Dependencia de traza


40


Índice


PruebasIntroducciónVisión generalArtefactos de Pruebas Modelo de pruebas Caso de prueba Procedimiento de prueba Componente de prueba Plan de prueba Defecto Evaluación de prueba


42


PruebaArtefactos

Modelo de pruebas:

Modelo de

pruebas

1

Sistema de prueba

Procedimiento

de prueba

Caso de prueba

XX

Componente

de prueba

* **

43


PruebaArtefactos

Caso de prueba

Especifica una forma de probar el sistema, incluyendo la entrada o resultado con la que se ha de probar y las condiciones bajo las que ha de probarse.

Lo que se prueba puede venir dado por un requisito o colección de requisitos del sistema cuya implementación justifica una prueba que es posible y no demasiado cara de realizar

44


PruebaArtefactos

Casos de prueba comunes

Un caso de prueba que especifica cómo probar un caso de uso o un escenario específico de un caso de uso

Un caso de prueba que especifica cómo probar una realización de caso de uso diseño o un escenario específico de la realización.

45

Modelo de pruebas

Caso de uso

(del modelo de casos de uso)

<<trace>>X

Realización de caso de uso

-diseño

(del modelo de diseño)

Caso de prueba

(prueba de caja blanca)

Caso de prueba

(prueba de caja negra)

X<<trace>>


PruebaArtefactos

Ejemplo

Casos de prueba para probar el caso de uso “Transferencia”

Cada caso verifica un escenario, por ejemplo, en forma de tabla con:

Entrada

Resultado

Condiciones

46


PruebaArtefactos

Casos de prueba

Algunos pueden diferenciarse en valores de entrada o resultados, para verificar escenarios del mismo caso

Se puede reflejar en una tabla, un caso de uso por fila

Otros casos de prueba

Pruebas de instalación

Pruebas de configuración

Pruebas negativas

Pruebas de tensión o estrés

47


PruebaArtefactos

Procedimiento de prueba

Especifica cómo realizar uno o varios casos de prueba o partes de éstos

Manual o automatizado

48

Procedimiento

de prueba

Caso de prueba

XX

1..*1..* ► especifica cómo llevar a cabo


PruebaArtefactos

Componente de prueba

Automatiza uno o varios procedimientos de prueba o partes de ellos

Puede desarrollarse en un lenguaje de script, de programación o alguna herramienta de automatización de pruebas

49

Componente

de prueba

Procedimiento

de prueba

1..*1..* ► automatiza

X


PruebaArtefactos

Plan de pruebaDescribe las estrategias, recursos y planificación de la prueba Definición del tipo de pruebas a realizar para cada iteración, porcentaje

de pruebas que deberían ejecutarse con un resultado…

DefectoAnomalía del sistema (síntoma de un fallo software o un problema descubierto en una revisión) Puede utilizarse para localizar cualquier cosa que los desarrolladores

necesiten registrar como síntoma de un problema

Evaluación de pruebaEvaluación de los resultados de los esfuerzos de prueba, tales como la cobertura del caso de prueba, la cobertura de código y el estado de los defectos

50


Índice


PruebasIntroducciónVisión generalArtefactos de PruebasActividades de Pruebas Planificar prueba Diseñar prueba Implementar prueba Realizar prueba de integración Realizar prueba de sistema Evaluar prueba

51


PruebaActividades

Planificar pruebaPlanificar los esfuerzos de prueba en una iteración Describiendo una estrategia de prueba

Estimando requisitos para el esfuerzo de la prueba

Planificando el esfuerzo de la prueba

Los diseñadores desarrollan una estrategia de prueba para la iteración: qué tipo de pruebas ejecutar, cómo ejecutarlas, cuándo y

cómo determinar si el esfuerzo tiene éxito

Desarollar casos y procedimientos de prueba con solapamiento mínimo para probar casos de uso importantes y probar requisitos con riesgo alto

52


PruebaActividades

Diseñar pruebaLos objetivos son: Identificar y describir los casos de prueba para cada

construcción

Identificar y estructurar los procedimientos de prueba especificando cómo realizar los casos de prueba

Pasos Diseñar casos de prueba de integración

Diseño de casos de prueba de sistema

Diseño de casos de prueba de regresión

Identificación y estructuración de los procedimientos de prueba

53


PruebaActividades

Diseñar pruebaPasos Diseñar casos de prueba de integración

• Verificar que los componentes interaccionan entre sí apropiadamente después de haber sido integrados en una construcción

• Normalmente derivados de realizaciones de CU-diseño

• Se busca un conjunto mínimo de casos de prueba cada uno un camino o escenario

• Se establecen combinaciones de estado inicial, entradas, etc…




54


PruebaActividades

Diseñar prueba

Pasos

Diseñar casos de prueba de integración

Diseño de casos de prueba de sistema• Para probar que el sistema funciona correctamente como un todo

• Combinaciones de CU instanciados bajo condiciones diferentes



55


PruebaActividades

Diseñar prueba

Pasos



Diseño de casos de prueba de regresión• Pueden usarse algunos de pruebas anteriores

• Flexibles y resistentes a cambios en el software


56


PruebaActividades

Diseñar prueba

Pasos




Identificación y estructuración de los procedimientos de prueba• Caso a caso, se especifican sus procedimientos

• Pueden reutilizarse

57


PruebaActividades

Implementar prueba

Automatizar, si es posible, los procedimientos de prueba, creando componentes de prueba:

Usando herramientas de automatización de prueba

Programándolos usando como especificaciones iniciales los procedimientos de prueba

Grandes cantidades de datos de entrada y salida

58


PruebaActividades

Realizar pruebas de integraciónRealizar las pruebas de integración necesarias para las construcciones creadas en una iteración, recopilando los resultados Realizar pruebas de integración relevantes a la construcción

manualmente o ejecutando los componente que lo automatizan

Comparar los resultados de las pruebas con los resultados esperados

Informar de los defectos a los ingenieros de los componentes que fallan

Informar de los defectos a los diseñadores de pruebas, para la evaluación

59


PruebaActividades

Realizar prueba de sistema

Pruebas de sistema necesarias en cada iteración y recopilar los resultados

Empiezan cuando las pruebas de integración indican que el sistema satisface los objetivos de calidad de integración fijados en el plan de prueba de la integración actual

Análogo a las pruebas de integración

60


PruebaActividades

Evaluar pruebaEvaluar esfuerzos de prueba en una iteración

Se comparan los resultados con el plan. Métricas: Compleción de la prueba: porcentaje de casos de prueba

que han sido ejecutados y el porcentaje de código que ha sido probado

Fiabilidad: tendencias en los defectos detectados y en las pruebas que se ejecutan con el resultado esperado. Estudiar tendencias y patrones esperados y, en función de ellos:• Realizar pruebas adicionales

• Relajar el criterio para las pruebas

• Separar partes del sistema

Documentar la evaluación de la prueba

61


Bibliografía

El Proceso Unificado de Desarrollo de Software. I. Jacobson, G. Booch y J. Rumbaugh. PearsonPrentice-Hall 2007

M. Piattini et al. Análisis y Diseño detallado de Aplicaciones Informáticas de Gestión. Ed. Ra-Ma. 1996

62

Documents

Tema 10: Implementación y Pruebas...de la prueba de sistema 3. Implementación y Pruebas Implementación Visión general Requisitos Diseño Implementación Prueba Análisis Inicio