Tutorial de pruebas de API: una guía completa para principiantes

api testing tutorial

Este tutorial detallado de pruebas de API explica todo sobre las pruebas de API, los servicios web y cómo introducir las pruebas de API en su organización:

Obtenga una visión profunda de las pruebas de API junto con el concepto de pruebas de cambio a la izquierda y servicios web de este tutorial introductorio.

Conceptos como API web, cómo funciona la API (con ejemplos del mundo real) y en qué se diferencia de los servicios web se explican bien con ejemplos en este tutorial.

=>DESPLAZARSE HACIA ABAJOpara ver la lista completa de 5 tutoriales de pruebas de API en profundidad para principiantes

Lo que vas a aprender:

• Lista de tutoriales de pruebas de API
• Descripción general de los tutoriales de esta serie de pruebas de API
• Tutorial de pruebas de API
  • Prueba de desplazamiento a la izquierda
  • Ciclo de vida de desarrollo de software (SDLC) antes de la prueba de cambio a la izquierda
  • Fases de la prueba de cambio a la izquierda
  • API web
  • ¿Cómo funciona una API?
  • Servicios web
  • Servicios web vs API web
• Introducción a las pruebas de API en su organización
  • Cambio de enfoque a las pruebas de API
  • Espectro completo de pruebas de API
    • (i) Pruebas funcionales
    • (ii) Prueba de carga y rendimiento
    • (iii) Pruebas de seguridad
  • Cómo introducir las pruebas de API en su organización
  • Desafíos comunes y formas de mitigarlos
    • # 1) Elegir la herramienta adecuada
    • # 2) Especificaciones de prueba faltantes
    • # 3) Curva de aprendizaje
    • # 4) Conjunto de habilidades existente
  • Caso de estudio
• Conclusión
  • Lectura recomendada

Lista de tutoriales de pruebas de API

Tutorial #1: Tutorial de pruebas de API: una guía completa para principiantes
Tutorial #2: Tutorial de servicios web: componentes, arquitectura, tipos y ejemplos
Tutorial #3: Las 35 preguntas principales de la entrevista de ASP.Net y API web con respuestas
Tutorial #4: Tutorial POSTMAN: Pruebas de API con POSTMAN
Tutorial #5: Pruebas de servicios web con el cliente HTTP Apache

Descripción general de los tutoriales de esta serie de pruebas de API

Tutorial de pruebas de API

Esta sección lo ayudará a obtener una comprensión básica de los servicios web y la API web, lo que, a su vez, será útil para comprender los conceptos principales en los próximos tutoriales de esta serie de pruebas de API.

API (Application Programming Interface) es un conjunto de todos los procedimientos y funciones que nos permiten crear una aplicación accediendo a los datos o características del sistema operativo o plataformas. La prueba de dichos procedimientos se conoce como prueba API.

Prueba de desplazamiento a la izquierda

Uno de los tipos importantes de pruebas que se solicitan hoy en día en las entrevistas de prueba de API es Shift Left Testing. Este tipo de testing se practica en casi todos los proyectos que siguen una Metodología Agile.

Antes de que se introdujera Shift Left Testing, las pruebas de software entraban en escena solo después de que se completaba la codificación y se entregaba el código a los probadores. Esta práctica condujo al ajetreo de último minuto para cumplir con el plazo y también obstaculizó en gran medida la calidad del producto.

Aparte de eso, los esfuerzos realizados (cuando se informaron defectos en la última fase antes de la producción) fueron enormes ya que los desarrolladores tuvieron que pasar por la fase de diseño y codificación de nuevo.

Ciclo de vida de desarrollo de software (SDLC) antes de la prueba de cambio a la izquierda

El flujo de SDLC tradicional era: Requisito -> Diseño -> Codificación -> Pruebas.

Desventajas de las pruebas tradicionales

• Las pruebas están en el extremo derecho. Se incurre en muchos costos cuando se identifica un error en el último minuto.
• El tiempo invertido en resolver el error y volver a probarlo antes de promoverlo a producción es enorme.

Por lo tanto, surgió una nueva idea para cambiar la fase de prueba a la izquierda, lo que condujo a Shift Left Testing.

Lectura sugerida => Shift Left Testing: un mantra secreto para el éxito del software

Fases de la prueba de cambio a la izquierda

Las pruebas de cambio a la izquierda llevaron a una migración exitosa de la detección de defectos a la prevención de defectos. También ayudó al software a fallar rápidamente y corregir todas las fallas lo antes posible.

API web

En términos generales, una API web puede definirse como algo que lleva la solicitud de un sistema cliente a un servidor web y envía la respuesta desde un servidor web a una máquina cliente.

¿Cómo funciona una API?

Tomemos un escenario muy común de reservar un vuelo en www.makemytrip.com, que es un servicio de viajes en línea que agrega información de varias aerolíneas. Cuando realiza una reserva de vuelo, ingresa información como la fecha del viaje / fecha de regreso, clase, etc. y hace clic en buscar.

Esto le mostrará el precio de varias aerolíneas y su disponibilidad. En este caso, la aplicación interactúa con las API de varias aerolíneas y, por lo tanto, da acceso a los datos de la aerolínea.

Otro ejemplo es www.trivago.com que compara y enumera el precio, la disponibilidad, etc. de diferentes hoteles de una ciudad en particular. Este sitio web se comunica con las API de varios hoteles para acceder a la base de datos y enumera los precios y la disponibilidad de su sitio web.

Así, una Web API se puede definir como 'una interfaz que facilita la comunicación entre una máquina cliente y el servidor web'.

Servicios web

Los servicios web son (como la API web) los servicios que sirven de una máquina a otra. Pero la principal diferencia que surge entre la API y los servicios web es que los servicios web utilizan una red.

Es seguro decir que todos los servicios web son API web, pero no todas las API web son servicios web (se explica en la última parte del artículo). Por lo tanto, los servicios web son un subconjunto de la API web. Consulte el diagrama siguiente para obtener más información sobre la API web y los servicios web.

API web frente a servicios web

Servicios web vs API web

Tanto la API web como los servicios web se utilizan para facilitar la comunicación entre el cliente y el servidor. La principal diferencia viene solo en la forma en que se comunican.

Cada uno de ellos requiere un cuerpo de solicitud que sea aceptable en un idioma específico, sus diferencias para proporcionar una conexión segura, su velocidad para comunicarse con el servidor y responder al cliente, etc.

Las diferencias entre los servicios web y la API web se enumeran a continuación para su referencia.

Servicio web

• Los servicios web generalmente usan XML (lenguaje de marcado extensible), lo que significa que son más seguros.
• Los servicios web son más seguros ya que tanto los servicios web como las API proporcionan SSL (capa de conexión segura) durante la transmisión de datos, pero también proporcionan WSS (seguridad de servicios web).
• El servicio web es un subconjunto de la API web. Por ejemplo, Los servicios web se basan solo en tres estilos de uso, es decir, SOAP, REST y XML-RPC.
• Los servicios web siempre necesitan una red para funcionar.
• Los servicios web admiten 'aplicaciones diferentes de un código'. Esto significa que se escribe un código más genérico en diferentes aplicaciones.

API web

• Una API web generalmente usa JSON (notación de objetos JavaScript), lo que significa que la API web es más rápida.
• La API web es más rápida ya que JSON tiene un peso ligero, a diferencia de XML.
• Las API web son el superconjunto de servicios web. Por ejemplo, Los tres estilos de servicios web también están presentes en la API web, pero aparte de eso, utiliza otros estilos como JSON - RPC.
• La API web no requiere necesariamente una red para funcionar.
• La API web puede admitir o no la interoperabilidad según la naturaleza del sistema o la aplicación.

Introducción a las pruebas de API en su organización

En nuestro día a día, todos estamos tan acostumbrados a interactuar con las aplicaciones con API y, sin embargo, ni siquiera pensamos en los procesos de back-end que impulsan la funcionalidad subyacente.

Por ejemplo, Consideremos que está navegando por los productos en Amazon.com y ve un producto / oferta que realmente le gusta y desea compartirlo con su red de Facebook.

En el momento en que hace clic en el ícono de Facebook en la sección para compartir de la página e ingresa las credenciales de su cuenta de Facebook para compartir, está interactuando con una API que conecta sin problemas el sitio web de Amazon con Facebook.

Cambio de enfoque a las pruebas de API

Antes de discutir más sobre las pruebas de API, analicemos las razones por las cuales las aplicaciones basadas en API han ganado popularidad en los últimos tiempos.

Hay varias razones por las cuales las organizaciones están haciendo la transición a productos y aplicaciones basados ​​en API. Y algunos de ellos se enumeran a continuación para su referencia.

#1) Las aplicaciones basadas en API son más escalables en comparación con las aplicaciones / software tradicionales. La tasa de desarrollo de código es más rápida y la misma API puede atender más solicitudes sin ningún cambio importante de código o infraestructura.

#2) Los equipos de desarrollo no necesitan comenzar a codificar desde cero cada vez que comienzan a trabajar en el desarrollo de una función o aplicación. Las API suelen reutilizar funciones, bibliotecas, procedimientos almacenados, etc. repetibles existentes y, por lo tanto, este proceso puede hacerlos más productivos en general.

Por ejemplo, Si es un desarrollador que trabaja en un sitio web de comercio electrónico y desea agregar Amazon como procesador de pagos, entonces no tiene que escribir el código desde cero.

Todo lo que necesita hacer es configurar la integración entre su sitio web y la API de Amazon mediante las claves de integración y llamar a la API de Amazon para procesar los pagos durante el pago.

#3) Las API permiten una fácil integración con los otros sistemas tanto para aplicaciones independientes compatibles como con productos de software basados ​​en API.

Por ejemplo , Consideremos que desea realizar un envío de Toronto a Nueva York. Te conectas, navegas a un sitio web de carga o logística bien conocido e ingresas la información requerida.

Después de proporcionar la información obligatoria, al hacer clic en el botón Obtener tarifas, en la parte posterior, este sitio web de logística puede conectarse con varias API y aplicaciones de operadores y proveedores de servicios para obtener las tarifas dinámicas para la combinación de ubicaciones de origen a destino.

Espectro completo de pruebas de API

La prueba de las API no se limita a enviar una solicitud a la API y analizar la respuesta solo para verificar su exactitud. Las API deben probarse para determinar su rendimiento bajo diferentes cargas para detectar vulnerabilidades.

Analicemos esto en detalle.

(i) Pruebas funcionales

Las pruebas funcionales pueden ser una tarea desafiante debido a la falta de una interfaz GUI.

Veamos cómo enfoque de prueba funcional for APIs es diferente de la aplicación basada en GUI y también discutiremos algunos ejemplos a su alrededor.

a) La diferencia más obvia es que no hay una GUI con la que interactuar. Los evaluadores que suelen realizar pruebas funcionales basadas en GUI encuentran un poco más difícil la transición a pruebas de aplicaciones sin GUI en comparación con alguien que ya está familiarizado con ellas.

Inicialmente, incluso antes de comenzar a probar la API, deberá probar y verificar el proceso de autenticación en sí. El método de autenticación variará de una API a otra e involucrará algún tipo de clave o token para la autenticación.

Si no puede conectarse a la API correctamente, no se podrán realizar más pruebas. Este proceso puede considerarse comparable a la autenticación de usuario en las aplicaciones estándar en las que necesita credenciales válidas para iniciar sesión y usar la aplicación.

b) Probar validaciones de campo o validación de datos de entrada es muy importante durante la prueba de API. Si estuviera disponible una interfaz basada en formularios (GUI), entonces las validaciones de campo podrían implementarse en el front-end o back-end, asegurando así que un usuario no tenga permitido ingresar valores de campo no válidos.

Por ejemplo, Si una solicitud necesita que el formato de fecha sea DD / MM / AAAA, entonces podemos aplicar esta validación en el formulario que recopila información para asegurarnos de que la solicitud esté recibiendo y procesando una fecha válida.

Sin embargo, esto no es lo mismo para las aplicaciones API. Necesitamos asegurarnos de que la API esté bien escrita y sea capaz de hacer cumplir todas estas validaciones, distinguir entre datos válidos e inválidos y devolver el código de estado y el mensaje de error de validación al usuario final a través de una respuesta.

c) Probar la exactitud de las respuestas de API para una respuesta válida e inválida es crucial. Si se recibe un código de estado de 200 (que significa que todo está bien) como respuesta de la API de prueba, pero si el texto de respuesta dice que se ha encontrado un error, entonces esto es un defecto.

Además, si el mensaje de error en sí es incorrecto, puede ser muy engañoso para el cliente final que está intentando integrarse con esta API.

En la captura de pantalla a continuación, el usuario ingresó un peso no válido, que es más que los 2267 Kgs aceptables. La API responde con el código de estado de error y el mensaje de error. Sin embargo, el mensaje de error menciona incorrectamente las unidades de peso como libras en lugar de KG. Este es un defecto que puede confundir al cliente final.

(ii) Prueba de carga y rendimiento

Las API están diseñadas para ser escalables.

Esto, a su vez, hace que Load y Pruebas de rendimiento esencial, especialmente si se espera que el sistema que se está diseñando atienda miles de solicitudes por minuto u hora, según el requisito. Realizar pruebas de carga y rendimiento de forma rutinaria en la API puede ayudar a comparar el rendimiento, las cargas máximas y el punto de ruptura.

Estos datos son útiles al planificar la ampliación de una aplicación. Tener esta información disponible ayudará a respaldar las decisiones y la planificación, especialmente si la organización planea agregar más clientes, lo que significaría más solicitudes entrantes.

Por ejemplo , digamos que según los requisitos proporcionados, sabemos que la API diseñada debe atender al menos 500 solicitudes por hora y mantener el tiempo de respuesta promedio de menos de .01 segundos.

Según nuestras pruebas de carga y rendimiento, descubrimos que mientras API reciba menos de 500 solicitudes por hora, puede mantener el SLA para el tiempo de respuesta promedio. Sin embargo, si recibe otras 200 solicitudes, el tiempo de respuesta promedio aumenta y se alcanza el punto de ruptura cuando la solicitud entrante supera las 1200 por hora.

Por lo general, se ve que durante las fases iniciales de diseño, el énfasis suele estar en los aspectos funcionales de la API. A medida que pasa el tiempo, un producto comienza a admitir varios clientes en vivo, es entonces cuando las pruebas de rendimiento de API y las pruebas de carga entran en escena de una manera más rutinaria.

(iii) Pruebas de seguridad

Las interfaces de programación de aplicaciones o API son vulnerables y son el punto de acceso más fácil para los piratas informáticos malintencionados que desean acceder a los datos o obtener el control de una aplicación.

Esto puede llevar a cualquier empresa a problemas legales, en los que, debido a una brecha de seguridad, personas u organizaciones no deseadas pueden acceder a los datos del cliente a través de una API venerable.

Pruebas de seguridad es una rama especializada de las pruebas y debe ser manejada por especialistas. Los recursos de pruebas de seguridad pueden provenir de la organización o de consultores independientes.

Leer también = >> ¿Qué son las pruebas de contrato de pacto?

Cómo introducir las pruebas de API en su organización

El proceso para introducir pruebas de API en cualquier organización es similar al proceso utilizado para implementar o desplegar cualquier otra herramienta y marco de prueba.

La siguiente tabla resume los pasos principales junto con el resultado esperado de cada paso.

Desafíos comunes y formas de mitigarlos

Analicemos algunos de los desafíos comunes a los que se enfrentan los equipos de control de calidad al intentar implementar un marco de prueba de API en una organización.

# 1) Elegir la herramienta adecuada

Seleccionar la herramienta correcta para el trabajo es el desafío más común. Hay varias herramientas de prueba de API que están disponibles en el mercado.

Puede parecer muy atractivo implementar la última y más cara herramienta disponible en el mercado, pero si no produce los resultados deseados, entonces esa herramienta no sirve de nada.

Por lo tanto, elija siempre la herramienta que aborde los requisitos 'imprescindibles' según las necesidades de su organización.

Aquí hay una matriz de evaluación de herramientas de muestra para las herramientas API disponibles

# 2) Especificaciones de prueba faltantes

Como probadores, necesitamos conocer los resultados esperados para probar una aplicación de manera efectiva. Esto a menudo es un desafío, ya que para conocer los resultados esperados, necesitamos tener requisitos claros y precisos, lo cual no es el caso.

Por ejemplo , considere los requisitos que se proporcionan a continuación:

'La solicitud solo debe aceptar una fecha de envío válida y todos los requisitos no válidos deben rechazarse'

A estos requisitos les faltan detalles clave y son muy ambiguos: ¿cómo definimos una fecha válida? ¿Y el formato? ¿Estamos devolviendo algún mensaje de rechazo al usuario final, etc.?

mejor software de clonación para windows 7

Ejemplo de requisitos claros:

1) La aplicación solo debe aceptar una fecha de envío válida.

La fecha de envío se considera válida si es

• No en el pasado
• Mayor o igual a la fecha de hoy
• Tiene un formato aceptable: DD / MM / AAAA

2)

Código de estado de respuesta = 200
Mensaje: OK

3) La fecha de envío que no cumpla con los criterios anteriores debe considerarse inválida. Si un cliente envía una fecha de envío no válida, debe responder con los siguientes mensajes de error:

3.1

Código de estado de respuesta NO 200
Error: la fecha de envío proporcionada no es válida; asegúrese de que la fecha esté en formato DD / MM / AAAA

3.2

Código de estado de respuesta NO 200
Error: la fecha de envío proporcionada es anterior a la actual

# 3) Curva de aprendizaje

Como se mencionó anteriormente, el enfoque para las pruebas de API es diferente en comparación con el enfoque seguido al probar aplicaciones basadas en GUI.

Si está contratando especialistas internos o consultores para las pruebas de API, entonces la curva de aprendizaje del enfoque de prueba de API o la herramienta de prueba de API puede ser mínima. Cualquier curva de aprendizaje, en este caso, estaría asociada a la adquisición del conocimiento del producto o aplicación.

Si se asigna a un miembro del equipo existente para que aprenda las pruebas de API, entonces, según la herramienta elegida, la curva de aprendizaje puede ser de media a alta, además de cambiar el enfoque de la prueba. La curva de aprendizaje para el producto o la aplicación en sí puede ser baja-media dependiendo de si este probador ha probado esa aplicación antes o no.

# 4) Conjunto de habilidades existente

Esto se relaciona directamente con el punto anterior sobre la curva de aprendizaje.

Si un evaluador estaba pasando de las pruebas basadas en GUI, entonces el evaluador tendría que cambiar el enfoque de las pruebas y aprender la nueva herramienta o marco según sea necesario. P.ej. Si la API acepta las solicitudes en formato JSON, entonces el evaluador debería aprender qué es JSON para comenzar a crear las pruebas.

Caso de estudio

Tarea

Para escalar una aplicación existente, una empresa quería ofrecer un producto en API, así como una aplicación GUI estándar. Se le pidió al equipo de QA que proporcionara un plan de cobertura de pruebas para asegurarse de que están listos para adaptarse a las pruebas de API más allá de las pruebas regulares basadas en GUI.

Desafíos

• Ninguno de los otros productos de software tenía una arquitectura basada en API, por lo tanto, para adaptarse a las pruebas en torno a esta tarea, el equipo debe establecer el proceso de prueba de API desde cero. Esto significa que las herramientas debían ser evaluadas, preseleccionadas, finalizadas y el equipo tenía que ser capacitado para las pruebas.
• No se asignó un presupuesto adicional para adquirir e implementar la herramienta. Esto significa que el equipo tuvo que elegir una herramienta de prueba de API gratuita o de código abierto y alguien del equipo existente tuvo que estar capacitado para realizar esta tarea.
• No había requisitos para los campos de API y la validación de datos. Los requisitos eran 'debería funcionar igual que la aplicación GUI correspondiente'.

El enfoque seguido por el equipo para mitigar los riesgos y solucionar los desafíos

• El equipo de QA trabajó con el equipo del proyecto para identificar los siguientes requisitos:
  • Tipo de API (REST / SOAP): DESCANSO
  • Pruebas necesarias (funcional, carga, seguridad): Solo pruebas funcionales
  • Se requieren pruebas automatizadas (Sí / No): Opcional por ahora
  • Informes de prueba (Sí / No): Requerido
• El equipo de control de calidad evaluó las herramientas Herramientas de prueba de API basado en los requisitos imprescindibles. Postman API Tool se finalizó como una herramienta de su elección, ya que era gratuita y también fácil de usar, lo que minimizaba la curva de aprendizaje, tenía el potencial de automatizar las pruebas y venía con buenos informes incorporados.
• El mismo evaluador que probó la aplicación fue capacitado para usar Postman para crear pruebas iniciales, eliminando así cualquier brecha en el conocimiento del producto.
• Para hacer frente a los requisitos faltantes, el equipo del proyecto creó la documentación de nivel de campo de alto nivel utilizando Swagger. Sin embargo, esto dejó algunas lagunas en términos de formatos de datos aceptables y esto se examinó con el equipo del proyecto y se acordaron y documentaron los formatos esperados.

Conclusión

Las aplicaciones basadas en API han ganado popularidad en los últimos tiempos. Estas aplicaciones son más escalables en comparación con las aplicaciones / software tradicionales y permiten una integración más fácil con las otras API o aplicaciones.

Este tutorial de pruebas de API explica todo sobre las pruebas de API, las pruebas de desplazamiento a la izquierda, los servicios web y la API web en detalle. También exploramos las diferencias entre los servicios web y la API web con ejemplos.

En la segunda parte del tutorial, discutimos el espectro completo de API Testing, cómo introducir API Testing en su organización y algunos desafíos comunes en este proceso junto con soluciones para ellos.

¡Consulte nuestro próximo tutorial para obtener más información sobre los servicios web junto con ejemplos!

SIGUIENTE Tutorial

Lectura recomendada

• Pruebas alfa y beta (una guía completa)
• Pruebas funcionales versus pruebas no funcionales
• Tutorial de pruebas de usabilidad: una guía completa de introducción
• Guía completa de pruebas de verificación de compilación (pruebas de BVT)
• Tutorial de pruebas de DevOps: ¿Cómo afectará DevOps a las pruebas de control de calidad?
• Tutorial de pruebas de accesibilidad (una guía completa paso a paso)
• Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
• ¿Qué son las pruebas de software? Más de 100 tutoriales de prueba manuales gratuitos