¿Qué son las pruebas de API? Guía de pruebas de API

Comprender las pruebas de API de una manera significativa puede desbloquear el poder para crear una estrategia de prueba verdaderamente efectiva. En esta guía, aprenda qué son las pruebas de API, incluidos los diferentes tipos de pruebas de API, para asegurarse de que sabe cómo probar API de manera efectiva.

En una implementación reciente, estaba trabajando con un cliente para crear una estrategia de prueba de API cuando, de repente, me preguntaron: "¿Qué son las pruebas de API?" Entonces me di cuenta de que las pruebas de API son sorprendentemente difíciles de describir, e incluso cuando las describen, tienden a sonar aburridas y complicadas.

Bueno, estoy aquí para decirles que las pruebas de API NO son aburridas ni complicadas. En realidad, es muy divertido y poderoso, y comprenderlo de una manera significativa desbloquea el poder de crear una estrategia de prueba verdaderamente efectiva. Para comprender realmente cómo realizar pruebas de API, siga leyendo.

¿Qué es una API y cómo la uso?

En el desarrollo de servicios, una interfaz de programa de aplicación (API) es una forma en que varias aplicaciones se comunican entre sí utilizando un lenguaje común, a menudo definido por un contrato. Ejemplos de estos serían un documento Swagger para servicios RESTful o un WSDL para servicios SOAP. Incluso las bases de datos tienen un lenguaje de interfaz, es decir, SQL.

Al igual que la interfaz de usuario permite que un ser humano interactúe con una aplicación, las API permiten que las máquinas se comuniquen entre sí de manera eficiente.

Las API son excelentes porque representan bloques de construcción que los desarrolladores pueden usar para ensamblar fácilmente todo tipo de interacciones sin tener que reescribir una interfaz cada vez que necesitan máquinas para comunicarse. Además, dado que las API tienen contratos, las aplicaciones que desean comunicarse entre sí se pueden construir de formas completamente diferentes, siempre que se comuniquen de acuerdo con el contrato de API. Esto permite que diferentes desarrolladores de diferentes organizaciones en diferentes partes del mundo creen aplicaciones altamente distribuidas mientras reutilizan las mismas API.

Cuando un usuario interactúa con el frontend de una aplicación (es decir, una aplicación móvil), ese frontend realiza llamadas API a los sistemas backend, simplificando el proceso de desarrollo de dos maneras principales:

1. El desarrollador no tiene que preocuparse por crear una aplicación personalizada para cada dispositivo móvil o navegador.
2. Se pueden actualizar o modificar diferentes sistemas backend sin tener que volver a implementar la aplicación completa cada vez.

Como resultado, los desarrolladores pueden ahorrar tiempo centrándose en el servicio individual para realizar una tarea discreta, en lugar de dedicar tiempo a escribir la lógica en su aplicación.

Un buen ejemplo de uso de API estándar

Servicios de compras de Amazon ' API documentadas Permitir que los desarrolladores interactúen con las compras de Amazon mientras crean sus aplicaciones. El desarrollador puede utilizar las API de Amazon en los momentos adecuados en su experiencia de usuario, para crear un recorrido del cliente sin problemas.

Por ejemplo, esto podría verse así:

El usuario interactúa con la interfaz de usuario mientras que la aplicación interactúa con las API de Amazon de backend, según lo definido por el desarrollador. Todo funciona muy bien siempre que las API subyacentes se comporten como se espera.

… .Pero eso es un gran si.

Entonces llegamos a la importancia de probar estas API.

¿Qué son las pruebas de API?

Entonces, ¿cómo se realizan las pruebas de API? ¿Qué implica? ¿Cómo hacer una prueba de API? A diferencia del usuario, que interactúa con la aplicación solo en el nivel de la interfaz de usuario, el desarrollador / evaluador debe garantizar la confiabilidad de todas y cada una de las API subyacentes. Sin probar las API en sí, los desarrolladores y probadores se quedarían atascados en las pruebas manuales, al igual que un usuario, probando la aplicación en el nivel de la interfaz de usuario, esperando hasta que se compile toda la pila de aplicaciones antes de poder comenzar a probar.

En su lugar, puede realizar pruebas de API automatizadas probando la aplicación a nivel de API, diseñando casos de prueba que interactúan directamente con las API subyacentes y obteniendo numerosas ventajas, incluida la capacidad de probar la lógica comercial en una capa que es fácil de automatizar en un manera estable. A diferencia de las pruebas manuales, que se limitan a validar una experiencia de usuario específica, las pruebas de API le brindan el poder de proteger su aplicación contra lo desconocido.

¿Cómo realizar pruebas de API?

Diferentes tipos de pruebas de API: dónde, por qué y cómo

La mejor manera de abordar las pruebas de API es construir una práctica de prueba sólida de abajo hacia arriba. Con este fin, una excelente manera de diseñar una estrategia de prueba es seguir las recomendaciones de Martin Fowler. pirámide de prueba. El enfoque piramidal sugiere que cree una amplia gama de pruebas de API (por ejemplo, contrato, escenario, rendimiento, etc.) sobre una base sólida de pruebas unitarias con pruebas de IU. Las pruebas de API le permiten probar la lógica de la aplicación a un nivel que las pruebas unitarias no pueden.

Estas estrategias de prueba son complementarias. Probar antes, en los niveles inferiores de la aplicación, le ayuda a "fallar rápidamente y fallar temprano", detectando los defectos temprano en su origen, en lugar de hacerlo más tarde en el SDLC. Las pruebas unitarias son importantes, pero por ahora estamos enfocados en las pruebas de API. ¿Cómo se prueban las API? ¿Qué tipo de pruebas se pueden realizar? ¿Por qué son importantes? Cómo puedo do Pruebas de API?

Los siguientes son los diferentes tipos de pruebas de API, incluido dónde, por qué y cómo podría usarlas.

Pruebas de contrato

Una API representa un contrato entre dos o más aplicaciones. El contrato describe cómo interactuar con la interfaz, qué servicios están disponibles y cómo invocarlos. Este contrato es importante porque sirve como base para la comunicación. Si hay algo mal con el contrato, nada más importa realmente.

El primer y más básico tipo de pruebas de API son las pruebas de contrato, que prueban el propio contrato de servicio (Swagger, PACT, WSDL o RAML). Este tipo de prueba valida que el contrato esté escrito correctamente y pueda ser consumido por un cliente. Esta prueba funciona mediante la creación de una serie de pruebas que extraen el contrato y validan lo siguiente.

• El contrato de servicio se redacta de acuerdo con las especificaciones.
• Una solicitud de mensaje y una respuesta son semánticamente correctas (validación de esquema).
• El punto final es válido (HTTP, MQ/JMS Topic/Queue, etc.).
• El contrato de servicio no ha cambiado.

Pienso en estos como sus primeras "pruebas de humo". Si estas pruebas fallan, realmente no hay razón para continuar probando este servicio en particular. Si estas pruebas pasan, puede continuar para comenzar a probar la funcionalidad real de la API.

Pruebas de componentes

Las pruebas de componentes son como pruebas unitarias para la API. Desea tomar los métodos individuales disponibles en la API y probar cada uno de ellos de forma aislada. Estas pruebas se crean realizando un paso de prueba para cada método o recurso que está disponible en el contrato de servicio.

La forma más sencilla de crear pruebas de componentes es consumir el contrato de servicio y dejar que cree los clientes. Luego, puede manejar los datos de cada caso de prueba individual con datos positivos y negativos para validar que las respuestas que regresan tienen las siguientes características:

• La carga útil de la solicitud está bien formada (validación del esquema)
• La carga útil de respuesta está bien formada (validación del esquema)
• El estado de la respuesta es el esperado (200 OK, se devolvió el conjunto de resultados de SQL o incluso un error si eso es lo que está buscando)
• Las cargas útiles de error de respuesta contienen los mensajes de error correctos.
• La respuesta coincide con la línea de base esperada. Esto puede tomar dos formas:
  • Regresión / diferencia: la carga útil de la respuesta se ve exactamente igual de una llamada a otra (un enfoque de arriba hacia abajo en el que esencialmente toma una instantánea de la respuesta y la verifica cada vez). Esto también puede ser un gran catalizador para identificar el cambio de API (más sobre esto más adelante).
  • Afirmación: los elementos individuales en la respuesta coinciden con sus expectativas (este es un enfoque más quirúrgico, de abajo hacia arriba, dirigido a un valor específico en la respuesta).
• El servicio responde dentro de un plazo previsto

Estas pruebas de API individuales son las más importantes que puede crear porque se aprovecharán en todas las técnicas de prueba posteriores. ¿Por qué reconstruir casos de prueba cuando simplemente puede hacer referencia a estas llamadas API individuales en todos los diferentes tipos de pruebas en el futuro? Esto no solo promueve la coherencia, sino que también simplifica el proceso de abordar las pruebas de API.

Pruebas de escenario

Las pruebas de escenarios tienden a ser lo que la mayoría de la gente piensa cuando piensan en las pruebas de API. En esta técnica de prueba, usted ensambla las pruebas de componentes individuales en una secuencia, muy similar al ejemplo que describí anteriormente para el servicio de Amazon.

Hay dos grandes técnicas para obtener la secuencia:

1. Revise la historia del usuario para identificar las llamadas API individuales que se están realizando.
2. Ejercite la interfaz de usuario y capture el tráfico que se realiza a las API subyacentes.

Las pruebas de escenarios le permiten comprender si se pueden introducir defectos combinando diferentes puntos de datos.

Me encontré con un ejemplo muy interesante de esto mientras trabajaba con un cliente. Emplearon una serie de servicios para llamar al perfil financiero de un cliente, cuentas disponibles, tarjetas de crédito y transacciones recientes. Cada una de estas llamadas API funcionó individualmente, pero cuando los pones juntos en una secuencia, empezaron a fallar. La razón de esto resultó ser una marca de tiempo simple, que, cuando se devolvió desde una llamada a la API, tenía un formato diferente al esperado en una solicitud posterior. No captaron esto cuando estaban haciendo pruebas unitarias o pruebas de humo porque habían afirmado que se devolvió una marca de tiempo sin especificar el formato. No fue hasta que se probó el escenario general que quedó claro que la transferencia de la marca de tiempo de una llamada a otra causaba la avería.

Otro beneficio de las pruebas de escenarios es la capacidad de validar el comportamiento esperado cuando las API se utilizan de formas inesperadas. Cuando lanza una API, está proporcionando una serie de componentes básicos al mundo. Es posible que haya prescrito técnicas para combinar estos bloques, pero los clientes pueden tener deseos impredecibles y combinar API de forma inesperada para exponer un defecto en su aplicación. Para protegerse contra esto, desea crear muchas pruebas de escenarios con diferentes combinaciones de API para proteger su aplicación contra una falla crítica.

Dado que las pruebas de componentes forman la columna vertebral de las pruebas de escenarios, una organización suele tener un número más amplio de pruebas de escenarios. Se crean cuando se introduce una nueva funcionalidad para modelar el viaje del cliente hacia la nueva característica. Al hacer esto, realmente puede reducir la cantidad de tiempo dedicado a las pruebas porque solo tiene que crear pruebas para la nueva funcionalidad y sabe que tiene una biblioteca confiable de pruebas subyacentes para detectar cualquier cosa inesperada.

Pruebas de rendimiento

Las pruebas de rendimiento generalmente se relegan al final del proceso de prueba, en un entorno de prueba específico de rendimiento. Esto se debe a que las soluciones de prueba de rendimiento tienden a ser caras, requieren conjuntos de habilidades especializadas y requieren entornos y hardware específicos. Este es un gran problema porque las API tienen acuerdos de nivel de servicio (SLA) que deben cumplirse para poder lanzar una aplicación. Si espera hasta el último momento para realizar las pruebas de rendimiento, las fallas en el cumplimiento de los SLA pueden causar grandes retrasos en el lanzamiento.

Realizar pruebas de rendimiento en una etapa anterior del proceso le permite descubrir problemas relacionados con el rendimiento antes de ejecutar su ciclo de regresión completo. Si siguió el proceso de prueba hasta este punto, esto en realidad será bastante fácil porque tiene todos los casos de prueba subyacentes que necesita para realizar las pruebas de rendimiento. Simplemente puede realizar sus pruebas de escenario, cargarlas en su herramienta de prueba de rendimientoy ejecutarlos con un mayor número de usuarios. Si estas pruebas fallan, puede rastrear la falla hasta la historia del usuario individual y tener un mejor nivel de comprensión de lo que se verá afectado. Luego, los gerentes pueden usar este conocimiento para tomar una decisión sobre la liberación de la aplicación.

Pruebas de seguridad

Las pruebas de seguridad son importantes para todas las partes interesadas de su organización. Si se expone y explota una vulnerabilidad de seguridad, puede provocar una pérdida significativa de reputación y sanciones económicas. Al igual que un usuario puede usar accidentalmente sus API de formas que no esperaría, un usuario también puede intentar explotar sus API intencionalmente. Un pirata informático puede hacerse con su API, descubrir vulnerabilidades y aprovecharlas.

Para protegerse contra este tipo de comportamiento, debe crear casos de prueba que intenten realizar este tipo de ataques maliciosos. Puede aprovechar sus casos de prueba existentes para hacerlo, porque una prueba de escenario puede proporcionar el vector de ataque a la aplicación. Luego puede reutilizar este vector de ataque para lanzar sus ataques de penetración. Un buen ejemplo de esto es combinar diferentes tipos de fuzzing de parámetros o ataques de inyección SQL con sus pruebas de escenario. De esa manera, las pruebas de seguridad detectarán cualquier cambio que se propague a través de la aplicación. Visite nuestra página de soluciones para obtener más información sobre Prácticas recomendadas de seguridad de API.

Pruebas omnicanal

Debido a las múltiples interfaces con las que interactúan las aplicaciones (móvil, web, API, bases de datos ...), se encontrará con lagunas en la cobertura de prueba si prueba cualquiera de estas de forma aislada, sin las sutilezas de las complejas interacciones entre estas interfaces.

Las pruebas omnicanal cubren de manera integral las numerosas interfaces de la aplicación para garantizar una cobertura completa de las pruebas, al entrelazar las pruebas de la API y la base de datos en la validación de móvil y interacciones de la interfaz de usuario web. Esto significa realizar una prueba que ejercite una de las interfaces y coordinarla con otra: ejecutar sus pruebas de IU como Web (Selenium) o Móvil (Appium) y entrelazarlas con cualquiera de sus API o pruebas de base de datos, intercambiar puntos de datos de la sistema a través de la ejecución de la prueba. Con pruebas omnicanal efectivas, puede crear casos de prueba estables y reutilizables que se pueden automatizar fácilmente.

Cambio de gerencia

El cambio es uno de los indicadores de riesgo más importantes para su aplicación. El cambio puede ocurrir de muchas formas, que incluyen:

• Cambio de formato de mensaje de protocolo para un servicio
• Elementos agregados o eliminados de una API
• Cambio de código subyacente que afecta el formato de datos devuelto
• Re-arquitectura de un servicio para dividirlo en múltiples partes (extremadamente frecuente a medida que las organizaciones pasan a los microservicios)

A medida que se produce el cambio, es necesario crear casos de prueba para identificar el cambio y proporcionar planes de remediación. Usando una solución que proporciona análisis para abordar el impacto de estos cambios le permitirá comprender qué cambio ha ocurrido y apuntar a las pruebas específicas que se ven afectadas.

El cambio se puede capturar en forma de plantilla, para actualizar cualquiera de los componentes subyacentes o pruebas de escenario con una nueva funcionalidad. Dado que el resto de sus pruebas hacen referencia a estas pruebas, se reducirá el impacto del cambio.

Resumen

Desarrollar una sólida estrategia de prueba automatizada de API es la mejor manera de garantizar que sus aplicaciones “funcionen igual hoy que ayer” (es más que una frase pegadiza). Las pruebas de API le permiten crear un marco sólido para identificar defectos en varias capas de su aplicación. Todas estas pruebas se pueden automatizar y ejecutar continuamente, para que pueda asegurarse de que su aplicación esté alineada con las expectativas comerciales y al mismo tiempo sea funcionalmente precisa. Dado que las pruebas de API funcionan a un nivel mucho más bajo que las pruebas de IU, sabe que tendrá consistencia y las pruebas que está construyendo durarán mucho tiempo.