Header Ads Widget

Ticker

6/recent/ticker-posts

9 errores comunes cometidos durante las pruebas de API


Las pruebas de API son una faceta importante del proceso de desarrollo de API. Dichas pruebas pueden ayudar a revelar fallas de seguridad importantes, errores de procesamiento de datos e incluso fallas en la funcionalidad básica. Con todo lo dicho, es un hecho lamentable que muchos procesos de prueba de API sean fundamentalmente defectuosos y, debido a esto, los problemas a menudo se mantienen y se extienden mucho más allá de su vida útil razonable.

Hoy, vamos a discutir 9 de los errores más comunes que se cometen durante las pruebas de API . Destacaremos por qué estos errores son importantes y brindaremos algunas soluciones simples para mejorar las metodologías de prueba, los resultados y el estado general de la API.

Esta publicación se inspiró en un documento técnico de APIFortress. Descárguelo aquí y lea nuestra revisión de su oferta de pruebas de API

1: Entradas errantes

Una de las fallas más grandes que puede soportar una API es una falla en la funcionalidad de llamada básica Estos problemas son especialmente frustrantes cuando el problema en cuestión es algo simple que funciona correctamente solo, pero falla cuando se llama con otros recursos.

Ésta es la naturaleza de las entradas erróneas . Las entradas erróneas son esencialmente puntos en el código de API donde una pieza de estrangulamiento, referencia, categoría o función se define incorrectamente como parte de un conjunto pero funciona como un individuo. Cuando surja esta situación, la API parecerá funcionar perfectamente bien, sin arrojar errores en la mezcla. Sin embargo, cuando se prueba el punto final individual, surgen problemas.

Por ejemplo, supongamos que tiene una aplicación de comercio que clasifica los artículos por categoría. Entonces digamos que tiene una gran parte de sus entradas con una entrada 'NULL'. En este caso, mientras que la llamada parece funcionar perfectamente bien, cuando se llama a esa categoría 'NULL' en una API, la prueba falla en la ejecución. Para nuestra aplicación de comercio, lo que esencialmente está sucediendo es un corte drástico de los usuarios de otros recursos. Con una categoría errante como 'NULL', está sacando potencialmente miles de artículos de la tienda de una manera que no se puede buscar.

Solución

Prueba, prueba, prueba. Los problemas simples como una entrada 'NULL' u otro punto de entrada de datos erróneo pueden identificarse fácilmente durante las pruebas iniciales , especialmente cuando se prueban puntos finales únicos. Pruebe tanto en sentido ascendente como descendente, identificando áreas potenciales donde las entradas deficientes y mal formadas podrían estar afectando el estado general de la API.

2: almacenamiento en caché desactualizado

El almacenamiento en caché hace que el mundo de Internet gire. Al guardar datos en un archivo público, los usuarios pueden acceder a los mismos recursos una y otra vez sin agregar carga adicional al servidor y estresarlo más allá de sus capacidades.

Esta es generalmente una mejor práctica, pero como cualquier cosa simple y considerada una mejor práctica, una implementación incorrecta puede ser tan mala como no tenerla en absoluto.

Volvamos a hacer referencia a esa API de comercio electrónico hipotética. El sistema está configurado para almacenar en caché cada 30 minutos con el fin de actualizar el stock y reducir la carga del servidor durante los ciclos ocupados. Hoy, la API está teniendo una venta importante y, debido a eso, se están agregando muchos más elementos de lo habitual al punto final de la lista.

¿El problema? El punto final de la lista se almacena en caché , pero los datos se presentan en forma en vivo a través de un frente web dinámico. Debido a esto, los clientes pueden ver los nuevos datos, pero el almacenamiento en caché mal implementado da como resultado un elemento en el que se puede hacer clic, una imagen e incluso una descripción, todo lo cual, cuando se hace clic, conduce a una página 404; la resolución para ese punto final no ha aún se ha almacenado en caché.

Solución

Considere cómo el usuario va a interactuar con su API. ¿Revisarán un artículo cada 30 minutos durante una venta, o el tráfico será más alto que nunca, lo que resultará en una mayor interacción? Si ese es el caso, la configuración de almacenamiento en caché anterior que se usó para un flujo de tráfico medio durante un período de tiempo prolongado, obviamente, no va a manejar un flujo de tráfico alto en un período de tiempo muy corto.

Pruebe la API como si fuera un consumidor. Llegue a todos los puntos finales que pueda imaginar de tantas formas como pueda. Agregue entradas, elimínelas e intente manipularlas. Si en algún momento su experiencia se ve obstaculizada, corríjala para que el futuro cliente real no enfrente el mismo problema.

3: campos no válidos

Otro gran problema en el espacio de la API es que los datos se devuelven de una manera incorrecta e inesperada. Las aplicaciones siempre tienen sus peculiaridades y salvedades únicas, y debido a esto, los pequeños problemas pueden de hecho convertirse en grandes desastres dadas otras integraciones.

Por ejemplo, al devolver un objeto URL, los desarrolladores suelen preferir devolver HTTP o NULL como respuesta. Sin embargo, si esta respuesta tiene un formato incorrecto y devuelve HTTP: NULL, muchas aplicaciones, dispositivos o navegadores de terceros lo leerán como una URL válida, intentando navegar hasta el recurso.

Obviamente, esto no es ideal por varias razones y crea inconsistencias en las pruebas. Una aplicación de prueba puede encontrar esto aceptable, analizando HTTP: NULL como una dirección válida, mientras que otra aplicación de prueba determinará, correctamente, que es un campo no válido.

Solución

Validez de campo de prueba con permutación tras permutación. Cuanto más duro sea su API ahora, más fácil será lidiar con las fallas a largo plazo. Las máquinas deben estar adiestradas, no tienen un conocimiento intrínseco y, por lo tanto, deben ser guiadas hacia un comportamiento correcto ante ciertos estímulos.

Como parte de esto, la documentación adecuada es clave. Una API es tan buena como su documentación (o tan buena como su entorno de pruebas y virtualización ). Los usuarios deben saber qué esperar para poder codificarlo. Si los desarrolladores y los usuarios saben que deben esperar HTTP o NULL, cuando se devuelve HTTP: NULL debido a peculiaridades en un sistema específico, se puede resolver automáticamente correctamente.

Para obtener ayuda sobre la construcción de documentos, consulte nuestra Guía definitiva para más de 30 soluciones de documentación de API

4: falsos negativos

Parte de la naturaleza fundamental de las pruebas es la expectativa de un resultado positivo o negativo. Independientemente de la naturaleza y el modo de prueba, todo el propósito es obtener respuestas concisas, confiables y repetibles. Desafortunadamente, el desarrollo a veces se interpone en esto.

Cuando se utilizan API, una respuesta de 200 indica que todo está bien: es el "todo claro" universal. Sin embargo, al desarrollar una API, muchos proveedores pondrán el estado predeterminado en 200, lo que significa que un error NULL u otra falla en respuesta aún devolverá un 200.

Para el desarrollador de API, nada se ve mal. Para los sistemas de prueba, están obteniendo las respuestas esperadas. Sin embargo, para el usuario, todo dice que está bien, pero claramente no lo está.

Este tipo de falso positivo es increíblemente dañino porque no permite que el desarrollador vea errores cuando ocurren. Es como intentar completar un rompecabezas en la oscuridad. Eso es básicamente imposible y rompe todo el propósito del rompecabezas. Lo mismo ocurre con las API.

Solución

En esta industria, a menudo evaluamos la confiabilidad de la API con el tiempo de actividad y el estado . Sin embargo, eso no es del todo correcto. Más bien, deberíamos poner más énfasis en el tiempo de actividad funcional ; el momento en que una API funciona correctamente. Para hacerlo, verifique sus respuestas de error con frecuencia y asegúrese de que realmente se comporten como deberían.

Más importante aún, evite los atajos en su código base. 200 respuestas deben reservarse solo para respuestas positivas, no como una respuesta estándar. Las respuestas, para el caso, deben ser claras, concisas y relacionadas con el tema en cuestión.

Como parte del tema continuo a lo largo de esta pieza, pruebe y pruebe con frecuencia. Solo a través de pruebas rigurosas y constantes se pueden descubrir estos problemas.

5: Estandarización no estándar

Al desarrollar API, la estandarización es increíblemente útil para el equipo de desarrollo incipiente. Esto puede ayudar a informar cómo deben ejecutarse las cosas, cómo deben verse las llamadas y el comportamiento esperado del idioma. Desafortunadamente, muchos desarrolladores intentan desarrollar fuera del estándar y, a menudo, no comparten estas derivaciones. Lo que termina sucediendo es que la funcionalidad prevista que no es estándar termina siendo considerada un error o problema.

Una declaración indocumentada que muestra números que cambian dentro de un patrón puede parecer aleatoria o derivada de la base del código, cuando en realidad es simplemente una marca de tiempo. Un punto final falla durante la consulta y devuelve "el campo no es válido", cuando la entrada se titula "campo". Para el desarrollador, se preguntan qué campo está vacío, cuando en realidad simplemente no entienden qué está roto.

Esta falta de estandarización podría estar bien para una API interna donde todo es conocido por todos, pero en una API consumida públicamente, esto conduce a la segmentación, confusión y fallas en la comunicación.

Solución

Siga las soluciones conocidas siempre que sea posible. Si bien esta es una respuesta bastante simple, viene con una advertencia: moverse fuera de estas soluciones estándar es perfectamente aceptable, especialmente cuando se requiere una nueva funcionalidad que los lenguajes y prácticas estándar no admiten.

Sin embargo, la clave en este caso es la documentación adecuada . Tome nota de lo que se espera, permite o infiere e intente hacerlo público. La comunicación y la documentación te liberarán.

Para ayudar con la estandarización de API, consulte las colecciones de recursos del libro de estilo de API para diseñadores de API

6: Falla en la comunicación del equipo

Esto trae a colación un buen punto: la falta de comunicación entre equipos dispares es increíblemente dañina. Los equipos a menudo se dividen entre la experiencia del usuario, el desarrollo y las líneas de soporte, y debido a esto, la comunicación entre cada uno es vital.

El fracaso en este ámbito puede provocar problemas en cascada. Si el desarrollo no notifica un cambio de tipo, el soporte técnico puede proporcionar información falsa y perjudicar la experiencia del usuario. Un cambio de interfaz del equipo de UX que no se transmite al equipo de desarrollo podría provocar que la funcionalidad del sitio no funcione y que la mitad de la API sea inaccesible.

Consideremos esa API de comercio electrónico anterior. A medida que la API crece, se agregan nuevos tipos, específicamente para admitir diferentes versiones de la misma película en varios formatos; DVD, Blu-ray, versión del director, etc. Desafortunadamente, el equipo de desarrollo nunca notificó al equipo de UX o al equipo de soporte sobre los nuevos tipos de datos. Debido a esto, la interfaz web no muestra ningún contenido en ninguna de estas tres categorías, lo que obliga a fallar también en las otras categorías debido a que el sistema no está diseñado para tres categorías variables.

Solución

Una vez más, una solución muy simple: la comunicación . Las plataformas de simulación y planos de API pueden mitigar gran parte de los problemas relacionados con las adiciones de conjuntos de características solitarias, y dado esto, realmente no hay razón para agregar características a los recursos de producción sin una comunicación adecuada.

Cuando un plan se configura a través de planos, debe mantenerse y cada revisión debe basarse en ese concepto y ruta de desarrollo. Probar su API con este modelo una vez en producción y luego probar nuevas funciones en la simulación preformada puede ayudar a aliviar la mayoría de estos problemas.

7: compatibilidad

Al agregar nuevas funciones, la comunicación no es lo único que debe preocuparse. Debido a las rutas de desarrollo dispares y, a veces, segmentadas, no garantizar la compatibilidad puede resultar en una funcionalidad defectuosa y grandes problemas de interoperabilidad.

Por ejemplo, volviendo a nuestro ejemplo de comercio electrónico, supongamos que el equipo de desarrollo impulsa un cambio en el código y notifica al equipo de front-end. La interfaz es consciente y afirma que puede admitir la actualización.

Desafortunadamente, nada relacionado con el código se puede buscar ni es interactivo.

Tras la investigación, el equipo descubre que el front-end está diseñado para leer la API estrictamente y contra una versión en caché por motivos de seguridad, y debido a esto, rechazó el nuevo conjunto de funciones, haciendo que los datos sean inaccesibles y, a todos los efectos, inexistentes.

Solución

La producción no es una prueba. Al integrar un nuevo proceso o función, no debe pasar a producción a menos que haya sido probado y preparado rigurosamente para confirmar que hace lo que usted desea que haga. Probar un sistema en un proceso singular, como una API que se ejecuta en un entorno simulado que no refleja la vida real, es esencialmente inútil.

Pruebe lo mismo que lo haría con un activo de producción en vivo y pruebe cada permutación y variación que pueda pensar. Intenta romper el servicio. Asegúrese de que se pueda manejar lo peor, específicamente lo peor que se haya visto activamente en la red antes.

Más sobre piratería informática:  su API es vulnerable si estos 4 riesgos no se mitigan

8: Garantice la legibilidad

El mundo es internacional: millones de interacciones cada día entre varios conjuntos de idiomas y conjuntos de caracteres se ejecutan a través de una amplia y diversa gama de sistemas.

Esto significa una cosa para el proveedor de API: conjuntos de caracteres . Un conjunto de caracteres es un conjunto de letras que admiten un idioma determinado. Umlauts, Hiragana / Katakana y Kanji requieren diferentes conjuntos de caracteres que pueden fallar en una llamada si no están presentes.

Eso no quiere decir que todos los idiomas del mundo deban ser compatibles, pero los idiomas más utilizados serían un gran comienzo. Cuando su API procesa caracteres en inglés, español y chino a diario, garantizar la legibilidad de los datos es primordial.

Solución

Los monitores de carga útil avanzados pueden hacer maravillas para verificar la legibilidad de cada elemento a medida que se ingresa. El saneamiento también puede ayudar, convirtiendo las entradas en ID de usuario u otros identificadores únicos y eliminando las entradas de caracteres especiales. Y, por supuesto, se pueden utilizar conjuntos de caracteres para que estas entradas sean válidas. La solución elegida debe coincidir con los conjuntos de caracteres más comunes.

9: prueba inteligente

Con todo lo que se ha dicho sobre la importancia de las pruebas, quizás el elemento más importante de las pruebas es asegurarse de que sus pruebas sean realmente buenas. Con una prueba mal elaborada, los problemas que surgen entre las relaciones de los elementos o incluso los conjuntos de datos de suma total pueden pasar a primer plano y convertirse en un problema mucho mayor.

Las pruebas con métodos defectuosos también pueden ayudar a dar falsos positivos. Tan peligrosos como son los falsos negativos, los falsos positivos también son increíblemente peligrosos debido al hecho de que crean un entorno en el que los problemas graves se dejan en paz o se ignoran inconscientemente.

Solución

Pruebe inteligentemente . Utilice pruebas que hayan demostrado su eficacia en múltiples aplicaciones y asegúrese de que sea una herramienta de uso común y bien comprobada.

Una de las mejores cosas que puede hacer un desarrollador es crear una API simulada que se haya roto intencionalmente. Al romper la API de una manera conocida y probarla, se puede probar la metodología de prueba en sí. Si sabe que un punto final va a devolver un error, pero en cambio devuelve un 200, sabe con certeza que su metodología es incorrecta.

Recuerde: los resultados de las pruebas son tan buenos como el mecanismo de prueba en sí.

Conclusión: las pruebas inteligentes son vitales para el kit de herramientas de desarrollo de API

La mitad de cualquier batalla es conocer el terreno del campo de batalla. Lo mismo ocurre con el desarrollo de API: saber cuáles son los errores más comunes en las pruebas de API y cómo negarlos es un elemento vital en el conjunto de herramientas de cualquier desarrollador. Si bien hay una amplia gama de problemas adicionales que pueden surgir durante las pruebas de API, estos son, con mucho, los más comunes y, en muchos casos, los más dañinos.

Afortunadamente, teniendo en cuenta estos problemas, muchos de los problemas adicionales se pueden negar mediante correcciones en cascada. Al esperar y resolver adecuadamente estos problemas, el desarrollo de API puede ser un proceso fluido y positivo.

 

Publicar un comentario

0 Comentarios