Cómo Probar Puntos de Acceso de API
Una Interfaz de Programación de Aplicaciones (API, por sus siglas en inglés) permite que dos sistemas se comuniquen entre sí. En esencia, una API ofrece el contrato y el lenguaje que rigen la comunicación entre dos sistemas.
Las pruebas de API implican evaluar estas interfaces para asegurar que cumplan con los estándares de funcionalidad, fiabilidad, rendimiento y seguridad, generalmente enviando varias solicitudes a la API y evaluando las respuestas. Las pruebas de API son una de las principales prioridades para casi todos los desarrolladores; de acuerdo con la encuesta mundial de APIs de Rapid de 2022, más del 90% de los desarrolladores declara probar o planear probar sus APIs.
Los endpoints de API son rutas o URLs específicas que una API proporciona, permitiendo el acceso a diferentes funcionalidades de la aplicación de software. Cada endpoint corresponde a una función específica, como recuperar datos, actualizar un registro o realizar un cálculo, y está diseñado para manejar tipos específicos de solicitudes y respuestas dentro de la estructura general de la API.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Probar consistentemente los endpoints de API a lo largo del proceso de desarrollo ayuda a detectar problemas de forma temprana, ahorrando tiempo y recursos a largo plazo.
Entonces, ¿cómo se pueden realizar pruebas de API de manera eficiente a lo largo del ciclo de vida de desarrollo de la API? ¡Vamos a profundizar!
¿Qué son los endpoints de una API?
Una API es un conjunto de reglas y protocolos para construir e interactuar con aplicaciones de software, permitiendo que diferentes sistemas de software se comuniquen. La documentación y especificaciones de cada API indican cómo se puede intercambiar la información.
Las APIs pueden utilizar solicitudes HTTP para recuperar datos de una aplicación web o servidor, de forma similar a cómo se renderiza una página web.
servicios, URLs, justo como las que usas para visitar un sitio web. Dentro de una API, un endpoint es una ubicación particular que recibe solicitudes y responde a ellas. A través de la transmisión y recepción de datos y comandos mediante el endpoint, se facilita la comunicación entre diversas aplicaciones y sistemas.
Permite a los desarrolladores acceder y utilizar rápidamente datos y características de otros sistemas, evitando así tener que construir todo desde cero en nuevas aplicaciones.
Ejemplo de un endpoint de API
Veamos cómo es un endpoint de API. Usaré como ejemplo la Cat API y su documentación en Postman:
En este caso, los endpoints son “images”, “favorites”, “breeds”, etc. Cada uno permite realizar varias acciones, las cuales se llevan a cabo mediante diferentes métodos de solicitud HTTP. Por ejemplo, los métodos más comúnmente utilizados son los que realizan acciones CRUD: POST para creación, GET para lectura, PUT para actualización y DELETE para borrado.
La documentación de la API debe proporcionar detalles sobre los endpoints disponibles, el método de solicitud permitido para cada endpoint, y modelos de la solicitud y respuesta. Con esta información, deberíamos poder empezar a probar los endpoints. Hablaremos de esto en una de las próximas secciones.
¿Por qué probar los endpoints de API?
Cada API se crea para llevar a cabo funciones específicas, y la funcionalidad de la aplicación depende de las transacciones de la API para recibir la respuesta. La transacción básica puede hacer muchas llamadas internas a la API; si una de estas llamadas falla, el sistema en su conjunto podría fallar y dejar de funcionar. Además, varias aplicaciones pueden utilizar la misma API, así que cuando una API falla, puede afectar a una gran cantidad de aplicaciones. Probar los endpoints de la API ayuda a prevenir problemas antes de que los encuentre el cliente.
¿Cómo probar los endpoints de API?
Las pruebas de API se pueden realizar tanto de manera manual como automatizada. Ambos tipos de pruebas pueden llevarse a cabo usando herramientas para pruebas de API.
A diferencia de las pruebas de UI, las pruebas de API no dependen de un navegador. Sin embargo, se puede usar una herramienta de pruebas de API que actúe como cliente.
Basándonos en la documentación, podemos extraer el endpoint al que se debe enviar la solicitud HTTP, el método HTTP, los parámetros de consulta, el cuerpo de la solicitud (si se requiere), los posibles códigos de estado de respuesta HTTP, y el cuerpo de la respuesta HTTP. Con esta información, podemos identificar los casos de prueba de API que necesitan ser ejecutados.
Dependiendo de los requisitos, podemos decidir qué pruebas deben llevarse a cabo, desde pruebas funcionales hasta no funcionales, como pruebas de rendimiento, pruebas de carga y pruebas de seguridad.
La prueba de API más básica consiste en enviar la solicitud y validar la respuesta. Dependiendo del tipo de solicitud y del endpoint en sí, es posible que necesitemos información adicional para enviar la solicitud. Aquí tienes una lista de lo que necesitamos para enviar una solicitud:
- Endpoint/URL: esta es la dirección a la que se envía la solicitud
- El cuerpo de la solicitud: para métodos de solicitud como POST y PUT, se requiere un cuerpo que contenga los datos que se enviarán al servidor
- Parámetros de consulta: se pueden utilizar parámetros de búsqueda adicionales para limitar los resultados devueltos en la respuesta
- Encabezados: estos son metadatos que se pueden enviar con la solicitud. En el ejemplo del gato de antes, se puede usar una clave de API como encabezado, lo cual permite recuperar más información que sin una clave:
Después de que la solicitud se haya enviado correctamente, la prueba debe comprobar la respuesta. Las cosas a verificar en la respuesta son:
- El código de estado HTTP: cada respuesta tiene un código de estado. Estos pueden agruparse en 5 clases principales: los códigos que comienzan con 1 (100-199) representan una respuesta informativa, los que comienzan con 2 (200-299) representan un mensaje exitoso, los códigos entre 300 y 399 son redirecciones, los códigos que empiezan con 4 (400-499) son errores del cliente y los códigos del grupo 500 son errores del servidor.
- El cuerpo de la respuesta HTTP: la información que regresa del servidor. La documentación debe indicar qué tipo de información debe contener la respuesta, por ejemplo:
- Encabezados de la respuesta: metadatos que devuelven los servidores
- Tiempo de respuesta: si nos interesa también el rendimiento de la API.
Como ejemplo rápido, usaré Postman para mostrar cómo se ve una solicitud GET utilizando la Cat API. Enviaré una solicitud GET al endpoint de imágenes. Para hacerlo, basta con usar la dirección del endpoint, el método GET y enviar la solicitud:
Después de enviar la solicitud, podemos ver el código de respuesta HTTP, el cuerpo y el tiempo que tomó recibir una respuesta:
El contenido del cuerpo de la respuesta es lo que una API devuelve según la entrada proporcionada, mientras que el código de estado de la respuesta indica el estado actual de la solicitud.
Existen diferencias en los tipos de datos y tamaños de las respuestas de una API. Las respuestas pueden ser texto plano, un documento XML, una estructura de datos JSON u otros formatos. Pueden abarcar desde un archivo JSON/XML de cien páginas hasta una simple cadena de unas pocas palabras, o incluso estar vacías. Por lo tanto, es fundamental seleccionar una técnica de verificación adecuada para una API en particular.
Creando casos de prueba para API
Los casos de prueba funcionales pueden extraerse utilizando técnicas de pruebas de caja negra. La documentación especifica qué tipos de datos acepta cada parámetro, por lo que se pueden crear particiones y límites basados en estos datos.
Luego, podemos crear escenarios más complejos combinando múltiples solicitudes en una prueba. Por ejemplo, una prueba que crea un recurso, lo actualiza, lo lee y luego lo elimina enviará 4 solicitudes diferentes.
Para la verificación de APIs es necesario realizar pruebas positivas y negativas que aseguren que la API está funcionando según lo requerido. Dado que las pruebas de API son un subconjunto de las pruebas de caja negra, los datos de entrada y salida son los que orientan ambos tipos de pruebas. Algunas ideas para crear escenarios de prueba son las siguientes:
Escenarios positivos:
- Verificar que la API acepte la entrada y produzca el resultado deseado según el requerimiento.
- Verificar si el código de estado de la respuesta—ya sea que devuelva un código de error o un 2xx—se retorna de la manera indicada por el requerimiento.
- Indicar el número mínimo y máximo de campos que deben ingresarse.
Escenarios negativos:
- Asegurarse de que en casos donde la salida esperada esté ausente, la API brinde una respuesta adecuada.
- Realizar una prueba de validación de entrada.
- Examinar el comportamiento de la API en diferentes niveles de autorización.
Pruebas no funcionales de API
Aparte de las pruebas funcionales, podemos realizar varias pruebas no funcionales para las APIs. Aquí están algunas de las más importantes:
Pruebas de rendimiento
Las pruebas de rendimiento se refieren a la medición del desempeño del software bajo diversas cargas de trabajo, escenarios y condiciones. Estas pruebas pueden ayudarte a encontrar cuellos de botella en los recursos, garantizar la estabilidad y escalabilidad, y asegurar la escalabilidad. Los subtipos de pruebas de rendimiento incluyen pruebas de carga, pruebas de estrés, pruebas de resistencia y pruebas de picos. El tipo de prueba de rendimiento más popular, conocido como prueba de carga, replica el tráfico promedio o alto de usuarios en tu software. Puede ayudarte a evaluar el rendimiento, el tiempo de respuesta y el uso de recursos de tu software. Apache JMeter, una herramienta de Java de código abierto que puede generar y enviar diferentes solicitudes a tu API y medir los resultados, es una de las mejores herramientas para realizar pruebas de carga a tu API.
Pruebas de seguridad
El proceso de confirmar que tu software está protegido contra ataques maliciosos, accesos no autorizados y fugas de datos se conoce como pruebas de seguridad. Puede ayudarte a garantizar la privacidad, exactitud y accesibilidad de los datos de tu programa. Se pueden realizar pruebas de seguridad en diversos niveles, incluyendo los niveles de base de datos, aplicación y red. Las revisiones de código, pruebas de penetración, análisis de vulnerabilidades y hacking ético son algunos de los métodos más populares para las pruebas de seguridad. Postman es una popular herramienta multiplataforma que puede enviar y recibir solicitudes a tu API y comprobar características de seguridad como la autenticación, autorización, cifrado y manejo de errores. Es una de las mejores herramientas para probar la seguridad de tu API.
Pruebas de confiabilidad
Las pruebas de confiabilidad son el proceso de determinar cuán confiable y constante es tu software a lo largo del tiempo y en diversas situaciones. Estas pruebas pueden ayudarte a asegurar la capacidad de recuperación, tolerancia a fallos y disponibilidad de tu software. Puedes realizar pruebas de confiabilidad introduciendo intencionadamente errores, fallos o defectos en tu software y observando cómo reacciona y se recupera. El tiempo medio entre fallos (MTBF), el tiempo medio hasta el fallo (MTTF), el tiempo medio de reparación (MTTR) y la tasa de fallos son algunas de las métricas frecuentemente utilizadas para las pruebas de confiabilidad. Chaos Monkey, una herramienta que termina aleatoriamente instancias en tu entorno en la nube y prueba cómo tu software maneja la interrupción, es una de las mejores herramientas para probar la confiabilidad de tu API.
Reflexiones finales
Las pruebas de API son una habilidad cada vez más importante para los profesionales de aseguramiento de la calidad (QA). Es fundamental probar exhaustivamente los endpoints de API para asegurarse de que funcionan según lo previsto y cumplen con los estándares requeridos. Probar los endpoints ayuda a identificar y resolver posibles problemas o errores y valida la funcionalidad general de la aplicación.
Para probar eficazmente los endpoints de una API, es esencial seguir buenas prácticas, como diseñar casos de prueba completos, considerar diversas entradas y salidas, y utilizar herramientas de automatización para una prueba eficiente y confiable. Además, aprovechar entornos de prueba que simulen escenarios reales puede mejorar aún más la precisión de las pruebas de los endpoints de la API.
La realización de pruebas exhaustivas y efectivas de los endpoints de la API es esencial para garantizar la confiabilidad, el rendimiento y la funcionalidad de las aplicaciones modernas. Al comprender qué son los endpoints de una API y cómo probarlos, los desarrolladores pueden asegurar la integración exitosa de sus aplicaciones con otros sistemas mientras ofrecen una experiencia de usuario excepcional.
Por favor, suscríbete al boletín de QA Lead para recibir actualizaciones sobre nuevo contenido de pruebas.
