Descubre las mejores estrategias para el testing de APIs en esta guía detallada. Aprende a mejorar la estrategia de pruebas abarcando aspectos como la eficiencia, adaptabilidad y seguridad de las APIs mediante las heurísticas más conocidas y una nueva heurística propuesta por nuestro equipo. 

En el ámbito del desarrollo de software, las pruebas de API tienen un rol esencial para validar que las aplicaciones funcionen de manera correcta y que su integración con otros sistemas sea fluida. 

Pese a esto, llevar a cabo una evaluación exhaustiva de todas las funcionalidades de una API puede resultar desafiante, en particular cuando las fechas límite están próximas. En este punto, las heurísticas para las pruebas de API testing se convierten en una herramienta valiosa.

Pero, ¿qué son las heurísticas? 

Podemos definirlas como principios o estrategias que el equipo de pruebas emplea para analizar de forma efectiva la calidad de una API. 

En lugar de seguir procedimientos rígidos y detallados, las heurísticas ofrecen un enfoque más ágil y flexible. Esto brinda al equipo de testers la posibilidad de identificar rápidamente los problemas y tomar decisiones informadas.

Ventajas de las heurísticas para pruebas de API

1. Eficiencia en la detección de problemas

Las heurísticas posibilitan que el equipo de testers identifique de manera rápida las áreas problemáticas de una API. Al emplear principios y estrategias específicas, el equipo de testers puede focalizar sus esfuerzos en las áreas más críticas, lo cual conlleva un ahorro de tiempo y recursos valiosos.

2. Flexibilidad y adaptabilidad

Las heurísticas no son reglas rígidas, sino estrategias flexibles. Esto le permite al equipo de testers adaptarse de manera sencilla a diversos contextos y a los requerimientos específicos del proyecto. Además, las heurísticas pueden ser ajustadas y mejoradas a lo largo del tiempo, lo cual genera un proceso de pruebas más eficaz y ágil.

3. Cobertura exhaustiva

Al emplear heurísticas específicas, el equipo de testers puede asegurarse de evaluar distintos aspectos de la API, la respuesta a diferentes tipos de solicitudes y la seguridad. Esto permite una cobertura más exhaustiva y ayuda a identificar brechas en la funcionalidad de la API.

Heurísticas conocidas

A continuación, te presentamos algunas de las heurísticas que encontramos a disposición y utilizamos día a día para mejorar la calidad de las pruebas de API. Muchas de estas tienen puntos en común. Aún así, cada proyecto y contexto es único, por lo cual resulta esencial adaptar y ajustar estas heurísticas de acuerdo a las necesidades específicas.

VADER

Diseñada por Stuart Ashman, VADER proporciona un marco estructurado para evaluar diferentes aspectos de una API, desde el uso correcto de verbos HTTP hasta la eficacia en la gestión de errores y la capacidad de respuesta.

Verbs (Verbos): 

Este aspecto se refiere a evaluar si se están utilizando los verbos HTTP de manera adecuada. Lo importante es entender bien cuáles son las reglas de negocio de la API que estás evaluando.

Recordemos los principales verbos HTTP y sus características:

• POST

Habitualmente, se utiliza para registrar nueva información. 

• GET

Se utiliza para obtener la información. Puede ser un listado o una entidad específica filtrada por algún identificador, depende del producto testeado. 

• DELETE

Se usa para eliminar registros, pero es importante saber si el borrado es lógico (se pone inactivo) o físico (se borra completamente). 

• PUT

En general, se utiliza para actualizar toda la información de una entidad. 

• PATCH 

Similar al PUT pero se usa para actualizar solo una parte de una entidad.

Authorization/Authentication (Autorización/ Autenticación): 

Este punto hace referencia a verificar la correcta implementación de los mecanismos de autorización y autenticación. Esto incluye asegurarse de que las solicitudes estén protegidas adecuadamente y que se requieran credenciales válidas para acceder a ciertos recursos.

Recordemos que la autenticación es un mecanismo para determinar quién eres, es decir, podrás autenticarte siempre y cuando el sistema reconozca que te encuentras registrado, mientras que la autorización determina a qué recursos puedes acceder.

Data (Datos): 

Aquí se examina la integridad y precisión de los datos manejados por la API. Es decir, el enfoque acá es asegurar que la información se almacene, procese y transmita de manera correcta según las reglas de negocio establecidas, revisar los tipos o estructuras de datos permitidos, valores permitidos, máximos y mínimos permitidos y estructuras.

Errors (Errores): 

Este punto implica comprobar cómo la API maneja los errores. Esto implica evaluar los códigos de estado HTTP devueltos en situaciones de error, así como la claridad y utilidad de los mensajes de error proporcionados.

Entendiendo las reglas de negocio, podemos utilizar set de datos que sabemos que deberían provocar un error o enviar peticiones mal formadas y evaluar si ese error está siendo tratado adecuadamente, si se responde un código de error y un mensaje adecuado para esa circunstancia. Por ejemplo, es una mala práctica que se devuelvan códigos de error 500.

Responsiveness (Capacidad de respuesta): 

Este último punto evalúa la velocidad y eficiencia de la API en términos de tiempo de respuesta, y verifica que la API sea lo suficientemente rápida para satisfacer los requisitos de rendimiento del sistema.

POISED

Esta heurística fue desarrollada por Amber Race y es un acrónimo que representa seis áreas claves que deben tenerse en cuenta para lograr la calidad y la robustez del sistema.

Parameters (Parámetros): 

Se refiere a la evaluación de los parámetros de cada operación de la API bajo prueba. Básicamente, se trata de experimentar con los datos, pasar parámetros vacíos, aleatorios, modificar los tipos de datos permitidos, etc. Además, verificar que el servidor responde adecuadamente.

Output (Salida): 

El objetivo es corroborar que la respuesta del servidor sea la esperada. Se puede experimentar tanto como lo permitan las reglas de negocio, enviar peticiones cuyas salidas deberían ser algún mensaje específico según la regla de negocio y validar que cumpla con los requisitos especificados. 

Por ejemplo: Si el alta de una persona usuaria sólo está permitida si la persona es mayor de edad, al enviar datos de una persona menor, la salida esperada es un mensaje del tipo: “La persona usuaria no puede ser menor de edad.”

Interoperability (Interoperabilidad): 

Considera la capacidad del sistema para interoperar con otros sistemas o componentes. Se trata de evaluar si el sistema puede comunicarse eficazmente con otros sistemas, servicios o dispositivos. 

No siempre será necesario, hay que entender bien para qué se utilizará la API, en qué otros sistema se debe acoplar o quiénes necesitarán utilizarla. En este sentido, es una buena oportunidad para evaluar si la documentación es buena y es comprensible para desarrolladoras y desarrolladores que necesiten integrar un sistema con nuestra API bajo prueba.

Security (Seguridad): 

Se enfoca en la seguridad del sistema. Además de la autenticación y autorización, propone dar un paso más y  evaluar otros aspectos de la seguridad como el cifrado de datos, y la identificación de posibles vulnerabilidades. Por ejemplo: verificar si es posible enviar y almacenar un código Javascript a través de un POST.

Error Handling (Manejo de errores):  

Al igual que en VADER, aquí se examina cómo el sistema maneja situaciones de error. Nuevamente, debemos poner foco en casos de prueba negativos y forzar todo tipo de errores que se nos ocurra, como no enviar campos obligatorios, jugar con valores límites o usar tipos de datos no permitidos dentro de lo que las especificaciones nos dicen. 

Es importante brindar retroalimentación sobre cómo el servidor está comunicando los errores, si los mensajes son claros.

Data (Datos):

Aquí como en VADER importa probar la integridad de los datos, la forma en que se almacenan, se recuperan y se procesan. Por ejemplo: si los datos que se almacenan mediante un POST son obtenidos correctamente mediante un GET, así como, si el borrado de los datos debe ser de forma permanente o es un borrado lógico. El acceso a bases de datos puede ser una buena idea para complementar este tipo de pruebas. 

TATTA

Mark Winteringham, quien es el autor del libro Testing Web APIs distingue entre “Testing the API” (Probando la API) y “Testing Through the API” (Probando a través de la API). Ambos enfoques implican evaluar el funcionamiento de un servicio web, pero se centran en diferentes aspectos del proceso de prueba.

Probando la API (Testing the API):

• Verificar que un servicio web de terceros sea accesible.
• Verificar si el servicio web cumple con las expectativas y está en funcionamiento.
• Evaluar si el servicio web devuelve los resultados esperados.

Probando a través de la API (Testing Through the API):

• Observar el comportamiento del servicio web.
• Evaluar cómo el servicio web evalúa los datos y los transforma para devolver resultados.
• Verificar la estructura correcta de los registros devueltos por el servicio web.
• Evaluar cómo el servicio web maneja situaciones como el desbordamiento de datos (por ejemplo, un entero demasiado grande).
• Confirmar si se realiza una redirección tras una solicitud no autorizada.

El enfoque que se elija puede depender de diferentes factores, como las herramientas utilizadas y los propósitos específicos de la prueba.

LHTRAFFIC

Diseñado por Karol Szewczak, LHTRAFFIC se deriva de Left-handle traffic y proporciona un marco exhaustivo para evaluar aspectos críticos de seguridad y funcionalidad en el diseño, desarrollo y prueba de APIs. Este enfoque aborda cuestiones que van desde posibles fugas de información hasta problemas de inyección y manipulación de datos.

Leaky APIs (APIs que filtran información): 

Hace referencia a las APIs que pueden estar revelando información que no deberían. Es importante inspeccionar los datos que se transmiten a través de la red, evaluar si quienes utilizan la API realmente necesitan toda esa información y si se están enviando datos sensibles que no deberían exponerse. 

También implica revisar los encabezados de respuesta con el objetivo de asegurar que no revelen detalles sobre los frameworks subyacentes.

Hidden APIs (APIs ocultas): 

Se refiere a APIs que el equipo de desarrollo no pensaba que las personas encontrarían, pero que son visibles de diversas maneras. 

Esto implica verificar si se proporciona un archivo “robots.txt” para prevenir el acceso de rastreadores a recursos importantes, evitar la exposición de puntos finales de administrador, y revisar la documentación automática, como Swagger, con el objetivo de asegurarnos de que no revele información sensible o APIs privadas.

Tampering Requests or Responses (Manipulación de solicitudes y respuestas):

Estudia el lugar donde se realiza la validación de los parámetros enviados con las solicitudes de API. Alerta sobre la posibilidad de manipulación de datos por parte de un atacante intermedio o un proxy. 

Esto significa que si hay un sistema web o móvil integrado a nuestra API, las validaciones no pueden estar solo del lado de la interfaz de usuario (frontend), sino que nuestro backend debe contar con el código defensivo necesario para mitigar posibles envíos de parámetros no permitidos.

Authorization or Authentication (Autorización o Autenticación): 

Se enfoca en la autorización y autenticación de la API. Como hemos mencionado aquí, es importante saber que con un conjunto de credenciales (correctas o incorrectas) una persona puede autenticarse o no y, que si logra hacerlo, hay que probar a qué recursos puede acceder. 

Es una oportunidad para entender bien el sistema, corroborar que esté bien documentado, y responder a diferentes  interrogantes. Por ejemplo: qué tipos de autorización se admiten, si es posible saltárselas (por ejemplo, no pasar un token en las solicitudes), cómo se manejan los errores de autenticación, si se envían credenciales de manera segura, y si se pueden realizar enumeraciones de usuarios, entre otras consideraciones.

Fuzzing (Pruebas de fuzzing): 

Recomienda realizar pruebas de “fuzzing” en la API utilizando datos malformados o inesperados con el objetivo de detectar posibles vulnerabilidades. 

Esto implica probar con diferentes tipos de datos, como números o cadenas, y utilizar herramientas como la “Big List of Naughty Strings”. Se trata de una lista en constante evolución de cadenas de caracteres que tienen una alta probabilidad de causar problemas cuando se utilizan como datos de entrada de usuario.

Forgotten (Olvidado): 

Explora la posible presencia de encabezados predeterminados que podrían haber quedado activados por accidente. También subraya la importancia de desactivar la documentación automática, como Swagger, en entornos de producción si inicialmente estaba destinada solo al entorno de desarrollo.

Injections (Inyecciones): 

Hace alusión a la búsqueda de posibles inyecciones, como las conocidas inyecciones SQL, y a la evaluación de diferentes puntos de inyección, que incluyen encabezados, parámetros y el cuerpo de la solicitud.

Content-type (Tipo de contenido): 

Examina si el encabezado Content-type está alineado con el tipo MIME enviado. También estudia cómo responde la aplicación cuando se envía un tipo de contenido no compatible y si la API admite varios tipos de contenido.

ICEOVERMAD 

Creado por Ash Winter, no solo busca contemplar aspectos funcionales de la API si no también aspectos sobre la performance y la arquitectura del sistema.

Integration (Integración): 

Tiene como objetivo evaluar cómo los consumidores se integrarán con el servicio, cuándo lo harán y si está destinado a ser renderizado en un navegador, generado en un archivo u otro método de consumo.

Consumers (consumidores): 

Busca identificar quiénes serán los consumidores del servicio, ya sean humanos o máquinas, y comprender qué problema resuelve el servicio para cada consumidor.

Endpoints: 

Implica analizar la forma del endpoint y cómo se accede a él, si es un solo endpoint, múltiples endpoints o si se enruta a través de un balanceador de carga. Evalúa el nivel de seguridad aplicado.

Operations (operaciones): 

Se enfoca en identificar las funciones comerciales que realiza el servicio, si se pueden asignar a funciones actuales realizadas a través de una interfaz de usuario, si las operaciones tienen nombres descriptivos y son legibles para humanos y máquinas, y si manejan datos sensibles.

Volume (Volumen): 

Implica evaluar si el servicio se utilizará a un alto volumen concurrentemente o de manera esporádica con solicitudes únicas de alto valor, si el tamaño de las transacciones individuales es un problema, cómo se gestionan las sesiones de la API y si la arquitectura objetivo está clusterizada.

Error Handling (Manejo de errores: 

Involucra analizar cómo el servicio maneja errores en el lado del servidor y del cliente, si los errores son informativos y/o detallados, y cómo se maneja la pérdida de conectividad con la base de datos.

RESTful: 

Consiste en evaluar si el servicio tiene las características de un servicio RESTful y determinar si esto es deseable en el contexto específico.

Modularity (Modularidad): 

Se refiere a analizar cómo se distribuyen los componentes del servicio, cómo interactúan, si pueden existir de manera independiente y si pueden fallar entre sí.

Authentication (Autenticación): 

Implica investigar cómo las personas se autentican dentro del servicio, qué permisos son aplicables y cómo eso cambia el funcionamiento del servicio, qué niveles de seguridad se utilizan y si los datos se envían o reciben cifrados.

Definitions (Definiciones):

Tiene que ver con determinar qué define las entradas y salidas del servicio, si se utiliza WSDL, WADL, XSD, XSLT u otro método, qué límites impone esto al servicio y qué métodos HTTP se utilizan y con qué propósito.

BINMEN

Se trata de una heurística ideada por Gwen Diagram y Ash Winter. Esta es una heurística sencilla que se concentra en verificar el manejo de errores por parte del servidor al igual que otras heurísticas, pero desglosa en diferentes puntos específicos para inducir o forzar esos comportamientos.

Boundary (Límites): 

Las pruebas de límites o “Boundary” hacen referencia a probar la API con valores que estén en los límites de lo que se supone que la API puede manejar. Esto podría implicar probar la API con el valor máximo y mínimo posible, así como con valores ligeramente por encima y por debajo de estos límites.

Invalid Entries (Entradas inválidas): 

Las “Invalid Entries” consisten en pruebas en las que se usan entradas que no deberían ser aceptadas por la API. Se realizan con el propósito de verificar que la API maneja adecuadamente las entradas inválidas, ya sea devolviendo un error de una manera controlada o ignorándose.

Nulls (Nulos): 

En “NULL” se procede a enviar valores nulos a la API para asegurar que puede manejar adecuadamente este tipo de valores. Algunas APIs pueden tener problemas al manejar valores nulos, lo que puede provocar errores inesperados.

Method (Método): 

En las pruebas de “Method”, se busca comprobar que cada uno de los métodos de la API funcione de acuerdo con la documentación, sean consistentes y predecibles. Esto puede incluir pruebas para los métodos GET, POST, PUT, DELETE, etc.

Empty (Vacío): 

Similarmente a las pruebas NULL, las pruebas “Empty” suponen enviar valores vacíos a la API. Esto puede ayudar a identificar problemas que pueden surgir cuando la API recibe una entrada vacía.

Negatives (Negativos): 

Las pruebas negativas implican enviar a la API entradas que no son válidas o que se sabe que provocarán un error. El objetivo de estas pruebas es asegurar que la API pueda manejar adecuadamente estos errores y no se caiga o deje de funcionar.

En resumen

Las heurísticas anteriores cubren de manera exhaustiva los aspectos críticos del  API testing. Sin embargo, cada heurística tiene su fortaleza y enfoque.

Podemos tomar de ellas los puntos en común, combinar diferentes puntos relevantes de cada una, así como adicionar otros aspectos que en nuestra experiencia consideramos importantes, para generar un marco más completo y diverso. 

A continuación, proponemos otra heurística que engloba los aspectos principales y de los cuales es importante hacer énfasis, un resumen y un ejemplo de los que recomendamos tener en cuenta en cada punto:

Heurística BAD-VIPERS

Con BAD-VIPERS, los equipos de  testing podrían abordar aspectos funcionales, de seguridad, de rendimiento, aspectos relacionados con la integración de la API y su documentación, y así ofrecer una visión más holística e integral de la API testing.

Para explicar punto a punto la heurística y mostrar algunos ejemplos vamos a considerar una operación POST sobre determinado endpoint que se encarga de dar de alta un usuario en la base de datos, a partir de los valores enviados en el body del mensaje con datos básicos de una persona o usuario de un sistema:

VIPERS

Verbs (Verbos) 

Este aspecto se refiere a evaluar si se están utilizando los verbos HTTP de manera adecuada.

Ejemplo: Asegúrate de que un POST al endpoint /api/usuarios crea un nuevo usuario, mientras que un GET recupera un usuario o una lista de usuarios. Un error común sería permitir la creación de usuarios con un GET, lo cual es incorrecto ya que violaría los principios RESTful.

Integration (Integración)

Este aspecto evalúa la capacidad de la API para interactuar de manera efectiva con otros sistemas o componentes. Esto implica determinar si la API puede comunicarse eficientemente con otros sistemas, servicios o dispositivos, en función de su propósito y las necesidades de los usuarios.

Ejemplo: Al integrar /api/usuarios con /api/login, confirma que después de crear un usuario con POST se pueda autenticar con éxito a través del endpoint de login, con el objetivo de que ambas APIs trabajen juntas de modo coherente.

Parameters (Parametros)

Básicamente, se trata de experimentar con los datos, pasar parámetros vacíos, aleatorios, modificar los tipos de datos permitidos, etc. Además, verificar que el servidor responde adecuadamente. Aquí se pueden utilizar técnicas como Fuzzing utilizando datos malformados o inesperados, con el fin de detectar posibles vulnerabilidades. 

Ejemplo: Envía a /api/usuarios una petición POST con un cuerpo como: 

{ 

“username”: “”, 

“email”: “[email protected]“,

 “password”: “12345” 

} 

para verificar que el servidor maneja adecuadamente los parámetros vacíos y devuelve un error específico por falta del username.

Error Handling (Manejo de errores)

El manejo de errores de la API se examina evaluando los códigos de estado HTTP en situaciones de error y la claridad de los mensajes de error. Esto implica inducir errores como omitir campos necesarios o usar datos no permitidos, y examinar si se devuelve un mensaje apropiado.

Es esencial analizar cómo se gestiona la pérdida de conectividad con la base de datos y cómo se manejan los errores en el lado del cliente y del servidor.

Ejemplo: Omite el campo email en una solicitud POST a /api/usuarios y espera un 400 Bad Request con un mensaje explicativo como {“error”: “El campo ’email’ es obligatorio”}.

Responsiveness (Capacidad de respuesta)

Un aspecto no tan funcional y si más de performance y sumamente importante es evaluar la velocidad y eficiencia de la API en términos de tiempo de respuesta. Asegura que la API sea lo suficientemente rápida para satisfacer los requisitos de rendimiento del sistema.

Ejemplo: Mide el tiempo de respuesta al hacer una solicitud GET a /api/usuarios. Si tarda más de 500ms en obtener una respuesta, investiga y optimiza la eficiencia del endpoint. Los resultados pueden sugerir la necesidad de hacer pruebas de performance.

Security (Seguridad)

La seguridad en APIs implica explorar APIs privadas o no documentadas y comprobar posibles datos sensibles en la API. La presencia de información confidencial en la URL representa riesgos significativos. 

Las APIs privadas requieren de medidas de seguridad para limitar su acceso. Es crucial determinar el uso de SSL para lograr la transmisión segura de datos. 

Debemos proteger la API para mitigar amenazas como los ataques XSS. Además de la autenticación y autorización, es esencial evaluar el cifrado de datos y detectar posibles vulnerabilidades, como la posibilidad de enviar código Javascript a través de un POST.

Ejemplo: Prueba el endpoint /api/usuarios enviando una solicitud POST con un payload que incluya un script malicioso en el campo username, para verificar que la API tiene protección contra ataques XSS.

BAD

Behave (Comportamiento)

Es importante entender cuál es el comportamiento esperado de la API en términos generales, entender el negocio y armar un plan de pruebas priorizando los aspectos más críticos. 

Es importante prestar atención a las respuestas que emite el servidor, con el fin de validar que sean las esperadas. Mediante el envío de peticiones diseñadas según las reglas de negocio, se pueden llevar a cabo pruebas minuciosas que deberían resultar en respuestas específicas del servidor. De esta manera, verificamos que dichas respuestas cumplan con los estándares y requisitos previamente definidos.

Ejemplo: Realiza una solicitud POST para crear un usuario en /api/usuarios con datos correctos y verifica que el servidor devuelve la salida esperada. Por ejemplo, un mensaje de éxito con el ID del usuario creado.

Authorization/Authentication (Autorización/ Autenticación): 

La autenticación en el testing de APIs se centra en verificar si los mecanismos de identificación están correctamente implementados. Es esencial que las solicitudes estén suficientemente protegidas y necesiten credenciales válidas para el acceso. 

Este proceso de autenticación permite determinar la identidad del usuario, con el fin de que el sistema reconozca únicamente a los usuarios registrados. Además, se debe analizar y probar cómo se manejan los errores de autenticación, cómo se transmiten los datos de manera segura y cómo se manejan las sesiones de usuario.

Ejemplo: Intenta hacer una solicitud GET a /api/usuarios/privado sin incluir un token de autenticación, para verificar que el sistema rechace correctamente la solicitud y devuelva un 401 Unauthorized.

El testeo de APIs en términos de autorización se centra en comprobar los accesos permitidos a los usuarios. Este proceso es crucial para determinar a qué recursos puede acceder un usuario autenticado. Incluye entender qué tipos de autorización se admiten y probar situaciones en las que se intenta eludir la autorización.

Ejemplo: Intenta actualizar la información de un usuario con PUT a /api/usuarios/{id} sin los permisos adecuados para comprobar que la API restringe el acceso y devuelve un 403 Forbidden.

Documentation (Documentación)

En nuestro rol es importante validar la documentación de lo que probamos, determinar si es de fácil acceso, tiene claridad y organización. Esta revisión busca asegurar que la información necesaria sea eficientemente localizable, que tenga coherencia y cuente con ejemplos que ayuden a detallar la funcionalidad de la API.

Ejemplo: Confirma que la documentación de /api/usuarios detalla claramente cómo realizar peticiones y qué respuestas esperar, en consideración de ejemplos de solicitudes y posibles errores.

Conclusión

En conclusión, el panorama cambiante del mercado global de pruebas de API exige una adaptación y mejora continua de las estrategias de prueba. 

Al adoptar una combinación de estas heurísticas y aprovechar las últimas herramientas de prueba de API, los equipos de prueba pueden potenciar sus APIs para ofrecer el rendimiento, la seguridad y la fiabilidad esperados, y cumplir con los altos estándares requeridos en el mundo digital actual.

---

¿Estás buscando un partner de calidad para las pruebas de API?

Somos una de las empresas más confiables en ingeniería de calidad de software. Conoce nuestras soluciones y contáctanos para conversar sobre cómo podemos ayudarte a hacer crecer tu negocio.

¡Síguenos en LinkedIn, X, Facebook, Instagram y YouTube para ser parte de nuestra comunidad!