Automatización de Pruebas para Servicios Web: Generación de Propiedades y Modelos *

Automatización de Pruebas para Servicios Web: Generación de Propiedades y Modelos * Macías López 1, Henrique Ferreiro 1, Miguel A. Francisco 2, Laura M. Castro 1 MADS Group, University of A Coruña (Spain) 1, Interoud Innovation S.L. (Spain) 2 Abstract: Los servicios web son una solución muy extendida a la hora de integrar componentes durante la construcción de una aplicación o sistema software, así como para facilitar la comunicación entre diferentes sistemas, ya que proporcionan un mecanismo para acceder a sus funcionalidades suficientemente flexible como para favorecer la máxima reutilización. Para que dicha integración tenga éxito, son esenciales las tareas de prueba, algo a lo que los servicios web no son ajenos: al igual que en cualquier otro desarrollo de software, es imperativo validar su comportamiento y garantizar su calidad tanto como sea posible, de la manera más eficiente posible. En la práctica, el compromiso entre el esfuerzo y el costo conduce con demasiada frecuencia al desarrollo de suites de prueba de menor tamaño y menor alcance de lo que sería deseable. En este trabajo presentamos un framework para la realización de pruebas a servicios web a partir de su especificación escrita en WSDL y sus restricciones de negocio escritas en OCL, que sigue un enfoque de caja negra y utiliza pruebas basadas en propiedades. Esta combinación de estrategias nos permite afrontar el problema de la generación de suites de prueba y casos de prueba de mejor calidad mediante su derivación automática a partir de la descripción formal de los servicios web. Para ilustrar las ventajas de nuestro framework, presentamos un caso de estudio real: un servidor de contenidos multimedia distribuido. Keywords: pruebas basadas en propiedades, servicios web, WSDL, OCL 1. Introducción A medida que Internet crece en importancia en nuestra sociedad, la necesidad de facilitar el acceso a diferentes tipos de sistemas a través de la web se ha vuelto más importante que nunca. La forma habitual de hacerlo es a través de servicios web, cuyo objetivo es proporcionar un medio para interacción entre componenes software o sistemas, o entre sistemas y usuarios finales. Hay múltiples maneras de describir estas interacciones, siendo una de las más comúnmente utilizadas WSDL (Web Services Description Language) [W3C01], un lenguaje basado en XML para especificar las operaciones que ofrece un servicio web. El estándar WSDL opera a nivel sintáctico y no hay una manera de representar los requisitos o condiciones de funcionamiento del servicio web simplemente utilizando la información en WSDL. Por lo tanto, con el fin de añadir información semántica a la descripción del servicio web, la descripción WSDL debe completarse con Trabajo parcialmente financiado gracias a FP7-ICT-2011-8 Ref. 317820. Automatización de Pruebas para Servicios Web 1 / 15

anotaciones semánticas que expresan condiciones previas, postcondiciones y los efectos de cada invocación de servicio. Se han propuesto una serie de opciones para hacer esto, tales como WSDL-S (Web Services Semantics) [W3C05], SWRL (Semantic Web Rule Language) [W3Cb], u OCL (Object Constraint Language) [OMG12]. Para garantizar la calidad de un servicio web [Emm06], es necesario garantizar que las operaciones funcionan tal y como indica su especificación, esto es, que la información semántica no se viola. Basándonos en trabajos previos [FC12], que utilizan descripciones UML junto con restricciones OCL para realizar pruebas automáticas de componentes de software, proponemos aplicar pruebas basadas en propiedades (PBT) [DWA + 10] para pruebas automáticas de servicios web. PBT se basa en la utilización de propiedades que el sistema a probar (SUT) necesita satisfacer, en lugar de casos de prueba individuales. A partir de propiedades, diferentes herramientas pueden generar esos casos de prueba específicos automáticamente. Usando la técnica que proponemos, es posible utilizar una aproximación de caja negra para describir el comportamiento funcional del SUT y utilizar esta especificación para generar propiedades para la realización de pruebas. En particular, dada una descripción WSDL de un servicio web y su definición semántica en OCL, podemos generar esas propiedades en lugar de escribirlas manualmente. En este artículo explicamos cómo se ha desarrollado esta propuesta. Como caso de estudio, hemos utilizado VoDKATV, un middleware IPTV/OTT que proporciona una experiencia multimedia avanzada a los usuarios finales, como es el acceso a vídeo bajo demanda, o servicios de navegación por Internet. La sección 2 describe el estado del arte, introduciendo los conceptos en los que se fundamenta nuestro trabajo y un análisis de diferentes enfoques que podrían utilizarse para probar servicios web. La sección 3 explica la arquitectura de nuestro framework, describe sus componentes y cómo interactúan. La sección 4 presenta información detallada sobre VoD- KATV, sus principales componentes y el servicio web específico que hemos seleccionado como terreno de prueba. Por último, en la sección 5 se presentan las conclusiones y trabajos futuros. 2. Background 2.1. WSDL WSDL-S y OCL Un servicio web es un componente software modular y bien definido que ofrece una API que se accede a través de la red, típicamente, Internet. Las aplicaciones utilizan los servicios web mediante el envío y recepción de mensajes escritos en un formato estandarizado, como XML [W3Ca] o JSON [Cro06]. Gracias a la utilización de formatos estándar y comunicaciones HTTP, los servicios web permiten la cooperación de sistemas independientemente de sus características tecnológicas específicas, así como la integración de componentes en sistemas grandes. WSDL es un lenguaje basado en XML para la definición de servicios web en términos de operaciones, entradas, salidas, mensajes, tipos de datos, así como protocolos específicos para el acceso a los servicios. Con poco esfuerzo podemos transformar las especificaciones WSDL en implementaciones en casi cualquier lenguaje de programación para realizar llamadas a dicho servicio web. Algunas de las herramientas de transformación más utilizadas son Apache CXF [Apab] o Apache Axis2 [Apaa] para Java, y podemos encontrarlas incluso integradas en conocidos IDEs, como Eclipse [Ecl]. WSDL se considera, pues, ampliamente aceptado en la industria como estándar para la descripción de servicios web. Automatización de Pruebas para Servicios Web 2 / 15

Los servicios web semánticos pueden enriquecerse con la descripción semántica de su comportamiento. Las descripciones semánticas se expresan con ontologías, una conceptualización formal de un dominio particular. La descripción se crea usando componentes de ese dominio y expresando sus relaciones. WSDL-S tiene como objetivo añadir este tipo de información a los servicios web, extiendendo el lenguaje de especificación WSDL y permitiendo búsqueda automática, descubrimiento, selección, composición e integración entre servicios de dominios heterogéneos. En nuestra propuesta, utilizamos el atributo modelreference que WSDL-S agrega a efectos de anotación; este atributo define la asociación entre una entidad WSDL y un concepto (externo) que describe su semántica. Gracias a este atributo, mantendremos la descripción WSDL y OCL por separado, por lo que cambios en una no afectarán a la otra. Utilizaremos OCL para expresar estos conceptos. OCL es un lenguaje formal usado para la representación de condiciones en modelos UML. Estas condiciones pueden ser invariantes del sistema que se está modelando, o consultas sobre los objetos descritos en el modelo. Un aspecto importante de restricciones OCL es que no tienen efectos secundarios: la evaluación de una expresión OCL no cambia el estado del modelo. Utilizaremos OCL para describir precondiciones y postcondiciones de las operaciones incluidas en la especificación WSDL de un servicio web. 2.2. Pruebas de servicios web La mayor parte de los trabajos publicados sobre pruebas de servicios web presentan métodos para crear buenos conjuntos de pruebas, desde una perspectiva de caja negra. Ejemplos de esto son [AAM10], donde los autores utilizan la técnica de matriz ortogonal (OAT), el método de pares definido por [NS09], y la técnica de partición de [BLTC08]. Algunas propuestas construyen artefactos intermedios para ayudar en el proceso, como por ejemplo [ZZK07], que construye un autómata finito usando BPEL, o [TG07] que combina UML y OCL. En [BBMP09] se presenta un marco completo para realizar pruebas a partir de una especificación WSDL, donde los casos de prueba se generan utilizando un criterio de cobertura y algunas heurísticas. Esta solución también se utiliza en [BIPT09], donde la información acerca de cómo los clientes deben interactuar con el servicio web se infiere. El trabajo previo más próximo a nuestra propuesta, en la que la información semántica se suministra en SWRL [W3Cb] en lugar de OCL, es [NS08]. En todos estos enfoques, no obstante, hay una manifiesta falta de automatización en diferentes momentos del proceso de prueba. Por último, [Lam12] presenta uno de los pocos enfoques totalmente automáticos, en el que se utiliza una herramienta de PBT, pero no se utiliza información semántica, por lo que las pruebas se mantienen en el nivel sintáctico. 2.3. Pruebas basadas en propiedades usando QuickCheck Como alternativa a la producción de las pruebas de forma manual a partir de una especificación de alto nivel en lenguaje natural, o para escribir un modelo formal para describir un sistema o componente, la PBT utiliza sentencias declarativas para especificar las propiedades que el software debe satisfacer de acuerdo con su especificación. Con este enfoque, los casos de prueba pueden entonces ser generados a partir de las propiedades, un proceso que se puede automatizar, lo que permite ejecutar un gran número pruebas para cada propiedad, aumentando la eficacia del proceso de prueba. Automatización de Pruebas para Servicios Web 3 / 15

En nuestro trabajo, hemos utilizado QuickCheck, una herramienta de PBT que automatiza la generación, ejecución y evaluación de casos de prueba. QuickCheck originalmente fue desarrollada por Claessen y Hughes para el lenguaje Haskell [CH00] y re-diseñado, mejorado y comercializado por Quviq AB para Erlang [AH03]. Quviq QuickCheck 1 proporciona generación y ejecución de casos de prueba, permitiendo ejecutar una gran cantidad de pruebas con muy poco esfuerzo, para comprobar si los componentes cumplen dichas propiedades. Para probar sistemas complejos, sin embargo, las propiedades aisladas no son suficientemente expresivas. Para este tipo de situaciones, en lugar de secuencias de casos de prueba independientes, necesitamos secuencias de llamadas que modifican el estado del servicio, y comprobaciones de que las condiciones se cumplen antes y después de cada interacción, así como que el estado global del servicio sigue siendo coherente con su comportamiento esperado después de cada llamada. Sistemas de almacenamiento en la nube a los que se accede a través de servicios web son ejemplos de este tipo de sistemas. En este trabajo se generarán de forma automática, a partir de WSDL y OCL, tanto propiedades aisladas como modelos de máquinas de estado, en función de si el SUT es un sistema sin estado o un sistema con estado. 3. Transformando WSDL + OCL en propiedades Los requisitos de un sistema representan las necesidades que debe cubrir, que son, por lo general, especificadas de manera abstracta, sin entrar en detalles de implementación. El uso de PBT para probar los servicios web que puedan implementar una especificación WSDL dada, requiere describir esos requisitos en forma de propiedades que describan los requisitos del SUT. Para ello, se obtiene información tanto del WSDL como de las restricciones en OCL (precondiciones y postcondiciones de cada operación), y la combinación de ambos nos permite construir nuestro modelo de prueba, compuesto por un conjunto de propiedades. Dependiendo de las necesidades del servicio web, el modelo de prueba puede ser diferente: para los servicios web sin estado, se generan propiedades universalmente cuantificadas; para los servicios web con estado, los requisitos se modelan utilizando una máquina de estados. Tanto a partir de las propiedades como del modelo de máquina de estados del servico web, QuickCheck es capaz de generar casos de prueba concretos y, a continuación, nuestro framework utiliza un adaptador HTTP (generado también a partir de la especificación WSDL) para ejecutarlos directamente contra el SUT. Por lo tanto, para emplear este framework no necesitamos conocer los detalles técnicos del lenguaje de implementación de un servicio web determinado. Además, si se conserva la misma API, distintas implementaciones de un servicio web se puede probar con las mismas propiedades y/o modelo. La arquitectura general de nuestro framework se muestra en la figura 1. En primer lugar, utilizamos la información del archivo WSDL, extraída a través de un parser WSDL. Por ejemplo, a continuación se muestra un extracto de un archivo WSDL que describe un servicio web que proporciona una operación pow (wsdl:interface) que recibe como parámetros GET (wsdl:binding) un entero a y un entero positivo b (pow de wsdl:types), y devuelve otro entero como resultado (powresponse de wsdl:types): 1 De ahora en adelante, nos referiremos a Quviq QuickCheck simplemente como QuickCheck. Automatización de Pruebas para Servicios Web 4 / 15

SUT WSDL file OCL constraints WSDL parser OCL parser Type information (data + services) Semantic information (services) QuickCheck properties/model test cases adapter Figura 1: Arquitectura de prueba propuesta <wsdl:types> <xs:schema...> <xs:element name="pow"> <xs:complextype> <xs:sequence> <xs:element minocurs="0" name="a" type="xs:int" /> <xs:element minocurs="0" name="b" type="xs:positiveinteger" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="powresponse"> <xs:complextype> <xs:sequence> <xs:element minoccurs="0" name="return" type="xs:int" /> </xs:sequence> </xs:complextype> </xs:element>... </xs:schema> </wsdl:types> <wsdl:interface name="mathutilsinterface"> <wsdl:operation name="pow"> <wsdl:input element="msg:powparams"/> <wsdl:output element="msg:powresponse"/> <wssem:modelreference="powconstraints"/> </wsdl:operation> </wsdl:interface> Automatización de Pruebas para Servicios Web 5 / 15

<wsdl:binding name="mathutilshttpbinding" type="http://www.w3.org/ns/wsdl/http" interface="tns:mathutilsinterface"> <wsdl:operation ref="tns:pow" whttp:method="get" whttp:location="pow" /> </wsdl:binding> <wsdl:service name="mathutils" interface="tns:mathutilsinterface"> <wsdl:endpoint name="mathutilshttpendpoint" binding="tns:mathutilshttpbinding" address="http://localhost:8080/mathutils/"> </wsdl:endpoint> </wsdl:service> A partir de este ejemplo, nuestro parser debe analizar diferentes etiquetas como el nombre del servicio (etiqueta service), el atributo WSDL-S modelreference que apunta al archivo OCL, la URL (address) de cada operación (operation) del servicio (binding), etc. En el ejemplo anterior, el WSDL hace referencia a un archivo powconstraints que describe la semántica de las operaciones descritas en el WSDL, expresando las precondiciones y postcondiciones de cada operación. Por ejemplo, dicha especificación podría indicar que el resultado de la operación pow se obtiene multiplicando el entero a por sí mismo b veces. Esto puede ser expresado en OCL con el siguiente código, el cual describe una postcondición (post) en donde se usa la operación iterate que se encarga de iterar a través de todos los elementos de una lista, en este caso una secuencia de b elementos (Sequence{1..b}), y comprueba que el resultado final sea igual a la multiplicacion del elemento a por sí mismo tantas veces como elementos tenga dicha secuencia, es decir, b veces: context MathUtils::pow(a: Integer, b: UnlimitedNatural): Integer post: result = Sequence{1..b}-> iterate(i : Integer; acc : Integer = 1 acc*a) Este archivo OCL también es analizado por nuestra herramienta, comprobando si hay información semántica asociada a cualquiera de las operaciones recuperadas en el paso anterior. Por último, recuperada la información requerida de los archivos WSDL y OCL, es el momento de construir las propiedades a partir de las que QuickCheck va a generar los casos de prueba. Con respecto a los parsers de WSDL y OCL, hemos preferido hacer nuestras propias implementaciones. Decidimos implementar nuestro propio parser de WSDL porque necesitamos integrar el resultado con la información semántica proporcionada en forma de restricciones OCL, como paso previo a la generación de propiedades. Por otro lado, también existen diferentes herramientas para tratar ficheros OCL, pero en la práctica totalidad de los casos, su análisis tiene que ser realizado asociado a un modelo UML. Esto nos ha llevado nuevamente a desarrollar nuestro propio parser OCL, aprovechando parcialmente el trabajo realizado por el proyecto OCLNL [ocl]: una gramática BNF etiquetada [FR03] para OCL. Utilizamos esta gramática junto con una herramienta de generación de compiladores (BNFC) [bnf] para construir el árbol de sintaxis abstracta, el analizador léxico y el parser. 3.1. Servicios web sin estado Los servicios o sistemas sin estado no tienen un estado interno que se vea afectado por el resultado de una secuencia de llamadas a su API, por lo que la respuesta devuelta por una llamada Automatización de Pruebas para Servicios Web 6 / 15

específica es independiente del momento concreto en que se ejecuta. En este caso, el nombre de la operación que se quiere probar y el tipo de su resultado y los argumentos que se recuperan del archivo WSDL son suficientes para construir las pruebas, siendo las restricciones especificadas en el archivo OCL utilizadas como oráculo de dichas pruebas. El ejemplo WSDL del apartado anterior describe el servicio web MathUtils, que ofrece la operación pow con una postcondición especificada en el archivo de OCL. Con esa información, nuestra herramienta genera automáticamente la siguiente propiedad: prop_pow() ->?FORALL({A, B}, {ocl_gen:int(), ocl_gen:nat()}, begin mathutils:pow(a, B) == ocl_seq:iterate(fun(i, Acc) -> Acc * A end, 1, ocl_seq:new(1, B)) end). Esta propiedad es utilizada por QuickCheck para generar casos de prueba específicos. Así, cada par de número entero (ocl gen:int()) y número natural (ocl gen:nat()) que se genera ({A, B}), se utiliza como parámetros para la función mathutils:pow/2, la cual realiza la llamada a la operación pow proporcionada por el SUT, gracias al adaptador HTTP: pow(arg1, Arg2) -> inets:start(), Req = httpc:request("http://localhost:8080/mathutils/pow?a=" ++ Arg1 ++ "&b=" ++ Arg2), case Req of {ok, {{Version, 200, Reason}, Headers, Result}} -> list_to_float(result); Other -> "Unknown error" end. Este adaptador realiza la petición a la URL concreta utilizando la función httpc:request/1, donde la URL del servicio web se obtiene del archivo WSDL, y devuelve el resultado obtenido. El valor devuelto por el servicio web es finalmente contrastado, como parte de la propiedad, con respecto a la postcondición especificada en el archivo OCL. Para ello, se han creado módulos Erlang, como ocl_seq, que implementan cada una de las operaciones disponibles en OCL, como iterate, los cuales se usan en la propiedad generada prop_pow. En general, la propiedad generada que pruebe que una operación f que recibe unos parámetros P, y que lleva asociada una precondición pre, cumple una postcondición post, es la siguiente:?forall(p,?suchthat(p, G(), pre(p)), begin R = f(p), post(p, R) end). la cual será usada por QuickCheck para generar datos aleatorios que cumplan las precondiciones, se ejecute la función a probar (usando el adaptador HTTP), y se compruebe si la postcondición especificada se cumple. La mayor diferencia entre PBT y los métodos de prueba en los que los datos de entrada se especifican manualmente es el uso de generadores. QuickCheck incorpora una biblioteca de generadores de datos básicos (enteros, strings, listas, etc.) a partir de los cuales pueden construirse otros más complejos. Utilizando esta librería básica de QuickCheck, nuestro framework proporciona generadores para todos los tipos soportados por OCL, y usa esos generadores para construir generadores de tipos complejos en caso de ser necesario [FC12]. Este enfoque conduce a una mejora significativa respecto a las pruebas tradicionales [Pet07] y respecto a la mayoría Automatización de Pruebas para Servicios Web 7 / 15

de los trabajos mencionados en la sección 2.2, ya que en lugar de valores concretos, definimos tipos, rangos, y condiciones que los datos de entrada tienen que cumplir, y que son así generados automáticamente en lugar de escritos manualmente. QuickCheck no sólo puede generar una gran cantidad de pruebas concretas derivadas de las propiedades, y ejecutarlas contra el SUT. Otra característica clave de QuickCheck es su capacidad de, cuando se encuentra un caso de prueba que falla, reducirlo de forma automática a un contraejemplo equivalente más pequeño, de manera que resulte más fácil de depurar la razón del fallo. Siguiendo con el ejemplo anterior, se ejecuta la propiedad prop pow, obtenemos: > Testing property: pow...failed! After 52 tests. {-13,16} Shrinking..(2 times) {13,15} que representa la ejecución de 52 pruebas hasta que se revela una incoherencia entre la propiedad y el comportamiento real del servicio web, en concreto, cuando el parámetro a es 13, y b es 16 (13 16 ). En este caso, el fallo es el conocido error de redondeo de los flotantes, como aparece explicado en [ACH08]. Ante un error, debemos determinar si es necesario ajustar la propiedad, o bien corregir el SUT. 3.2. Servicios web con estado En contraposición a los componentes sin estado donde cada acción es independiente entre sí, muchos sistemas tienen un comportamiento que depende de las acciones anteriores. Con el fin de probar estos sistemas, el estado interno tiene que ser tomado en cuenta en el proceso de prueba. QuickCheck tiene soporte para pruebas de este tipo de sistemas mediante el uso de máquinas de estados. En lugar de especificar propiedades generales, se especifica una única propiedad concreta: dada cualquier secuencia de comandos invocados sobre el servicio web, siempre que satisfagan las precondiciones indicadas, sus resultados conformarán las respectivas postcondiciones (figura 2):?FORALL(Commands, commands(statemmodel), ok = run_commands(statemmodel, Commands)). donde StatemModel se construye en QuickCheck mediante la implementación de una serie de callbacks que permiten especificar la lista de comandos de interés (funcionalidades del servicio web a probar), las precondiciones y postcondiciones para verificar el estado del sistema tras cada interacción, y la información que se necesita mantener en el estado interno de la prueba. Las pruebas consisten entonces en secuencias generadas al azar a partir de las posibles transiciones definidas para cada estado [AHJW06]. Nuestro caso de estudio, que procedemos a explicar en la siguiente sección, entra en esta segunda categoría de servicios web con estado. 4. Caso de estudio: VoDKATV 4.1. Arquitectura de VoDKATV VoDKATV es un middleware IPTV/OTT que proporciona a los usuarios finales acceso a diferentes servicios en una pantalla de TV, tablet, smartphone, PC, etc., lo que permite un avanzada Automatización de Pruebas para Servicios Web 8 / 15

Figura 2: Pruebas con estado experiencia multimedia multi-pantalla. VoDKATV es un sistema distribuido compuesto por varios componentes, que se integran a través de servicios web (figura 3). La parte principal del sistema de VoDKATV es el paquete core, que contiene los componentes clave del sistema. Los componentes básicos usan los componentes del backend para obtener información de sistemas externos, por ejemplo, la EPG de canales IPTV (proporcionado por el componente EPGServer) o los contenidos multimedia en alquiler de un catálogo de vídeo bajo demanda (proporcionado por el componente AssetManager). Por otro lado, los componentes básicos son utilizados por los clientes (clients), es decir, las aplicaciones que los usuarios finales utilizan para acceder al sistema en una pantalla de TV, teléfono inteligente o cualquier otro dispositivo compatible. Finalmente, la arquitectura también incluye aplicaciones de administración para gestionar y configurar el sistema (paquete admin). Hemos utilizado VoDKATV como caso de estudio para nuestro framework. En concreto, hemos utilizado el servicio web proporcionado por el componente VoDKATV-server, que devuelve datos en formato XML. 4.2. Aplicación de la propuesta al caso de estudio VoDKATV almacena información sobre los usuarios y los dispositivos que pueden acceder al sistema. Los dispositivos se identifican mediante una dirección MAC, y están asociados a un hogar (o room, en nomenclatura VoDKATV). Cuando un nuevo usuario se registra en el sistema VoDKATV, se crea un nuevo hogar y se registran los dispositivos de ese usuario para ese hogar. El Automatización de Pruebas para Servicios Web 9 / 15

Figura 3: Arquitectura de VoDKATV servicio web elegido como caso de estudio ofrece, entre otras, operaciones para crear, modificar, actualizar y eliminar hogares y dispositivos. Por ejemplo, el WSDL para crear un nuevo hogar: <wsdl:operation name="createroom" pattern="http://www.w3.org/ns/wsdl/in-out" style="http://www.w3.org/ns/wsdl/style/iri" wsdlx:safe="true"> <wsdl:input element="msg:createroomparams"/> <wsdl:output element="msg:createroomresponse"/> </wsdl:operation> donde createroomparams especifica los parámetros del servicio web: <xsd:element name="createroomparams"> <xsd:complextype> <xsd:sequence> <xsd:element name="roomid" type="xsd:string" /> <xsd:element name="description" type="xsd:string" minoccurs="0" maxoccurs="1" /> </xsd:sequence> </xsd:complextype> </xsd:element> y createroomresponse es la respuesta devuelta por el servicio web: <xsd:element name="createroomresponse"> <xsd:complextype> <xsd:sequence> <xsd:element name="roomid" type="xsd:string" /> <xsd:element name="description" type="xsd:string" minoccurs="0" maxoccurs="1" /> <xsd:element name="error" type="tns:error" minoccurs="0" maxoccurs="1" /> </xsd:sequence> </xsd:complextype> </xsd:element> Automatización de Pruebas para Servicios Web 10 / 15

<xsd:complextype name="error"> <xsd:sequence> <xsd:element name="code" type="xsd:string" /> <xsd:element name="params" type="tns:errorparams" minoccurs="0" maxoccurs="1"/> <xsd:element name="description" type="xsd:string" /> </xsd:sequence> </xsd:complextype> <xsd:complextype name="errorparams"> <xsd:sequence> <xsd:element name="param" type="tns:errorparam" minoccurs="1" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="errorparam"> <xsd:attribute name="name" type="xsd:string" /> <xsd:attribute name="value" type="xsd:string" /> </xsd:complextype> Nuestro enfoque requiere especificar el comportamiento del servicio web de modo que los casos de prueba puedan generarse automáticamente. La especificación de CreateRoom será: si el identificador de hogar está vacío, el servicio web debe devolver un error required; si ya existe el identificador de hogar, debe devolverse un error duplicated; en otro caso, el hogar debe crearse, y el servicio web debe devolver su identificador (roomid) y descripción (description). Esta especificación se escribe con precondiciones y postcondiciones OCL. A diferencia del ejemplo MathUtils (sección 3), que es un componente sin estado, aquí tenemos que saber qué hogares se crearon previamente para poder evaluar si el sistema VoDKATV debe devolver un error o no, esto es, se trata de un servicio web con estado. Para ello, escribimos las postcondiciones OCL usando state_rooms como parte del estado interno del modelo de prueba. Dicha variable de estado contendrá los hogares que deben ser creados correctamente en sistema, es decir, cuando no se obtiene un error required o duplicated. Con este enfoque, la especificación para la operación CreateRoom se puede escribir en OCL, usando la operación including de OCL para añadir los hogares al estado, de la siguiente manera: context VoDKATVInterface::CreateRoom( roomid:string, description:string): CreateRoomResponse post CreateRoom: if ((roomid = ) or (roomid = null)) then (self.state_rooms = self.state_rooms@pre and result.errors->size() = 1 and result.errors->at(0).code = required ) else if (self.state_rooms->select( room room.roomid = roomid)->notempty()) then (self.state_rooms = self.state_rooms@pre and result.errors->size() = 1 and result.errors->at(0).code = duplicated ) else self.state_rooms = self.state_rooms@pre->including( Automatización de Pruebas para Servicios Web 11 / 15

Tuple { roomid:string = roomid, description:string = description }) and result.roomid = roomid and result.description = description endif endif Esta especificación de OCL, junto con el WSDL, es transformada por nuestro framework para generar propiedades QuickCheck. Para ello, se utiliza el mismo método descrito en [FC12]. En este caso, al emplear una variable de estado (state_rooms) y el operador OCL @pre, se generará una representación de máquina de estado. Las máquinas de estados QuickCheck requieren la especificación de los siguientes elementos (figura 2): los comandos a ejecutar (es decir, las operaciones del servicio web a probar); las precondiciones para cada operación (definidas en el fichero OCL); las postcondiciones para cada operación (definidas en el fichero OCL); la información almacenada en el estado interno y su valor inicial; la actualización del estado interno tras la ejecución de cada operación. Como ya hemos mencionado, el modelo QuickCheck se conecta a un adaptador HTTP (sección 3) generado por nuestra herramienta a partir del WSDL. Por lo tanto, cuando se prueba una operación, se invocará la correspondiente operación del servicio web y el resultado se contrasta con la correspondiente postcondición. El siguiente es el código generado para comprobar que se devuelve un error required cuando el identificador de hogar está vacío: postcondition(prestate, AfterState, call,?module, createroom, [RoomId, Description], Result) -> case RoomId of "" -> Error = ocl_datatypes:get_property(errors, Result), ocl_seq:eq(afterstate#ts.rooms, PreState#ts.rooms) andalso ocl_string:eq(ocl_datatypes:get_property(code, Error))),"required") end;... Así, nuestra herramienta es capaz de crear automáticamente un modelo de prueba QuickCheck ejecutable a partir de las descripciones WSDL y OCL, capaz de realizar pruebas automáticamente para comprobar la conformidad del servicio web descrito por el WSDL con las restricciones semánticas expresadas en OCL. 4.3. Análisis de resultados QuickCheck genera casos de prueba concretos a partir del modelo de prueba generado, es decir, secuencias aleatorias de comandos con valores aleatorios para los parámetros (de acuerdo con las posibles precondiciones). Además, estas secuencias son ejecutadas, invocando las correspondientes operaciones del servicio web, y determinando si el SUT cumple con las postcondiciones. En el caso de VoDKATV, pueden generarse y ejecutarse cientos de miles de casos de prueba en cuestión de segundos. Dichos casos de prueba han incluído 29 operaciones diferentes de Automatización de Pruebas para Servicios Web 12 / 15