CS-432: Ingeniería Moderna de Software Semana 7

Presentación del tema: "CS-432: Ingeniería Moderna de Software Semana 7"— Transcripción de la presentación:

1 CS-432: Ingeniería Moderna de Software Semana 7
Dr. Jesús Borrego Lead Faculty, COS Regis University

2 Agenda Modelos de implementación y despliegue Clases de diseño
Asociación de relación Listas e iteradores Diagramas de secuencia

3 Términos clave Assert - afirmar Black box – caja opaca o caja negra
Performance testing – pruebas de rendimiento Regression testing - pruebas de regresión Stress testing – pruebas de estrés Testing framework – marcos de pruebas Testing workflow – flujo de trabajo de pruebas User acceptance testing – pruebas de aceptación del usuario White box – caja clara o caja blanca

4 Revisando el proyecto En el desarrollo de software es importante revisar el diseño y la implementación para prevenir problemas futuros El objecto es encontrar errores en el software antes de entregar el proyecto Pruebas de software occurren en todas las fases del proyecto

5 Pruebas dirigidas por casos de uso
Los casos de uso dirigen el análisis, diseño y desarrollo de software; también dirigen las pruebas del software Verificación - ¿se desarrolla el producto bien? Validación - ¿se desarrolla el producto correcto? Pruebas del modelo de casos de uso es parte de validación Intenta determinar si los requerimientos del cliente son cubiertos por la aplicación

6 Verificación Las pruebas del modelo de implementación son parte de la verificación del producto El modelo de verificación consiste de un conjunto de casos de pruebas Los casos de prueba especifican como se deben verificar los casos de pruebas Los casos de pruebas se deben trazar a los requerimientos del cliente

7 Trazas de casos de uso

8 Flujo de trabajo de pruebas
El flujo de trabajo define las actividades requeridas para el desarrollo del modelo de pruebas Consiste de seis actividades: desarrollo del plan, pruebas del modelo de diseño, prueba de diseño, prueba de implementación, ejecución de pruebas y evaluación de las pruebas

9 Flujo de trabajo de pruebas
El flujo de trabajo define las actividades requeridas para el desarrollo del modelo de pruebas Consiste de seis actividades: desarrollo del plan, pruebas del modelo de diseño, prueba de diseño, prueba de implementación, ejecución de pruebas y evaluación de pruebas

10 Desarrollo del plan de pruebas
Definir las estrategias que se usarán, incluyendo las pruebas del modelo Ejemplos caja blanca y caja negra, o caja clara y caja opaca Estimar los recursos requeridos para ejecutar las actividades de prueba Programar las actividades de prueba

11 Pruebas del modelo de diseño
Determinar estrategias para verificar si el modelo es correcto ¿Tiene errores? Determinar estrategias para verificar si el modelo es completo ¿Faltan partes? Determinar estrategias para verificar si el modelo es consistente ¿Hay ambigüedades?

12 Pruebas de diseño Identificar y describir los casos de prueba por cada versión de la aplicación Identificar y estructurar procedimientos de pruebas que especifiquen como se desarrollaran las pruebas Para verificar los componentes de la aplicación que se ejecutan Para verificar la integración de los componentes dentro del sistema completo

13 Pruebas de implementación
Crear casos de prueba para automatizar procedimientos de ensayo Automatizar la ejecución de los casos de prueba Facilitan el comportamiento de las pruebas después de que se crea la versión de software nueva Ejecutar lo mas posible todas las partes de los casos de pruebas

14 Ejecución de pruebas Pruebas de unidad Pruebas de regresión
Pruebas de integración Pruebas de aceptación del usuario Pruebas de estrés Pruebas de rendimiento

15 Evaluación de las pruebas
Revisar los resultados para determinar si las pruebas fueron adecuadas Determinar si se necesitan mas pruebas para asegurar si el producto es correcto Planear las pruebas requeridas para obtener mejor cobertura de los módulos de la aplicación

16 Metodologías de pruebas
Caja opaca – se utiliza conocimientos de las funciones requeridas del objeto bajo prueba Se usan casos de uso para revisar el producto Probar que se satisfagan las funciones del caso de uso No han conocimiento de como se construye la unidad, ni la lógica implementada en su implementación También llamada caja negra

17 Metodologías de pruebas - II
Caja clara – se utiliza conocimientos de la implementación del módulo y la lógica empleada Se requiere acceso al código fuente Se utilizan los diagramas de clase para revisar la interfaz del módulo Se requiere acceso a los diagramas de secuencia y diagramas de estado También llamada caja blanca

18 ¿Cuál es mejor? - Ventajas
3 ventajas de caja opaca 1 2 3 3 ventajas de caja clara

19 ¿Cuál es mejor? - Desventajas
3 desventajas de caja opaca 1 2 3 3 desventajas de caja clara

20 Modelos de pruebas Estrategia general que puede adaptarse a modelos de orientación de objetos Examina el modelo para determinar si es correcto, completo y consistente UML no requiere que sea correcto, completo y consistente, así que es necesario ver a que grado debe de serlo para cada iteración Este método permite un enfoque ágil para modelos orientados a objetos

21 Incorporar el modelo en el desarrollo
Es importante documentar deficiencias encontradas para implementar correcciones antes del desarrollo final Para evitar errores futuros Se pueden documentar las fallas o deficiencias en herramientas usadas para este objeto Las fallas se asignan a ingenieros de software para implementar soluciones

22 Pruebas para tratar cuestiones
Exactitud – probar tanto la precisión sintáctica y semántica del modelo Sintáctica – los elementos del modelo UML son usados correctamente Semántica – los elementos empleados corresponden a la realidad modelada Integridad – probar si el modelo es completo verificando si faltan elementos requeridos; requiere examinar si el modelo cubre escenarios adecuadamente

23 Pruebas para tratar cuestiones - 2
Consistencia – probar si los elementos del modelo tienen conflictos con otros elementos; también verifica que los elementos del modelo no contradicen los elements de los que depende Lindland, Sindre y Solvberg (1994) y McGregor y Korson (1994)

24 Evaluar el modelo de casos de uso
Exactitud – cada caso de uso representa precisamente un requisito Integridad – cada caso de uso representa la funcionalidad total requerida para un modelo satisfactorio Consistencia – cada caso de uso es consistente con otros casos de uso y evitar contradicciones entre otros casos de uso

25 Planear las pruebas Se pueden clasificar los casos de uso para ilustrar la frecuencia y la criticidad con el fin de dar prioridad a las pruebas Ya que usualmente no es posible cubrir todos los casos Es importante identificar los casos de uso críticos y cubrirlos con suficientes casos de prueba Es útil crear una matriz de referencia de casos de uso contra casos de prueba

26 Ejemplo de matriz de pruebas
¿Que problemas notan?

27 Revisar el modelo de análisis
El objeto es determinar si la aplicación que se está modelando interpreta correctamente el dominio de la aplicación Exactitud – la descripción del dominio es correcta, los algoritmos producirán los resultados correctos. Los conceptos y algoritmos cubren los casos de uso Integridad – Los conceptos son suficientes para cubrir el alcance del contenido especificado

28 Revisar el modelo de análisis - 2
Integridad – Hay suficiente detalle para describir los conceptos a un nivel apropiado. Los expertos están de acuerdo con los atributos y comportamientos de cada clase Consistencia – Los elementos del modelo deben ser consistentes con las definiciones y significados del negocio. Si hay varias maneras de representar on concepto de acción, las maneras son modeladas apropiadamente

29 Revisar el modelo de diseño
El objeto es similar al del análisis, pero require nuevos elementos Exactitud – cada clase implementa correctamente la interfaz semántica. Las clases que corresponden an interfaces tienen que implementar la interfaz Integridad –Clases son definidas para cada interfaz en la arquitectura. Pre-condiciones del uso de los métodos son especificadas apropiadamente

30 Revisar el modelo del diseño - 2
Integridad – Post-condiciones son especificadas incluyendo condiciones que generan errores Consistencia – El comportamiento en la interfaz de cada clase provee una única manera de implementar una tarea, o, si hay varias maneras, ellas proporcionan el mismo comportamiento, pero con diferentes condiciones previas

31 Retos únicos del diseño
Otros retos adicionales que no son generalmente visibles en programación de procedimento: Interfaces – Las interfaces deben de implementarse correctamente para proporcionar la funcionalidad requerida. Dando que varias clases proporcionan la misma interfaz (ArrayList, LinkedList), cambios a una interfaz requieren cambios a varias clases

32 Retos únicos del diseño - 2
Herencia – El uso de herencia causa problemas de acoplamiento en los que un cambio en una clase resulta en cambios en todas las clases inferiores. Se requiere un cuidadose análisis para verificar que un cambio que se esta heredando es apropiado para todas las otras clases inferiores. Delegación a menudo puede aliviar muchos problemas asociados con la herencia

33 Retos únicos del diseño - 3
Delegación – Delegar tareas a otros objetos, aunque similar al uso de módulos en lenguajes de programación de procedimiento, también presenta un conjunto de problemas. En una clase, la delegación es encapsulada tras una intefaz pública, por lo tanto es necesario asegurarse que la implementación de la interfaz sigue siendo correcta cuando la clase que se delega la funcionalidad es cambiada

34 Revisar el modelo de implementación
Revisar el modelo de implementación se centra en verificar que el código implementado satisface el diseño documentado en el modelo de diseño Exactitud – Los componentes ejecutables del sistema crean una versión correcta y se adhieren al modelo de diseño (compilación y despliegue) Integridad – Los componentes ejecutables proporcionan toda la funcionalidad especificada en el modelo de diseño

35 Revisar el modelo de implementación - 2
Consistencia – Los componentes ejecutables del sistema son apropiadamente integrados en una manera que proporciona la funcionalidad indicada en los requerimientos de los casos de uso

36 Marcos de pruebas Usando los conceptos cubiertos en este curso, es posible desarrollar in marco de pruebas para cualquier aplicación que vayan a implementar Consideren el caso donde cambios a una reciente aplicación son actualizados en el repositorio del código En cuando se incorporan los cambios al repositorio, se debe construír la aplicación actualizada

37 Marcos de pruebas - 2 Se desea revisar la aplicación nueva con un número de casos de pruebas, como de integración y regresión Se puede automatizar la ejecución de dichos casos de prueba cada noche como parte del proceso de construcción de la aplicación

38 Ejemplo AccountCatalog es una clase responsable por actualizar cuentas de ahorros en la base de datos y obtener la información de la base de datos Se desea proveer un mecanismo conveniente y general para verificar el comportamiento correcto de los métodos públicos de la clase

39 Requerimientos del mecanismo
El mecanismo debe proveer pruebas de unidad, pruebas de integración y pruebas de regresión Un método simple es crear un método de pruebas en la clase [verifyTest() ] que regresa TRUE si el objeto pasa la prueba y ha sido verificado

40 Usando el mecanismo Podemos crear una clase TestDriver que sería responsable de mandar un mensaje verifyTest() al object AccountCatalog Tomamos en cuenta un patrón Singleton, verificando que es correctamente implementado Naturalmente, el diseño del método verifyTest() debe especificar como se debe conducir la prueba

41 Conduciendo la prueba Crear un objecto (new Account) con ciertos atributos Ejecutar el método saveAccount() Ejecutar método find ( int ) usando el ID del objeto creado y comparar y contrastar los atributos del objeto obtenido para revisar que los atributos sean los mismos Sin los attributos son iguales, regresa TRUE, o FALSE si no son iguales Hay otra opción

42 Director de Pruebas Se puede generalizar el proceso creando una clase que implementa los comportamientos comunes para revisar el comportamiento del objeto Por ejemplo AccountCatalog puede heredar comportamiento de la clase de pruebas o delegar el comportamiento a la clase de pruebas

43 Opciones Heredando o Delegando

44 Ventaja Este enfoque también permite la reutilización de las conductas de pruebas comunes, como el registro de pruebas que fallaron en un registro común En este caso, la interfaz TestHandler especifica lo que todos los conductores de pruebas deben implementar el método verifyTest() El archivo de registro proporciona el lugar donde se pueden captar los errores encontrados durante las pruebas

45 Diagrama

46 Método Afirmar Hay un comportamiento sofisticado que se puede implementar en varios lenguajes como Java, Lisp y C# El método Afirmar (Assert) en la clase previa permite que un programa especifique el resultado de un mensaje esperado cuando los parámetros apropriados se presentan Si el resultado es esperado, regresa TRUE, o FALSE si el resultado no es También se puede mostrar un mensaje

47 Ejemplo

48 Actividad 1 07 Unit Test Netbeans (11:16 min), por José Luis Daza Sandi: WQ

49 Exámen Final 10 preguntas como el primer exámen
Presentar casos donde deben preparar diagramas de UML, como las tareas Entregar antes del martes

50 ¿Preguntas? Correo electrónico a