Header Ads Widget

Ticker

6/recent/ticker-posts

9 tipos de pruebas para realizar en sus API


 El tema de las pruebas de API se usa a menudo de pasada, pero los tipos de prueba de API  exactos  son amplios y variados. Desde pruebas funcionales hasta pruebas de penetración, detección de errores, pruebas de fuzz y más, hay muchas formas de validar el rendimiento y la seguridad de la API. Por esta razón, es un tema que merece una aclaración y una mayor discusión.

Hoy, analizaremos nueve tipos de pruebas de API  y por qué son importantes para los proveedores de API. Veremos lo que estos tipos de pruebas pretenden probar y cómo se implementan generalmente. Luego, analizaremos la idoneidad de cada prueba para casos de uso dados e identificaremos las metodologías de prueba adecuadas.

La importancia de las pruebas de API

Antes de discutir los tipos de pruebas, primero debemos establecer por qué las pruebas son tan importantes. En términos generales, las pruebas deben emplearse para tres propósitos básicos: validar una solución, mantener una solución y erradicar un error. La API más fantástica no tiene ningún valor si no se puede confiar en ella. Por lo tanto, realizar pruebas para validar la implementación es clave.

Cuando se prueba para mantener una solución, lo que realmente se prueba es la implementación de dicha solución y todos los resultados de dicha implementación. Es importante realizar pruebas para ver si la API está utilizando los recursos correctamente, si existen mejores vías para el manejo de datos y otros enfoques similares. Si bien la validación debería resolver la mayoría de estas preocupaciones desde el principio, algunas solo se pueden encontrar durante la implementación, y las brechas de seguridad a veces solo pueden hacerse evidentes una vez que la solución se implementa completamente en el sistema de destino.

Si bien los dos propósitos de prueba anteriores cubren el desarrollo general y la implementación posterior de una base de código, nuestro propósito final, erradicar un error , es muy específico para una vulnerabilidad determinada. Las pérdidas de memoria, la inseguridad y otras preocupaciones similares se pueden abordar directamente con este tipo de prueba y, en muchos aspectos, las pruebas de vulnerabilidad específicas a veces pueden ser más precisas, más efectivas y más completas que las pruebas holísticas generales.

En última instancia, el tipo de prueba que se realiza está directamente determinado por la necesidad de dicha prueba y, como tal, los tipos de pruebas que se discutirán en breve tienen su lugar y propósito en un enfoque mucho más amplio de  las pruebas API holísticas .

Relacionado: Consejos y herramientas para depurar API

9 tipos de pruebas para pruebas API holísticas

Habiendo dicho todo esto, ¿qué tipos específicos de pruebas puede esperar un proveedor de API ejecutar en su código base? Si bien es cierto que existen pruebas especializadas, y no se puede pedir una lista que sea completa en este ámbito, la mayoría de las pruebas encajan ampliamente en una de nueve categorías .

1. Prueba de validación

Las pruebas de validación son uno de los últimos pasos del proceso de desarrollo, pero es una de las pruebas más importantes que se pueden ejecutar. Las pruebas de validación generalmente se realizan al final del proceso de desarrollo básico, específicamente después de que se completa la verificación de las partes y funciones constituyentes de la API. Mientras que muchas de las pruebas que discutiremos a lo largo de este artículo tratan con facetas específicas del código base o funciones específicas, las pruebas de validación son una consideración de mucho más alto nivel .

Las pruebas de validación son esencialmente un conjunto de preguntas simples aplicadas a la totalidad del proyecto. Estas preguntas incluyen:

  • Producto:  ¿Construimos el producto correcto? ¿Es la API en sí misma el producto correcto para el problema que se proporcionó? ¿Experimentó la API algún problema significativo de código o característica que llevó a una implementación de otro modo ajustada y enfocada en una dirección insostenible?
  • Comportamiento: ¿La API accede a los datos correctos de la manera correctamente definida? ¿La API está accediendo a demasiados datos, está almacenando estos datos correctamente dados los requisitos de confidencialidad e integridad del conjunto de datos?
  • Eficiencia : ¿Es la API el método más preciso, optimizado y eficiente para hacer lo que se requiere? ¿Se puede eliminar o modificar cualquier base de código para eliminar las deficiencias en el servicio general?

Todas estas preguntas sirven esencialmente para validar la API como una solución holística , y se realizan después de que la API se desarrolla en función de un criterio establecido y acordado para garantizar la integración correcta del entorno, el cumplimiento de los estándares y la entrega de objetivos y resultados finales específicos. En última instancia, se puede decir simplemente que esta prueba es una garantía de desarrollo correcto frente a las necesidades y requisitos establecidos por el usuario .

2. Prueba funcional

Las pruebas funcionales siguen siendo una metodología de prueba muy amplia, pero son menos amplias que las que se encuentran en las pruebas de validación. La prueba funcional es simplemente una prueba de funciones específicas dentro del código base. Estas funciones, a su vez, representan escenarios específicos para garantizar que la API funcione dentro de los parámetros esperados y que los errores se manejen bien cuando los resultados están fuera de los parámetros esperados.

Las pruebas funcionales son mucho más fáciles de explicar con un escenario. Supongamos que nuestra API procesa música para realizar pedidos a través de un portal en línea. Cuando un usuario busca una canción, busca por Track NameArtist NameEn este caso, las pruebas funcionales adoptan un enfoque en capas y manejan algunos escenarios específicos.

Primero, la función de la API se prueba con las entradas adecuadas , por ejemplo,  Song 2 de Blur . La API valida la solicitud y entrega los resultados esperados. Sin embargo, se necesitan pruebas adicionales; por lo tanto, nuestras pruebas también incluyen erratas, búsqueda de Song2 , song2 o letras de canciones.

Debido a la naturaleza de la prueba, deberíamos esperar algunas respuestas declaradas Deberíamos esperar un error (y por lo tanto, los códigos de error apropiados y las instrucciones de manejo) o una respuesta corregida que contenga el material que solicitamos.

Las pruebas funcionales deben cumplir todos estos puntos; no solo se debe incluir el caso de prueba regular, sino que también se deben implementar escenarios de erratas y casos extremos en el régimen de prueba.

Más sobre pruebas de API: los 9 errores de API más comunes que no se detectan

3. Pruebas de IU

Si bien tanto la validación como las pruebas funcionales están algo generalizadas en sus enfoques, las pruebas de IU son más específicas. La prueba de IU es exactamente lo que dice en la lata: una prueba de la interfaz de usuario para su API y sus partes constituyentes. Esta prueba se ocupa específicamente de la función de la interfaz de usuario, ya sea que esa interfaz sea de naturaleza gráfica o dependa de las llamadas al punto final de la línea de comandos .

En muchos sentidos, esto es menos una prueba de la API en sí, y más una prueba de la interfaz que se vincula con la API y la experiencia del desarrollador al usar esa interfaz. Aunque no es una prueba directa de la API en términos de base de código, esto brinda una visión muy generalizada del estado, la usabilidad y la eficiencia tanto del front-end como del back-end .

De hecho, esta es la razón por la que las pruebas de IU se utilizan a menudo como un sustituto de las pruebas funcionales; en muchos sentidos, esta prueba cumple la misma función, aunque en un sentido menos completo y más general. Dicho esto, este es un enfoque deficiente en las pruebas modernas, y las pruebas de la interfaz de usuario deben limitarse estrictamente a garantizar que la propia interfaz de usuario funcione según lo previsto.

Cabe mencionar que las pruebas de IU web son un subconjunto de este tipo de prueba y se preocupan más por las integraciones de un extremo a otro entre las instancias web que las API que representan. Aunque las pruebas de IU web son de hecho un subconjunto que es distinto de otras pruebas de IU, vale la pena mencionarlo e incluirlo en esta categoría.

Leer más: Prueba automática para la documentación de API

4. Prueba de carga

La prueba de carga es una prueba obsesionada con la realidad: evita deliberadamente lo teórico ( ¿este código funciona en teoría?)  Y se equivoca en lo práctico ( ¿funcionará este código con 1k solicitudes, 10k solicitudes y 100k solicitudes?).  Por lo tanto, las pruebas de carga se realizan normalmente después de completar una unidad específica o el código base en su conjunto, probando si la solución teórica funciona como una solución práctica bajo una carga determinada.

Las pruebas de carga toman algunos escenarios diferentes para garantizar el máximo rendimiento. El primero de estos escenarios se denomina " línea de base " y prueba la API con el tráfico regular teórico que la API espera en el uso normal del día a día. Esto incluye pruebas de tamaño regular salpicadas con algunas solicitudes extremadamente grandes en un esfuerzo por medir cualquier impacto entre los dos tipos de solicitudes en la práctica.

Por lo general, se realiza una segunda prueba de carga con el tráfico máximo teórico . Esto se hace para garantizar que, incluso durante tiempos de carga completa , se disponga de métodos para acelerar las solicitudes de forma segura. Si bien es posible que la API nunca alcance este máximo teórico, al menos es bueno asegurarse de que se pueda alcanzar de manera segura con la API reaccionando de manera adecuada.

Por último, normalmente se realiza una prueba de sobrecarga , probando al máximo teórico y agregando un 10-20% de tráfico adicional en la parte superior. Si bien este tipo de prueba casi anticipa algún tipo de falla, es tanto una prueba de la función de la API como una prueba de la generación y el manejo del código de error integrado en la API y, como tal, casi se convierte en una prueba híbrida. se refiere a lo que ocurre durante la operación de carga alta y cómo se manejan las fallas durante dicha operación de carga alta.

Relacionado: Cómo manejar las API de alto tráfico

5. Tiempo de ejecución / Detección de errores

Este tipo de prueba está completamente relacionado con la ejecución real de la API. Mientras que la mayoría de nuestras otras pruebas se refieren principalmente al resultado de la implementación de la API en un entorno o escenario, esta prueba se ocupa principalmente de los resultados universales de utilizar la base de código API . Estos tipos de pruebas generalmente siguen uno de los siguientes enfoques:

  • Monitoreo : el tiempo de ejecución del código compilado se prueba para detectar varios errores de implementación, fallas del controlador y otros problemas intrínsecos con la implementación para garantizar que no haya inseguridad en la base del código debido a un mal funcionamiento.
  • Errores de ejecución : el código debe responder a las solicitudes válidas de una manera predecible y conocida, y debe fallar las solicitudes no válidas de la misma manera; predeciblemente y con un patrón conocido.
  • Fugas de recursos : las solicitudes no válidas, los comandos desbordados a propósito y otros tipos de solicitudes "ilegales pero comunes" se envían a la API para probar la memoria, los recursos, los datos o las fugas e inseguridades operativas.
  • Detección de errores : el código se somete a situaciones de falla conocidas para garantizar que los errores se detecten, manejen y enruten correctamente.

Tenga en cuenta que muchos de estos podrían considerarse parte de categorías anteriores; esto se debe a que la detección de errores / tiempo de ejecución es una  revisión casi final de los errores conocidos y los problemas generados por pruebas anteriores, y está diseñada para garantizar de manera integral que las resoluciones se hayan aplicado con éxito.

Relacionado: 6 técnicas para un tiempo de actividad del 99,999%

6. Pruebas de seguridad

Las pruebas de seguridad , las pruebas de penetración y las pruebas de fuzz a menudo se lanzan como tres componentes separados de un proceso de auditoría de seguridad mayor y, por esta razón, se analizarán de manera conjunta. Este tipo de pruebas están diseñadas para garantizar que la implementación de la API sea segura frente a amenazas externas .

Las pruebas de seguridad , como se mencionó anteriormente, abarcan pruebas de penetración y fuzz, pero implica pasos adicionales, incluida la validación de las metodologías de cifrado y la validación del diseño de la solución de control de acceso para la API. Esto incluye la gestión de derechos de usuario y la validación de comprobaciones de autorización para el acceso a recursos.

7. Prueba de penetración

Las pruebas de penetración llevan esto un paso más allá, y generalmente son el segundo paso en el proceso de auditoría general. En este tipo de prueba, la API es atacada por alguien que tiene un conocimiento práctico limitado de la propia API para evaluar el vector de amenazas desde una perspectiva externa. Estos ataques pueden limitarse a determinadas funciones, recursos o procesos, o pueden dirigirse a la totalidad de la API y sus partes constituyentes.

8. Prueba de fuzz

Finalmente, las pruebas de fuzz suelen ser un paso posterior en la auditoría de seguridad general y, ciertamente, son menos refinadas que las pruebas penetrantes o las pruebas anteriores mencionadas. En las pruebas Fuzz, cantidades masivas de datos puramente aleatorios, a veces denominados "ruido" o "fuzz", se ingresan a la fuerza en el sistema para intentar un bloqueo forzado , un desbordamiento u otro comportamiento negativo. Esto se hace para probar la API en sus límites absolutos y sirve como el "peor escenario".

9. Pruebas de interoperabilidad y cumplimiento de WS

Si bien esta no es necesariamente una serie común de pruebas, ni es una con la que probablemente se enfrentarán los proveedores de API RESTful , es algo que debería discutirse dado el uso aún amplio de SOAP en el entorno empresarial. La prueba de interoperabilidad y cumplimiento de WS es un tipo de prueba que realmente solo se aplica a las API de SOAP y, específicamente, verifica dos campos generales de función.

En primer lugar, se comprueba la interoperabilidad entre las API de SOAP garantizando la conformidad con los perfiles de interoperabilidad de servicios web . Al cumplir estas pautas y utilizar estas pruebas, se puede confirmar y respaldar la interoperabilidad entre las API de SOAP. Esto también tiene el beneficio adicional de asegurar que sus API sean compatibles con algunos miembros relativamente grandes del consorcio que establecieron estos estándares, incluidos IBM, Microsoft, BEA Systems, Oracle, Intel y más.

En segundo lugar, el cumplimiento de WS- * se prueba para garantizar que estándares como WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security y WS-Trust se implementen y utilicen correctamente. Este es un paso general para garantizar que su implementación SOAP específica coincida con los estándares actuales de la industria y sea segura en sus operaciones.

Pensamientos finales

Es muy común que los profesionales de TI utilicen diferentes términos para describir los numerosos procedimientos de prueba. Intentamos definir qué significan exactamente para obtener una imagen más clara de qué pruebas específicas se podrían aplicar a sus entornos de API.

Si bien no todas estas pruebas serán válidas dada su base de código, implementación y caso de uso específico, es más que probable que al menos algunas de ellas sean estándar para el ciclo de vida promedio de desarrollo de API web.

Dicho esto, la cantidad de pruebas, especialmente aquellas que son propietarias, incluso está creciendo y transformándose para satisfacer las necesidades de la industria moderna. En consecuencia, esta lista debe considerarse una guía general para complementar las pruebas y requisitos específicos de sus acuerdos contractuales y aquellos sistemas que un cliente o socio requerirá para la integración.

¿Nos falta algún tipo de prueba? ¡Háganos saber en los comentarios a continuación!

Publicar un comentario

0 Comentarios