SoapUI - Guía rápida

SOAP es el acrónimo de Protocolo simple de acceso a objetos. Está definido por World Wide Web Consortium (W3C) enhttps://www.w3.org/TR/2000/NOTE-SOAP-20000508 como sigue -

SOAP es un protocolo ligero para el intercambio de información en un entorno distribuido y descentralizado. Es un protocolo basado en XML que consta de tres partes: un sobre que define un marco para describir lo que hay en un mensaje y cómo procesarlo; un conjunto de reglas de codificación para expresar instancias de tipos de datos definidos por la aplicación; y una convención para representar llamadas y respuestas a procedimientos remotos.

SOAP - Funciones importantes

A continuación se muestran algunas características importantes de SOAP.

  • Es un protocolo de comunicación diseñado para comunicarse a través de Internet.

  • Puede extender HTTP para mensajería XML.

  • Proporciona transporte de datos para servicios web.

  • Puede intercambiar documentos completos o llamar a un procedimiento remoto.

  • Puede usarse para transmitir un mensaje.

  • Es independiente de la plataforma y del idioma.

  • Es la forma XML de definir qué información se envía y cómo.

  • Permite que las aplicaciones cliente se conecten fácilmente a servicios remotos e invoquen métodos remotos.

Aunque SOAP se puede utilizar en una variedad de sistemas de mensajería y se puede entregar a través de una variedad de protocolos de transporte, el enfoque inicial de SOAP son las llamadas a procedimientos remotos transportadas a través de HTTP. Otros marcos como CORBA, DCOM y Java RMI proporcionan una funcionalidad similar a SOAP, pero los mensajes SOAP están escritos completamente en XML y, por lo tanto, son exclusivamente independientes de la plataforma y el lenguaje.

Un mensaje SOAP es un documento XML ordinario que contiene los siguientes elementos:

  • Envelope- Define el inicio y el final del mensaje. Es un elemento obligatorio.

  • Header- Contiene cualquier atributo opcional del mensaje utilizado para procesar el mensaje, ya sea en un punto intermedio o en el punto final último. Es un elemento opcional.

  • Body- Contiene los datos XML que componen el mensaje que se envía. Es un elemento obligatorio.

  • Fault - Un elemento de falla opcional que proporciona información sobre los errores que ocurren durante el procesamiento del mensaje.

Todos estos elementos se declaran en el espacio de nombres predeterminado para el sobre SOAP:

https://www.w3.org/2001/12/soap-envelope

El espacio de nombres predeterminado para la codificación SOAP y los tipos de datos es:

https://www.w3.org/2001/12/soap-encoding

Note- Todas estas especificaciones están sujetas a cambios. Por lo tanto, continúe actualizándose con las últimas especificaciones disponibles en el sitio web de W3.

SOAP - Estructura del mensaje

El siguiente bloque describe la estructura general de un mensaje SOAP:

<?xml version = "1.0"?> 
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">  
   <SOAP-ENV:Header> 
      ... 
      ... 
   </SOAP-ENV:Header>  
   <SOAP-ENV:Body> 
      ... 
      ... 
      <SOAP-ENV:Fault> 
         ... 
         ... 
      </SOAP-ENV:Fault>  
   </SOAP-ENV:Body>  
</SOAP_ENV:Envelope>

REST es el acrónimo de Representational State Transfer. Se puede definir como un estilo arquitectónico de diseño de software. REST no es una especificación ni un estándar W3C. Por lo tanto, es más fácil trabajar con RESTful Services. No requiere ningún marco de especificación de middleware.

REST - Funciones importantes

A continuación se muestran algunas características importantes de REST.

  • Se basa en un protocolo de comunicación sin estado, cliente-servidor y almacenable en caché; prácticamente en todos los casos, se utiliza HTTP.

  • Es una alternativa ligera de WebService y RPC (llamada a procedimiento remoto) como SOAP-WSDL.

  • Representa todo en ID únicos o URI.

  • Hace el uso de métodos HTTP estándar, como GET, POST, PUT, DELETE.

  • Vincula las fuentes.

  • Los recursos REST pueden tener múltiples representaciones.

  • Cualquier información nombrada se considera un recurso. Por ejemplo: una imagen, una persona, un documento, todo puede considerarse como un ejemplo de recurso y representarse como un ID único o un URI.

  • La propia World Wide Web, basada en HTTP, puede verse como una arquitectura basada en REST.

Los servicios REST son independientes de la plataforma y el idioma. Dado que se basa en estándares HTTP, puede funcionar fácilmente en presencia de cortafuegos. Al igual que los servicios web, REST no ofrece seguridad incorporada, gestión de sesiones, garantía de QoS, pero se pueden agregar construyendo sobre HTTP. Para el cifrado, se puede utilizar REST además de HTTPS.

SoapUI es una herramienta que se puede utilizar tanto para pruebas funcionales como no funcionales. No se limita a los servicios web, aunque es la herramienta de facto utilizada en las pruebas de servicios web.

SoapUI - Funciones importantes

A continuación se muestran algunas características importantes de SoapUI.

  • Es capaz de desempeñar el papel de cliente y servicio.

  • Permite a los usuarios crear pruebas funcionales y no funcionales de forma rápida y eficiente utilizando un único entorno.

  • Tiene licencia según los términos de la Licencia pública general GNU Leaser (LGPL).

  • Se implementa puramente mediante la plataforma JAVA.

  • Es compatible con Windows, Mac y varios dialectos de Linux.

  • Permite a los evaluadores ejecutar pruebas funcionales, de regresión, de cumplimiento y de carga automatizadas en diferentes API web.

  • Es compatible con todos los protocolos y tecnologías estándar para probar todo tipo de API.

SoapUI se puede utilizar para probar la API RESTful completa y las pruebas del servicio web SOAP. Es compatible con pruebas funcionales, pruebas de rendimiento, pruebas de interoperabilidad, pruebas de regresión, pruebas de carga y mucho más.

Es fácil de usar y también es fácil convertir pruebas funcionales en pruebas no funcionales, como pruebas de carga y estrés.

SoapUI es rico en los siguientes cinco aspectos:

  • Pruebas funcionales
  • Pruebas de seguridad
  • Prueba de carga
  • Protocolos y tecnologías
  • Integración con otras herramientas

Aprendamos más sobre cada una de estas capacidades.

Pruebas funcionales

  • SoapUI permite a los probadores escribir pruebas API funcionales en SoapUI.

  • SoapUI admite la función de arrastrar y soltar que acelera el desarrollo del script.

  • SoapUI admite la depuración de pruebas y permite a los evaluadores desarrollar pruebas basadas en datos.

  • SoapUI admite múltiples entornos, lo que facilita el cambio entre entornos QA, Dev y Prod.

  • SoapUI permite la creación de scripts avanzados (el evaluador puede desarrollar su código personalizado según los escenarios).

Pruebas de seguridad

  • SoapUI realiza un conjunto completo de análisis de vulnerabilidades.

  • SoapUI evita la inyección de SQL para proteger las bases de datos.

  • SoapUI escanea en busca de desbordamientos de pila, causados ​​por documentos de gran tamaño.

  • SoapUI busca secuencias de comandos entre sitios, que se producen cuando los parámetros del servicio se exponen en los mensajes.

  • SoapUI realiza escaneo de fuzzing y escaneo de límites para evitar un comportamiento errático de los servicios.

Prueba de carga

  • SoapUI distribuye las pruebas de carga entre n números de agentes LoadUI.

  • SoapUI simula pruebas de carga de alto volumen y del mundo real con facilidad.

  • SoapUI permite informes personalizados avanzados para capturar parámetros de rendimiento.

  • SoapUI permite la supervisión del rendimiento del sistema de un extremo a otro.

Protocolos y tecnologías

SoapUI admite una amplia gama de protocolos:

  • SOAP - Protocolo simple de acceso a objetos
  • WSDL: lenguaje de definición de servicios web
  • REST - Transferencia de estado representacional
  • HTTP - Protocolo de transmisión de hipertexto
  • HTTPS: protocolo de transmisión de hipertexto protegido
  • AMF - Formato de mensaje de acción
  • JDBC: conectividad de base de datos Java
  • JMS: servicio de mensajería Java

Integración con otras herramientas

  • Proyecto Apache Maven
  • HUDSON
  • JUnit
  • Apache - Ant y más….

SoapUI es una herramienta de versión gratuita de código abierto con características básicas de prueba, mientras que SoapUI NG Pro es una herramienta comercializada que tiene características avanzadas de informes, funcionalidad basada en datos y mucho más.

Comparación

La siguiente tabla compara y contrasta las diversas características de SoapUI y SoapUI NG Pro.

Caracteristicas SoapUI SoapUI NG Pro
Supported Technologies
JABÓN si si
WSDL / WADL si si
DESCANSO si si
JMS si si
AMF si si
JDBC si si
HTTP si si
General Features
Aplicación independiente si si
Soporte para múltiples entornos No si
Licencia flotante No si
Cobertura WSDL No si
Cobertura de solicitud / respuesta No si
Aserción de mensaje si si
Prueba de refactorización No si
Ejecutando múltiples pruebas si si
Prueba basada en fuentes de datos No si
Bibliotecas de secuencias de comandos No si
Informe de unidad No si
Pasos de prueba manual si si
Reporting
Informes de Junit No si
Exportación de datos de informes No si
Informe HTML WSDL si si
Cobertura de la suite de pruebas No si
Cobertura de casos de prueba No si
Cobertura de afirmación No si
Cobertura de grabación de mensajes No si

SoapUI es una herramienta multiplataforma. Es compatible con los sistemas operativos Windows, Linux y Mac.

Prerrequisitos

  • Processor - Procesador de 1 GHz o superior de 32 o 64 bits.

  • RAM - 512 MB de RAM.

  • Hard Disk Space - Mínimo 200 MB de espacio en el disco duro para la instalación.

  • Operating System Version - Windows XP o posterior, MAC OS 10.4 o posterior.

  • JAVA - JAVA 6 o posterior.

Proceso de descarga

Step 1- Vaya a www.soapui.org y haga clic en Descargar SoapUI.

Step 2- Haga clic en 'Obtenerlo' para descargar SoapUI Open Source. Comenzará a descargar el archivo .exe de 112 MB en el sistema. Espere hasta que se complete el proceso de descarga.

Proceso de instalación

Step 1 - Después de la descarga, ejecute el archivo .exe como "Ejecutar como administrador".

Windows iniciará el proceso de configuración como se muestra en la siguiente captura de pantalla.

Step 2 - Una vez configurado, la ventana del proceso muestra la siguiente pantalla, haga clic en Siguiente.

Step 3 - Acepte el contrato de licencia y haga clic en Siguiente.

Step 4- Elija el directorio de instalación o manténgalo como la ruta predeterminada seleccionada por el sistema. Haga clic en Siguiente.

Step 5- Elija los componentes que desea instalar. Haga clic en Siguiente.

Step 6 - Acepte el Acuerdo de licencia para HermesJMS y haga clic en Siguiente.

Step 7 - Seleccione el directorio de destino para guardar los tutoriales y haga clic en Siguiente.

Step 8 - Elija la ubicación de la carpeta del menú de inicio o deje la ubicación predeterminada como está y haga clic en 'Siguiente'.

Step 9 - Active la casilla de verificación 'crear un icono de escritorio' y haga clic en 'Siguiente'.

Ahora comienza la instalación. Tardará unos minutos en completarse.

Step 10 - Una vez completada la instalación, haga clic en Finalizar en el siguiente asistente.

Al hacer clic en Finalizar, se inicia SoapUI.

  • Barra de menús
  • Barra de herramientas
  • Barra de navegación del proyecto
  • Propiedades del espacio de trabajo
  • Panel de registro

Proceso de configuración

El primer paso es crear un espacio de trabajo que pueda contener varios proyectos.

Step 1 - Vaya a Archivo → Nuevo espacio de trabajo.

Step 2 - Agregue el nombre del espacio de trabajo y haga clic en Aceptar.

Step 3 - Ahora, seleccione la ruta donde se guardará el xml del espacio de trabajo.

Step 4 - Seleccione la ruta y haga clic en Guardar.

El espacio de trabajo se crea como se muestra en la siguiente captura de pantalla. También se muestran las propiedades del espacio de trabajo.

WSDL son las siglas de Web Services Description Language. Es un formato estándar para describir un servicio web. WSDL fue desarrollado conjuntamente por Microsoft e IBM. WSDL se pronuncia como 'wiz-dull' y se deletrea como 'WSD-L'.

WSDL ─ Una breve historia

WSDL 1.1 fue presentado como una nota del W3C por Ariba, IBM y Microsoft para describir los servicios para la actividad XML del W3C en protocolos XML en marzo de 2001.

WSDL 1.1 no ha sido respaldado por el World Wide Web Consortium (W3C), sin embargo, acaba de publicar un borrador para la versión 2.0 que será una recomendación (un estándar oficial) y, por lo tanto, respaldado por el W3C.

WSDL ─ Puntos a tener en cuenta

WSDL es un protocolo basado en XML para el intercambio de información en un entorno descentralizado y distribuido. Algunas de las otras características de WSDL son las siguientes:

  • Las definiciones de WSDL describen cómo acceder a un servicio web y qué operaciones realizará.

  • Es un lenguaje para describir cómo interactuar con servicios basados ​​en XML.

  • Es una parte integral de Universal Description, Discovery and Integration (UDDI), un registro de empresas mundial basado en XML.

  • WSDL es el lenguaje que usa UDDI.

Uso de WSDL

WSDL se utiliza a menudo en combinación con SOAP y XML Schema para proporcionar servicios web a través de Internet. Un programa cliente que se conecta a un servicio web puede leer el WSDL para determinar qué funciones están disponibles en el servidor. Todos los tipos de datos especiales utilizados se incrustan en el archivo WSDL en forma de esquema XML. A continuación, el cliente puede utilizar SOAP para llamar a una de las funciones enumeradas en el WSDL.

Entendiendo WSDL

WSDL divide los servicios web en tres elementos identificables específicos que pueden combinarse o reutilizarse una vez definidos.

Los tres elementos principales de WSDL que se pueden definir por separado son:

  • Types
  • Operations
  • Binding

Un documento WSDL tiene varios elementos, pero están contenidos dentro de estos tres elementos principales, que se pueden desarrollar como documentos separados y luego se pueden combinar o reutilizar para formar archivos WSDL completos.

En este tutorial, seguimos CurrencyConverter WSDL: http://www.webservicex.net

Formato y elementos

CurrencyConverter WSDL tendrá el siguiente aspecto:

WSDL ─ Tipo de puerto

El elemento <portType> combina varios elementos de mensaje para formar una operación completa de ida o de ida y vuelta. Por ejemplo, un <portType> puede combinar una solicitud y un mensaje de respuesta en una sola operación de solicitud / respuesta. Esto se usa más comúnmente en los servicios SOAP. Un portType puede definir varias operaciones.

Ejemplo

  • El elemento portType define una sola operación, llamada ConversionRate.
  • La operación consta de un único mensaje de entrada ConversionRateHttpPostIn.
  • La operación para el mensaje de salida es ConversionRateHttpPostOut.

Patrones de funcionamiento

WSDL admite cuatro patrones básicos de funcionamiento:

Un camino

El servicio recibe un mensaje. Por tanto, la operación tiene un único elemento de entrada. La gramática para la operación unidireccional es:

<wsdl:definitions .... >  
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Solicitud ─ Respuesta

El servicio recibe un mensaje y envía una respuesta. Por tanto, la operación tiene un elemento de entrada, seguido de un elemento de salida. Para encapsular errores, también se puede especificar un elemento de falla opcional. La gramática para una operación de solicitud-respuesta es:

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Solicitar ─ Respuesta

El servicio envía un mensaje y recibe una respuesta. Por tanto, la operación tiene un elemento de salida, seguido de un elemento de entrada. Para encapsular errores, también se puede especificar un elemento de falla opcional. La gramática para una operación de solicitud-respuesta es:

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Notificaciones

El servicio envía un mensaje. Por tanto, la operación tiene un único elemento de salida. A continuación se muestra la gramática para una operación de notificación:

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

WSDL ─ Enlace y servicio

los <binding>El elemento proporciona detalles específicos sobre cómo se transmitirá realmente una operación portType a través del cable.

  • Los enlaces pueden estar disponibles a través de varios transportes, incluidos HTTP GET, HTTP POST o SOAP.

  • Los enlaces proporcionan información concreta sobre qué protocolo se está utilizando para transferir operaciones portType.

  • Los enlaces proporcionan información sobre la ubicación del servicio.

  • Para el protocolo SOAP, el enlace es <soap: binding> y el transporte son mensajes SOAP sobre el protocolo HTTP.

  • Puede especificar varios enlaces para un solo portType.

Servicio

los <service>El elemento define los puertos admitidos por el servicio web. Para cada uno de los protocolos admitidos, hay un elemento de puerto. El elemento de servicio es una colección de puertos.

Los clientes de servicios web pueden aprender lo siguiente del elemento de servicio:

  • Dónde acceder al servicio,
  • A través de qué puerto acceder al servicio web, y
  • Cómo se definen los mensajes de comunicación.

El elemento de servicio incluye un elemento de documentación para proporcionar documentación legible por humanos.

<wsdl:service name = "CurrencyConvertor">
   <wsdl:port name = "CurrencyConvertorSoap" binding = "tns:CurrencyConvertorSoap">
      <soap:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorSoap12"binding = "tns:CurrencyConvertorSoap12>
      <soap12:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorHttpGet" binding = "tns:CurrencyConvertorHttpGet">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:portname = "CurrencyConvertorHttpPost"binding = "tns:CurrencyConvertorHttpPost">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port> 
</wsdl:service>

El proyecto SoapUI es el punto central en todas las pruebas de SoapUI. Una vez que se crea el proyecto, el usuario puede crear y ejecutar pruebas funcionales, cargar pruebas, crear servicios simulados y mucho más.

En este capítulo, discutiremos dos cosas: cómo:

  • Crea un proyecto SOAP
  • Agregar un WSDL

Crear un proyecto SOAP

Step 1 - En el navegador del lado izquierdo de la pantalla, haga clic con el botón derecho en "Proyecto" y seleccione "Nuevo proyecto SOAP".

O vaya a Archivo y seleccione Nuevo proyecto de jabón.

En la selección, se abre una nueva ventana emergente: Nuevo proyecto de jabón.

Step 2 - Project Name: Introduzca un nombre de proyecto; es el campo de entrada del usuario. Initial WSDL: No es obligatorio. Depende del usuario. El usuario puede proporcionar WSDL o agregar después de la creación del proyecto.

En este caso, creamos un proyecto y luego agregamos el WSDL.

Step 3- Haga clic en Aceptar. Creará un nuevo proyecto y será visible en el panel de navegación del lado izquierdo.

Agregar un WSDL

Los proyectos SOAP se basan en WSDL. No es necesario comenzar importando un WSDL, pero facilita las pruebas, ya que WSDL contiene toda la información necesaria para probar un servicio web, como información sobre las solicitudes y respuestas, lo que contienen y mucho más, lo que simplifica las pruebas de SoapUI.

Step 1 - Para agregar un WSDL, haga clic con el botón derecho en el nombre del proyecto (SOAP - Ejemplo) y seleccione Agregar WSDL.

Al seleccionarlo, se muestra el asistente WSDL.

Step 2 - WSDL Location: Introduzca un WSDL como http://www.webservicex.com o búsquelo desde la computadora.

Step 3- Tan pronto como se ingrese WSDL, se habilitarán 3 casillas de verificación: Crear solicitudes, Crear TestSuite, Crear MockServices. Según los requisitos, el usuario puede marcar una o varias casillas de verificación.

De forma predeterminada, la casilla de verificación Crear solicitudes está marcada.

Step 4- Haga clic en Aceptar. WSDL se ha agregado correctamente al proyecto. Puede verificarse observando el panel de navegación izquierdo. Dentro del proyecto, hay varias operaciones y las solicitudes se agregan de acuerdo con WSDL.

Vista de detalles

Para obtener más detalles del proyecto, haga doble clic en el nombre del proyecto, se abrirá una nueva ventana con varios detalles.

En la pestaña Descripción general, se proporciona diversa información como:

  • File Path - Muestra la ubicación del xml del proyecto guardado.

  • Interface Summary - Nombre de la interfaz y WSDL asociado.

  • Test Summary - Muestra suites de prueba, casos de prueba, pasos de prueba, afirmaciones agregadas al proyecto.

El usuario puede hacer doble clic en el nombre de la interfaz para obtener los detalles de la interfaz. Se abrirá una nueva ventana y mostrará la información relacionada con WSDL. Son muy útiles para navegar y examinar un WSDL.

En la pestaña Descripción general, enumera las definiciones de WSDL, las partes de definición y los detalles de la operación.

De manera similar, Service Endpoints enumera los detalles de los endpoints.

En la pestaña Contenido WSDL, todos los detalles de WSDL en formato XML / esquema se proporcionan como se muestra en la siguiente captura de pantalla.

TestSuitees una colección de casos de prueba que se puede utilizar para agrupar pruebas funcionales en unidades lógicas. Se puede crear cualquier número de TestSuites dentro de un proyecto SoapUI para soportar escenarios de prueba masivos.

Creación de TestSuite

Step 1 - Dentro de un proyecto, haga clic derecho en la interfaz (junto al nombre del proyecto) y luego haga clic en 'Generar TestSuite'.

Aquí, SOAP - Example es un nombre de proyecto, mientras que CurrencyConvertorSoap y CurrencyConvertorSoap12 son interfaces.

Step 2- Se abre un nuevo asistente. Seleccione las opciones según el requisito.

Step 3 - Una vez realizada la selección, haga clic en Aceptar.

Step 4- Marque la casilla de verificación de Generate LoadTest. Esto generará un LoadTest para cada TestCase creado en este TestSuite.

Step 5 - Ingrese el nombre de TestSuite en el nuevo asistente y luego haga clic en Aceptar.

El TestSuite creado se muestra en el panel de navegación como se muestra en la siguiente captura de pantalla.

Step 6- Haga doble clic en TestSuite Name y se abrirá la ventana TestSuite en el panel derecho. Dado que no se agregan TestCases, está en blanco.

Las propiedades de TestSuite se pueden ver en la parte inferior del Panel de navegación. Se pueden agregar nuevas propiedades personalizadas en el nivel de TestSuite.

Un TestCase es una colección de TestSteps ensamblados para probar algún aspecto específico de los servicios web. El usuario puede agregar un número n de TestCases a un TestSuite e incluso modularizarlos para que se llamen entre sí para escenarios de prueba complejos.

Creación de TestCase

Step 1- Dentro de TestSuite, el usuario puede agregar múltiples casos de prueba. Haga clic con el botón derecho en Test Suite y seleccione "Nuevo caso de prueba".

Step 2 - Ingrese el nombre del TestCase y haga clic en Aceptar.

El TestCase creado tiene cero pasos de prueba a partir de ahora. TestCase se agrega sin TestSteps para todo tipo de pruebas disponibles. Una vez que se agregan los TestSteps, los números en el corchete cambiarían automáticamente. El TestStep funcional debe ir a 'Pasos de prueba', mientras que un TestStep de rendimiento debe ir a 'Prueba de carga', y un TestStep de seguridad debe ir a 'Pruebas de seguridad'.

Step 3- Haga doble clic en TestCase Name y se abrirá una ventana TestCase en el panel lateral derecho. Dado que no se agregaron TestSteps, está en blanco como se ve en la siguiente captura de pantalla.

TestSteps son los "bloques de construcción" de las pruebas funcionales en SoapUI. Estos se agregan a un TestCase y se utilizan para controlar el flujo de ejecución y validar la funcionalidad de los servicios web que se probarán.

Inserción de TestStep

Step 1- Haga clic derecho en TestSteps. Agregar paso y seleccione un paso de prueba apropiado de la lista. Por ejemplo, si el usuario tiene que probar un servicio web REST, el usuario seleccionará la solicitud de prueba REST.

Step 2 - Agregue un TestStep para validar la solicitud SOAP importada seleccionando TestSteps → Agregar paso → Solicitud SOAP.

Step 3 - Ingrese el nombre del TestStep y haga clic en Aceptar en el asistente.

Al hacer clic en 'Aceptar', aparece un cuadro de diálogo para seleccionar la operación a invocar. Se enumeran todas las operaciones y los usuarios pueden seleccionar la operación que les gustaría invocar.

Hay dos operaciones que se enumerarán. Ambas operaciones son iguales excepto la versión de SOAP utilizada.CurrencyConvertorSoap usa SOAP versión 1.1 mientras que, CurrencyConvertorSoap12 utiliza SOAP versión 1.2.

Step 4 - Seleccione el primero - CurrencyConvertorSoap y haga clic en Aceptar.

Al agregar un TestCase, se pueden agregar diferentes aserciones estándar. Las afirmaciones también se denominan puntos de control / puntos de validación de la solicitud / respuesta SOAP.

Step 5 - Creemos un TestCase con una opción predeterminada que significa crear un TestStep SIN ninguno de los siguientes puntos de validación -

  • Verifica si el mensaje de respuesta es SOAP, al ejecutar la prueba.
  • Verifica si el esquema de respuesta es válido.
  • Verifica si la respuesta SOAP contiene FAULT.

Step 6 - Al hacer clic en Aceptar, aparece la siguiente captura de pantalla XML de solicitud.

El recuento de pasos de prueba ahora se incrementa a uno como un TestStep funcional agregado. De manera similar, al agregar TestSteps de carga y seguridad, el número correspondiente aumenta automáticamente según el número de pasos agregados.

Solicitar configuración

Aquí, realizaremos la conversión de la moneda de INR a USD.

  • FromCurrency - INR
  • ToCurrency - USD

A continuación, ingrese estas entradas en el lugar del signo de interrogación que se enviará como un XML de solicitud. Después de colocar esos valores en las etiquetas XML correspondientes, haga clic en el botón 'Enviar solicitud' para verificar la respuesta.

Respuesta

Al enviar una solicitud, el servidor web procesa la solicitud de servicio web y envía una respuesta como se muestra en la siguiente captura de pantalla.

Al leer la respuesta, se puede concluir que 1 unidad de INR = 0.0147 unidades de USD.

Solicitud HTTP

Los mensajes SOAP se transportan mediante el protocolo HTTP. Para ver la solicitud HTTP, haga clic en RAW en la ventana Solicitud de SoapUI (lado izquierdo).

La solicitud se publica en el servidor web. Por lo tanto, se utiliza el método POST de Http.

La solicitud SOAP se transporta en el cuerpo del mensaje http, que se muestra a continuación.

POST http://www.webservicex.com/currencyconvertor.asmx HTTP/1.1 
Accept-Encoding: gzip,deflate 
Content-Type: text/xml;charset = UTF-8 
SOAPAction: "http://www.webserviceX.NET/ConversionRate" 
Content-Length: 353 
Host: www.webservicex.com 
Connection: Keep-Alive 
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

Respuesta HTTP

Haga clic en la pestaña 'RAW' en la ventana de respuesta SOAP-UI para comprender cómo se envía la respuesta a través de HTTP.

Después de procesar la solicitud, se muestra el código de respuesta http (200), lo que significa que es un éxito. El servidor web lo ha procesado correctamente.

La respuesta SOAP se envía de vuelta al cliente como parte del cuerpo del mensaje HTTP.

HTTP/1.1 200 OK 
Cache-Control: private, max-age = 0 
Content-Type: text/xml; charset = utf-8 
Content-Encoding: gzip 
Vary: Accept-Encoding 
Server: Microsoft-IIS/7.0 
X-AspNet-Version: 4.0.30319 
X-Powered-By: ASP.NET 
Date: Sun, 22 Jan 2017 19:39:31 GMT 
Content-Length: 316

Los siguientes códigos HTTP se utilizan para enviar respuestas por parte del servidor web y son muy útiles para la depuración.

Código HTTP Descripción

1xx:

Informational - Esto significa que se recibió una solicitud y hay un proceso continuo.

2xx:

Success - La acción fue recibida, comprendida y aceptada con éxito.

3xx:

Redirection - Esto significa que se deben tomar más medidas para completar la solicitud.

4xx:

Client Error - Esto significa que la solicitud contiene una sintaxis incorrecta o no se puede cumplir.

5xx:

Server Error - El servidor no cumplió con una solicitud aparentemente válida.

Las propiedades son un aspecto central de las pruebas más avanzadas con SoapUI. Las propiedades de las pruebas funcionales se utilizan para parametrizar la ejecución y la funcionalidad de las pruebas.

  • Las propiedades se pueden utilizar para contener los puntos finales de los servicios, lo que facilita el cambio de los puntos finales reales utilizados durante la ejecución de la prueba.

  • Las propiedades se pueden utilizar para mantener las credenciales de autenticación, lo que facilita su administración en un lugar central o en un archivo externo.

  • Las propiedades se pueden usar para transferir y compartir identificadores de sesión durante la ejecución de la prueba, por lo que varios pasos de prueba o casos de prueba pueden compartir las mismas sesiones.

Definición de propiedades

Las propiedades se pueden definir en muchos niveles en un proyecto.

  • Las propiedades que son comunes a nivel de proyecto se pueden definir a nivel de proyecto.

  • Del mismo modo, las propiedades específicas de TestSuite y TestCase se pueden definir en sus respectivos niveles.

  • Las propiedades específicas del proyecto se definen en la pestaña Propiedades personalizadas.

Por ejemplo, una propiedad “ToCurrency” se puede definir a nivel de Proyecto haciendo clic en el símbolo "+" e ingresando el Nombre y Valor de la Propiedad.

Acceso a la propiedad

Se puede acceder a una propiedad en cualquier lugar del proyecto mediante la expansión de propiedad.

La estructura sería como -

  • $ {# Project # PropertyName}: para el nivel de proyecto

  • $ {# TestSuite # PropertyName}: para el nivel de Test Suite

  • $ {# TestCase # PropertyName}: para el nivel de caso de prueba

  • $ {TestStepName # PropertyName}: para el nivel de paso de prueba

  • $ {# MockService # PropertyName}: para la propiedad MockService

  • $ {# Global # PropertyName}: para propiedades globales, se encuentra en Archivo → Preferencia → pestaña Propiedades globales. Esta propiedad se puede utilizar en todos los proyectos.

  • $ {# System # PropertyName}: para la propiedad del sistema, que se encuentra en Ayuda → Propiedades del sistema

  • $ {# Env # PropertyName}: para la variable de entorno

La misma estructura se puede colocar en Request XML para obtener el valor de un atributo específico durante el tiempo de ejecución.

Una propiedad también se puede considerar como una variable en un programa de computadora. Si el usuario quiere definir algo que también se pueda usar en otro lugar, las Propiedades son muy útiles. Las propiedades también se pueden definir dinámicamente, pero dependen del script Groovy.

A veces existe el requisito de extraer algún valor de un mensaje de respuesta e incluirlo en las solicitudes posteriores. En tal caso, necesitamos tener un mecanismo para recuperar un valor especificado y transferirlo a los otros elementos del proyecto. SoapUI admite dicha funcionalidad a través de Property Transfer TestStep.

Agregar transferencia de propiedad

Step 1 - Seleccione TestCase o TestStep, haga clic derecho → Agregar pasos → Transferencia de propiedad.

Step 2 - Ingrese el nombre de TestStep y haga clic en Aceptar.

Step 3 - Se agrega el paso RateTransfer y se abrirá un nuevo asistente.

Step 4- Haga clic en el icono Agrega una nueva transferencia de propiedad + en la esquina superior izquierda de la ventana de transferencia de propiedad. Se le pedirá que ingrese un nombre para la transferencia. Ingrese Tasa y haga clic en Aceptar.

Transferencia de una propiedad

Una vez creada la transferencia, Source y Target panesEs necesario especificar las expresiones XPath relevantes para extraer y reemplazar los valores de propiedad. En el cuadro desplegable junto a Fuente, se enumeran varios niveles de proyectos de SoapUI que se pueden usar como fuente de transferencias de propiedad. De forma predeterminada, se mostrará el TestStep más cercano.

En este caso, es el Request – INR to USDTestStep. La lista desplegable junto a Propiedad muestra la propiedad de origen que se utiliza en la transferencia, que puede ser solicitud, respuesta o punto final de servicio.

Step 1- Seleccione Respuesta y vaya a Idioma de ruta. El usuario puede seleccionar XPath, Xquery o Jason para definir la propiedad. En este caso, seleccione XPath.

Step 2 - Para obtener la declaración del xml de origen, haga clic en ns y especifique XPath.

Step 3- Especifique el destino donde se transferirá el valor extraído de la expresión XPath anterior. El panel de destino se utiliza en la parte inferior de la ventana de transferencia de propiedad para eso.

Step 4 - Transferir el valor extraído de ConversionRateResult de la respuesta del paso RequestINRtoUSD.

Target - Propiedades

Property - ConversionRate (una nueva propiedad agregada, no tiene ningún valor inicialmente).

Step 5 - Una vez que el caso de prueba se ejecuta correctamente, la propiedad "ConversionRate" se actualiza en función de la respuesta.

A continuación se muestra la captura de pantalla inicialmente.

A continuación se muestra la captura de pantalla después de una ejecución exitosa.

De manera similar, Target puede ser un XML de solicitud siguiente. Si el destino es una solicitud SOAP, debemos proporcionar XPath para identificar el atributo de destino.

El panel de registros almacena la información completa sobre la transacción entre el cliente y el servidor. Los usuarios podrán ver las distintas pestañas del panel de registro. En este capítulo, analizaremos los paneles de registro más utilizados al trabajar con SoapUI.

Registro de SoapUI

El registro de SoapUI muestra la información de respuesta del servidor web. La misma información se almacena en el archivo soapui.log de la carpeta instalada de SOAP-UI en el directorio 'bin'.

Registro HTTP

El registro HTTP muestra toda la transferencia de paquetes HTTP. Toda la información en 'RAW' se muestra en el registro HTTP.

Registro de errores

El registro de errores muestra todos los errores encontrados durante toda la sesión del proyecto. La misma información está disponible en 'soapui-errors.log' presente en el directorio 'bin' de la ubicación de instalación de SoapUI.

Registro de memoria

Esta pestaña monitorea el consumo de memoria y lo muestra en forma de gráfico como se muestra en la siguiente captura de pantalla. Es realmente útil cuando se realiza una operación que requiere mucha memoria.

La afirmación se puede interpretar como un punto de control o un punto de validación. Una vez que se envía una solicitud a un servidor web, se recibe una respuesta. Se requiere validar la respuesta que contiene los datos como se esperaba o no. Para validar la respuesta, SoapUI tiene una función de afirmaciones.

Puntos a tener en cuenta

  • Las afirmaciones se utilizan para validar el mensaje recibido por un TestStep durante la ejecución.

  • Compara la parte del mensaje o el mensaje completo con algún valor esperado.

  • Se puede agregar cualquier número de afirmaciones a un TestStep, cada una validando algún aspecto y contenido diferente del mensaje de respuesta.

  • Después de que se ejecuta un TestStep, todas sus aserciones se aplican a la respuesta recibida y si alguna de ellas falla, TestStep se marca como fallado en la vista TestCase.

  • La entrada fallida se muestra en el registro de ejecución de la prueba.

Tipo de afirmaciones

SoapUI admite una amplia gama de afirmaciones en respuesta.

A continuación se muestra la lista de afirmaciones admitidas por SoapUI.

Afirmación Descripción
Property Content
Contiene Comprueba la existencia de la cadena especificada. También es compatible con la expresión regular.
No contiene Comprueba la inexistencia de la cadena especificada. También es compatible con la expresión regular.
Partido XPath Utiliza la expresión XPath para seleccionar el nodo de destino y sus valores. Compara el resultado de una expresión XPath con un valor esperado.
Coincidencia de XQuery Utiliza una expresión Xquery para seleccionar el contenido de la propiedad de destino. Compara el resultado de una expresión XQuery con un valor esperado.
Compliance, Status, Standards
HTTP DEScargar todos los recursos Descarga todos los recursos referidos a un documento HTML (imágenes, scripts, etc.) y valida que todos estén disponibles. Aplicable a cualquier propiedad que contenga HTML.
Códigos de estado HTTP no válidos Comprueba que el TestStep de destino recibió un resultado HTTP con un código de estado que no está en la lista de códigos definidos. Aplicable a cualquier TestStep que reciba mensajes HTTP.
No falla SOAP Valida que el último mensaje recibido no sea un fallo SOAP. Aplicable a SOAP TestSteps.
Cumplimiento del esquema Valida que el último mensaje recibido sea compatible con la definición de esquema WSDL o WADL asociada. Aplicable a los pasos de prueba SOAP y REST. La URL de definición de esquema admite expansiones de propiedades (por ejemplo, $ {# System # my.wsdl.endpoint} / services / PortType? Wsdl).
Fallo de SOAP Valida que el último mensaje recibido es un error SOAP. Aplicable a SOAP TestSteps Solicitud SOAP: valida que la última solicitud recibida sea una solicitud SOAP válida. Solo se aplica a los pasos de prueba de MockResponse.
Respuesta SOAP Valida que la última respuesta recibida sea una respuesta SOAP válida. Solo se aplica a los pasos de la solicitud de prueba de SOAP.
Códigos de estado HTTP válidos Comprueba que el TestStep de destino recibió un resultado HTTP con un código de estado en la lista de códigos definidos. Aplicable a cualquier TestStep que reciba mensajes HTTP.
Solicitud de direccionamiento WS Valida que la última solicitud recibida contiene encabezados de direccionamiento WS válidos. Solo se aplica a MockResponse TestSteps.
Respuesta de WS-Addressing Valida que la última respuesta recibida contiene encabezados de direccionamiento WS válidos. Solo se aplica a los pasos de la solicitud de prueba de SOAP.
Estado de WS-Security Valida que el último mensaje recibido contenía encabezados WS-Security válidos. Aplicable a los pasos de prueba de SOAP.
Script
Afirmación de script Permite a los usuarios ejecutar un script personalizado para realizar validaciones definidas por el usuario. Aplicable solo a TestSteps (es decir, no a propiedades)
SLA
SLA de respuesta Valida si el tiempo de respuesta de la última respuesta recibida estuvo dentro del límite definido. Aplicable a Script TestSteps y TestSteps que envían solicitudes y reciben respuestas.
JMS
Estado de JMS Valida que la solicitud JMS del TestStep de destino se ejecute correctamente. Aplicable para solicitar TestSteps con un punto final JMS.
Tiempo de espera JMS Valida que la sentencia JMS del TestStep de destino no tardó más que la duración especificada. Aplicable para solicitar TestSteps con un punto final JMS.
Security
Exposición a información sensible Verifica si el mensaje de respuesta no expone información confidencial sobre el sistema de destino. Podemos usar esta aserción para REST, SOAP y HTTP TestSteps.
JDBC
Estado de JDBC Valida que la solicitud JDBC del TestStep de destino se ejecutó correctamente. Solo se aplica a JDBC TestSteps.
Tiempo de espera de JDBC Valida que la declaración JDBC del TestStep de destino no tardó más que la duración especificada. Solo se aplica a JDBC TestSteps.

En SoapUI, los usuarios enfrentan muchos problemas comunes genéricos que podrían resolverse con un poco de alerta. Algunos de estos problemas más comunes son los siguientes:

Issue- El espacio de nombres está definido incorrectamente. Utilice el espacio de nombres correcto. El espacio de nombres debe ser la URL donde se encuentra el servicio web.

Solution - Si se produce un error al desarrollar una afirmación de scripting, use 'log.info' para imprimir el contenido de las variables.

Issue - Si se recibe un código de error como XML de respuesta, puede deberse a una entrada no válida.

Solution - Verificar la entrada de la solicitud XML.

Example - En el convertidor de moneda, si la entrada de 'FromCurrency' es '123' que no existe, la salida arroja un código de falla como 'SOAP-Client', lo que significa que el problema es con el parámetro que se está pasando desde el lado del cliente.

Solicitud

Respuesta

Issue - No hay coincidencia en la respuesta actual cuando se usa XPath o XQuery.

Solution -

  • Utilice la sintaxis correcta al definir XPath o XQuery.
  • Verifique que se utilicen dos puntos y no un punto al declarar el espacio de nombres.
  • Asegúrese de que XPath y XQuery sean correctos.

Las pruebas de rendimiento son uno de los puntos de control importantes más comunes en las pruebas de servicios web. La prueba de rendimiento se define como la creación o simulación artificial de la carga y la medición de cómo la maneja el entorno.

Esto significa que no es necesario que sea el rendimiento de un sistema bajo una carga alta, también puede ser el rendimiento de un sistema bajo carga base o carga esperada. Ni siquiera tiene que estar estructurado, automatizado o creado en TestWare como SoapUI; simplemente actualizar el navegador web una y otra vez muy rápido también es una prueba de carga.

Tipos de pruebas de rendimiento

Los siguientes son los tipos de pruebas de rendimiento:

  • Baseline Testing - Examina cómo funciona un sistema con una carga normal o esperada y crea una línea de base con la que se pueden comparar los otros tipos de pruebas.

  • Load Testing- Incluye aumentar la carga y ver cómo se comporta el sistema bajo mayor carga. Durante las pruebas de carga, el usuario puede monitorear los tiempos de respuesta, el rendimiento, la condición del servidor y mucho más. El objetivo de las pruebas de carga no es romper el entorno de destino.

  • Soak Testing - El objetivo de las pruebas es asegurarse de que no surja ningún comportamiento no deseado durante un período de tiempo más largo.

  • Scalability Testing- Las pruebas de escalabilidad se parecen mucho a las pruebas de carga, sin embargo, en lugar de aumentar el número de solicitudes, aumenta el tamaño o la complejidad de las solicitudes enviadas. Por ejemplo, enviar solicitudes grandes, archivos adjuntos grandes o solicitudes profundamente anidadas.

Aspectos clave del servicio web

Dos aspectos se destacan en las características únicas del desempeño del Servicio Web.

Primer aspecto

En el lado del servidor, el procesamiento XML / JSON está en marcha, tanto el análisis como la serialización de XML / JSON . Lo que a menudo falla primero es el procesamiento de las cargas útiles. Las razones del fracaso pueden ser múltiples; puede estar en la plataforma, las debilidades del servidor de aplicaciones o puede ser un problema de implementación en forma de WSDL innecesariamente complejos. También podría significar que el código está realizando una solicitud a una base de datos que tarda en responder.

Testing Aspect- La complejidad de analizar la carga útil XML / JSON significa que es necesario centrarse más en las pruebas de escalabilidad. También significa que los WSDL deben examinarse de cerca. Si las solicitudes y respuestas son complejas o más grandes, o si incluyen archivos adjuntos grandes, debe centrarse en enfatizar la complejidad y ver cómo se comporta bajo carga.

Segundo aspecto

Otro factor que se encuentra con frecuencia es la seguridad. Los sitios seguros detrás de HTTPS tienen un rendimiento considerablemente menor y en las pruebas de servicios web podemos agregar una capa de WSSecurity a la capa de seguridad HTTP, disminuyendo aún más el rendimiento.

Testing Aspect- El tema de los medios de seguridad, es necesario centrarse en realizar pruebas de solicitudes que sean seguras. Si todo el servicio web es seguro, significa que las pruebas de carga son más importantes, especialmente si se utiliza WS-Security y el manejo de tokens.

Load testinges una forma específica de prueba de rendimiento que se realiza para evaluar el comportamiento del sistema bajo una carga específica. En SoapUI, generalmente usamos el término "prueba de carga" para todos los tipos de pruebas no funcionales, sin embargo, SoapUI admite todo tipo de evaluaciones de rendimiento de servicios web como carga, estrés y resistencia.

Puntos a tener en cuenta

  • Las pruebas de carga son bastante únicas en SoapUI; un caso de prueba funcional que permite crear y modificar pruebas de rendimiento rápidamente.

  • El principal diferenciador es que las pruebas de rendimiento en SoapUI generalmente se crean a partir de las pruebas funcionales existentes. Esto permite crear rápidamente pruebas de rendimiento avanzadas.

  • El rendimiento del servicio web se puede validar en diferentes escenarios de carga. Mantenga las validaciones funcionales para asegurarse de que no se rompan bajo carga, ejecute varias pruebas de carga simultáneamente para ver cómo se afectan entre sí y mucho más.

Creación de prueba de carga

Step 1 - Haga clic con el botón derecho en Caso de prueba funcional y seleccione Nueva prueba de carga.

Step 2 - Introduzca el nombre de la prueba de carga y haga clic en Aceptar en el asistente de diálogo.

Load Test se abrirá y se creará Load Test como se muestra en la siguiente captura de pantalla.

Ejecución de prueba de carga

Cuando se crea una nueva prueba de carga, está preconfigurada para ejecutarse durante 60 segundos (arriba a la derecha) con 5 subprocesos utilizando la estrategia de carga simple.

Modifique estos valores según el requisito y Ejecute. Note - El usuario debe conocer la configuración y los conceptos de las pruebas de carga.

El usuario verá la tabla de estadísticas en el medio, comenzando con la recopilación de datos y después de 60 segundos debería haber terminado la prueba de carga.

Agregar una afirmación

Step 1 - En el editor LoadTest, seleccione la pestaña LoadTest Assertion en la parte inferior del editor.

Step 2 - Haga clic en el botón Add Assertion en la barra de menú LoadTest Assertion para agregar una aserción.

Step 3- Se abrirá el cuadro de diálogo Agregar afirmación. Seleccione Paso máximo. Seleccionar Máximo establece un tiempo máximo en milisegundos que las respuestas pueden tomar, si el tiempo excede lo que hemos establecido, la prueba fallará. Haga clic en Aceptar.

Step 4- Se abrirá la ventana TestStep Max Assertion. Como se ve en la siguiente captura de pantalla, permitimos una respuesta máxima de un segundo, 1000 milisegundos. No modifiquemos nada. Haga clic en Aceptar.

La aserción Step Maximum ahora se agregará correctamente.

Step 5- Ahora vuelva a ejecutar la prueba. Si las respuestas tardan demasiado, debería ver que los números en la columna de errores se suman rápidamente.

Un servicio web es una colección de protocolos y estándares abiertos que se utilizan para intercambiar datos entre aplicaciones o sistemas. Las aplicaciones de software escritas en varios lenguajes de programación y que se ejecutan en varias plataformas pueden utilizar servicios web para intercambiar datos a través de redes informáticas como Internet de una manera similar a la comunicación entre procesos en una sola computadora. Esta interoperabilidad (por ejemplo, entre Java y Python, o aplicaciones de Windows y Linux) se debe al uso de estándares abiertos.

Los servicios web basados ​​en la arquitectura REST se conocen como servicios web RESTful. Estos servicios web utilizan métodos HTTP para implementar el concepto de arquitectura REST. Un servicio web RESTful generalmente define un URI (Identificador uniforme de recursos), que es un servicio que proporciona representación de recursos como JSON y un conjunto de métodos HTTP.

Todas las capacidades de prueba REST de SoapUI se basan en una representación lógica conocida como servicio REST. No debemos confundir esto con el término "servicio" aquí, ya que no es una implementación de servicio sino un mapeo del servicio RESTful que se está invocando. Podemos agregar tantos servicios REST como podamos en un proyecto SoapUI. Cada uno representa un servicio RESTful particular. Son los siguientes:

SoapUI permite administrar el funcionamiento de la base de datos mediante un TestStep llamado JDBC Request.

Step 1 - Haga clic con el botón derecho en TestStep y seleccione Agregar paso → Solicitud JDBC.

Step 2 - Ingrese el nombre del paso y haga clic en Aceptar.

Se agrega el paso JDBC. Haga doble clic en el paso y se abrirá el asistente de JDBC.

Para crear una conexión JDBC, el usuario debe proporcionar un controlador y una cadena de conexión válidos. Estos parámetros se utilizan para identificar el tipo de base de datos y crear una conexión para utilizar la base de datos.

Para MySQL, el controlador de la base de datos puede ser com.mysql.jdbc.Driver. De manera similar, para otras bases de datos, hay un controlador predefinido que se puede encontrar en la sección de documentos de la base de datos.

Step 3 - La cadena de conexión debe tener el siguiente formato:

Jdbc:mysql://[host]:[port]/[database]?[property][=value]

Aquí, propiedad es el nombre de usuario y la contraseña junto con otros parámetros necesarios para conectarse con una base de datos.

Por ejemplo,

jdbc:mysql://localhost:8089/xxx_DB?user=root&password=root

Step 4- Haga clic en Probar conexión. En una conexión exitosa, mostrará SUCCESS; de lo contrario, proporcionará los detalles del error.

JDBC tiene su propia sección Agregar propiedad que se puede utilizar como variable en SQL Query.

Veamos cómo se comporta -

Supongamos que la Consulta SQL que debe realizarse en el paso JDBC es Seleccionar * de Moneda donde MonedaCode = 'xxx'.

En este escenario, CurrencyCode se puede cambiar según la entrada de la solicitud. Si el usuario proporciona un valor codificado de forma rígida, el paso de JDBC no se ejecutará para la moneda que se proporcionó en la solicitud.

Para superar estos escenarios, JDBC admite la propiedad de adición, donde se puede definir un Código de propiedad y seguirá cambiando mediante el Paso de transferencia de propiedad.

SQL Query se ejecutará en función del valor actual del Código de propiedad y SQL Query parametrizará el CurrencyCode =: Code.

Haga clic en Agregar propiedad + y el nombre como Código y proporcione un valor o déjelo en blanco para usar el paso de Transferencia de propiedad para proporcionarlo.

JDBC Request también puede hacer uso de la mayoría de las aserciones con TestSteps de solicitud SOAP. En SoapUI, la mayoría de estas afirmaciones son independientes de TestSteps. Por lo tanto, las aserciones como Contains y XPath Match se pueden usar con JDBC Request TestStep.

Al hacer clic en el Add an assertion en el menú superior de JDBC Request TestStep, el usuario puede averiguar qué afirmaciones son compatibles con TestStep.

Además de las aserciones genéricas, hay dos aserciones específicas de JDBC Request TestStep:

JDBC Timeout - Esta aserción se puede utilizar para verificar si la consulta SQL actual se ejecuta dentro del valor de propiedad de tiempo de espera de consulta especificado.

JDBC Status - Para verificar si la declaración SQL se ejecuta correctamente, podemos usar la aserción de estado JDBC.

Para configurar el tiempo de espera de la consulta, proporcione el valor correspondiente al tiempo de espera de la consulta de propiedad en el lado izquierdo de la pantalla. Tenga en cuenta que acepta valor en milisegundos (ms).