CS-432: Ingeniería Moderna de
Software
Semana 7
Dr. Jesús Borrego
Lead Faculty, COS
Regis University
1
scis.regis.edu ● [email protected]
Agenda
Modelos de implementación y despliegue
• Clases de diseño
• Asociación de relación
• Listas e iteradores
• Diagramas de secuencia
2
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
3
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
4
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
5
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
6
Trazas de casos de uso
7
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
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 pruebas
9
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
10
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?
11
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
12
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
13
Ejecución de pruebas
•
•
•
•
•
•
14
Pruebas de unidad
Pruebas de regresión
Pruebas de integración
Pruebas de aceptación del usuario
Pruebas de estrés
Pruebas de rendimiento
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
15
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
16
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
17
¿Cuál es mejor? - Ventajas
• 3 ventajas de caja opaca
▫1
▫2
▫3
• 3 ventajas de caja clara
▫1
▫2
▫3
18
¿Cuál es mejor? - Desventajas
• 3 desventajas de caja opaca
▫1
▫2
▫3
• 3 desventajas de caja clara
▫1
▫2
▫3
19
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
20
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
21
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
22
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)
23
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
24
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
25
Ejemplo de matriz de pruebas
• ¿Que problemas notan?
26
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
27
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
28
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
29
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
30
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
31
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
32
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
33
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
34
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
35
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
36
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
37
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
38
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
39
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
40
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
41
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
42
Opciones
Heredando
43
o
Delegando
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
44
Diagrama
45
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
46
Ejemplo
47
Actividad 1
• 07 Unit Test Netbeans (11:16 min), por José Luis
Daza Sandi:
http://www.youtube.com/watch?v=KOeFrxoa0
WQ
48
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
49
¿Preguntas?
• Correo electrónico a [email protected]
50
Descargar

ABET - Regis University: Academic Web Server for Faculty