VVS Tema5 A2 - cs.uns.edu.arprf/teaching/VVS11/downloads/Tema5/VVS_Tema… · yComputación Orientada a Servicios ... descripción e intercambio de mensajes independientes de la

Verificación y Validación de Software -- UNS 1

Testing para ServiciosTemario V


• Lectura• Sommerville I., 2000. Software Engineering, 7th Edition.

Addison-Wesley.• Ian Gorton, 2006. Essential Software Architecture. Springer-

Verlag.• Michael Bell, 2008. Service-Oriented Modeling: Service

Analysis, Design, and Architecture. Wiley.• Xinyu Z. 2008. Testing and Verifying Web Services: From the

Researcher’s Perspective. VDM Verlag.• Bozkurt M., Harman M., Hassoun Y., 2010. TestingWeb

Services: A Survey. Technical report TR-10-01. Centre for Research on Evolution, Search & Testing, King’s College London.

Testing para Servicios


Desarrollo basado en Servicios (1)

Computación Orientada a Servicios Service Oriented Computing (SOC)Paradigma de computación cuyo principal objetivo es el desarrollo de aplicaciones distribuidas en ambientes heterogéneos.Promueve la idea de ensamblar componentes de aplicaciones en una red de servicios con bajo acoplamientopara crear procesos de negocios flexibles y dinámicos y aplicaciones ágiles que extiendan organizaciones y plataformas de computación.



Arquitectura Orientada a Servicios Software Oriented Arquitecture (SOA)Permite la creación, publicación, búsqueda e integración de “servicios” o unidades lógicas de solución que se crean individualmente, para que puedan utilizarse colectivamente y repetidamente para la construcción de soluciones de mayor envergadura.Considera la reducción de costos posicionando a los servicios como la base para representar las soluciones lógicas.



ServicioElemento computacional

Autónomo: auto-control, auto-gobierno, auto-contenido y libre de limitaciones externasIndependiente de plataforma: alta reusabilidad → requiere descripción e intercambio de mensajes independientes de la plataforma

Puede ser descrito, publicado, descubierto, orquestado y programado usando protocolos estándares para construir redes de aplicaciones distribuidas colaborativas



Servicio Se implementa como un programa de software físicamente independiente con características de diseño específicas.Cada servicio tiene asignado su propio contexto funcional y comprende un conjunto de capacidades relacionadas a ese contexto.Un servicio es considerado un contenedor de capacidades asociadas con un propósito común (o contexto funcional).



Modelo de servicioes una clasificación que indica la naturaleza de un servicio, basado en el tipo de lógica que encapsula, el reusopotencial de la lógica, y cómo el servicio puede relacionarse a ciertos dominios de negocioTipos de servicio

De Tarea (task): también llamados servicios del negocio centrado en tareas o servicios de los procesos del negocio. De Entidad (entity): también llamados servicios del negocio centrado en la entidad o servicios de entidad del negocioUtilitario (utility): también llamados de aplicación, de infraestructura, o tecnológicos.


Servicios de Tarea (task)Centrados en tareas de negocio específicas. Generalmente controladores de composición. Poco reutilizables.Ej: Ejecutar Reporte de Facturación

Servicios de Entidad (entity)Servicios del negocio con un contexto funcional que se deriva de uno o más entidades del negocio relacionadas. Altamente reutilizables. Ej: Pedidos, Cliente, Factura

Servicios Utilitarios (utility): Encapsulan funcionalidad común, transversal, que es útil para muchas composiciones de servicios. Altamente reutilizables. Ej: notificaciones, bitácora de eventos, manejo de excepciones y conversión de monedas.





Proveedor del servicio (service provider)Dueño y responsable de resolver problemas y el mantenimiento del servicio El único que puede controlar la evolución del servicioTambién puede ser considerado “proveedor” aquel que lo hospeda (host)Publica el servicio, registrándolo en una “Entidad de Descubrimiento”

Entidad de descubrimiento (service broker)Mecanismo para búsqueda de servicios: registro donde los servicios son publicados Permite a los clientes buscar servicios que cumplen con sus requerimientos y provee información sobre cómo acceder a dichos servicios

Cliente del servicio (service user)Tiene las dos tareas principales: encontrar y realizar la interacción (binding)Usa la información que le provee el broker para conectarse al proveedor e invocar el servicio


• Características de SOC• Promueve la reusabilidad de software de manera

desacoplada• Reemplaza el desarrollo de componentes in-house por:

Descubrimiento, Selección e Integración de servicios• Se ha adoptado SOC en la industria con Servicios Web.



1API: Interfaz de Programación de Aplicación2SOAP: Simple Object Access Protocol

• Servicio Web• Cuerpo de solución lógica que provee un contrato físico y desacoplado

que se define mediante WSDL y uno o más esquemas XML y/o definiciones WS-Policy.

• Programa con interfaz bien definida que puede ser localizada, publicada y accedida por medio de protocolos Web como HTTP o SMTP.

• Contrato de Servicio Web• Expone las capacidades públicas como operaciones, estableciendo

interfaces técnicas comparables a las APIs1 tradicionales.

• Protocolo de Mensajes (SOAP2)• Define cómo dos objetos en diferentes procesos se comunican

intercambiando datos XML.



Arquitectura de Servicios Web:




Simple Object Access Protocol (SOAP)Protocolo basado en XML que permite intercambiar mensajes sobre HTTPDefinición W3C: “protocolo liviano para intercambiar información estructurada en un entorno distribuido, descentralizado”Combina XML y HTTP → los mensajes SOAP pueden intercambiarse entre aplicaciones sin importar su plataforma o lenguaje de programación



WSDL (Web Service Description Language)Formato XML para describir servicios webUna especificación WSDL es la interfaz de un servicio webque provee toda la información necesaria para interactuar con él (formato de mensajes, operaciones que provee, ubicación del servicio)



WSDL: ejemplo HelloService• Definition: HelloService• Message :

sayHelloRequest: parámetro firstNamesayHelloResponse saludo en respuesta

• Port Type: la operación sayHello consiste de un mensaje de solicitud y uno de respuesta.

• Binding: Dirección para usar el protocolo de transporte SOAP HTTP • Service: servicio disponible en http://www.examples.com/SayHello/.• Port: URI http://www.examples.com/SayHello/ donde el servicio

puede ser accedido



Descubrimiento de ServiciosBúsqueda en registros UDDI

Catálogos en los que se publica la especificación de los serviciosServicios Categorizados

Catálogos de servicios organizados en categorías de acuerdo a “actividades de negocio”

Proveedores de serviciospublican sus servicios en la categoría apropiada del registro UDDI



• Descubrimiento de Servicios


””Plan small, dream big; test small, execute big!Plan small, dream big; test small, execute big!””


• Modelado Orientado a Servicios (OS)• Promueve el reuso, y el diseño de soluciones en entornos

OS débilmente acoplados.• Apunta a crear primero una réplica de “lo grande” para

identificar sus características y comportamiento clave.

• Los desarrolladores deben identificar los servicios más adecuados para lograr sus soluciones de diseño.

• Es difícil confiar en los proveedores a menos que se establezcan acuerdos sobre calidad y seguridad.



• Composición de servicios• Agregación de servicios compuestos colectivamente para

automatizar una tarea particular o proceso de negocio. (Principio de Diseño “Composicionalidad de Servicio”).

• Por lo menos deben participar dos servicios y debe haber además un iniciador de la composición, sino se trata de un intercambio de punto-a-punto

• BPEL (lenguaje de orquestación)• Lenguaje basado en XML diseñado para el control

centralizado de la invocación de diferentes servicios • Contiene lógica de negocio que ayuda a la programación en

gran escala (programming in the large)

• Ejemplo BPEL: seleccionar la mejor oferta de dos aseguradoras• 1º sección: definir partner links (cliente y dos

aseguradoras A y B)• 2º sección: definir variables • 3º sección: pasos del proceso

Esperar la invocación del clienteSolicitar las dos ofertasElegir la menor




• Incertidumbre sobre confianza en SOA• Poca confianza, dada la infraestructura abierta de la Web.• Arquitectura desacoplada. Se espera interoperar y colaborar lo más

cercano y transparente posible con otro registros UDDI.• Involucra descubrimiento en ejecución, binding dinámico con multi-

partes incluyendo middleware y otros servicios, y composición en ejecución.

• Composición y re-composición dinámica ante cambios de entorno y requerimientos.

• Invocaciones por partes desconocidas con requerimientos inpredecibleso maliciosos

• Debe soportar configuración y re-configuración dinámica paraTolerancia a Fallos. Los servicios pueden caerse cada tanto.


Pruebas para Servicios (1)

Oportunidades y Desafíos en Testing SOALos servicios Web no son todavía ampliamente usados debido a los aspectos de seguridad, que se entiende mejor como Confianza. El aspecto más importante es: ‘los servicios trabajaran correctamente cada vez que se los necesita?’Todavia hay muy poco esfuerzo aplicado a Pruebas y CertificaciónSe necesitan nuevas soluciones que provean seguridad de que los servicios pueden ser realmente confiables.

[CBDI Forum, 2002]



• Perspectivas del testing• Desarrollador del Servicio

Prueba el servicio para detectar el máximo posible de fallasEs dueño de la implementación, por lo tanto puede hacer testing de caja blancaTrata de asegurar propiedades no funcionales y tiene la habilidad de manejar excepciones Los costos de testing son limitados (no tiene que pagar para probar su propio software), pero las pruebas no funcionales no pueden ser realistas (no puede anticipar la infraestructura de los clientes o del proveedor, ni la carga de la red). No reflejan escenarios reales.

• Proveedor del ServicioPrueba el servicio para asegurar que se garantizan los requerimientos estipulados por el consumidorNo puede hacer testing de caja blancaLos costos de testing son limitados: Las pruebas no funcionales no pueden ser realistas (no puede anticipar la infraestructura de los clientes, ni la carga o configuración de la red). No reflejan escenarios reales.



• Perspectivas del testing (2)• Integrador del Servicio

Realiza pruebas para confiar que en su composición, cada servicio cumple los supuestos hechos en tiempo de diseñoLa búsqueda de servicios en tiempo de ejecución y el binding tardío dificultan las tareas porque el servicio puede ser uno de varios posiblesEl integrador no tiene ningún control sobre el servicio en uso, que sufre cambios sobre su tiempo de vidaRealizar pruebas desde esta perspectiva resulta en costos para el integrador y gasto de recursos para el proveedor

• Certificador Third-partyEl integrador puede usar un certificador third-party para asegurar la propensión a erroresDesde el punto de vista del proveedor se reducen la cantidad de stakeholdersinvolucrados en las pruebasEl certificador prueba el servicio en nombre de alguien desde la perspectiva del integrador, pero no prueba el servicio en una composición específica.



• Perspectivas del testing (3)• Usuario final

Sólo le preocupa que la aplicación que está usando trabaje bien mientras la está usandoEl dinamismo de SOA representa una ventaja potencial (buena performance, costos reducidos) pero también una amenaza potencial.Incluir la capacidad de auto-retesting ayuda a reducir dicha amenazaHacer testing desde esta perspectiva tiene su costo y gasto de recursosEj: una aplicación centrada en servicios en un smartphone y conectada a la red inalámbrica, comienza a realizar pruebas (auto-testing) a símisma, invocando varios servicios, mientras el uso de la red crece



Limitaciones del testing para ServiciosLimitacions de observabilidad del código del servicio y de la estructura (el usuario sólo puede ver la interfaz)Falta de control, dada la independencia de la infraestructura sobre la que los servicios se ejecutan y que sólo el proveedor controla la evolución del servicioDinamismo y adaptabilidad, limita la capacidad del tester para determinar los servicios invocadosCosto del testing

Costo de usar el servicio (en caso de acceso a servicios pagos)Caída del servicio, por testing masivoEfecto del testing en sistemas donde cada uso significa una transacción de negocio (ej: sistemas de intercambio de stock)



Tipos de pruebasPrueba de protocolo SOA: funcionalidad y performance de protocolos SOA, e.g. prueba de SOAP, de publicación de servicios, de descubrimiento, de rendimiento de protocolos, naturaleza asíncrona de las operaciones SOA.Prueba y evaluación de Servicios: con disponibilidad de código (caja-blanca y negra) y sin acceso a código (caja-negra).Prueba de una aplicación integrada o composición de servicios: integración multi-nivel y evaluación con/sin código fuente.QoS (calidad de servicio): evaluación de performance.Prueba de Interoperabilidad: conformancia sobre los protocolos SOAPrueba de Regresión: conformancia ante modificaciones



Tipos de pruebasPrueba de Carga/Stress: examinar comportamiento de sistema con diferentes usos y volumen de datosMonitoreo: seguimiento y evaluación en ejecución de comportamientoPrueba de Seguridad: asegurar refuerzo de propiedades de seguridadPrueba de Brokers de Servicios: asegurar que los brokers como el de UDDI realicen registración/descubrimiento en forma apropiada, y quizá extender un broker para actuar como agente de verificación y rankeo de servicios publicados.Framework de prueba/evaluación para SOA: con procesos y herramientas para prueba/evaluación de servicios y aplicaciones



• Tipos de pruebas• Prueba basada en Modelos (Redes de Petri, UML, Máquina

de Estados, Grafos): modelos SOA son heterogéneos y no pueden describir comportamiento de servicios en forma comprensiva. Las pruebas son limitadas, sólo estádisponible las interfaces (e.g. WSDL), mientras que los modelos no (e.g. BPEL).

• Pruebas basadas en Agentes: cada servicio debe estar equipado con un stub agente que contenga comportamiento inteligente

• Políticas/Monitoreo: se necesitan refuerzos de políticas/monitoreo distribuidas, implica desafío entre eficiencia y fiabilidad.



• Tipos de pruebas• Inyección de Defectos: implementar inyección dinámica de

defectos en mensajes/sistema. Instrumentación de código puede ser imposible.

• Simulación: no puede cubrir todas las situaciones reales.• Perturbación: probar mensajes XML• Prueba de Mutación: probar WSDL• Prueba de Unidad: probar BPEL o servicio atómico• Prueba de Grupo: se necesita un grupo de servicios

similares. Cuando el volumen de servicios es más grande, esta prueba puede resulta más eficiente.


Generación de TS para Servicios (1)

modelosespecificaciones

• Generación de Datos de Prueba (Test Sets)• Según estándar IEEE, un caso de prueba es “un documento

especificando la entrada, resultados pronosticados y conjunto de condiciones de ejecución”

• Dato de prueba = Datos de Entrada � Caso de prueba• Para generar un caso de prueba, los datos de entrada deben

primero ser generados a partir de alguna fuente que describa:

El SUT (System Under Test)El comportamiento del SUTCómo debe ser utilizado el SUT



Generación de Datos de Prueba basado en Especificación:

Se debe disponer de un documento de referencia:descripción de interfaces de usuario, especificación de requerimientos/diseño, un modelo publicado, un manual de usuario.

En un entorno de servicios Web sólo se cuenta con las especificaciones WSDL de los servicios → la generación de datos de prueba basada en especificación es la elección natural



Generación de Datos de Prueba basado en Especificación:Se pueden generar casos de prueba, usando la información de tipos de datos del Schema XML, para

Análisis de Valores Límite, Clases de Equivalencia, Prueba Random.

Se pueden enfocar en operaciones únicas, o para ejecución de múltiples métodos, para lo cual se puede usar dependencia de datos entre las operaciones provistas.

El mapeo de dependencias se basa en los mensajes de entrada/salida de diferentes métodos (similar a criterios para componentes).



Generación de Datos de Prueba basado en Modelo:Se generan datos de prueba desde los requerimientos.Los modelos pueden ser Máquinas de Estado, particularmente considerando servicios con persistencia (estados abstractos). O extendiendo con restricciones de tiempo que se pueden verificar mediante modelos de BPEL.También extensiones de Redes de Petri, y en base a restricciones para aumentar el cubrimiento.



Generación de Datos de Prueba basado en Modelo:Uso de Diagrama de Actividad de UML para modelar procesos BPEL, desde los cuales se aplica un método que combina búsqueda depth-first con criterios de cubrimiento de pruebas.Usando BPEL las pruebas se realizan como de caja-blanca. Se tiene acceso a la lógica interna de todo el proceso, y se puede generar un TS con el cubrimiento deseado.


• Generación de Datos de Prueba basado Partición:• Aplicación de Partición por Categoría a los Schemas

XML.• Otra posibilidad es usando Ontologías

Servicios Semánticos definidos con OWL-S. El modelo basado en la ontología especifica los conceptos de prueba y sirve como un contrato de prueba. Las particiones de datos se crean usando la información de la ontología.



• Las operaciones que provee un servicio son las unidades elementales a ser probadas:• La prueba de unidad para servicios Web se realiza enviando/recibiendo

mensajes SOAP.• Se generan los mensajes SOAP usando la información de la

especificación WSDL.• Se verifica la correctitud del WSDL y del funcionamiento del servicio

Web.• Uno de los principales problemas de la Prueba Funcional de Servicios

Web es su alto costo. El uso de herramientas puede ayudar a reducir esfuerzo manual para generar casos de prueba y de reportes, pero la verificación de resultados en general se realiza manualmente. La escritura de Oráculos conlleva un esfuerzo a minimizar.

Prueba de Unidad para Servicios (1)

• Varias herramientas se han propuesto para automatizar generación de casos• WSDLTest (Sneed & Huang):

Genera peticiones aleatorias desde el esquema WSDLEs capaz de verificar el resultado de los casos de pruebaNecesita que el tester agregue, manualmente, pre y post condiciones en test scripts (requiere que el tester esté bien familiarizado con el SUT)

• (Lenz et al)Framework para prueba orientada a modelos, que puede utilizarse para prueba de unidadLas pruebas son generadas a partir de especificaciones UML 2 Testing Platform


• Creación de Oráculos• Mecanismos para determinar la salida esperada para cada

dato de entrada• Heckel & Lochmann

Genera oráculos basado en contratos pre-generados usando el enfoque DbC (Design by Contract): Formalización de obligaciones y beneficios. 3 preguntas:

* ¿Qué espera?* ¿Qué garantiza?* ¿Qué mantiene?

Los contratos son suministrados por el proveedor del servicio, que especifica pre y post-condiciones


• Creación de Oráculos (2)• Chan et Al

Framework para prueba basado en relaciones metamórficasRelación metamórfica: relación existente o esperada entre un conjunto de entradas distintivas y sus correspondientes salidas

Estas relaciones son especificadas por el tester para cada testsuitPositivo: Permite al cliente especificar los resultados esperadosNegativo: Requiere el uso de relaciones que pueden ser costosas de definir por el proveedor


• Creación de Oráculos (3)• Atkinson et al

Uso de planillas de prueba (test sheets)Se usan tablas para definir los casos de prueba

Planillas para datos de entradaPlanilla para resultados

También utiliza el enfoque de contrato


• Creación de Oráculos (4)• ASTRAR (Tsai et al)

Única solución automatizada al problema del oráculoAdapta testing de “grupo de sangre”Múltiples servicios web, que tienen la misma lógica de negocio, son probados a la vezSelección de un conjunto aleatorio de servicios web, ejecución de pruebas, votación para análisis estadístico de salidas y creación del oráculoEl mecanismo de votación se analiza la fiabilidad de los servicios y se presentan en un ranking de acuerdo a su capacidad de revelar fallas


• Creación de Oráculos (5)• Mayer & Lübke

Prueba de composición usando BPELDos modos: pruebas simuladas y pruebas de la vida realPruebas Simuladas: procesos BPEL son ejecutados en un motor y contactado a través de un API, en lugar de la invocación real

• Las pruebas de unidad son las más importantes a realizar en un sistema.• Mayoría de las propuestas incluyen generación automática

de datos de prueba y ejecución. • Sólo Tsai et al provee generación totalmente automática de

oráculo



• El uso de modelos formales y precisos permiten incrementar el nivel de confianza en el software, mediante pruebas formales

• La verificación formal de composiciones de servicios Web es popular por la capacidad de investigar propiedades de comportamiento.

• Estrategias:• Usando Ejecución Simbólica• Usando Model-Checking• Basado en Redes de Petri

Prueba de Servicios basada en Modelos (1)


• Usando Ejecución Simbólica• Técnica de verificación intermedia entre formal e informal• El SUT es ejecutado simbólicamente, usando un conjunto

de clases de entrada en lugar de valores de entrada• Una clase de entrada, representada por un símbolo,

representa un conjunto de valores• Sinha and Paradkar

Se basa en EFSM (Extended Finite State machine) para probar conformidad funcional de servicios que operan con datos persistentes. Se generan EFSMs desde una transformación de un modelo WSDL-S.



• Usando Ejecución Simbólica• Sinha and Paradkar (cont)

Usa cuatro técnicas de generación de datos de prueba:

Cubrimiento completo de Predicado: cada condición del EFSM se transforma a una Forma Normal Disyuntiva (DNF) y se generan secuencias de prueba que cubren las transiciones. Mutación: el operador relacional Boolean se aplica a las condiciones de guarda de cada operación. Cubrimiento de Proyección: el usuario especifica los objetivos de prueba incluyendo/excluyendo restricciones.Método BZ-TT (basado en especificación B, Z, y diagramas de estado).



• Uso de Ejecución Simbólica:• Bentakouk et al

Prueba de composiciones de servicios. Las composiciones se traducen a un Sistema de Transición Simbólico (STS), del cual luego se crea un Arbol de Ejecución Simbólico (SET).



• Uso de Ejecución Simbólica:• Bentakouk et al (cont)

Toma los criterios de cubrimiento especificados por el tester y genera el conjunto de caminos de ejecución sobre el SET. Esto caminos se ejecutan usando un Oráculo de prueba sobre la composición de servicios. Se pueden manejar tipos de datos enriquecidos basados en XML. El uso de Ejecución Simbólica evita casos de prueba no-implementables



• Usando Model-Checking• Model-checking es un método de verificación formal para

sistemas concurrentes de estado finito. • Se verifica si el modelo del sistema puede satisfacer las

propiedades dadas en la forma de lógica temporal. • El modelo suele estar

expresado como un sistema de transiciones, es decir, un grafo dirigido, que consta de un conjunto de vértices y arcos



• Usando Model-Checking• Durante el proceso de prueba, se detectan testigos y

contraejemplos• Testigos y contraejemplos son caminos (secuencia de

entradas) en la ejecución del modelo.• Un testigo es un camino donde la propiedad se satisface• Un contraejemplo es un camino que toma el sistema de

estados finito desde el estado inicial, hasta el estado donde la propiedad es violada.

• Los contraejemplos se usan para generar casos de prueba.• Se usa una herramienta llamada model checker (SPIN,

NuSMV, Blast).



Prueba de Servicios basada en Modelo (8)

• Usando Model-Checking:• Fu et al

Propone una herramienta (SPIN)Traduce BPEL a un modelo de automata con guardas basado en XPath mejorado con colas para recibir mensaje.




Luego el modelo se transforma a una especificación Promela(Process or ProtocolMeta Language) con las colas o con comunicación síncronabasada en el resultado de analisis de sincronicidad.




SPIN toma Promela como entrada y verifica las propiedades de su Lógica Temporal Lineal (LTL). Se modelan las interacciones de los servicios participantes de una composición como conversaciones y el LTL se usa para expresar las propiedades de estas conversaciones.



• Usando Model-Checking:• García-Fanjul

Similar al método de Fu et alTransforma BPEL directamente a Promela. Genera casos de prueba usando las especificaciones creadas porcontraejemplos obtenidos por model-checkingSe cubren las transiciones ejecutando repetidamente la herramienta SPIN con una fórmula LTL diferente


Prueba de Servicios basada en Modelo (12)• Usando Model-Checking:

• Zheng et alPropone usar la herramienta SPIN o NuSMVIncluye en la lógica temporal criterios de cubrimiento como cubrimiento de estados, de transiciones y de todos los caminos DU para prueba de flujo de control y de datos sobre BPELUsa un autómata denominado Web Service Automaton (WSA) que se usa para transformar BPEL a Promela para SPIN o SMV para NuSMV. WSA permite incluir dependencias de datos BPEL que no pueden representarse en otros autómatas. Se generan casos de prueba usando contraejemplos para realizar prueba de conformidad sobre BPEL y usar el WSDL para probar las operaciones del servicio Web.


Prueba de Servicios basada en Modelo (13)• Usando Model-Checking:

• Huang et alPropone la aplicación de model-checking a composiciones de servicios web semánticos usando OWL-S. El enfoque convierte especificaciones OWL-S en un lenguaje similar a C y el Planning Domain Definition Language (PDDL) para usarlo con el model checker BLAST. Usando BLAST Se pueden generar casos de prueba negativos y positivosProponen una extensión de especificaciones OWL-S y del lenguaje PDDL para soportar este enfoque y usan una versión modificada de la herramienta BLAST



• Usando Redes de Petri:• Es posible especificar y analizar sistemas concurrentes,

asíncronos, distribuidos, paralelos, no-determinísticos, y/o estocásticos (relativo al azar)

• Permiten diferentes tipos de análisis: alcanzabilidad, boundedness (calidad de no tener límite), deadlock(bloqueo mortal), liveness (mantenerse con vida), reversibilidad, fairness (justicia), y conservación.

• También para medir cubrimiento de casos de prueba.



• Usando Redes de Petri• Dong y Yu

Propone construir High level Petri-Net (HPN) [58], a partir del WSDL. Usa las redes HPNs generadas para generar los casos de prueba y también usa restricciones definidas por el usuario para los tipos de datos XML

• Wang et alPropone generar casos de prueba usando redes de Petri y razonamiento de ontologíasLas redes de Petri se usan para describir la semántica operacional del servicio. Son generadas a partir del modelo de proceso OWL-S



• Usando Redes de Petri:• Ouyang et al.

propone transformar procesos BPEL a Petri-Nets, en base a la herramienta BPEL2PNMLluego usa WofBPELpara chequear actividades BPEL inalcanzables y conflictos entre actividades que consumen mensajes.



• Usando Redes de Petri:• Lohmann et al

Analiza la interacción entre procesos BPEL usando una clase de redes de Petri llamada Open WorkFlow Net (oWFN)Usan dos herramientas:

BPEL2oWFN transforma BPEL a oWFN. El modelo oWFN es usado por otra herramienta llamada Fiona que analiza su comportamientoLas redes de Petri se usan para verificar el comportamiento del proceso


Prueba de Servicios basada en Modelo (18)• Usando Redes de Petri:

• Tarhini et al. Propone dos modelos para describir composición de servicios webEl SUT es representado con dos modelos abstractos: Task PrecedenceGraph (TPG) y Timed Labeled Transition System (TLTS). TPG modela la interacción entre servicios y TLTS modela el comportamiento interno de los servicios participantes

TPG de una agencia de viajes TLTS de la reserva de hotel



• Usando Redes de Petri• Tarhini et al. (cont)

Propone tres tipos diferentes de generación de casos de prueba, para chequear distintos niveles de composición de servicios1. pruebas de valores límites usando las especificaciones

derivadas del WSDL2. pruebas del comportamiento del servicio web seleccionado3. Interacción entre los servicios participantes


Prueba de Servicios basada en Defectos (1)

• Prueba basada en Defecto• Intenta probar que un SUT no contiene fallos prescritos• Se prueban los servicios respecto a defectos comunes que

pueden existir en un entorno SOA, para mejorar la fiabilidad de los servicios.

Fiabilidad (dependability) incorpora fiabilidad propiamente dicha (reliability), disponibilidad (avalilability), seguridad (safety) y mantenibilidad [Johansson, 2002]



• Clasificación de técnicas:• Análisis de propagación de Interfaces

Se realiza alterando de forma random la entrada de un componente.Las fallas se introducen en el sistema para estudiar su efecto

• Prueba de Robustez basada en Valores Límitelos datos de prueba se eligen de los límites de los parámetros de entrada.

• Prueba de SintaxisSe introducen entradas inválidas tal que las reglas de la especificación de los parámetros de entrada son violadas.

• Clases de Equivalencia



• Perturbación XML/SOAP: • Se realiza capturando mensajes SOAP entre los servicios y

sus usuarios.• Se generan mensajes defectuosos inyectando, defectos

antes de enviarlos o directamente enviando mensajes defectuoso a un servicio Web.

• Luego de las perturbaciones, se observa el comportamiento del servicios para verificación.



• Perturbación XML/SOAP: • Offutt y Xu

Proponen tres tipos de perturbaciones: Valores de Datos: modificando valores en un mensaje SOAP.RPC (Remote Procedure calls Communication Perturbation): se modifican los argumentos de procedimientos remotos. Aplicar mutación a los objetos sintácticos y perturbación al código SQL.Perturbación de los Datos de Comunicación: usado para mensajes de prueba que incluyen relaciones y restricciones de BD.



• Perturbación XML/SOAP: • Offutt y Xu (cont)

Incluye una serie de operadores de perturbación, por ej:insertN (e, ep , ec , n )agrega un nodo entre dos nodos conectados por el arco e deleteN (n)se elimina el nodo n y los arcos que llegan desde su padre y losarcos que dependen de él se pasan a su padredeleteND (n)borra un dato con su tipo de dato

Los operadores se usan para modificar los esquemas XML para definir criterios de coberturaLos casos de prueba se generan como mensajes XML para satisfacerlos esquemas alterados



• Perturbación XML/SOAP: • Offutt y Xu (cont)



• Inyección de Defectos sobre Redes• Se realiza corrompiendo, perdiendo (dropping) o

reordenando paquetes en las redes.• Looker et al.

Propone framework Web Service Fault Injection Tool (WS-FIT). Se realiza inyección a nivel de latencia de red junto con perturbación SOAP. Propone simular un servicio defectuoso, al reemplazar valores de mensajes SOAP con valores erróneos dentro de un rango especificado de los parámetros. También propone un modelo extendido de ontología usado para generar defectos y una ontología de modos de defectos que identifica los tipos de defectos (artificiales o naturales).


Prueba de Servicios basada en Defectos (8)• Inyección de Defectos

sobre Redes• Looker et al (cont)

La termocupla solicita la potencia actual del calentador y calcula la temperaturaEl código anzuelo (hook) captura mensajes que el fault injector modificaPermite simular fallos del tipo que puede producirse a nivel de una API si necesidad de modificar código



• Mutación de Especificaciones de Servicios• Se utilizan para medir la aptitud de la suite de prueba• Se inyectan fallas ya sea modificando el código o

cambiando el estado del SUT en tiempo de ejecución• Para hacer los cambios se aplica una serie de operadores de

mutación• En servicios web se realiza aplicando operadores de

mutación a las especificaciones WSDL


Prueba de Servicios basada en Defectos (10)• Mutación de Especificaciones de Servicios

• Siblini and MansourProponen 9 operadores de mutación para WSDL, clasificados en 3 tipos:

Elementos Tipos: (*) sobre datos de tipo complejo.(a) Intercambio de tipos*(b) Intercambio de atributos del mismo tipo*(c) Agregar/eliminar un elemento*(d) Agregar/eliminar un atributo opcional*(e) Setear el atributo nil a true*(f) Intercambio de elementos del mismo tipo(g) Intercambio de atributos del mismo tipo

Elementos Mensajes: intercambiar partes entre mensajes del mismotipo.Elemento PortType: intercambiar mensajes del mismo tipo en elementos operaciones.



• Mutación de Especificaciones de Servicios• Siblini and Mansour (cont)

Ejemplo (b) Intercambio de atributos del mismo tipo



• Mutación de Especificaciones de Servicios• Mei & Zhang

Definen operadores de mutación para contratosLos contratos son incluidos en especificaciones WSDL extendidasLos operadores definidos en el modelo

Negación del contratoIntercambio de pre y post condicionesOperador de debilitación de precondiciónOperador de fortaleza de postcondiciónOperador de contrato stuck-at (cuando están mal definidos los contratos, lo que equivale a precondición true o a postcondición false)



• Mutación de Especificaciones de Servicios• Mei & Zhang (cont)

Precondiciones de ValidatePin requieren que la longitud del ID y PIN del usuario sea 4Las precondiciones de la interfaz WithDrawrequieren que la cantidad de dinero de una operación estéentre 0 y 2000 y que sea múltiplo de 50



• Mutación de Especificaciones de Servicios• Mei & Zhang (cont)

Documents

VVS Tema5 A2 - cs.uns.edu.arprf/teaching/VVS11/downloads/Tema5/VVS_Tema… · yComputación Orientada a Servicios ... descripción e intercambio de mensajes independientes de la