Post on 08-Jul-2018
8/19/2019 UML Proceso de Pruebas
1/10
DOCENTE
MARIA DEL ROSARIO MORENO
FERNANDEZ TRABAJO
UML Y EL PROCESO DE PRUEBAS
ESTUDIANTE
JESUS VIDAL RODRIGUEZ
CARRERA
INGENIERÍA EN SISTEMASCOMPUTACIONALES
MATERIA
VERIFICACIÓN Y VALIDACION DESOFTWARE
UNIDAD 1
INSTITUTO TECNOLÓGICOSUPERIOR DE TIERRA
8/19/2019 UML Proceso de Pruebas
2/10
TIERRA BLANCA, VER. 03 DE MARZO DE201
INTRODUCCIÓN
En general, la implementación de modelo de pruebas puede satisfacer un modelo
y no otro: por ejemplo puede satisfacer el Modelo de Clases y no el de Uso (o vice
versa); incluso puede satisfacer varios modelos sin satisfacer los reuerimientos!
"os modelos son, por definición, complementarios! #e presentan varios modelos
porue, en general, cumplir uno sólo de ellos no es suficiente! $s% se previenen
problemas ue pueden surgir a largo pla&o y se obtiene un beneficio ue afecta
directamente al producto!
8/19/2019 UML Proceso de Pruebas
3/10
REQUERIMIENTOS COMO FUENTE DE PRUEBAS
'a emos visto cómo podemos, y debemos, utili&ar los reuerimientos como
fuente de casos de prueba! "a obligación surge de la necesidad de verificar ue la
implementación satisface los reuerimientos!
UM" sólo eige ue los reuerimientos est*n descritos en lenguaje informal y ya
en el curso emos visto los problemas asociados a especificaciones en lenguaje
informal: necesidad de reagrupamiento de reuerimientos, incompletitud,
ambig+edad e inconsistencia! ambi*n emos visto como podemos anali&ar y
mejorar las especificaciones de los reuerimientos aciendo uso de mecanismos
como las tablas de decisión y cuidado en la eplicitación de un criterio de
verificabilidad!
MODELO DE USO COMO FUENTE DE PRUEBAS
El Modelo de Uso le describe al usuario cómo utili&ar el sistema, poor lo ue
mucas veces constituye el n-cleo del manual del usuario! En principio tanto el
modelo de uso como el manual del usuario pueden servir de base para acer
pruebas de ue la implementación se usa de acuerdo con ellos!
Cada caso de uso describe una tarea ue debe llevar a cabo un actor; por lo ue
pueden generarse casos de prueba para validar ue las tareas se llevan a cabo
seg-n lo indica el caso de uso! El caso de uso es una narrativa en lenguaje
informal, con los consabidos inconvenientes ue esto trae! $dicionalmente el caso
de uso describe un flujo de control ue describe u* pasos pueden repetirse,
cu.les son opcionales, u* cursos alternos ay: flujos ue deben probarse! /!
0acobson fue el primero en proponer ue se generen los siguientes casos de
prueba:
1! Casos correspondientes al curso normal del caso;2! Casos correspondientes a cursos ecepcionales;3! Casos ue surgen de reuerimientos espec%ficos a un item del caso de uso;4! Casos asociados a la prueba de caracter%sticas descritas en documentos
asociados al caso de uso!
Esta propuesta no constituye una estrategia, sino a lo sumo una descripción de
ciertos principios generales ue debe cumplir una clase de estrategias ra&onables!
$dicionalmente, considero ue es preferible generar los casos tipo 3, a partir de
otros artefactos, como por ejemplo los contratos, si estos se utili&an!
http://ldc.usb.ve/~teruel/ci4713/clases2001/testReqs.htmlhttp://ldc.usb.ve/~teruel/ci4713/clases2001/testReqs.htmlhttp://ldc.usb.ve/~teruel/ci4713/clases2001/testReqs.htmlhttp://ldc.usb.ve/~teruel/ci4713/clases2001/testReqs.html
8/19/2019 UML Proceso de Pruebas
4/10
5inder propone construir tablas de decisión para cada caso de uso, usando
variables operacionales como variables de decisión y generar los casos de
pruebas seg-n las estrategias o modelos de defectos asociados a tablas de
decisión! Una variable operacional es visible en la frontera del sistema, y
t%picamente es una entrada o salida del sistema o abstrae parte del estado del
sistema!
En la pr.ctica las narrativas de los casos de uso describen inteligiblemente flujos
sencillos de control; las tablas de decisión permiten manejar inteligiblemente un
alto n-mero de opciones con poca dependencia sobre el estado del sistema! #in
embargo, para flujos de cierta complejidad es conveniente recurrir a un autómata
de interacción! Este autómata puede tener un componente informal (t%picamente a
este nivel, las acciones se describen informalmente a bastante alto nivel), pero el
eco de precisar el flujo, permite aplicar las estrategias de generación de casos
de prueba a partir de autómatas, probablemente con ciertas dificultades para
precisar el estado en ue se encuentra o ueda el sistema, as% como ue se
llevaron a cabo las acciones asociadas a las transiciones correctamente!
MODELO CONCEPTUAL COMO FUENTE DE PRUEBAS
6o es conveniente usar el modelo conceptual como fuente de pruebas! "a
implementación eventualmente cumple es con el Modelo de Clases, por lo ue es
conveniente ue se utilice el Modelo de Clases como fuente de pruebas!
/dealmente debe eistir una correspondencia epl%cita y verificable entre elModelo Conceptual y el Modelo de Clases; en la pr.ctica esta correspondencia
suele estar documentada parcialmente y su verificabilidad es reali&able sólo
mediante inspecciones informales!
MODELO DE CLASES COMO FUENTE DE PRUEBAS
"os defectos a los ue est. propensa la implementación de un modelo de clases
incluyen:
• Errores en la multiplicidad de la asociación;
• 7alta o sobra una asociación;
• $ctuali&ación anómala, t%picamente en la actuali&ación de información
replicada;
• Eliminación anómala, como por ejemplo:
http://ldc.usb.ve/~teruel/ci4713/clases2001/testAutomata.htmlhttp://ldc.usb.ve/~teruel/ci4713/clases2001/testAutomata.htmlhttp://ldc.usb.ve/~teruel/ci4713/clases2001/testAutomata.htmlhttp://ldc.usb.ve/~teruel/ci4713/clases2001/testAutomata.html
8/19/2019 UML Proceso de Pruebas
5/10
• En la eliminación de un objeto ue ayuda a definir una entidad d*bil;
• En la eliminación de un objeto ue pertenece a una asociación 1 a 6 (por el
lado del 1);
• En el manejo de nulificaciones (nullifies), cascadas y restricciones;
• $sociaciones incorrectas entre objetos;
• /nserciones incorrectas;
• En general, no se satisfacen las restricciones de integridad!
5inder proporciona un ejemplo interesante! #upongamos ue eisten dos
clases 8ersona y 8erro, cuya asociación es due9o ue permite ue cada perro
tenga a lo sumo un due9o y ue cada persona pueda tener cero o m.s perros!
Esta asociación puede implementarse de las siguientes formas:
"imit.ndose a dos clases (8ersona, 8erro), 6ote ue esta implementación es poco
elegante en su manejo de apuntadores a otras clases (sobre todo en la
clase 8erro, ue reuiere referenciar una persona y al próimo perro ue comparteel mismo due9o)!
Usando tres clases (8ersona, 8erro, Es ue9o e)!
Usando tres clases (8ersona, 8erro, ue9o)! En este caso la clase ue9o puede
contener un atributo 8ersona y un atributo tipo vector o colección de 8erro! Cuatro
clases: 8ersona, 8erro, ue9o (una interfa&),
eamos cómo lucir%an, en este ejemplo, algunos de los defectos mencionados
previamente:
• Errores en la multiplicidad de la asociación!
• Erróneamente se permite ue dos personas sean due9as del mismo perro!
•
7alta una asociación!
• ado un due9o podemos obtener sus perros, pero por error en la
implementación no ay forma (eficiente) de encontrar el due9o de un perro!
8/19/2019 UML Proceso de Pruebas
6/10
• $ctuali&ación anómala!
#i cada objeto 8erro incluye su propio objeto 8ersona ue es su due9o, el
due9o de cinco perros aparece replicado cinco veces!
• Eliminación anómala!
#i eliminamos el due9o, u* pasa con sus perros:o #i la eliminación es con nulificación, los perros dejan de tener due9o;
o #i la eliminación fuer&a una cascada, los perros se eliminan (irreal);
• $sociaciones incorrectas entre objetos;
El sistema incorrectamente registra a como el due9o del perro y, en ve& del
perro &!
5inder propone la siguiente estrategia de generación de casos de pruebas:
• Considere la multiplicidad como una condición! $pl%uele el modelo de
defectos de fronteras de un rango, recordando ue en la pr.ctica una
multiplicidad 1!!?, tiene un m.imo implementado!
• 8ara detectar problemas de consistencia en la actuali&ación de objetos
replicados en asociaciones i!!?, cree una instancia de la asociación asoc demultiplicidad i!!n (con n@2)! $ctualice los i objetos de las asociación y liste la
información asociada a todos los elementos del conjunto obji!asoc!asocA
1 para revisar ue fueron actuali&ados consistentemente! $s% en el ejemplo
mencionado se debe generar un due9o de, digamos cinco perros, actuali&ar
la información del due9o y revisar si la información asociada al due9o de
cada uno de esos cinco perros es igual!
• 8ara detectar problemas con la eliminación del objeto fuente de una
asociación 1!!?:1! Cree una asociación 1!!n(con n@2),
2! Elimine el objeto fuente y revise ue pasó con los objetos destinos!3! uelva a crear la asociación y borre los n objetos destino y revise u* pasó
con el objeto fuente!4! Elimine el objeto fuente y revise a ver si todos los objetos y la asociación
fueron eliminados!
8/19/2019 UML Proceso de Pruebas
7/10
En general propongo ue todas las restricciones de integridad deben considerarse
como predicados y deben generarse los casos de prueba sugeridos por los
modelos de defectos ue se escojan para esos predicados!
CONTRATOS COMO FUENTE DE PRUEBAS
8ueden aplicarse los modelos de defectos pertinentes sobre las precondiciones y
pos condiciones de los contratos! "a visibilidad de las salidas (recuerde ue las
salidas de un contrato especifican u* objetos y asociaciones se crean, modifican
o eliminan) puede reuerir escribir código especial para las pruebas!
En principio luce atractivo desarrollar una erramienta de apoyo a este tipo de
pruebas ue valide la ejecución de una implementación de un evento de sistema
contra el contrato!
DIAGRAMAS DE COLABORACIÓN COMO FUENTE DE PRUEBAS
"a implementación de un evento de sistema debe cumplir con su diagrama de
colaboración! 8ara revisar si efectivamente cumple, deber%a ejecutarse la
implementación, revisando ue los mensajes enviados corresponden a lo indicado
por el diagrama de colaboración! /dealmente se deber%a determinar las secuencias
de mensajes esperados y luego comparar estas secuencias contra las tra&as o
secuencias generadas por la implementación! 6ótese ue ay erramientas ue
generan estas tra&as, indicando no sólo el mensaje sino el objeto ue env%a y el
objeto ue recibe!
Benerar manualmente las tra&as esperadas a partir de los diagramas de
colaboración, no necesariamente es factible! El problema radica en ue los
diagramas de colaboración no especifican cómo cambia el estado de un objeto al
recibir un mensaje m! 8or ende si ese objeto env%a mensajes m1, m2 como parte
de la reacción a m, pero sólo si se satisface una guarnición ue depende del
estado del objeto, es muy probable ue sea imposible determinar el estado: en
consecuencia no es posible determinar si m1, m2 deben agregarse a la tra&a
esperada! Este problema sólo se resuelve si se reali&a alguna de las siguientes
acciones:
#e especifican los cambios al estado ocurrido como reacción a la recepción de un
mensaje y previo a cada env%o de un mensaje de reacción! $dicionalmente ace
falta especificar los par.metros y respuestas asociadas a los mensajes, ya ue las
guarniciones pueden depender de sus valores!
8/19/2019 UML Proceso de Pruebas
8/10
#e puedan ejecutar los diagramas de colaboración a la par ue la implementación,
tomando valores de la implementación cuando sean necesarios! 6o tengo
información ue tal erramienta eista!
Esto sugiere la posibilidad de invertir el orden de determinación de las tra&as! Es
decir, primero generar las tra&as de la implementación, junto con los valores de
las guarniciones asociadas a cada elemento de la tra&a! Esto permitir%a verificar
ue la tra&a esperada o anticipada por el diagrama de colaboración es el mismo
ue la tra&a generada por la implementación! =esultado de las guarniciones! Una
erramienta de apoyo a esta actividad deber%a instrumentar el código de la
implementación apropiadamente: nuevamente no cono&co erramienta ue apoye
esta tarea!
asta aora se a sugerido generar casos de prueba a partir de la estructura de
los par.metros del evento del sistema, es decir la generación de los casos utili&an
una estrategia caja negra respecto al diagrama de colaboración! #in embargo, el
diagrama de colaboración puede verse como un diagrama de flujo de alto nivel,
donde las guarniciones corresponden a puntos de decisión! 8or ende podemos
generar casos de prueba caja blanca para lograr una cierta cobertura del grafo
asociado al diagrama de colaboración! Es conveniente acer notar ue sospeco
ue controlar las entradas de estos casos de prueba puede ser sumamente dif%cil!
5inder es muy pesimista respecto a la utilidad de los diagramas de colaboración
en el proceso de prueba AADy el proceso de dise9o Mucas de sus cr%ticas son
igualmente v.lidas para cualuier otro artefacto de dise9o, como veremos!
8/19/2019 UML Proceso de Pruebas
9/10
CONCLUSIÓN
En general, los -nicos roles ue se usan en un iagrama de Colaboración son
cuando se omite el nombre de un objeto! Esto ocurre cuando ay un sólo objeto
de esa clase, o cuando se trata de un objeto tipo Cat.logo ue fue introducido
para apoyar la implementación eficiente de una asociación conceptual! Consideroue estos roles constituyen abreviaciones en contetos bien delimitados ue no
representan dificultades significativas!
odo artefacto de dise9o representa una abstracción ue puede llevar a confusión
entre abstracción e implementación; no veo ue el diagrama de colaboración sea
m.s o menos propenso a conducir a esta confusión ue otros artefactos! El
diagrama de colaboración representa un punto intermedio entre un contrato y la
implementación, punto -til para reducir el tama9o del paso entre los otros dos
artefactos! En mi eperiencia, el diagrama de colaboración es muy -til para
identificar donde introducir patrones de dise9o; algunos de mis compa9eros anencontrado ue es un artefacto -til en las discusiones entre programadores! 8or
supuesto ue cualuier artefacto de dise9o puede usarse para acer dise9os
deficientes y dise9os etraordinarios, pues estos artefactos son erramientas cuyo
buen o mal manejo depende tambi*n de cómo y ui*n las maneja!
8/19/2019 UML Proceso de Pruebas
10/10
BIBLIOGRAFÍA
B!"#!$%&'()'Binder, R. (2000). Sistemas orientados a objetos, modelos y herramientas
software. España Addis!n"#es$e%.