Temario V Testing para Servicios. Verificación y Validación de Software -- UNS 1

Transcripción

1 Temario V Testing para Servicios Verificación y Validación de Software -- UNS 1

2 Testing para Servicios Lectura Sommerville I., Software Engineering, 7th Edition. Addison-Wesley. Ian Gorton, Essential Software Architecture. Springer- Verlag. Michael Bell, Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley. Xinyu Z Testing and Verifying Web Services: From the Researcher s Perspective. VDM Verlag. Bozkurt M., Harman M., Hassoun Y., TestingWeb Services: A Survey. Technical report TR Centre for Research on Evolution, Search & Testing, King s College London. Verificación y Validación de Software -- UNS 2

3 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 acoplamiento para crear procesos de negocios flexibles y dinámicos y aplicaciones ágiles que extiendan organizaciones y plataformas de computación. Verificación y Validación de Software -- UNS 3

4 Desarrollo basado en Servicios (2) 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. Verificación y Validación de Software -- UNS 4

5 Desarrollo basado en Servicios (3) Servicio Elemento computacional Autónomo: auto-control, auto-gobierno, auto-contenido y libre de limitaciones externas Independiente 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 Verificación y Validación de Software -- UNS 5

6 Desarrollo basado en Servicios (4) 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). Verificación y Validación de Software -- UNS 6

7 Desarrollo basado en Servicios (5) Modelo de servicio es una clasificación que indica la naturaleza de un servicio, basado en el tipo de lógica que encapsula, el reuso potencial de la lógica, y cómo el servicio puede relacionarse a ciertos dominios de negocio Tipos 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 negocio Utilitario (utility): también llamados de aplicación, de infraestructura, o tecnológicos. Verificación y Validación de Software -- UNS 7

8 Desarrollo basado en Servicios (6) 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. Verificación y Validación de Software -- UNS 8

9 Desarrollo basado en Servicios (7) Verificación y Validación de Software -- UNS 9

10 Desarrollo basado en Servicios (8) 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 servicio Tambié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 Verificación y Validación de Software -- UNS 10

11 Desarrollo basado en Servicios (9) 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.

12 Desarrollo basado en Servicios (10) 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 APIs 1 tradicionales. Protocolo de Mensajes (SOAP 2 ) Define cómo dos objetos en diferentes procesos se comunican intercambiando datos XML. 1 API: Interfaz de Programación de Aplicación 2 SOAP: Simple Object Access Protocol Verificación y Validación de Software -- UNS 12

13 Desarrollo basado en Servicios (11) Arquitectura de Servicios Web: Verificación y Validación de Software -- UNS 13

14 Desarrollo basado en Servicios (12) Simple Object Access Protocol (SOAP) Protocolo basado en XML que permite intercambiar mensajes sobre HTTP Definició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 Verificación y Validación de Software -- UNS 14

15 Desarrollo basado en Servicios (13) WSDL (Web Service Description Language) Formato XML para describir servicios web Una especificación WSDL es la interfaz de un servicio web que provee toda la información necesaria para interactuar con él (formato de mensajes, operaciones que provee, ubicación del servicio) Verificación y Validación de Software -- UNS 15

16 Desarrollo basado en Servicios (14) WSDL: ejemplo HelloService Definition: HelloService Message : sayhellorequest: parámetro firstname sayhelloresponse 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 Port: URI donde el servicio puede ser accedido Verificación y Validación de Software -- UNS 16

17 Desarrollo basado en Servicios (14) Descubrimiento de Servicios Búsqueda en registros UDDI Catálogos en los que se publica la especificación de los servicios Servicios Categorizados Catálogos de servicios organizados en categorías de acuerdo a actividades de negocio Proveedores de servicios publican sus servicios en la categoría apropiada del registro UDDI Verificación y Validación de Software -- UNS 17

18 Desarrollo basado en Servicios (15) Descubrimiento de Servicios Verificación y Validación de Software -- UNS 18

19 Desarrollo basado en Servicios (16) 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. Plan small, dream big; test small, execute big! 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. Verificación y Validación de Software -- UNS 19

20 Desarrollo basado en Servicios (17) 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) Verificación y Validación de Software -- UNS 20

21 Desarrollo basado en Servicios (18) 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 cliente Solicitar las dos ofertas Elegir la menor

22 Desarrollo basado en Servicios (19) 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 multipartes 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 inpredecibles o maliciosos Debe soportar configuración y re-configuración dinámica para Tolerancia a Fallos. Los servicios pueden caerse cada tanto. Verificación y Validación de Software -- UNS 22

23 Pruebas para Servicios (1) Oportunidades y Desafíos en Testing SOA Los 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ón Se necesitan nuevas soluciones que provean seguridad de que los servicios pueden ser realmente confiables. [CBDI Forum, 2002] Verificación y Validación de Software -- UNS 23

24 Pruebas para Servicios (2) Perspectivas del testing Desarrollador del Servicio Prueba el servicio para detectar el máximo posible de fallas Es dueño de la implementación, por lo tanto puede hacer testing de caja blanca Trata 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 Servicio Prueba el servicio para asegurar que se garantizan los requerimientos estipulados por el consumidor No puede hacer testing de caja blanca Los 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. Verificación y Validación de Software -- UNS 24

25 Pruebas para Servicios (3) 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ño La 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 posibles El integrador no tiene ningún control sobre el servicio en uso, que sufre cambios sobre su tiempo de vida Realizar pruebas desde esta perspectiva resulta en costos para el integrador y gasto de recursos para el proveedor Certificador Third-party El integrador puede usar un certificador third-party para asegurar la propensión a errores Desde el punto de vista del proveedor se reducen la cantidad de stakeholders involucrados en las pruebas El certificador prueba el servicio en nombre de alguien desde la perspectiva del integrador, pero no prueba el servicio en una composición específica. Verificación y Validación de Software -- UNS 25

26 Pruebas para Servicios (4) Perspectivas del testing (3) Usuario final Sólo le preocupa que la aplicación que está usando trabaje bien mientras la está usando El 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 amenaza Hacer testing desde esta perspectiva tiene su costo y gasto de recursos Ej: 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 Verificación y Validación de Software -- UNS 26

27 Pruebas para Servicios (5) Limitaciones del testing para Servicios Limitacions 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 servicio Dinamismo y adaptabilidad, limita la capacidad del tester para determinar los servicios invocados Costo del testing Costo de usar el servicio (en caso de acceso a servicios pagos) Caída del servicio, por testing masivo Efecto del testing en sistemas donde cada uso significa una transacción de negocio (ej: sistemas de intercambio de stock) Verificación y Validación de Software -- UNS 27

28 Pruebas para Servicios (6) Tipos de pruebas Prueba 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 SOA Prueba de Regresión: conformancia ante modificaciones Verificación y Validación de Software -- UNS 28

29 Pruebas para Servicios (7) Tipos de pruebas Prueba de Carga/Stress: examinar comportamiento de sistema con diferentes usos y volumen de datos Monitoreo: seguimiento y evaluación en ejecución de comportamiento Prueba de Seguridad: asegurar refuerzo de propiedades de seguridad Prueba 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 Verificación y Validación de Software -- UNS 29

30 Pruebas para Servicios (8) 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. Verificación y Validación de Software -- UNS 30

31 Pruebas para Servicios (9) 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. Verificación y Validación de Software -- UNS 31

32 Generación de TS para Servicios (1) 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 SUT Cómo debe ser utilizado el SUT modelos especificaciones Verificación y Validación de Software -- UNS 32

33 Generación de TS para Servicios (2) 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 Verificación y Validación de Software -- UNS 33

34 Generación de TS para Servicios (3) 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). Verificación y Validación de Software -- UNS 34

35 Generación de TS para Servicios (4) 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. Verificación y Validación de Software -- UNS 35

36 Generación de TS para Servicios (5) 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. Verificación y Validación de Software -- UNS 36

37 Generación de TS para Servicios (6) 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. Verificación y Validación de Software -- UNS 37

38 Prueba de Unidad para Servicios (1) 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. Verificación y Validación de Software -- UNS 38

39 Prueba de Unidad para Servicios (2) Varias herramientas se han propuesto para automatizar generación de casos WSDLTest (Sneed & Huang): Genera peticiones aleatorias desde el esquema WSDL Es capaz de verificar el resultado de los casos de prueba Necesita 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 unidad Las pruebas son generadas a partir de especificaciones UML 2 Testing Platform

40 Prueba de Unidad para Servicios (3) 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

41 Prueba de Unidad para Servicios (4) Creación de Oráculos (2) Chan et Al Framework para prueba basado en relaciones metamórficas Relació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 test suit Positivo: Permite al cliente especificar los resultados esperados Negativo: Requiere el uso de relaciones que pueden ser costosas de definir por el proveedor

42 Prueba de Unidad para Servicios (5) 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 entrada Planilla para resultados También utiliza el enfoque de contrato

43 Prueba de Unidad para Servicios (6) Creación de Oráculos (4) ASTRAR (Tsai et al) Única solución automatizada al problema del oráculo Adapta testing de grupo de sangre Múltiples servicios web, que tienen la misma lógica de negocio, son probados a la vez Selecció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áculo El 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

44 Prueba de Unidad para Servicios (7) Creación de Oráculos (5) Mayer & Lübke Prueba de composición usando BPEL Dos modos: pruebas simuladas y pruebas de la vida real Pruebas 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

45 Prueba de Servicios basada en Modelos (1) 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 Verificación y Validación de Software -- UNS 45

46 Prueba de Servicios basada en Modelos (2) 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. Verificación y Validación de Software -- UNS 46

47 Prueba de Servicios basada en Modelos (3) 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). Verificación y Validación de Software -- UNS 47

48 Prueba de Servicios basada en Modelos (4) 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). Verificación y Validación de Software -- UNS 48

49 Prueba de Servicios basada en Modelos (5) 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 noimplementables Verificación y Validación de Software -- UNS 49

50 Prueba de Servicios basada en Modelos (6) 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 Verificación y Validación de Software -- UNS 50

51 Prueba de Servicios basada en Modelos (7) 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). Verificación y Validación de Software -- UNS 51

52 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. Verificación y Validación de Software -- UNS 52

53 Prueba de Servicios basada en Modelo (9) Usando Model-Checking: Fu et al Luego el modelo se transforma a una especificación Promela (Process or Protocol Meta Language) con las colas o con comunicación síncrona basada en el resultado de analisis de sincronicidad. Verificación y Validación de Software -- UNS 53

54 Prueba de Servicios basada en Modelo (10) Usando Model-Checking: Fu et al 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. Verificación y Validación de Software -- UNS 54

55 Prueba de Servicios basada en Modelo (11) Usando Model-Checking: García-Fanjul Similar al método de Fu et al Transforma BPEL directamente a Promela. Genera casos de prueba usando las especificaciones creadas por contraejemplos obtenidos por model-checking Se cubren las transiciones ejecutando repetidamente la herramienta SPIN con una fórmula LTL diferente Verificación y Validación de Software -- UNS 55

56 Prueba de Servicios basada en Modelo (12) Usando Model-Checking: Zheng et al Propone usar la herramienta SPIN o NuSMV Incluye 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 BPEL Usa 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. Verificación y Validación de Software -- UNS 56

57 Prueba de Servicios basada en Modelo (13) Usando Model-Checking: Huang et al Propone 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 positivos Proponen 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 Verificación y Validación de Software -- UNS 57

58 Prueba de Servicios basada en Modelo (14) 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. Verificación y Validación de Software -- UNS 58

59 Prueba de Servicios basada en Modelo (15) 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 al Propone generar casos de prueba usando redes de Petri y razonamiento de ontologías Las redes de Petri se usan para describir la semántica operacional del servicio. Son generadas a partir del modelo de proceso OWL-S Verificación y Validación de Software -- UNS 59

60 Prueba de Servicios basada en Modelo (16) Usando Redes de Petri: Ouyang et al. propone transformar procesos BPEL a Petri- Nets, en base a la herramienta BPEL2PNML luego usa WofBPEL para chequear actividades BPEL inalcanzables y conflictos entre actividades que consumen mensajes. Verificación y Validación de Software -- UNS 60

61 Prueba de Servicios basada en Modelo (17) 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 comportamiento Las redes de Petri se usan para verificar el comportamiento del proceso Verificación y Validación de Software -- UNS 61

62 Prueba de Servicios basada en Modelo (18) Usando Redes de Petri: Tarhini et al. Propone dos modelos para describir composición de servicios web El SUT es representado con dos modelos abstractos: Task Precedence Graph (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 Verificación y Validación de Software -- UNS 62

63 Prueba de Servicios basada en Modelo (19) 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 servicios 1. pruebas de valores límites usando las especificaciones derivadas del WSDL 2. pruebas del comportamiento del servicio web seleccionado 3. Interacción entre los servicios participantes Verificación y Validación de Software -- UNS 63

64 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] Verificación y Validación de Software -- UNS 64

65 Prueba de Servicios basada en Defectos (2) 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ímite los datos de prueba se eligen de los límites de los parámetros de entrada. Prueba de Sintaxis Se introducen entradas inválidas tal que las reglas de la especificación de los parámetros de entrada son violadas. Clases de Equivalencia Verificación y Validación de Software -- UNS 65

66 Prueba de Servicios basada en Defectos (3) 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. Verificación y Validación de Software -- UNS 66

67 Prueba de Servicios basada en Defectos (4) 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. Verificación y Validación de Software -- UNS 67

68 Prueba de Servicios basada en Defectos (5) Perturbación XML/SOAP: Offutt y Xu (cont) Incluye una serie de operadores de perturbación, por ej: insertn (e, e p, e c, 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 los arcos que dependen de él se pasan a su padre deletend (n) borra un dato con su tipo de dato Los operadores se usan para modificar los esquemas XML para definir criterios de cobertura Los casos de prueba se generan como mensajes XML para satisfacer los esquemas alterados Verificación y Validación de Software -- UNS 68

69 Prueba de Servicios basada en Defectos (6) Perturbación XML/SOAP: Offutt y Xu (cont) Verificación y Validación de Software -- UNS 69

70 Prueba de Servicios basada en Defectos (7) 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). Verificación y Validación de Software -- UNS 70

71 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 temperatura El código anzuelo (hook) captura mensajes que el fault injector modifica Permite simular fallos del tipo que puede producirse a nivel de una API si necesidad de modificar código Verificación y Validación de Software -- UNS 71

72 Prueba de Servicios basada en Defectos (9) 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 Verificación y Validación de Software -- UNS 72

73 Prueba de Servicios basada en Defectos (10) Mutación de Especificaciones de Servicios Siblini and Mansour Proponen 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 mismo tipo. Elemento PortType: intercambiar mensajes del mismo tipo en elementos operaciones. Verificación y Validación de Software -- UNS 73

74 Prueba de Servicios basada en Defectos (11) Mutación de Especificaciones de Servicios Siblini and Mansour (cont) Ejemplo (b) Intercambio de atributos del mismo tipo Verificación y Validación de Software -- UNS 74

75 Prueba de Servicios basada en Defectos (12) Mutación de Especificaciones de Servicios Mei & Zhang Definen operadores de mutación para contratos Los contratos son incluidos en especificaciones WSDL extendidas Los operadores definidos en el modelo Negación del contrato Intercambio de pre y post condiciones Operador de debilitación de precondición Operador de fortaleza de postcondición Operador de contrato stuck-at (cuando están mal definidos los contratos, lo que equivale a precondición true o a postcondición false) Verificación y Validación de Software -- UNS 75

76 Prueba de Servicios basada en Defectos (13) Mutación de Especificaciones de Servicios Mei & Zhang (cont) Precondiciones de ValidatePin requieren que la longitud del ID y PIN del usuario sea 4 Las precondiciones de la interfaz WithDraw requieren que la cantidad de dinero de una operación esté entre 0 y 2000 y que sea múltiplo de 50 Verificación y Validación de Software -- UNS 76

77 Prueba de Servicios basada en Defectos (14) Mutación de Especificaciones de Servicios Mei & Zhang (cont) Verificación y Validación de Software -- UNS 77