Automatización de pruebas sobre una API: Postman, Newman y Jenkins

¿Qué es la automatización de pruebas?

La automatización de pruebas consiste en utilizar un programa para controlar la ejecución de pruebas y comprobar si los resultados obtenidos son los que estábamos esperando. Para explicar cómo conseguir la automatización de pruebas sobre una API se van a necesitar tres programas: Postman, Newman y Jenkins.

Postman

El primer programa que vamos a utilizar para conseguir la automatización de pruebas es Postman que se puede definir de la siguiente manera:

“El objetivo principal de Postman es ayudar a construir APIs rápidamente permitiendo la ágil creación de peticiones y flujos de trabajo mediante colecciones”

Entorno

Lo primero que tenemos que hacer antes de empezar a crear tests es preparar un entorno para el servidor en el que se van a ejecutar los tests. Para crear un entorno nos dirigimos a Manage environments → Add. Entonces podremos empezar a añadir pares clave-valor correspondientes a variables que utilizaremos en múltiples ocasiones en las peticiones.

Como ejemplo, he elegido la siguiente API para explicar cómo funciona: swapi.co/api, así que vamos a guardarla en una variable a la que llamaremos host:

Esta API no necesita que el usuario se autentifique, pero si lo necesitase podríamos guardar el usuario y la contraseña en el entorno.

Colección

Postman permite crear colecciones para almacenar las peticiones, por lo que lo primero que necesitamos es crear una colección, proporcionando su nombre (obligatorio) y una descripción.

Entonces podremos crear una petición, que tendrá más o menos el siguiente aspecto:

En este ejemplo intentamos conseguir una lista de naves espaciales, por lo que en la captura de pantalla se puede observar:

  1. Nombre de la petición.
  2. Método: Puede ser GET, POST, PUT, DELETE…
  3. API: La dirección completa sería swapi.co/api/starships, pero como ya guardamos swapi.co/api en la variable de entorno host solo tenemos que escribir {{host}} para usarla.
  4. Entorno.

La segunda parte de la creación de una petición es la sección Tests, pensada para crear asserts que verifiquen que la información que devuelve el servidor es la que estábamos esperando y también se pueden asignar valores a nuevas variables de entorno o globales para usar más adelante. Por ejemplo:

En este test tenemos un assert que comprueba que el código de estado es un 200 y además, un bucle para almacenar en una variable de entorno información sobre una determinada nave de todas las devueltas. En la parte derecha tenemos una serie de trozos de código que ayudan al usuario en la creación de tests.

El siguiente paso sería guardar la petición pulsando el botón “Save” y elegir dónde guardarla. Tenemos la opción de guardarla directamente en la colección:

O en una carpeta. Almacenarlas en carpetas tiene la ventaja de poder aislar su ejecución del resto de peticiones.

Ejecución de Tests

Para ejecutar la petición creada primero habrá que guardarla (¡Importante!) y después enviarla pulsando en “Send”. De la respuesta nos interesa dos partes: Body, donde vemos el json devuelto por el servidor con toda la información y Tests, donde se verá el resultado de los asserts.

En este caso uno de los 2 tests falló porque se especificó en los tests que se esperaba recibir más de 100 naves y si observamos la información recibida hay menos.

Una vez tenemos todas las peticiones que queremos junto con sus tests se pueden ejecutar en conjunto. Para eso necesitamos abrir el “Collection Runner”:

Para ejecutar los tests debemos seguir los siguientes pasos:

  1. Elegir entre ejecutar la colección entera o sólo una carpeta.
  2. Elegir el entorno donde tenemos almacenadas las variables.
  3. Número de veces que queremos ejecutar los tests.
  4. Start Test (Iniciar Test)

Una vez finaliza la ejecución se pueden ver los resultado en la parte derecha de la pantalla. Arriba del todo aparecerá un resumen en el que se puede ver cuántos tests fallaron, cuántos no y cuánto tardaron en ejecutarse. Debajo aparecerá lo mismo, pero para cada petición realizada.

Newman

Postman tiene una Versión de Línea de Comandos llamada Newman que tiene muchas utilidades pero sólo necesitamos una: Permite la integración de las colecciones creadas en Postman con un sistema de integración continua como Jenkins, que es un paso clave para conseguir la automatización de pruebas.

Instalar Newman es muy fácil:

npm install -g newman

Antes de empezar a ejecutar el test primero debemos exportar el entorno desde Postman .

Y la colección:

Así guardaremos un json del entorno y otro de la colección en una carpeta, a la que tendremos que dirigirnos desde una consola de comandos para poder ejecutar Newman.

Ahora, podemos elegir entre ejecutar la colección completa:

newman -c collection.json -e environment.json

O solo una carpeta (añadiendo el argumento -f):

newman -c collection.json -e environment.json -f Planets

La salida devuelve casi lo mismo que devolvía la de Postman: La ejecución de cada petición y un resumen indicando cuántos tests fallaron y cuántos no.

Jenkins

El último paso para completar la automatización de pruebas sobre la API elegida es instalar Newman en el mismo servidor en el que está Jenkins e instalar unos plugins:

  • Log Parser Plugin: Para analizar sintácticamente la salida.
    • Configuración:
      • Description: Error parsing.
      • Parsing Rules File: Archivo con las reglas y con el siguiente contenido:
error /✗/

Una vez tenemos los plugins instalados y configurados creamos un nuevo trabajo (New job) con la siguiente información:

Nombre del proyecto: Star Wars (por ejemplo)

Build → Add build step → Execute Shell y escribimos la misma series de comandos qui escribíamos para ejecutar Newman en local:

newman -c path/collection.json -e path/environment.json -f Starships

Post-build Actions → Add post-build action → Console Output (build log) parsing

Y en Select Parsing Rules seleccionamos “Error Parsing” (Descripción)

Post-build Actions → Add post-build action → Editable Email Notification

Y rellenamos la siguiente información:

  • Project Recipient List: Direcciones de correo que deben recibir el email.
  • Advanced Settings → Add Trigger → Script – After Build
    • Trigger Script:
//solo mandará un email si encuentra ✗ en los logs
build.logFile.text.readLines().any { it =~ /.*✗.*/ }

Guardar (Save) y Construir (Build now)…

La consola de salida mostrará lo mismo que cuando ejecutamos Newman en local junto con algunas líneas que indican que Jenkins ha hecho sus comprobaciones.

Test Automation. Automatización de pruebas. Jenkins. Test output

He ejecutado a propósito la carpeta “Starships” porque sé que un test va a fallar y así provocar que envíe un email. El email recibido será:

Test Automation. Automatización de pruebas. Jenkins. Email sent

En él podemos observar que el asunto indica que algo no fue bien (Something went wrong…) y en el cuerpo del mensaje que Jenkins ejecutó el trabajo correctamente y un enlace a la salida de la ejecución para ver los resultados.

Una vez estamos en la consola de salida del trabajo podemos acceder a “Parsed Console Output” para ver subrayadas en rojo las líneas en las que aparecen los tests que fallaron.

Conseguir automatización de pruebas sobre cualquier API es tan fácil como seguir los pasos indicados en este post, solo necesitamos configurar tres programas y no tendremos que preocuparnos de nada más. Ya se encargará Jenkins de mandarnos un correo si falló algún test 🙂

 

Otros artículos relacionados

Introducción a la automatización de casos de prueba

JMeter, un viejo amigo en plena forma

Experiencias con el curso y exámen ISTQB Foundation Level. ¿Merece la pena sólo por el certificado?

4 comentarios en «Automatización de pruebas sobre una API: Postman, Newman y Jenkins»

  1. muy buen post no sabia que perdia mucho potencial de postman solo ocupaba para pruebas unitarias, ¿de pueden hacer pruebas de alta concurrencia con postman?

    Responder

Deja un comentario

¿Necesitas una estimación?

Calcula ahora