CS-432: Ingenier

1
CS-432 Ingeniería Moderna de SoftwareSemana 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
• 1
• 2
• 3

19
Cuál es mejor? - Desventajas

• 3 desventajas de caja opaca
• 1
• 2
• 3
• 3 desventajas de caja clara
• 1
• 2
• 3

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 (1116 min), por José Luis
  Daza Sandi http//www.youtube.com/watch?vKOeFrxo
  a0WQ

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 jborrego_at_regis.edu