10 Trucos de SoapUI para principiantes (Parte I)

Compartir...Share on LinkedInEmail this to someoneShare on Google+Tweet about this on TwitterShare on FacebookPrint this page

10 Trucos de SoapUI para principiantesIntroducción

Así que has descargado e instalado SoapUI. Bien pensado. SoapUI es una extensa herramienta, sin embargo, a veces se necesita algo de tiempo para comprenderla en su totalidad. A continuación tienes 10 consejos muy básicos sobre el uso de SoapUI; seguirlas no te va a hacer un mejor tester, pero te harán un usuario de SoapUI más competente, y ese es un buen primer paso.

Por favor, ten en cuenta lo siguiente: Estos consejos son muy básicos. Se basan en algunos errores comunes que el principiante suele cometer, pero pueden parecer un poco simplistas para el usuario avanzado.

Empezaremos  con un principio importante en la forma de interactuar con SoapUI:

1) Haz clic con el botón derecho en todas partes

Este primer consejo puede parecer simple, pero ten en cuenta que queremos un inicio suave.

SoapUI es una herramienta muy profunda y, como tal, puede hacer muchas cosas. Por desgracia la mayoría de la gente nunca descubre todas las funciones disponibles en SoapUI, ya que sus menús no son todo lo intuitivos que podrían ser.

Así que, el consejo es, dondequiera que te encuentres en la interfaz de SoapUI, haz clic con el botón derecho en cualquier elemento con el que desees interactuar y mira lo que aparece, es posible que te sorprendas.

Este consejo es muy básico, pero una vez que te das cuenta de que SoapUI tiene que ver con hacer clic derecho, el trabajo con SoapUI será mucho más fácil.

Botón Derecho en SoapUI

2) Pon tus pruebas (tests) en un CasoDePruebas (TestCase)

Basándose en mejores prácticas, hay una cierta estructura que debe utilizarse a la hora de organizar las pruebas en SoapUI. El uso de esta estructura nos va a reportar ventajas según vayamos utilizando la herramienta.

Esta estructura no es muy difícil de usar, la mayoría de los testers organizan naturalmente sus pruebas en una estructura como esta. He aquí cómo funciona: Hay un grupo de pruebas, llamado TestSuites que contiene las pruebas reales, llamados casos de prueba. Un TestCase puede a su vez contener un número de pasos, llamado TestSTEPS. Eso es todo.

Organizacion en SoapUI

Si sigues la estructura TestStep, TestSuite, TestCase, tienes mucho que ganar. La reutilización de pruebas será más sencilla, así como clonar o copiar las pruebas. También es mucho más fácil ejecutar pruebas de carga en loadUI. La estructura no sólo tiene ventajas técnicas, sino que también hará las pruebas más fáciles para ti: Un proyecto de prueba bien estructurado hará la navegación más fácil, y te proporcionará una visión más clara de la cantidad de pruebas creadas y su finalidad.

¿Cómo pones la  petición (request) en un TestCase? Clic derecho (recuerda el punto 1) y selecciona Agregar a TestCase. Si ya tienes un TestCase al que deseas agregar a la petición, puedes arrastrarlo.

El siguiente consejo abordará cómo debes nombrar tus pruebas una vez que haya creado la estructura de la que hemos hablado en este punto.

3) ¿Qué hay en un nombre? Eso que llamamos Prueba

Ahora que hemos aprendido la importancia de utilizar una correcta estructura de pruebas en SoapUI  vamos a ver cómo se puede mejorar la legibilidad de prueba. Cuando se crea un nuevo TestCase, SoapUI ofrece un nombre fácil para ti, esto es muy útil e incluso una muy buena solución en algunos casos, pero no en todos los casos.

Dejar los nombres que SoapUI propone, como TestSuite 3 o TestCase 349, funciona bien cuando se tiene un número pequeño de pruebas. Pero, ¿recordarás dentro de 3 meses, o 3 años, lo que hacía el TestCase 349? O , ¿Sabrán tus compañeros del equipo de calidad con los que compartes el proyecto de SoapUI lo que hace el TestCase 349?

Es mejor dar un nombre que ayude a entender lo que hace la prueba, por ejemplo, ” TestSuite para validar los datos de clientes” o ” TestCase de pruebas de aumento de Descuentos”. Lo que sea, pero que sea un nombre descriptivo.

Esto hará la interacción con el proyecto mucho más fácil, especialmente si pones la misma atención en la forma de nombrar los TestSuites. La búsqueda de ” TestCase de pruebas de aumento de Descuentos ” es mucho más fácil si se encuentra en un TestSuite llamado ” TestSuite para de validación de descuentos”. Si consigues una nomenclatura clara en tu proyecto, será mucho más fácil recordarlo de nuevo después de no tocarlo durante un período de tiempo y también te ayudará a entender qué tipo de pruebas faltan.

Un buen consejo es utilizar una nomenclatura clara al nombrar los Items en tus proyectos.

Ahora que hemos visto cómo nombrar las pruebas, vamos a ver algunos consejos sobre la realización de las pruebas . Siguiente consejo es acerca de la necesidad de aserciones (validaciones).

4) ¿Validar o no validar? Esto nunca debería ser la cuestión.

Las pruebas en SoapUI tienen que ver con las validaciones. Sin ellas no se puede decir correctamente que has realizado una prueba. Las aserciones (validaciones) son una verificación de que la resuesta que recibes es la que esperabas . Por ejemplo , tengo un servicio web donde puedo buscar un producto por su productID . En la respuesta espero recibir el mismo productID en el campo denominado Identificación del producto. Si hago las pruebas manuales, primero  envío la solicitud y luego compruebo que el productID  en la respuesta. Esto es lo que llamamos la aserción o verificación. Como se puede ver, la verificación es una parte integral de las pruebas, y nos gustaría que que esto se convirtiera en un hábito en SoapUI . Un ejemplo de una verificación sería decir : “Si la respuesta contiene el nombre de la empresa eviware , el servicio que estoy probando parece funcionar ” .

Crear afirmaciones es sencillo en SoapU. Simplemente hay que ir a la pestaña Assertion en el Request /Response Editor.

Assertion SsoapUIHaremos click en el botón New Assertion y luego elegiremos el tipo de verificación que queremos. Al principio, podemos comenzar con una afirmación muy simple como la verificación Contains (Contiene), que comprueba toda la respuesta para verificar la existencia de un texto  en toda la respuesta. Después podemos empezar a utilizar la más exacta verificación XPath, en las que se verificará la existencia de un determinado texto en un elemento determinado en la respuesta. En el primer caso buscamos un determinado texto en la respuesta. En el segundo buscamos un determinado texto en un elemento concreto de la respuesta.

Ejemplo de Contains-Assertion

Ahora es el momento de pasar al siguiente nivel de SoapUI .

Una pregunta que frecuentemente recibimos de los usuarios nuevos son : ” ¿Cómo puedo tomar algo en la respuesta y lo uso en la próxima solicitud” ? O como se diría en SoapUI: ” ¿Cómo puedo transferir el contenido de un elemento de una respuesta y lo uso en un elemento en una solicitud posterior? ” . Todo será revelado en el siguiente consejo:

5) Aprende a transferir las propiedades

La segunda característica más usada en SoapUI después de las aserciones (verificaciones) es la Transferencia de Propiedades. Si esta práctica está tan extendida, debe ser que es útil pero, ¿para qué sirve? En los escenarios habituales de pruebas con SoapUI es probable que necesites recoger un valor en una respuesta (response) y moverlo a una petición (request); por ejemplo, recibes un identificador de sesión, sessionID en una respuesta después de un login, y debes usar ese identificador de sesión en las peticiones posteriores. Este es un escenario muy común, y la Transferencia de Propiedades te ayuda a conseguirlo.

La transferencia de propiedades se puede realizar de 2 maneras distintas. Los 2 métodos funcionan bien, cuál utilizar es una cuestión de gusto personal. Vamos a ver algunas capturas de pantalla del proyecto de ejemplo SoapUI para mostrar cómo funciona:

En el primer caso la transferencia de propiedades se hace en un paso dentro del TestCase utilizando expresiones XPath para seleccionar los valores y colocarlos , por ejemplo, en una petición posterior. También puedes guardar ese valor como una variable que utilizarás después.

Transferencia de propiedades mediante paso en un caso de test

Transferencia de propiedades mediante paso en un caso de test

La otra opción para transferir propiedades es utilizar el formato interno de SoapUI para hacer referencia a otras partes , por ejemplo, un elemento de una solicitud por SoapUI. En la petición en la que queramos utilizar un determinado valor, le diremos mediante el formato de soapui, de dónde tiene que obtenerlo.

Transferencia de propiedades con formato interno SoapUI

Transferencia de propiedades con formato interno SoapUI

Puedes leer más sobre la transferencia de propiedades en estos 2 artículos (ambos en inglés):  Transferring Property Values y Working with Properties.

Próximamente publicaremos un nuevo artículo con los 5 trucos restantes.

Este artículo está basado en el artículo 10 Tips for the SoapUI Beginner publicado en la web oficial de SoapUI.

11 comentarios

  • Sergio

    También hay una opción que a mí me parece interesante…, la opción es si el TestStep falla por los asserts puestos la ejecución continúe.

    http://stackoverflow.com/questions/16341547/continue-after-failed-assertion

    *También, en ocasiones es más cómodo insertar un step final tipo “Assert” antes que ir detallando cada assert dentro de los TestSetps y así agrupar todas las comprobaciones.

    http://www.soapui.org/Functional-Testing/assertion-test-step.html

  • Pingback: 10 Trucos de SoapUI para principiantes (Parte II)

  • Jose

    hola,

    Antes de todo muy interesante vuestra pagina.

    Como solucionarias esta situacion con Soapui.

    Tengo el siguiente problema:

    Request – createTicket (Este request devuelve un numero de ticket)
    Request – GetInfo (Header – Ticket number)
    Request – GetInfoList (Header – Ticket number)

    Tengo que conseguir pasar el parametro que devuelve el primer request (createTicket) a los siguientes request (GetInfo, GetInfoList). Estos dos request necesitan el numero de ticket pero en el header del mensaje post. Porque para que me funcionen los dos request es necesario que en el mensaje soap tenga en el header el ticket number.

    Muchas gracias

    • TesteandoSoftware

      Hola José,

      Lo primero muchas gracias por leernos. Respecto a tu pregunta, lo que necesitas hacer, en SoapUI se llama transferencia de propiedades. Se trata del quinto truco de esta serie, Aprende a transferir las propiedades, que puedes encontrar aqui: 10 Trucos de SoapUI para principiantes (Parte I)

      En el TestCase en el que estés trabajando tendrás que añadir un paso llamado Property Transfer. En este indicarás qué valor es el qué quieres extraer y en qué paso lo quieres utilizar. Tendrás que indicar que quieres obtener un valor de la Response de la Primera Request para utilizarlo posteriormente. Esta segunda parte puedes hacerla pasándolo directamente a la siguiente request, o bien almacenarlo como una Custom Property, al nivel en que la necesites.

      En el enlace anterior tienes otros 2 enlaces con más información.

      Un cordial saludo.

      TesteandoSoftware.com

  • Lalu

    Tengo duda respecto a saber si es posible probar la funcionalidad de sockets con seguridad desde SOAPUI??? espero puedan orientarme

  • Pingback: Herramientas pruebas software (I)

  • Andres

    Buenos d¡as, en primer lugar agradecerte por tu explicacion.

    Queria hacer pruebas enviando peticiones con diferente contenido, es decir, cada vez que se envie una peticion de prueba el contenido de la peticion la pueda cambiar, Asi, cuando el servicio web recibe las peticiones simultaneamente, las reciba con diferente contenido..

    ¿Esto es posible? o ¿hay alguna forma de simular la intencion que quiero hacer?

    Gracias

    • Testeando Software

      Hola Andrés,

      Gracias pro tu comentario. Si, claro que puedes hacerlo. Lo que tienes que hacer es, antes de enviar la petición, generar los campos que vas a enviar, de manera que cada vez sean distintos. Es decir, en la petición, no le pones los campos a mano, sino que le dices que lo coja de un valor que has generado previamente con groovy o javascript. En un paso antes de enviar la petición y los guardas como properties, y luego en la petición las recuperas con, por ejemplo, ${#TestSuite#property1} ${#TestSuite#property2}, si las has guardado a nivel de TestSuite.

      Un saludo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *