Verificación y Validación de Software -- UNS 2
• 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
Verificación y Validación de Software -- UNS 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 acoplamientopara 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 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 5
Desarrollo basado en Servicios (3)
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
Verificación y Validación de Software -- UNS 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 7
Desarrollo basado en Servicios (5)
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.
Verificación y Validación de Software -- UNS 8
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.
Desarrollo basado en Servicios (6)
Verificación y Validación de Software -- UNS 10
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
Desarrollo basado en Servicios (8)
• 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.
Desarrollo basado en Servicios (9)
Verificación y Validación de Software -- UNS 12
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.
Desarrollo basado en Servicios (10)
Verificación y Validación de Software -- UNS 13
Arquitectura de Servicios Web:
Desarrollo basado en Servicios (11)
Verificación y Validación de Software -- UNS 14
Desarrollo basado en Servicios (12)
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
Verificación y Validación de Software -- UNS 15
Desarrollo basado en Servicios (13)
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)
Verificación y Validación de Software -- UNS 16
Desarrollo basado en Servicios (14)
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
Verificación y Validación de Software -- UNS 17
Desarrollo basado en Servicios (14)
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
Verificación y Validación de Software -- UNS 18
Desarrollo basado en Servicios (15)
• Descubrimiento de Servicios
Verificación y Validación de Software -- UNS 19
””Plan small, dream big; test small, execute big!Plan small, dream big; test small, execute big!””
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.
• 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 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)
• 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
Desarrollo basado en Servicios (18)
Verificación y Validación de Software -- UNS 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 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.
Verificación y Validación de Software -- UNS 23
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]
Verificación y Validación de Software -- UNS 24
Pruebas para Servicios (2)
• 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.
Verificación y Validación de Software -- UNS 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ñ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.
Verificación y Validación de Software -- UNS 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á 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
Verificación y Validación de Software -- UNS 27
Pruebas para Servicios (5)
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)
Verificación y Validación de Software -- UNS 28
Pruebas para Servicios (6)
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
Verificación y Validación de Software -- UNS 29
Pruebas para Servicios (7)
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
Verificación y Validación de Software -- UNS 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 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 32
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
Verificación y Validación de Software -- UNS 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 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 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 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 37
• 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.
Generación de TS para Servicios (6)
Verificación y Validación de Software -- UNS 38
• 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
Prueba de Unidad para Servicios (2)
• 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
Prueba de Unidad para Servicios (3)
• 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
Prueba de Unidad para Servicios (4)
• 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
Prueba de Unidad para Servicios (5)
• 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
Prueba de Unidad para Servicios (6)
• 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
Prueba de Unidad para Servicios (7)
Verificación y Validación de Software -- UNS 45
• 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)
Verificación y Validación de Software -- UNS 46
• 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.
Prueba de Servicios basada en Modelos (2)
Verificación y Validación de Software -- UNS 47
• 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).
Prueba de Servicios basada en Modelos (3)
Verificación y Validación de Software -- UNS 48
• 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).
Prueba de Servicios basada en Modelos (4)
Verificación y Validación de Software -- UNS 49
• 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
Prueba de Servicios basada en Modelos (5)
Verificación y Validación de Software -- UNS 50
• 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
Prueba de Servicios basada en Modelos (6)
Verificación y Validación de Software -- UNS 51
• 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 Modelos (7)
Verificación y Validación de Software -- UNS 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 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 ProtocolMeta Language) con las colas o con comunicación síncronabasada en el resultado de analisis de sincronicidad.
Verificación y Validación de Software -- UNS 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 55
Prueba de Servicios basada en Modelo (11)
• 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
Verificación y Validación de Software -- UNS 56
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.
Verificación y Validación de Software -- UNS 57
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
Verificación y Validación de Software -- UNS 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 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 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
Verificación y Validación de Software -- UNS 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 BPEL2PNMLluego usa WofBPELpara chequear actividades BPEL inalcanzables y conflictos entre actividades que consumen mensajes.
Verificación y Validación de Software -- UNS 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 comportamientoLas redes de Petri se usan para verificar el comportamiento del proceso
Verificación y Validación de Software -- UNS 62
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
Verificación y Validación de Software -- UNS 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 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
Verificación y Validación de Software -- UNS 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 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í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
Verificación y Validación de Software -- UNS 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 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 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, 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
Verificación y Validación de Software -- UNS 69
Prueba de Servicios basada en Defectos (6)
• Perturbación XML/SOAP: • Offutt y Xu (cont)
Verificación y Validación de Software -- UNS 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 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 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
Verificación y Validación de Software -- UNS 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 73
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.
Verificación y Validación de Software -- UNS 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 75
Prueba de Servicios basada en Defectos (12)
• 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)
Verificación y Validación de Software -- UNS 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 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