![\"Heur\u00edsticas](\"https:\/\/lh7-us.googleusercontent.com\/jcd78HGHmui3PcgQ7FzhwKwEd2bNcA3IKOHjkRHoSaN9rV8yhX9OTTEdJnPAocElWKT6Nd_xlON07C1JnBeWWLLy8678fvs_1nEiXlKaObI27BZ6Ob2u0tfjTmSNcq6TL4ACMI1qeUXu5XcTw1EbsmE\")
<\/figure><\/div>\n\n\nEn el \u00e1mbito 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\u00f3n con otros sistemas sea fluida. <\/p>\n\n\n\n
Pese a esto, llevar a cabo una evaluaci\u00f3n exhaustiva de todas las funcionalidades de una API puede resultar desafiante, en particular cuando las fechas l\u00edmite est\u00e1n pr\u00f3ximas. En este punto, las heur\u00edsticas para las pruebas de API testing se convierten en una herramienta valiosa.<\/p>\n\n\n\n
Pero, \u00bfqu\u00e9 son las heur\u00edsticas<\/strong>? <\/p>\n\n\n\n Podemos definirlas como principios o estrategias que el equipo de pruebas emplea para analizar de forma efectiva la calidad de una API. <\/strong><\/p>\n\n\n\n En lugar de seguir procedimientos r\u00edgidos y detallados, las heur\u00edsticas ofrecen un enfoque m\u00e1s \u00e1gil y flexible. Esto brinda al equipo de testers la posibilidad de identificar r\u00e1pidamente los problemas y tomar decisiones informadas.<\/strong><\/p>\n\n\n\n Las heur\u00edsticas posibilitan que el equipo de testers identifique de manera r\u00e1pida las \u00e1reas problem\u00e1ticas de una API. Al emplear principios y estrategias espec\u00edficas, el equipo de testers puede focalizar sus esfuerzos en las \u00e1reas m\u00e1s cr\u00edticas, lo cual conlleva un ahorro de tiempo y recursos valiosos.<\/p>\n\n\n\n Las heur\u00edsticas no son reglas r\u00edgidas, sino estrategias flexibles. Esto le permite al equipo de testers adaptarse de manera sencilla a diversos contextos y a los requerimientos espec\u00edficos del proyecto. Adem\u00e1s, las heur\u00edsticas pueden ser ajustadas y mejoradas a lo largo del tiempo, lo cual genera un proceso de pruebas m\u00e1s eficaz y \u00e1gil.<\/p>\n\n\n\n Al emplear heur\u00edsticas espec\u00edficas, 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\u00e1s exhaustiva y ayuda a identificar brechas en la funcionalidad de la API.<\/p>\n\n\n\n A continuaci\u00f3n, te presentamos algunas de las heur\u00edsticas que encontramos a disposici\u00f3n y utilizamos d\u00eda a d\u00eda para mejorar la calidad de las pruebas de API. <\/strong>Muchas de estas tienen puntos en com\u00fan. A\u00fan as\u00ed, cada proyecto y contexto es \u00fanico, por lo cual resulta esencial adaptar y ajustar estas heur\u00edsticas de acuerdo a las necesidades espec\u00edficas.<\/p>\n\n\n\n Dise\u00f1ada por Stuart Ashman<\/a>, 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\u00f3n de errores y la capacidad de respuesta.<\/p>\n\n\n\n Este aspecto se refiere a evaluar si se est\u00e1n utilizando los verbos HTTP de manera adecuada. Lo importante es entender bien cu\u00e1les son las reglas de negocio de la API que est\u00e1s evaluando.<\/p>\n\n\n\n Recordemos los principales verbos HTTP y sus caracter\u00edsticas:<\/p>\n\n\n\n Habitualmente, se utiliza para registrar nueva informaci\u00f3n. <\/p>\n\n\n\n Se utiliza para obtener la informaci\u00f3n. Puede ser un listado o una entidad espec\u00edfica filtrada por alg\u00fan identificador, depende del producto testeado. <\/p>\n\n\n\n Se usa para eliminar registros, pero es importante saber si el borrado es l\u00f3gico (se pone inactivo) o f\u00edsico (se borra completamente). <\/p>\n\n\n\n En general, se utiliza para actualizar toda la informaci\u00f3n de una entidad. <\/p>\n\n\n\n Similar al PUT pero se usa para actualizar solo una parte de una entidad.<\/p>\n\n\n\n Este punto hace referencia a verificar la correcta implementaci\u00f3n de los mecanismos de autorizaci\u00f3n y autenticaci\u00f3n. Esto incluye asegurarse de que las solicitudes est\u00e9n protegidas adecuadamente y que se requieran credenciales v\u00e1lidas para acceder a ciertos recursos.<\/p>\n\n\n\n Recordemos que la autenticaci\u00f3n es un mecanismo para determinar qui\u00e9n eres, es decir, podr\u00e1s autenticarte siempre y cuando el sistema reconozca que te encuentras registrado, mientras que la autorizaci\u00f3n determina a qu\u00e9 recursos puedes acceder.<\/p>\n\n\n\n Aqu\u00ed se examina la integridad y precisi\u00f3n de los datos manejados por la API. Es decir, el enfoque ac\u00e1 es asegurar que la informaci\u00f3n se almacene, procese y transmita de manera correcta seg\u00fan las reglas de negocio establecidas, revisar los tipos o estructuras de datos permitidos, valores permitidos, m\u00e1ximos y m\u00ednimos permitidos y estructuras.<\/p>\n\n\n\n Este punto implica comprobar c\u00f3mo la API maneja los errores. Esto implica evaluar los c\u00f3digos de estado HTTP devueltos en situaciones de error, as\u00ed como la claridad y utilidad de los mensajes de error proporcionados.<\/p>\n\n\n\n Entendiendo las reglas de negocio, podemos utilizar set<\/em> de datos que sabemos que deber\u00edan provocar un error o enviar peticiones mal formadas y evaluar si ese error est\u00e1 siendo tratado adecuadamente, si se responde un c\u00f3digo de error y un mensaje adecuado para esa circunstancia. Por ejemplo, es una mala pr\u00e1ctica que se devuelvan c\u00f3digos de error 500.<\/p>\n\n\n\n Este \u00faltimo punto eval\u00faa la velocidad y eficiencia de la API en t\u00e9rminos de tiempo de respuesta, y verifica que la API sea lo suficientemente r\u00e1pida para satisfacer los requisitos de rendimiento del sistema.<\/p>\n\n\n\n Esta heur\u00edstica fue desarrollada por Amber Race<\/a> y es un acr\u00f3nimo que representa seis \u00e1reas claves que deben tenerse en cuenta para lograr la calidad y la robustez del sistema.<\/p>\n\n\n\n Se refiere a la evaluaci\u00f3n de los par\u00e1metros de cada operaci\u00f3n de la API bajo prueba. B\u00e1sicamente, se trata de experimentar con los datos, pasar par\u00e1metros vac\u00edos, aleatorios, modificar los tipos de datos permitidos, etc. Adem\u00e1s, verificar que el servidor responde adecuadamente.<\/p>\n\n\n\n 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\u00edan ser alg\u00fan mensaje espec\u00edfico seg\u00fan la regla de negocio y validar que cumpla con los requisitos especificados. <\/p>\n\n\n\n Por ejemplo: Si el alta de una persona usuaria s\u00f3lo est\u00e1 permitida si la persona es mayor de edad, al enviar datos de una persona menor, la salida esperada es un mensaje del tipo: \u201cLa persona usuaria no puede ser menor de edad.\u201d<\/p>\n\n\n\n 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. <\/p>\n\n\n\n No siempre ser\u00e1 necesario, hay que entender bien para qu\u00e9 se utilizar\u00e1 la API, en qu\u00e9 otros sistema se debe acoplar o qui\u00e9nes necesitar\u00e1n utilizarla. En este sentido, es una buena oportunidad para evaluar si la documentaci\u00f3n es buena y es comprensible para desarrolladoras y desarrolladores que necesiten integrar un sistema con nuestra API bajo prueba.<\/p>\n\n\n\n Se enfoca en la seguridad del sistema. Adem\u00e1s de la autenticaci\u00f3n y autorizaci\u00f3n, propone dar un paso m\u00e1s y evaluar otros aspectos de la seguridad como el cifrado de datos, y la identificaci\u00f3n de posibles vulnerabilidades. Por ejemplo: verificar si es posible enviar y almacenar un c\u00f3digo Javascript a trav\u00e9s de un POST.<\/p>\n\n\n\n Al igual que en VADER, aqu\u00ed se examina c\u00f3mo 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\u00edmites o usar tipos de datos no permitidos dentro de lo que las especificaciones nos dicen. <\/p>\n\n\n\n Es importante brindar retroalimentaci\u00f3n sobre c\u00f3mo el servidor est\u00e1 comunicando los errores, si los mensajes son claros.<\/p>\n\n\n\n Aqu\u00ed 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\u00ed como, si el borrado de los datos debe ser de forma permanente o es un borrado l\u00f3gico. El acceso a bases de datos puede ser una buena idea para complementar este tipo de pruebas. <\/p>\n\n\n\n Mark Winteringham<\/a>, quien es el autor del libro Testing Web APIs<\/a> distingue entre “Testing the API” (Probando la API) y “Testing Through the API” (Probando a trav\u00e9s de la API). Ambos enfoques implican evaluar el funcionamiento de un servicio web, pero se centran en diferentes aspectos del proceso de prueba.<\/p>\n\n\n\n Probando la API (Testing the API):<\/p>\n\n\n\n Probando a trav\u00e9s de la API (Testing Through the API):<\/p>\n\n\n\n El enfoque que se elija puede depender de diferentes factores, como las herramientas utilizadas y los prop\u00f3sitos espec\u00edficos de la prueba.<\/p>\n\n\n\n Dise\u00f1ado por Karol Szewczak<\/a>, LHTRAFFIC se deriva de Left-handle traffic y proporciona un marco exhaustivo para evaluar aspectos cr\u00edticos de seguridad y funcionalidad en el dise\u00f1o, desarrollo y prueba de APIs. Este enfoque aborda cuestiones que van desde posibles fugas de informaci\u00f3n hasta problemas de inyecci\u00f3n y manipulaci\u00f3n de datos.<\/p>\n\n\n\n Hace referencia a las APIs que pueden estar revelando informaci\u00f3n que no deber\u00edan. Es importante inspeccionar los datos que se transmiten a trav\u00e9s de la red, evaluar si quienes utilizan la API realmente necesitan toda esa informaci\u00f3n y si se est\u00e1n enviando datos sensibles que no deber\u00edan exponerse. <\/p>\n\n\n\n Tambi\u00e9n implica revisar los encabezados de respuesta con el objetivo de asegurar que no revelen detalles sobre los frameworks subyacentes.<\/p>\n\n\n\n Se refiere a APIs que el equipo de desarrollo no pensaba que las personas encontrar\u00edan, pero que son visibles de diversas maneras. <\/p>\n\n\n\n Esto implica verificar si se proporciona un archivo “robots.txt” para prevenir el acceso de rastreadores a recursos importantes, evitar la exposici\u00f3n de puntos finales de administrador, y revisar la documentaci\u00f3n autom\u00e1tica, como Swagger, con el objetivo de asegurarnos de que no revele informaci\u00f3n sensible o APIs privadas.<\/p>\n\n\n\n Estudia el lugar donde se realiza la validaci\u00f3n de los par\u00e1metros enviados con las solicitudes de API. Alerta sobre la posibilidad de manipulaci\u00f3n de datos por parte de un atacante intermedio o un proxy. <\/p>\n\n\n\n Esto significa que si hay un sistema web o m\u00f3vil 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\u00f3digo defensivo necesario para mitigar posibles env\u00edos de par\u00e1metros no permitidos.<\/p>\n\n\n\n Se enfoca en la autorizaci\u00f3n y autenticaci\u00f3n de la API. Como hemos mencionado aqu\u00ed, 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\u00e9 recursos puede acceder. <\/p>\n\n\n\n Es una oportunidad para entender bien el sistema, corroborar que est\u00e9 bien documentado, y responder a diferentes interrogantes. Por ejemplo: qu\u00e9 tipos de autorizaci\u00f3n se admiten, si es posible salt\u00e1rselas (por ejemplo, no pasar un token en las solicitudes), c\u00f3mo se manejan los errores de autenticaci\u00f3n, si se env\u00edan credenciales de manera segura, y si se pueden realizar enumeraciones de usuarios, entre otras consideraciones.<\/p>\n\n\n\n Recomienda realizar pruebas de “fuzzing” en la API utilizando datos malformados o inesperados con el objetivo de detectar posibles vulnerabilidades. <\/p>\n\n\n\n Esto implica probar con diferentes tipos de datos, como n\u00fameros o cadenas, y utilizar herramientas como la “Big List of Naughty Strings”<\/a>. Se trata de una lista en constante evoluci\u00f3n de cadenas de caracteres que tienen una alta probabilidad de causar problemas cuando se utilizan como datos de entrada de usuario.<\/p>\n\n\n\n Explora la posible presencia de encabezados predeterminados que podr\u00edan haber quedado activados por accidente. Tambi\u00e9n subraya la importancia de desactivar la documentaci\u00f3n autom\u00e1tica, como Swagger, en entornos de producci\u00f3n si inicialmente estaba destinada solo al entorno de desarrollo.<\/p>\n\n\n\n Hace alusi\u00f3n a la b\u00fasqueda de posibles inyecciones, como las conocidas inyecciones SQL, y a la evaluaci\u00f3n de diferentes puntos de inyecci\u00f3n, que incluyen encabezados, par\u00e1metros y el cuerpo de la solicitud.<\/p>\n\n\n\n Examina si el encabezado Content-type est\u00e1 alineado con el tipo MIME enviado. Tambi\u00e9n estudia c\u00f3mo responde la aplicaci\u00f3n cuando se env\u00eda un tipo de contenido no compatible y si la API admite varios tipos de contenido.<\/p>\n\n\n\n Creado por Ash Winter<\/a>, no solo busca contemplar aspectos funcionales de la API si no tambi\u00e9n aspectos sobre la performance y la arquitectura del sistema.<\/p>\n\n\n\n Tiene como objetivo evaluar c\u00f3mo los consumidores se integrar\u00e1n con el servicio, cu\u00e1ndo lo har\u00e1n y si est\u00e1 destinado a ser renderizado en un navegador, generado en un archivo u otro m\u00e9todo de consumo.<\/p>\n\n\n\n Busca identificar qui\u00e9nes ser\u00e1n los consumidores del servicio, ya sean humanos o m\u00e1quinas, y comprender qu\u00e9 problema resuelve el servicio para cada consumidor.<\/p>\n\n\n\n Implica analizar la forma del endpoint <\/em>y c\u00f3mo se accede a \u00e9l, si es un solo endpoint<\/em>, m\u00faltiples endpoints o si se enruta a trav\u00e9s de un balanceador de carga. Eval\u00faa el nivel de seguridad aplicado.<\/p>\n\n\n\n Se enfoca en identificar las funciones comerciales que realiza el servicio, si se pueden asignar a funciones actuales realizadas a trav\u00e9s de una interfaz de usuario, si las operaciones tienen nombres descriptivos y son legibles para humanos y m\u00e1quinas, y si manejan datos sensibles.<\/p>\n\n\n\n Implica evaluar si el servicio se utilizar\u00e1 a un alto volumen concurrentemente o de manera espor\u00e1dica con solicitudes \u00fanicas de alto valor, si el tama\u00f1o de las transacciones individuales es un problema, c\u00f3mo se gestionan las sesiones de la API y si la arquitectura objetivo est\u00e1 clusterizada.<\/p>\n\n\n\n Involucra analizar c\u00f3mo el servicio maneja errores en el lado del servidor y del cliente, si los errores son informativos y\/o detallados, y c\u00f3mo se maneja la p\u00e9rdida de conectividad con la base de datos.<\/p>\n\n\n\n Consiste en evaluar si el servicio tiene las caracter\u00edsticas de un servicio RESTful<\/em> y determinar si esto es deseable en el contexto espec\u00edfico.<\/p>\n\n\n\n Se refiere a analizar c\u00f3mo se distribuyen los componentes del servicio, c\u00f3mo interact\u00faan, si pueden existir de manera independiente y si pueden fallar entre s\u00ed.<\/p>\n\n\n\n Implica investigar c\u00f3mo las personas se autentican dentro del servicio, qu\u00e9 permisos son aplicables y c\u00f3mo eso cambia el funcionamiento del servicio, qu\u00e9 niveles de seguridad se utilizan y si los datos se env\u00edan o reciben cifrados.<\/p>\n\n\n\n Tiene que ver con determinar qu\u00e9 define las entradas y salidas del servicio, si se utiliza WSDL, WADL, XSD, XSLT u otro m\u00e9todo, qu\u00e9 l\u00edmites impone esto al servicio y qu\u00e9 m\u00e9todos HTTP se utilizan y con qu\u00e9 prop\u00f3sito.<\/p>\n\n\n\n Se trata de una heur\u00edstica ideada por Gwen Diagram<\/a> y Ash Winter<\/a>. Esta es una heur\u00edstica sencilla que se concentra en verificar el manejo de errores por parte del servidor al igual que otras heur\u00edsticas, pero desglosa en diferentes puntos espec\u00edficos para inducir o forzar esos comportamientos.<\/p>\n\n\n\n Las pruebas de l\u00edmites o “Boundary” hacen referencia a probar la API con valores que est\u00e9n en los l\u00edmites de lo que se supone que la API puede manejar. Esto podr\u00eda implicar probar la API con el valor m\u00e1ximo y m\u00ednimo posible, as\u00ed como con valores ligeramente por encima y por debajo de estos l\u00edmites.<\/p>\n\n\n\n Las “Invalid Entries” consisten en pruebas en las que se usan entradas que no deber\u00edan ser aceptadas por la API. Se realizan con el prop\u00f3sito de verificar que la API maneja adecuadamente las entradas inv\u00e1lidas, ya sea devolviendo un error de una manera controlada o ignor\u00e1ndose.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n En las pruebas de “Method”, se busca comprobar que cada uno de los m\u00e9todos de la API funcione de acuerdo con la documentaci\u00f3n, sean consistentes y predecibles. Esto puede incluir pruebas para los m\u00e9todos GET, POST, PUT, DELETE, etc.<\/p>\n\n\n\n Similarmente a las pruebas NULL, las pruebas “Empty” suponen enviar valores vac\u00edos a la API. Esto puede ayudar a identificar problemas que pueden surgir cuando la API recibe una entrada vac\u00eda.<\/p>\n\n\n\n Las pruebas negativas implican enviar a la API entradas que no son v\u00e1lidas o que se sabe que provocar\u00e1n 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.<\/p>\n\n\n\n Las heur\u00edsticas anteriores cubren de manera exhaustiva los aspectos cr\u00edticos del API testing. Sin embargo, cada heur\u00edstica tiene su fortaleza y enfoque.<\/strong> A continuaci\u00f3n, proponemos otra heur\u00edstica que engloba los aspectos principales y de los cuales es importante hacer \u00e9nfasis, un resumen y un ejemplo de los que recomendamos tener en cuenta en cada punto:<\/strong><\/p>\n\n\n\n Con BAD-VIPERS, los equipos de testing podr\u00edan abordar aspectos funcionales, de seguridad, de rendimiento, aspectos relacionados con la integraci\u00f3n de la API y su documentaci\u00f3n, y as\u00ed ofrecer una visi\u00f3n m\u00e1s hol\u00edstica e integral de la API testing.<\/strong><\/p>\n\n\n\n Para explicar punto a punto la heur\u00edstica y mostrar algunos ejemplos vamos a considerar una operaci\u00f3n 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\u00e1sicos de una persona o usuario de un sistema:<\/strong><\/p>\n\n\n\n Este aspecto se refiere a evaluar si se est\u00e1n utilizando los verbos HTTP de manera adecuada.<\/p>\n\n\n\n Ejemplo: Aseg\u00farate 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\u00fan ser\u00eda permitir la creaci\u00f3n de usuarios con un GET, lo cual es incorrecto ya que violar\u00eda los principios RESTful.<\/p>\n\n\n\n Este aspecto eval\u00faa 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\u00f3n de su prop\u00f3sito y las necesidades de los usuarios.<\/p>\n\n\n\n Ejemplo: Al integrar \/api\/usuarios con \/api\/login, confirma que despu\u00e9s de crear un usuario con POST se pueda autenticar con \u00e9xito a trav\u00e9s del endpoint <\/em>de login<\/em>, con el objetivo de que ambas APIs trabajen juntas de modo coherente.<\/p>\n\n\n\n B\u00e1sicamente, se trata de experimentar con los datos, pasar par\u00e1metros vac\u00edos, aleatorios, modificar los tipos de datos permitidos, etc. Adem\u00e1s, verificar que el servidor responde adecuadamente. Aqu\u00ed se pueden utilizar t\u00e9cnicas como Fuzzing <\/em>utilizando datos malformados o inesperados, con el fin de detectar posibles vulnerabilidades. <\/p>\n\n\n\n Ejemplo: Env\u00eda a \/api\/usuarios una petici\u00f3n POST con un cuerpo como: <\/p>\n\n\n\n { <\/p>\n\n\n\n “username”: “”, <\/p>\n\n\n\n “email”: “test@test.com<\/a>“,<\/p>\n\n\n\n “password”: “12345” <\/p>\n\n\n\n } <\/p>\n\n\n\n para verificar que el servidor maneja adecuadamente los par\u00e1metros vac\u00edos y devuelve un error espec\u00edfico por falta del username<\/em>.<\/p>\n\n\n\n El manejo de errores de la API se examina evaluando los c\u00f3digos 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.<\/p>\n\n\n\n Es esencial analizar c\u00f3mo se gestiona la p\u00e9rdida de conectividad con la base de datos y c\u00f3mo se manejan los errores en el lado del cliente y del servidor.<\/p>\n\n\n\n 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”}.<\/p>\n\n\n\n Un aspecto no tan funcional y si m\u00e1s de performance y sumamente importante es evaluar la velocidad y eficiencia de la API en t\u00e9rminos de tiempo de respuesta. Asegura que la API sea lo suficientemente r\u00e1pida para satisfacer los requisitos de rendimiento del sistema.<\/p>\n\n\n\n Ejemplo: Mide el tiempo de respuesta al hacer una solicitud GET a \/api\/usuarios. Si tarda m\u00e1s de 500ms en obtener una respuesta, investiga y optimiza la eficiencia del endpoint<\/em>. Los resultados pueden sugerir la necesidad de hacer pruebas de performance.<\/p>\n\n\n\n La seguridad en APIs implica explorar APIs privadas o no documentadas y comprobar posibles datos sensibles en la API. La presencia de informaci\u00f3n confidencial en la URL representa riesgos significativos. <\/p>\n\n\n\n Las APIs privadas requieren de medidas de seguridad para limitar su acceso. Es crucial determinar el uso de SSL para lograr la transmisi\u00f3n segura de datos. <\/p>\n\n\n\n Debemos proteger la API para mitigar amenazas como los ataques XSS. Adem\u00e1s de la autenticaci\u00f3n y autorizaci\u00f3n, es esencial evaluar el cifrado de datos y detectar posibles vulnerabilidades, como la posibilidad de enviar c\u00f3digo Javascript a trav\u00e9s de un POST.<\/p>\n\n\n\n Ejemplo: Prueba el endpoint<\/em> \/api\/usuarios enviando una solicitud POST con un payload<\/em> que incluya un script<\/em> malicioso en el campo username,<\/em> para verificar que la API tiene protecci\u00f3n contra ataques XSS.<\/p>\n\n\n\n Es importante entender cu\u00e1l es el comportamiento esperado de la API en t\u00e9rminos generales, entender el negocio y armar un plan de pruebas priorizando los aspectos m\u00e1s cr\u00edticos. <\/p>\n\n\n\n Es importante prestar atenci\u00f3n a las respuestas que emite el servidor, con el fin de validar que sean las esperadas. Mediante el env\u00edo de peticiones dise\u00f1adas seg\u00fan las reglas de negocio, se pueden llevar a cabo pruebas minuciosas que deber\u00edan resultar en respuestas espec\u00edficas del servidor. De esta manera, verificamos que dichas respuestas cumplan con los est\u00e1ndares y requisitos previamente definidos.<\/p>\n\n\n\n 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 \u00e9xito con el ID del usuario creado.<\/p>\n\n\n\n La autenticaci\u00f3n en el testing de APIs se centra en verificar si los mecanismos de identificaci\u00f3n est\u00e1n correctamente implementados. Es esencial que las solicitudes est\u00e9n suficientemente protegidas y necesiten credenciales v\u00e1lidas para el acceso. <\/p>\n\n\n\n Este proceso de autenticaci\u00f3n permite determinar la identidad del usuario, con el fin de que el sistema reconozca \u00fanicamente a los usuarios registrados. Adem\u00e1s, se debe analizar y probar c\u00f3mo se manejan los errores de autenticaci\u00f3n, c\u00f3mo se transmiten los datos de manera segura y c\u00f3mo se manejan las sesiones de usuario.<\/p>\n\n\n\n Ejemplo: Intenta hacer una solicitud GET a \/api\/usuarios\/privado sin incluir un token de autenticaci\u00f3n, para verificar que el sistema rechace correctamente la solicitud y devuelva un 401 Unauthorized.<\/p>\n\n\n\n El testeo de APIs en t\u00e9rminos de autorizaci\u00f3n se centra en comprobar los accesos permitidos a los usuarios. Este proceso es crucial para determinar a qu\u00e9 recursos puede acceder un usuario autenticado. Incluye entender qu\u00e9 tipos de autorizaci\u00f3n se admiten y probar situaciones en las que se intenta eludir la autorizaci\u00f3n.<\/p>\n\n\n\n Ejemplo: Intenta actualizar la informaci\u00f3n 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.<\/p>\n\n\n\n En nuestro rol es importante validar la documentaci\u00f3n de lo que probamos, determinar si es de f\u00e1cil acceso, tiene claridad y organizaci\u00f3n. Esta revisi\u00f3n busca asegurar que la informaci\u00f3n necesaria sea eficientemente localizable, que tenga coherencia y cuente con ejemplos que ayuden a detallar la funcionalidad de la API.<\/p>\n\n\n\n Ejemplo: Confirma que la documentaci\u00f3n de \/api\/usuarios detalla claramente c\u00f3mo realizar peticiones y qu\u00e9 respuestas esperar, en consideraci\u00f3n de ejemplos de solicitudes y posibles errores.<\/p>\n\n\n\n En conclusi\u00f3n, el panorama cambiante del mercado global de pruebas de API exige una adaptaci\u00f3n y mejora continua de las estrategias de prueba. <\/p>\n\n\n\n Al adoptar una combinaci\u00f3n de estas heur\u00edsticas y aprovechar las \u00faltimas 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\u00e1ndares requeridos en el mundo digital actual.<\/p>\n\n\n\n Somos una de las empresas m\u00e1s confiables en ingenier\u00eda de calidad de software. Conoce nuestras <\/strong>soluciones<\/strong><\/a> y <\/strong>cont\u00e1ctanos<\/strong><\/a> para conversar sobre c\u00f3mo podemos ayudarte a hacer crecer tu negocio.<\/strong><\/p>\n\n\n\n \u00a1S\u00edguenos en LinkedIn<\/a>, X<\/a>, Facebook<\/a>, <\/strong>Instagram<\/strong><\/a> y <\/strong>YouTube<\/strong><\/a> para ser parte de nuestra comunidad!<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":" Descubre las mejores estrategias para el testing de APIs en esta gu\u00eda detallada. Aprende a mejorar la estrategia de pruebas abarcando aspectos como la eficiencia, adaptabilidad y seguridad de las APIs mediante las heur\u00edsticas m\u00e1s conocidas y una nueva heur\u00edstica propuesta por nuestro equipo.\u00a0<\/p>\n","protected":false},"author":54,"featured_media":17528,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[143,165,17],"class_list":["post-17299","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-pruebas-software","tag-api-testing","tag-estrategia-pruebas","tag-testing-software"],"yoast_head":"\nVentajas de las heur\u00edsticas para pruebas de API<\/strong><\/h2>\n\n\n\n
1. Eficiencia en la detecci\u00f3n de problemas<\/strong><\/h3>\n\n\n\n
2. Flexibilidad y adaptabilidad<\/strong><\/h3>\n\n\n\n
3. Cobertura exhaustiva<\/strong><\/h3>\n\n\n\n
Heur\u00edsticas conocidas<\/h2>\n\n\n\n
VADER<\/h3>\n\n\n\n
Verbs (Verbos):<\/strong> <\/h4>\n\n\n\n
\n
\n
\n
\n
\n
Authorization\/Authentication (Autorizaci\u00f3n\/ Autenticaci\u00f3n): <\/strong><\/h4>\n\n\n\n
Data (Datos): <\/strong><\/h4>\n\n\n\n
Errors (Errores): <\/strong><\/h4>\n\n\n\n
Responsiveness (Capacidad de respuesta): <\/strong><\/h4>\n\n\n\n
POISED<\/h3>\n\n\n\n
Parameters (Par\u00e1metros): <\/strong><\/h4>\n\n\n\n
Output (Salida): <\/strong><\/h4>\n\n\n\n
Interoperability (Interoperabilidad): <\/strong><\/h4>\n\n\n\n
Security (Seguridad): <\/strong><\/h4>\n\n\n\n
Error Handling (Manejo de errores): <\/strong><\/h4>\n\n\n\n
Data (Datos):<\/strong><\/h4>\n\n\n\n
TATTA<\/h3>\n\n\n\n
\n
\n
LHTRAFFIC<\/h3>\n\n\n\n
Leaky APIs (APIs que filtran informaci\u00f3n): <\/strong><\/h4>\n\n\n\n
Hidden APIs (APIs ocultas): <\/strong><\/h4>\n\n\n\n
Tampering Requests or Responses (Manipulaci\u00f3n de solicitudes y respuestas):<\/strong><\/h4>\n\n\n\n
Authorization or Authentication (Autorizaci\u00f3n o Autenticaci\u00f3n): <\/strong><\/h4>\n\n\n\n
Fuzzing (Pruebas de fuzzing): <\/strong><\/h4>\n\n\n\n
Forgotten (Olvidado): <\/strong><\/h4>\n\n\n\n
Injections (Inyecciones): <\/strong><\/h4>\n\n\n\n
Content-type (Tipo de contenido): <\/strong><\/h4>\n\n\n\n
ICEOVERMAD <\/h3>\n\n\n\n
Integration (Integraci\u00f3n): <\/strong><\/h4>\n\n\n\n
Consumers (consumidores): <\/strong><\/h4>\n\n\n\n
Endpoints: <\/em><\/strong><\/h4>\n\n\n\n
Operations (operaciones): <\/strong><\/h4>\n\n\n\n
Volume (Volumen): <\/strong><\/h4>\n\n\n\n
Error Handling (Manejo de errores: <\/strong><\/h4>\n\n\n\n
RESTful: <\/strong><\/h4>\n\n\n\n
Modularity (Modularidad): <\/strong><\/h4>\n\n\n\n
Authentication (Autenticaci\u00f3n): <\/strong><\/h4>\n\n\n\n
Definitions (Definiciones):<\/strong><\/h4>\n\n\n\n
BINMEN<\/h3>\n\n\n\n
Boundary (L\u00edmites): <\/strong><\/h4>\n\n\n\n
Invalid Entries (Entradas inv\u00e1lidas): <\/strong><\/h4>\n\n\n\n
Nulls (Nulos): <\/strong><\/h4>\n\n\n\n
Method (M\u00e9todo): <\/strong><\/h4>\n\n\n\n
Empty (Vac\u00edo): <\/strong><\/h4>\n\n\n\n
Negatives (Negativos): <\/strong><\/h4>\n\n\n\n
En resumen<\/h2>\n\n\n\n
<\/strong>
<\/strong>Podemos tomar de ellas los puntos en com\u00fan, combinar diferentes puntos relevantes de cada una, as\u00ed como adicionar otros aspectos que en nuestra experiencia consideramos importantes, para generar un marco m\u00e1s completo y diverso. <\/strong><\/p>\n\n\n\nHeur\u00edstica BAD-VIPERS<\/h2>\n\n\n\n
VIPERS<\/strong><\/h3>\n\n\n\n
Verbs (Verbos) <\/strong><\/h4>\n\n\n\n
Integration (Integraci\u00f3n)<\/strong><\/h4>\n\n\n\n
Parameters (Parametros)<\/strong><\/h4>\n\n\n\n
Error Handling (Manejo de errores)<\/strong><\/h4>\n\n\n\n
Responsiveness (Capacidad de respuesta)<\/strong><\/h4>\n\n\n\n
Security (Seguridad)<\/strong><\/h4>\n\n\n\n
BAD<\/strong><\/h3>\n\n\n\n
Behave (Comportamiento)<\/strong><\/h4>\n\n\n\n
Authorization\/Authentication (Autorizaci\u00f3n\/ Autenticaci\u00f3n): <\/strong><\/h4>\n\n\n\n
Documentation (Documentaci\u00f3n)<\/strong><\/h4>\n\n\n\n
Conclusi\u00f3n<\/h2>\n\n\n\n
\n\n\n\n\u00bfEst\u00e1s buscando un partner de calidad para las pruebas de API?<\/strong><\/h3>\n\n\n\n
![\"\"\/](\"https:\/\/lh7-us.googleusercontent.com\/IyDtBcyXOpt2uFnJ8rNpLTtkmmvgouj_xVEsG1Pqzu7nOoguWGZo7D1DVWmB2cCBPF_dNrGPm9Lp_EBlZhergky24d-DrgbV_p6q9AUexGkhlOy5TOA3HRaGcXWJeQHDq1XG7znvr80W3VoVw1kKp90\")