ATLAS MANUAL DE USUARIO DEL ARQUETIPO WEBSERVICE

Transcripción

1 ATLAS MANUAL DE USUARIO DEL ARQUETIPO WEBSERVICE Versión 1.10 Área de Aplicaciones Especiales y Arquitectura de Software

2 Hoja de Control Título Documento de Referencia Responsable Manual de usuario del NORMATIVA ATLAS Área de Aplicaciones Especiales y Arquitectura de Software Versión 1.10 Fecha Versión 30/04/2014 Registro de Cambios Versión Causa del Cambio Responsable del Cambio Fecha del Cambio 1.0 Versión inicial del documento Área de Integración y Arquitectura de 25/05/2010 Aplicaciones - Nueva configuración de Arquetipo 1.1 Web Service Área de Integración y Arquitectura de - Incluida creación previa del arquetipo 16/09/2010 Aplicaciones de proyecto - Nueva nomenclatura de paquetes Modificaciones para versión de Área de Integración y Arquitectura de 16/02/2011 ATLAS Aplicaciones - Las preguntas frecuentes se 1.3 consultarán en el portal de Área de Aplicaciones Especiales y 05/07/2011 arquitectura. Arquitectura de Software Se modificad el nombre del área Nueva arquitectura modular de Área de Aplicaciones Especiales y arquetipo de servicio web 18/10/2011 Arquitectura de Software Nuevo módulo test con proyectos de SoapUI Área de Aplicaciones Especiales y Arquitectura de Software 21/11/ Se añaden las clases BaseService y BaseServiceImpl, así como los 1.6 servicios y DAOs para EstadoCivil - Se añade a la estructura del módulo Área de Aplicaciones Especiales y Arquitectura de Software 24/02/2012 web la carpeta generador. - Se añaden las clases de test 2 de 41

3 Versión Causa del Cambio Responsable del Cambio Fecha del Cambio agrupadas por servicio Se elimina las clases para la fachada ya que en los servicios web no tiene 1.7 sentido. Internamente se ha modificado la versión de axis por lo tanto esta Área de Aplicaciones Especiales y Arquitectura de Software 29/10/2012 versión del arquetipo utilizada esta nueva versión. 1.8 Revisión completa del documento por nueva estructura de arquetipo en ATLAS Área de Aplicaciones Especiales y Arquitectura de Software 27/02/ Se actualiza el apartado 3 para quitar referencias a la herramienta de validación Área de Aplicaciones Especiales y Arquitectura de Software 12/03/ Se modifica jetty por tomcat7 como servidor de aplicaciones Área de Aplicaciones Especiales y Arquitectura de Software 18/07/ de 41

4 Índice 1 INTRODUCCIÓN AUDIENCIA OBJETIVO CONOCIMIENTOS PREVIOS INFORMACIÓN SOBRE EL ARQUETIPO CREACIÓN DE UNA APLICACIÓN PARTIENDO DEL ARQUETIPO ESTRUCTURA DEL ARQUETIPO ESTRUCTURA DE DIRECTORIOS Y ARCHIVOS ESTRUCTURA DEL MÓDULO WEB ESTRUCTURA DEL MÓDULO LIB ESTRUCTURA DEL MÓDULO TEST CONFIGURACIÓN DEL DESCRIPTOR DE SERVICIOS SERVICES.XML Configuración básica Configuración para seguridad DESPLIEGUE Y EJECUCIÓN DE LA APLICACIÓN EJECUCION TEST EJECUCIÓN DE TEST UNITARIOS EJECUCIÓN DE LOS TESTS DE SOAPUI PRUEBAS FUNCIONALES CON SOAPUI GLOSARIO DE TÉRMINOS PANEL DE NAVEGACIÓN TESTCASES Acciones de los TestCases Crear un TestCase desde una Petición Ejecutar TestCase ASERCIONES Gestión de Aserciones Categorías de aserción Aserciones comunes Añadir Aserciones en TestCase Aserciones con XPath Match Ejemplos de Aserciones XPath Match: TEST SUITE Acciones del TestSuite Crear TestSuite de 41

5 Ejecutar TestSuite PREGUNTAS MAS FRECUENTES ENLACES RELACIONADOS de 41

6 1 INTRODUCCIÓN Los arquetipos son las plantillas para la generación de los distintos proyectos dentro del Framework Atlas. Estos arquetipos utilizan el plugin archetype de maven para generar la estructura de ficheros y directorios necesarios para nuestro proyecto, gestionando las librerías que le indiquemos así como las dependencias. Todas las librerías serán incluidas durante el empaquetado del proyecto, por lo que para generar y compilar un arquetipo debe estar conectado al repositorio de artefactos de la Comunidad de Madrid (Artifactory). El framework Atlas consta de los siguientes arquetipos: - Arquetipo para inicio de proyecto - Arquetipo para módulos de tipo web - Arquetipo para módulos de tipo jar. - Arquetipo para módulos de tipo webservice o servicios web - Arquetipo para módulos de tipo batch - Arquetipo para módulos de gestión documental (documentum) El genera un proyecto modular con un módulo maven de tipo war para el servicio web listo para ser desplegado, y un módulo de tipo jar para el cliente de dicho servicio. Está preparado para publicar un servicio de Spring a través de Axis2 sin generación de código intermedio. El proyecto viene preconfigurado para acceder a base de datos a través de Hibernate y publica como webservices una serie de servicios de ejemplo. Se incluye un ejemplo de servicio sin seguridad, otro seguro a nivel de transporte y otro securizado con webservice security. Para más información sobre estos tipos de seguridad consultar el manual ATLAS_MUS_Servicios_Web. 1.1 AUDIENCIA OBJETIVO Este documento está dirigido a desarrolladores de proyectos java para ICM en los que se desee crear una aplicación que publique un Servicio Web utilizando el framework de desarrollo Atlas. 1.2 CONOCIMIENTOS PREVIOS Para un completo entendimiento del documento, el lector deberá tener conocimientos previos sobre las siguientes tecnologías: - Java - Eclipse - Maven - Spring Framework. - Axis2 y SoapUI 6 de 41

7 Además, es necesario haber leído y seguido los pasos del manual ATLAS_MUS_Preparacion_Entorno_Desarrollo para tener el entorno de desarrollo preparado. 7 de 41

8 2 INFORMACIÓN SOBRE EL ARQUETIPO 2.1 Creación de una aplicación partiendo del arquetipo NOTA IMPORTANTE Antes de generar un arquetipo es IMPRESCINDIBLE haber generado un arquetipo para albergar el proyecto (consultar ATLAS_MUS_Preparacion_Entorno_Desarrollo para ver cómo crear un arquetipo de proyecto). Cualquier arquetipo posterior será incluido como un módulo de éste. Crear un proyecto de Servicios Web a partir de un arquetipo es similar a la creación de un proyecto Web, modificando el nombre del arquetipo a utilizar. Para crear un proyecto a partir de un arquetipo maven puede consultar la guía paso a paso que se indica en el documento ATLAS_MUS_Preparacion_Entorno_Desarrollo, según se indica en el apartado Creación de una aplicación Web desde cero, sustituyendo atlas-arquetipos-generador-web por atlas-arquetiposgenerador-servicioweb. 8 de 41

9 A continuación se nos mostrará una pantalla para indicar cuáles son los parámetros con los que vamos a crear nuestro proyecto. 9 de 41

10 ATENCION NOMENCLATURA Es muy importante utilizar en esta pantalla los valores que cumplan la normativa de Atlas: groupid: Nombre del proyecto. Normalmente es de 4 caracteres y es un código que se le da a un proyecto. Todos los módulos de un proyecto tendrán el mismo groupid y se corresponderá con el nombre del proyecto. artifactid: Nombre del módulo. (En el caso de servicios web el nombre del módulo será: xxxx_ws_yyyy donde xxxx se corresponde con el groupid indicado y yyyy el texto que identifique a este modulo y lo diferencie de otros: Ejemplo: ejpl_ws_acceso. El carácter de separación a utilizar debe ser el guión bajo. Version: La primera versión será package: El nombre del paquete java será el groupid, seguido de un punto y el nombre del bloque funcional dentro de la aplicación (para aplicaciones grandes se crearán varios bloques funcionales). Todos los nombres deben ir en minúsculas. Al pulsar Finish se crea el nuevo proyecto. 10 de 41

11 ATENCION Las clases que se incluyen de ejemplo son simplemente eso y deben ser eliminadas del proyecto cuando no se necesiten. Antes de comenzar a visualizar la estructura del nuevo proyecto generado, debemos realizar un ajuste en el fichero pom.xml del nuevo proyecto creado. Para ello, debemos abrir el fichero web\pom.xml, lib\pom.xml y test\pom.xml, eliminar la sección <parent> existente y descomentar la sección <parent> que aparece comentada. Antes de eliminar: Después de eliminar: 11 de 41

12 Una vez configurado el proyecto general y el subproyecto (módulo de tipo aplicación servicioweb), ya podemos seguir viendo la estructura del subproyecto para la aplicación que acabamos de generar. 2.2 Estructura del arquetipo Este arquetipo genera un proyecto maven multimodular con un proyecto padre cuyo pom llevará la configuración general del resto de subproyectos. El proyecto consta de tres módulos: Lib: Módulo de tipo jar donde se implementa el cliente del servicio web. Aquí se crearán las interfaces de servicio y los objetos de datos de intercambio. Es además, una dependencia del proyecto Web ya que el webservice implementado tendrá necesariamente que hacer uso de los objetos definidos en este módulo. Web: Módulo de tipo war, configurado para utilizar Spring, Hibernate, Axis2 y seguridad, y preparado para desplegar el servicio web en un servidor de aplicaciones. Aquí se creará la implementación del servicio web. Test: Módulo con proyectos de SoapUI preparados para realizar pruebas de llamada sobre el servicio web. Contiene un proyecto SoapUI para cada uno de los ejemplos de servicio incluidos. Este módulo no generará ningún producto empaquetado como los otros dos módulos (paquete war el módulo web y paquete jar el módulo lib). 2.3 Estructura de directorios y archivos 12 de 41

13 Una vez generado el proyecto se generan una serie de directorios a estilo maven, donde ubicaremos los fuentes y recursos de las partes de java, test y aplicación. A continuación se describe la estructura de cada uno de los dos módulos del proyecto Estructura del Módulo web El módulo web tiene la siguiente estructura de directorios y ficheros: Fichero de configuración de Maven del proyecto De esta ruta cuelga la estructura de paquetes con el código fuente del proyecto. El paquete raíz va a llamarse igual que el nombre del módulo que se está desarrollando. Inicialmente el paquete raíz se llamará con el código de proyecto (equivalente al groupid). Adicionalmente, en el subpaquete services residirán las implementaciones de los servicios web a publicar. En los ejemplos inferiores se ha tomado como paquete raíz ejpl. Implementación del servicio web. Las interfaces del servicio web deben crearse en el módulo lib. Ruta donde se generarán los recursos del proyecto, normalmente son ficheros de configuración y ficheros de propiedades. En nuestro caso contiene los siguientes ficheros: Fichero de propiedades que contiene todas las variables de configuración cuyo valor puede ser diferente en distintos entornos de ejecución (local, desarrollo, producción, etc.). Antes de desplegar un proyecto en los entornos de ICM, este fichero será sustituido por su homólogo correspondiente al entorno en el que 13 de 41

14 se vaya a desplegar. Fichero de configuración de log4j; lleva además configuración de los módulos de trazas y monitorización. Fichero de propiedades que contiene mediante clave y valor todos los valores particulares de la aplicación que no son susceptibles de ser modificados o configurados entre diferentes entornos de ejecución. Fichero de configuración de Spring para la carga en el contexto de Spring de todos los DAOs (clases de acceso a datos). Fichero de configuración de Spring que lleva la configuración del datasource, sessionmanager y transactionmanager que integra Hibernate con Spring. Inicialmente el datasource será configurado mediante las propiedades ubicadas en el fichero conf/jdbc.properties (se generan de forma automática con maven) aunque para el paso a integración deben configurarse localizando por jndi al datasource del servidor de aplicaciones. Fichero de configuración de Spring para la carga de las propiedades ubicadas en application.properties y resto de archivos de propiedades necesarios. Fichero de configuración de Spring para la carga de todas las clases de 14 de 41

15 Servicios. Ruta donde se generarán el código fuente para los test de nuestro proyecto. Este código nunca deberá estar incluido en el jar final. Paquete para los tests unitarios. En el módulo web no hay tests implementados por defecto. Ruta donde se generarán los recursos para realizar las pruebas de test, normalmente son ficheros de configuración y ficheros de propiedades. En nuestro caso contiene los siguientes ficheros: Ficheros de configuración por si se desea acceder a la aplicación por ssl Lleva la configuración del datasource, sessionmanager y transactionmanager que integra Hibernate con Spring. Este fichero es un espejo del fichero conf/applicationcontextdatabase.xml excepto que en ningún caso debe localizar el datasource por JNDI del servidor de aplicaciones, puesto que en la fase de test no tenemos acceso a dicho servidor. Ruta donde se generarán los recursos necesarios para la parte web de la aplicación. Fichero de acceso principal que redirige al listado de servicios del web service. Página de entrada que muestra un listado de servicios y un enlace a sus documentos WSDL. 15 de 41

16 de servicios de Axis2. Descriptor de despliegue aplicación Descriptor web de la Descriptor adicional para el servidor de aplicaciones Weblogic. Descriptores adicionales para el servidor de aplicaciones Jetty. OBSOLETO: A partir de Atlas se ejecuta tomcat7 en local Ficheros de configuración de tomcat7 para su ejecución en local y en los tomcats de ICM Directorio para herramienta de generación automática de código Estructura del Módulo lib El módulo lib tiene la siguiente estructura de directorios y ficheros: Fichero de configuración de maven del módulo lib. Normalmente las dependencias no se incluyen en este fichero, sino en el fichero pom.xml del proyecto padre. De esta ruta cuelga la estructura de paquetes con el código fuente del proyecto cliente. El paquete raíz va a llamarse igual que el nombre del módulo que se está desarrollando. Inicialmente el paquete raíz se llamará con el código de proyecto (equivalente al groupid). 16 de 41

17 Adicionalmente, para cada bloque funcional de nuestra aplicación debe crearse un subpaquete. Entidades de entrada/salida del API del webservice Interfaces de los servicios web que serán publicados. Implementaciones de cliente de las interfaces de los servicios web. Ruta donde se generarán los recursos del proyecto, normalmente son ficheros de configuración y ficheros de propiedades. En nuestro caso contiene los siguientes ficheros: Fichero de configuración de los servicios de cliente publicados. Ficheros de política de seguridad a aplicar si el servicio web es seguro Ruta donde se generarán el código fuente para los test de nuestro proyecto. Este código nunca deberá estar incluido en el jar final. Tests unitarios para comprobar la correcta implementación de los clientes del servicio web. Ruta donde se generarán los recursos para realizar las pruebas de test, normalmente son ficheros de configuración y ficheros de propiedades. En nuestro caso contiene los siguientes ficheros: Fichero de propiedades que contiene mediante clave y valor 17 de 41

18 todos los valores susceptibles de ser modificados o configurados entre diferentes entornos de ejecución. Este fichero solamente es para la ejecución de los test. Fichero de configuración de log4j; lleva además configuración de los módulos de trazas y monitorización. Contiene la configuración básica de un bean de Spring de ejemplo para ejecutar el test de JUnit que viene preconfigurado. Fichero de propiedades que contiene mediante clave y valor todos los valores particulares de la aplicación que no son susceptibles de ser modificados o configurados entre diferentes entornos de ejecución. Directorios de uso interno de ICM para la configuración de la aplicación en los distintos entornos. Los ficheros environment.properties de estos directorios solamente se utilizan para la ejecución de los test (la librería es independiente del entorno). Si se incluye una nueva variable en src/main/resources/environment.pro perties se ha de incluir también en todos estos Estructura del Módulo test 18 de 41

19 El módulo test tiene la siguiente estructura de directorios y ficheros: Fichero de configuración de maven del módulo test. Normalmente las dependencias no se incluyen en este fichero, sino en el fichero pom.xml del proyecto padre. De esta ruta cuelga la estructura de paquetes con el código fuente. En este módulo no se incluye código fuente.. Ruta donde se generarán los recursos del proyecto. En nuestro caso contiene los siguientes ficheros: Proyectos SoapUI para los servicios de ejemplo. Almacenes de certificados para las pruebas con SoapUI. Descriptores del ejemplo de servicio web. Ruta donde se generarán el código fuente para los test de nuestro proyecto. Este módulo no tiene código java de tests unitarios. Ruta donde se generarán los recursos para realizar las pruebas de test, normalmente son ficheros de configuración y ficheros de propiedades. Este módulo no tiene recursos para los tests java: 2.4 Configuración del descriptor de servicios services.xml Toda la configuración que se muestra a continuación se realiza según marca la documentación de Axis2, por lo que para cualquier consulta adicional puede consultarlo en la web 19 de 41

20 Configuración básica El arquetipo genera el fichero services.xml en el módulo web con una configuración válida que despliega un bean del contexto de Spring como WebService. Si necesitamos editar dicho fichero lo podremos hacer de la siguiente manera: service: etiqueta que especifica un servicio, podemos publicar tantos servicios como deseemos siempre que tengan un nombre diferente (parámetro name). Inicialmente se pone como nombre de servicio el nombre de la aplicación. ServiceObjectSupplier: especifica que clase nos proporciona los objetos que vamos a publicar, en nuestro caso Spring. Este parámetro no se debe modificar. SpringBeanName: Nombre del bean que vamos a publicar ubicado en el contexto de Spring (applicationcontext-services.xml). ServiceClass: Interfaz de la clase que se va a publicar. Se debe especificar la interfaz del servicio que queremos publicar para que Axis2 sepa como generar el WSDL correspondiente, de lo contrario podemos tener problemas por que las clases estén interceptadas por Spring-AOP y esto falsee su interfaz en ejecución. Esta clase debe crearse en el módulo cliente lib aunque se referencie en este módulo. A continuación se muestra un ejemplo de configuración del fichero services.xml del módulo web que publica un servicio. Services.xml <?xml version="1.0" encoding="utf-8"?> <servicegroup> <service name="ejemploservice"> <parameter name="serviceobjectsupplier"> org.apache.axis2.[...].springservletcontextobjectsupplier</parameter> <parameter name="springbeanname">ejemploservice</parameter> <parameter name="serviceclass">ejpl.webservice.services.ejemploservice</parameter> <messagereceivers> <messagereceiver mep=" class="org.apache.axis2.rpc.receivers.rpcmessagereceiver" /> <messagereceiver mep=" class="org.apache.axis2.rpc.receivers.rpcinonlymessagereceiver" /> </messagereceivers> </service> <!-- añadir aquí mas servicios si se desea <service name="nuevoservicio">... </service> --> </servicegroup> Configuración para seguridad 20 de 41

21 Para obtener información más detallada de la aplicación de seguridad en el servicio web, así como del contenido y operativa de los módulos, debe consultarse el documento ATLAS_MUS_Servicios_Web.doc. 2.5 Despliegue y Ejecución de la aplicación El arquetipo WebService es una aplicación web preparada para la publicación de alguno de sus servicios mapeados en Spring como servicio web Axis2. Para construir el proyecto debe ejecutarse el siguiente comando desde el POM padre del proyecto generado: mvn clean install Por defecto, al ejecutar Maven con los parámetros clean install se genera el paquete jar correspondiente al cliente del servicio web y el war correspondiente a la aplicación web que contiene este. Para desplegar el war en nuestro servidor de aplicaciones podemos coger el fichero de la carpeta en la que se ha generado (web/target/nombrefichero.war), o podemos utilizar un servidor Tomcat7 local que viene preconfigurado en el arquetipo. Para ejecutar directamente un servidor tomcat7 con nuestro proyecto desplegado, debemos ejecutar la siguiente línea de comandos desde el directorio web de nuestro proyecto la siguiente línea de comandos: mvn tomcat7:run Esto arranca un servidor tomcat7 en el puerto 9080 de nuestra máquina, en el que se encuentra desplegado el war de nuestra aplicación. Introduciendo la siguiente URL en un navegador se podrá ver un listado de los servicios desplegados. Esta URL solo es válida para el servidor Tomcat7 local. En el caso de los ejemplos securidados el acceso es por Para la ejecución de los tests JMeter, desde el módulo test: mvn clean install Pjmeter Para la generación y despliegue de los artefactos adicionales con los javadocs y el código fuente del proyecto: mvn clean install Dadditional_artifacts=true 21 de 41

22 Para probar la ejecución de este arquetipo puede comprobar en la URL donde se listan los servicios desplegados y sus documentos WSDL: EJECUCION TEST Ejecución de test unitarios Los test unitarios se encuentran en el módulo lib en la carpeta src/test/java/xxxx/client. Antes de ejecutarlos es necesario editarlos y quitar o comentar la ya que de lo contrario no se van a ejecutar. Esta etiqueta se ha incluido por que si se compila ejecutando los test y no está levantado el servidor de aplicaciones con el servicio web lo test no van a funcionar. Para comprobar la correcta implementación de la comunicación entre cliente y servidor, con el servidor del servicio web arrancado, se deberá ejecutar la siguiente sentencia desde el directorio lib del proyecto: mvn test También se pueden ejecutar cada test de Junit desde el propio Eclipse como se ejecuta cualquier clase de tipo Junit Ejecución de los tests de SoapUI SoapUI es una aplicación para realizar llamadas a servicios web. Esta aplicación es utilizada normalmente para comprobar la correcta ejecución de los servicios web. Los proyectos de prueba incluidos en el módulo de test se han generado con la versión de SoapUI. Esta aplicación puede ser descargada desde el siguiente enlace: Para realizar una prueba de llamada al servicio web, primero debe levantarse el servidor tomcat7 tal y como se especifica en el apartado anterior. A continuación ejecutar SoapUI. 22 de 41

23 Pulsar en el segundo icono y cargar el fichero del módulo test EjemploService-soapui-project.xml. Una vez cargado el proyecto, desplegar el elemento EjemploServiceSoap12Binding (también puede probarse el Soap11Binding) y el método alterar. Hacer doble click en Request 1. Con esto tendremos desplegado un XML de petición al servicio web. 23 de 41

24 Para ejecutar esta petición hay que pulsar el icono la respuesta.. Con esto se enviará la petición al servicio y se presentará 24 de 41

25 Para comprobar cualquier otro método de este proyecto o del proyecto de cliente seguro debe seguirse el mismo procedimiento. 25 de 41

26 3. Pruebas Funcionales con SoapUI. En SoapUI, las pruebas funcionales se pueden usar para validar requisitos funcionales, tanto para invocar los Servicios Web propios ( Pruebas unitarias ) como para una secuencia de peticiones ( pruebas de integración ), Además, es posible añadir lógica a las pruebas mediante scripts de Groovy, lo que permite, por ejemplo, interactuar con una base de datos o realizar un flujo de pruebas complejo Glosario de términos. TestCase: Caso de prueba funcional de Servicio Web. TestSuite: Contenedor de casos de pruebas (TestCases). TestStep: Paso que puede definirse en un caso de uso, pueden ser, peticiones http, peticiones Soap o Script de groovy. Aserciones: Condiciones que se evalúan tras obtener la respuesta de un petición Panel de Navegación. El panel de navegación está conformado por los siguientes componentes: (Ver imagen) 1 Panel de Navegación ATENCION Antes de realizar los siguiente pasos, se debe tener previamente importado los proyectos SoapUI que se encuentran en {proyecto}/test/src/main/java/resources/soapui/ 3.4. TestCases. Un TestCase en SoapUI, permite realizar pruebas funcionales de Servicios Web suministrando un numero de pasos (Prueba de Casos de Usos) que pueden ser ejecutados en secuencia Acciones de los TestCases. Las siguientes acciones están Disponibles desde el menú que aparece al hacer clic derecho en el nodo del TestCase. 26 de 41

27 2 Acciones de TestCase Show TestCase Editor: Abre el editor del TestCase. Disable/Enable TestCase: Opción que deshabilita/habilita el TestCase. Options: Muestra la ventana de opciones del TestCase. Add Step: añade un TestStep al TestCase. New LoadTest: Opción que abre una ventana para crear una nueva prueba de carga para el TestCase. Clone TestCase: Opción que permite clonar todo el TestCase, opcionalmente en otro TestSuite. Clear: Muestra una ventana para eliminar todos los TestSteps del TestCase. Rename: Opción que permite renombrar el TestCase. Remove: Opción que permite eliminar el TestCase de su TestSuite. Launch Runner: Opción que abre cuadro de diálogo para el lanzador del TestCase. Move TestCase Up: Opción que mueve el actual TestCase hacia arriba en la lista de los TestCase. Move TestCase Down: Opción que mueve el actual TestCase hacia abajo en la lista de los TestCase. Online Help: Opción que abre la página de ayuda online en el navegador Crear un TestCase desde una Petición. Una vez tengamos algunas peticiones configuradas, podremos realizar un Caso de Prueba que verifique su comportamiento. Sobre una petición, presione el botón derecho del ratón y seleccione la opción Add to TestCase 27 de 41

28 3 Agregar Caso de Prueba Aparecerá el listado de Casos de Pruebas previamente creados. 4 Listado de Casos de Pruebas Seleccione el Caso de Prueba al cual desea agregar el nuevo Caso de Prueba y presione el botón Aceptar. Si no hay ningún Grupo de Prueba/Caso de Prueba en el proyecto, soapui abrirá una ventana para pedir los nombres del TestSuite y TestCase. 5 Create TestSuite 6 Create TestCase 28 de 41

29 SoapUI abrirá una ventana para introducir el nombre y especificar aserciones comunes en la petición de prueba. Las aserciones a seleccionar son las siguientes: o Adds Validation that response is a SOAP message. (Valida que la respuesta recibida es un mensaje Soap) o Adds Validation that response is not a SOAP Fault. (Valida que la respuesta recibida sea un mensaje Soap no fallido, si la prueba válida si se produces un error, no se debe seleccionar esta opción). 7 Agregar TestCase Los correspondientes TestSuite/TestCase se crearán y la petición se añadirá como TestCase, la cuál es una copia de la petición original (de esta manera, puedes seguir utilizándolo sin modificar la petición de prueba) Un editor de peticiones de prueba casi idéntico al estándar se abre con el nuevo TestCase. 29 de 41

30 8 Editor de peticiones de prueba Ejecutar TestCase. En el panel de Navegación, haga doble clic en el caso de prueba que contiene aserciones. Seguidamente SoapUI abrirá la ventana correspondiente. Haga clic en el botón de reproducción, el caso de prueba se ejecutara, evaluando las aserciones contenidas en los pasos TestStep Aserciones. 30 de 41

31 Las aserciones se utilizan para validar el mensaje recibido por un TestStep durante la ejecución, por lo general mediante la comparación de las partes del mensaje (o todo el mensaje) a algún valor esperado. Se pueden añadir cualquier numero de aserciones a un TestStep. Después de una ejecución, todas las aserciones son aplicadas a la respuesta recibida, si alguna de esta validaciones falla, el TestStep se marca como fallido en la vista del caso de prueba y se muestra la correspondiente entrada en el registro de la ejecución de pruebas Gestión de Aserciones. Las aserciones siempre se muestran en la pestaña inferior del TestSpet que lo contiene. 31 de 41

32 En la imagen anterior se ven tres aserciones añadidas en el mensaje Soap del TestStep. Las dos primeras fueron OK, pero la última fue fallida. La barra de herramientas localizada en la parte superior del listado de aserciones, permite agregar, configurar, eliminar, mover y clonar aserciones y presionando el botón derecho del ratón, aparecerá un menú emergente que contiene acciones similares. Al hacer doble clic en una aserción nos lleva a su ventana de configuración si está disponible Categorías de aserción. Todas las categorías que contienen aserciones se enumeran a continuación: Property Content Contains: Busca la existencia de una cadena en los valores de (Propiedades de Contenido) las propiedades. Soporta expresiones regulares. Es aplicable a cualquier propiedad. Not Constains: Busca la inexistencia de una cadena en los valores de las propiedades. Soporta expresiones regulares. Es aplicable a cualquier propiedad. XPath Macht: Usos de es una expresión XPath para seleccionar el contenido de la propiedad de destino y compara el resultado con un valor esperado. Aplicable a cualquier propiedad que contiene XML. XQuery Match: Permite el uso de una expresión XQuery para seleccionar el contenido de la propiedad de destino y compara el resultado con un valor esperado. Aplicable a cualquier propiedad que contiene XML. Message Content Assertion: Permite la validación de contenido 32 de 41

33 Compliance, Status and Standards (Cumplimientoc, Estado y Normas) Script SLA complejo de mensajes XML. Aplicable a cualquier propiedad que contenga XML. HTTP Download all resource: Descarga todos los recursos que se encuentran referenciados en un documento HTML (imágenes, scripts, etc) y valida que todos ellos estén disponibles. Aplicable a cualquier propiedad que contiene HTML. Invalid HTTP Status Codes: Valida que el mensaje de respuesta recibido contiene un estado de código HTTP no valido en la lista definida. (Aplicable a cualquier TestStep que reciba mensajes HTTP). Not SOAP Fault: Valida que el mensaje de respuesta recibido no sea un error de Soap. Schema Compliance: Valida que el mensaje de respuesta recibido sea compatible con el WSDL asociado o la definición de esquema WADL. (Aplicable a SOAP y REST TestStep) SOAP Fault: Valida que el mensaje de respuesta recibido sea un error de Soap. (Aplicable solo a MockResponse y TestSteps Soap). SOAP Response: Valida que la respuesta recibida sea un mensaje Soap valido. (Aplicable solo a TestRequest y TestSteps Soap). Valid HTTP Status Codes: Valida que el mensaje de respuesta recibido contenga un estado de código HTTP valido en la lista definida. (Aplicable a cualquier TestStep que reciba mensajes HTTP). WS-Addressing Request: Valida que la solicitud recibida contenga encabezados de WS-Addressing válidos. (Aplicable solo a MockResponse y TestSteps Soap). WS-Addressing Response: Valida que la respuesta recibida contenga encabezados de WS-Addressing válidos. (Aplicable solo a TestRequest y TestSteps Soap). WS-Security Status: Valida que el mensaje recibido contenga cabeceras WS-Security validos. (Aplicable solo a TestSteps Soap). Script Assertion: Ejecuta un script personalizado para realizar validaciones arbitrarias. (Aplicable solo a TestSteps) Response SLA: Valida que la ultima respuesta recibida fue dentro de los limites definidos. (Aplicable a Script, TestSteps y TestSteps que envían peticiones y reciben respuesta) 33 de 41

34 JMS JBDC Security JMS Status: Valida que la solicitud JMS sea ejecutada con éxito. (Aplicable a TestSteps con JMS endpoint) JMS Timeout: Valida que la declaración JMS no tome más tiempo que la duración especificada. (Aplicable a TestSteps con JMS endpoint) JDBC Status: Valida que la declaración JDBC sea ejecutada con éxito. (Aplicable solo a JDBC TestSteps) JDBC Timeout: Valida que la declaración JDBC no tome más tiempo que la duración especificada. (Aplicable solo a JDBC TestSteps) Sensitive Information Exposure: Comprueba que el mensaje recibido no expone información sensible sobre el sistema de destino. (Aplicable a REST, SOAP y http TestSteps) Aserciones comunes. Las aserciones disponibles para todos tipos de TestSteps son: Contains - comprueba la existencia de una cadena especificada Not Contains - comprueba la inexistencia de una cadena especificada. Reponse SLA - comprobar el tiempo de respuesta frente a un valor especificado. XPath Match - compara el resultado de una expresión XPath para un valor esperado. XQuery match - compara el resultado de una expresión XQuery a un valor esperado Script - Ejecuta una secuencia de comandos arbitraria que se puede utilizar para validar el mensaje recibido si lo desea Añadir Aserciones en TestCase. Seleccionar el TestStep y presione la tecla enter, SoapUI abrirá un editor de peticiones de prueba. En la barra de herramientas ubicada en la parte superior del editor de peticiones de prueba, seleccionar el segundo botón. 34 de 41

35 9 Botón para Agregar Aserción SoapUI abrirá la ventana de dialogo que permitirá elegir el tipo de aserción. 10 Ventana para agregar Aserciones Presione el botón Add para agregar la aserción seleccionada Aserciones con XPath Match. La aserción XPath Match permite la especificación de una expresión XPath para ser evaluada en relación a un mensaje de respuesta recibido y comparar su resultado con un valor predefinido. Las expresiones pueden eleccionar todo, desde valores de atributos, hacer evaluaciones booleanas o seleccionar la respuesta de todo el cuerpo (XmlUnit se usa internamente para comparar los elementos XML, jerarquías o nodos). Internamente, soapui usa el motor Saxon 8.8 XPath que tiene soporte para XPath 1,0 y 2,0 XPath. La ventana de diálogo de configuración para la aserción XPath Match se divide en 2 zonas, la de la parte superior que contiene la expresión XPath deseada y la de la parte inferior que contiene el resultado esperado Ejemplos de Aserciones XPath Match: 35 de 41

36 Los siguientes ejemplos son realizados sobre el proyecto EjemploService-soapui-project.xml en el TestStep Alterar Valida si existe una etiqueta xml en el mensaje de respuesta: XPath Expression: declare namespace ax23=' exists(//ax23:cadenasalida) Expected Result: true Valida que el valor de la etiqueta idllamada sea numérico. XPath Expression: declare namespace ax23=' matches(//ax23:idllamada/text(),'\d') Expected Result: true Valida que el valor de la etiqueta idllamada sea mayor que 0. XPath Expression: declare namespace ax23=' //ax23:idllamada/text()>0 Expected Result: true Valida que el valor de la etiqueta cadenasalida contenga el valor cadena. XPath Expression: declare namespace ax23=' //ax23:cadenasalida/contains(text(),'cadena') 36 de 41

37 Expected Result: true Ver el siguiente enlace para ver todas todas las funciones predefinidas con XPath Test Suite. Una TestSuite sirve como contenedor para un numero arbitrario de Casos de Pruebas ( TestCases ). Cuando se ejecuta un TestSuite, los Casos de Pruebas ( TestCases ) incluidos se pueden ejecutar tanto en secuencia como en paralelo Acciones del TestSuite. Las siguientes acciones están disponibles desde el menú que aparece al realizar clic derecho sobre el nodo del TestSuite. Show TestSuite Editor: Opción que permite abrir el lanzador de TestSuite. Disable TestSuite: Opción que permite habilita/deshabilita el TestSuite New TestCase: Opción que permite crear un nuevo caso de prueba en el TestSuite Clone TestSuite: Opción que permite clonar una TestSuite, incluyendo todos los Casos de Pruebas ( TestCases ) y TestSpteps. Launch TestRunner: Opción que abre un cuadro de dialogo para ejecutar el TestSuite desde línea de comandos. Rename: Opción que permite renombrar el TestSuite. Remove: Opción que permite eliminar el TestSuite del proyecto SoapUI. Online Help: Abre la pagina de ayuda online en el navegador Crear TestSuite. Presionar botón derecho del ratón sobre la interfaz y seleccionar la opción Generate TestSuite. 37 de 41

38 11 Generate TestSuite SoapUI abrirá un cuadro de dialogo para generar un TestSuite completo para la interfaz seleccionada. 12 Opciones de generación del TestSuite El cuadro de dialogo contiene las siguientes opciones: o TestSuite: Combobox que permite seleccionar crear una TestSuite sobre una existente o una nuevo. o Style: Existen dos Tipos de estilos: One TestCase for each Operation: Permite crear TestSuite con casos de pruebas para cada operación. Single TestCase with one Request for each Operation: Permite crear TestSuite con casos de pruebas únicos con una sola solicitud por cada operación. o Request Content: Permite definir el contenido de la solicitud para los casos de prueba. Existe dos opciones. Use existing Request in Interface: Crea Casos de Pruebas con los mensajes de solicitud existentes en la interfaz. 38 de 41

39 Create new empty requests: Crea Casos de Pruebas con mensajes de solicitud vacios. o Operations: Permite seleccionar las operaciones a las cuales desea generar Casos de Pruebas. o Generate LoadTest: Permite crear una prueba de carga por defecto para cada Caso de Prueba generado. Seleccione las opciones que usted cree oportunas para sus pruebas y por ultimo presione el botón OK. Si en el cuadro de dialogo anterior ha seleccionado en la opción TestSuite el valor por defecto <create>, aparece la siguiente ventana, que permite especificar el nombre de la TestSuite : 13 Name of TestSuite Digite en nombre de la TestSuite y presione el botón Aceptar. Si ha seleccionado la opción One TestCase for each Operation en el cuadro de dialogo de creación de TestSuite y en el caso de que una operación tenga más de un mensaje de solicitud, aparecerá una ventana informando que el nombre del paso debe ser único y debe ser especificado. 14 Name of TestName Digite en nombre de la TestStep y presione el botón Aceptar Ejecutar TestSuite. Haciendo doble clic sobre un TestSuite, SoapUI abre el lanzador de TestSuite que contiene la lista de los Casos de Pruebas (TestCases). Cada Caso de Prueba tiene una barra de progreso que está determinada por la cantidad de pasos (TestStep) y por defecto no está activa. Haga clic en el botón de reproducción, los casos de pruebas se ejecutaran, evaluando las aserciones contenidas en los pasos TestStep, la barra de progreso puede tomar color rojo o verde según el resultado de cada TestStep (Rojo si el TestStep fue fallido, verde si fue correcto) y muestra un texto indicando del resultado final de cada prueba. 39 de 41

40 15 Lanzador de TestSuite sin Ejecutar 16 Lanzador de TestSuite Ejecutado 4 PREGUNTAS MAS FRECUENTES La lista de preguntas frecuentes se encuentra en el portal de arquitectura. 5 ENLACES RELACIONADOS Producto URL 40 de 41

41 Axis2 Configuración Services.xml Apache Maven Log4J SoapUI XPath de 41