X
BLOG

Aprovechamiento de la automatización para crear conjuntos de pruebas de API de alta cobertura

Aprovechamiento de la automatización para crear conjuntos de pruebas de API de alta cobertura Tiempo de leer: 8 minutos

Las interfaces de programación de aplicaciones (API) son la capa de servicio de las aplicaciones. Conectan la capa de datos y la capa de presentación (UI), e impulsan la forma en que los usuarios interactúan con las aplicaciones.

Si las API no responden correctamente a la actividad del usuario, la aplicación está rota. Depende de los desarrolladores y evaluadores asegurarse de que las API conectadas funcionen correctamente con su aplicación.

Las pruebas de API son fundamentales para identificar defectos en varias capas de su aplicación y garantizar una experiencia de cliente perfecta. Las pruebas de API incluyen:

  • Pruebas de servicio
  • Pruebas de contrato
  • Pruebas de componentes
  • Pruebas de escenario
  • Pruebas de carga / rendimiento
  • Pruebas de seguridad
  • Pruebas omnicanal

Realizar pruebas de API es un desafío porque requiere un enfoque técnico para diseñar los casos de prueba en función de los distintos formatos y protocolos de mensajes. También requiere una comprensión de las reglas comerciales de la organización para usar correctamente las API correctas juntas. Intentar probar las API mediante un enfoque manual requiere mucho tiempo y puede hacer que las pruebas se pospongan hasta el final del ciclo de desarrollo.

Las pruebas de API automatizadas le brindan el poder de proteger sus aplicaciones contra lo desconocido. Expone errores temprano, evalúa la solidez de la compilación y conduce a lanzamientos de software más rápidos. Dado que las pruebas de API se pueden automatizar y ejecutar de forma continua, puede asegurarse de que su aplicación esté alineada con las expectativas comerciales y, al mismo tiempo, verificar la precisión funcional.

Los pros y los contras de las pruebas API automatizadas

Con las herramientas y los procesos de prueba de API adecuados, su equipo obtendrá todos los beneficios de la automatización. Sin ellos, las pruebas de API pueden volverse abrumadoras rápidamente.

Ventajas

  • Proporciona una automatización sostenible de un escenario de un extremo a otro.
  • Abre canales de comunicación entre desarrollo y prueba.
  • Reduce el tiempo de diagnóstico y reparación.

Desventajas

  • Los evaluadores no saben cómo probar la API o cómo se utilizan.
  • Requiere habilidades y herramientas especializadas para obtener una cobertura de prueba completa.
  • Nadie quiere hacerlo.

Puede superar estos desafíos incorporando tecnología de prueba avanzada en sus pruebas existentes. Primero, veamos la creación de pruebas de API.

El desafío de crear pruebas de API

Uno de los mayores desafíos al establecer una práctica de automatización de pruebas de API es crear pruebas de API. Un obstáculo para comenzar, o expandir un conjunto de pruebas de API existente, es realizar las pruebas adecuadas.

Parte de este problema es el conocimiento de dominio necesario para escribir pruebas API basadas puramente en conocimientos técnicos o especificaciones API documentadas, si es que existen. Este no es el dominio habitual de los probadores. La mayoría de los desarrolladores con los conocimientos necesarios no participan en las pruebas a este nivel. Tienen prioridades en otros lugares.

Considere los dos enfoques complementarios:

  • Enfoque de arriba hacia abajo. Los escenarios de prueba se crean a partir del uso y las pruebas habituales de las aplicaciones.
  • Enfoque de abajo hacia arriba. Las pruebas se basan en la intención del diseño.

Combinando enfoques de arriba hacia abajo y de abajo hacia arriba para la creación de pruebas API

La mayoría de las aplicaciones proporcionan y utilizan varias API. Algunos son bien conocidos. Algunos incluso podrían estar documentados. A menudo, hay muchas partes móviles debajo del capó que hacen que comenzar con las pruebas de API sea un desafío.

En el enfoque de arriba hacia abajo, las interacciones API se descubren a través de la automatización de herramientas como parte del uso habitual y la integración de las pruebas.

El otro ángulo de ataque, un enfoque de abajo hacia arriba, es crear pruebas API basadas en la intención del diseño. Por lo general, es parte de la prueba de componentes y está asistida por herramientas.

La combinación de los enfoques de arriba hacia abajo (pruebas de integración) y de abajo hacia arriba (pruebas de componentes) supera la barrera para la creación de pruebas y aumenta la cobertura de las pruebas de API. Vea la siguiente ilustración.

Creación de pruebas de API por uso

Una de las mejores formas de capturar escenarios de prueba de API es utilizar el uso existente del producto tanto en producción como en prueba. Aprovechando los registros y la reproducción inteligentes, es posible crear escenarios y pruebas reutilizables.

Usando herramientas como SOAtest Generador de pruebas de API inteligente, puede registrar las interacciones de la API que están sucediendo debajo del capó de la aplicación. La herramienta utiliza el aprendizaje automático para organizar el tráfico complejo en patrones de uso de API. Esto hace posible crear un conjunto de pruebas de API utilizando pruebas manuales existentes para extraer, filtrar y crear escenarios de prueba de API utilizando la interfaz de usuario.

SOAtest luego usa AI para identificar patrones y establecer relaciones de datos para crear la plantilla de prueba API. Puede modificar y reutilizar la plantilla con variaciones. Estas pruebas se pueden aprovechar para realizar pruebas de seguridad y rendimiento. Más importante aún, una vez creadas, estas pruebas se desacoplan de la interfaz de usuario y la aplicación subyacente, y sus dependencias se pueden ejercer solo a partir de las pruebas de API.

El registro y análisis del tráfico de API en escenarios de prueba se extiende a las pruebas de IU automatizadas con herramientas como Selenium. Cualquier uso de la aplicación que inicie llamadas a la API, ya sea manual o automatizado, puede usarse para crear pruebas de API. También es posible vincular escenarios registrados con requisitos de trazabilidad.

Una vez registrados, estos escenarios se pueden investigar y modificar dentro de SOAtest como se muestra a continuación.

SOAtest detecta las diversas llamadas a la API y la interacción de datos que se produce. Entonces es posible modificar el escenario y las cargas útiles de datos según sea necesario. Una vez que se comprenden los patrones, se pueden insertar afirmaciones en el escenario para verificar los valores y comportamientos correctos.

La capacidad de crear un conjunto de pruebas API listo para usar basado únicamente en las técnicas de prueba existentes da como resultado la creación rápida de pruebas con la capacidad de reutilizar y extender. Es un atajo a través de uno de los mayores obstáculos para las pruebas de API.

Creación de pruebas de API por diseño (de servicios)

Es posible que esté pensando: “No conocemos el diseño de las API. ¡La mayoría de ellos no están documentados! " En la mayoría de los casos, esto es correcto. Sin embargo, todavía es posible juntar las pruebas de API a partir de la información existente para ayudar a extender la cobertura de las pruebas de API de abajo hacia arriba, al observar las definiciones de servicio y los contratos que son explícitos o implícitos en la aplicación.

En términos de una especificación de API, la mayoría de los servicios tienen una definición en un documento de arrogancia o WSDL. SOAtest puede leer estas definiciones y crear una plantilla de escenario de prueba de API. Incluye un caso de prueba para todos los clientes de la definición. Puede editar y manipular la plantilla para crear pruebas de API significativas.

SOAtest proporciona muchas opciones para crear pruebas sin script a partir de la plantilla, incluidos datos parametrizados basados ​​en números aleatorios o resultados de pruebas anteriores, como se muestra en el ejemplo siguiente.

Usando técnicas simples de copiar y pegar, creación de pruebas sin script, junto con una administración flexible de datos de prueba, SOAtest proporciona una manera fácil de construir conjuntos de pruebas. No pretende reemplazar el enfoque de arriba hacia abajo, sino complementarlo. Cuando a las pruebas manuales o de IU le faltan partes importantes de una API (informadas por los resultados de cobertura), el enfoque de abajo hacia arriba llena estos vacíos. Sin embargo, es difícil determinar qué probar y qué falta sin comprender la cobertura.

Comprensión de la cobertura de su prueba

La cobertura significa varias cosas según el contexto. Por lo general, se trata de cobertura de código, API y requisitos. Debe comprender todo esto para tener una idea clara de cuán completos son sus esfuerzos de prueba.

  • Examen de la unidad. La preocupación es la cobertura del código. ¿Qué parte del código tiene una prueba asociada con su ejecución?
  • APIs Es importante saber cuáles se prueban y hasta qué punto se ha ejercido cada API.
  • Requerimientos. Cada requisito debe tener una prueba que demuestre que está implementado correctamente.

Estas son preocupaciones superpuestas que importan en diferentes momentos durante el ciclo de vida del proyecto. Por ejemplo, si lo que está rastreando es la cobertura de prueba de API, es importante asegurarse de que la prueba cubra adecuadamente las API y aumente las pruebas existentes donde falte. La mejor manera de ver esto es a partir de la definición del servicio, como se muestra en la imagen a continuación.

SOAtest realiza un seguimiento de cada prueba ejecutada y qué API están cubiertas: total, parcialmente o nada. Saber dónde faltan las pruebas nos permite dirigir nuestros esfuerzos en una prueba ascendente basada en la definición del servicio, o posiblemente una nueva prueba basada en la interfaz de usuario, si corresponde. También señala dónde fallan las pruebas (en rojo), dirigiendo nuestra atención a las pruebas que necesitan actualizaciones o que algo está mal en la implantación.

Parasoft DTP (Development Testing Platform) actúa como un repositorio central y un centro para los resultados de varias prácticas de prueba y proporciona una vista de alto nivel de dónde se encuentra el proyecto en términos de los diferentes tipos de cobertura como se muestra en el siguiente tablero.

Esta vista incorpora resultados agregados de análisis de código estático, pruebas unitarias, API y pruebas de IU manuales y automatizadas. Es la gama completa de la pirámide de pruebas. Proporciona una imagen completa de la cobertura de todos los aspectos: API, requisitos y cobertura de código.

Considere la cobertura de requisitos en términos de historias de usuarios guardadas en JIRA. El panel de pruebas funcionales (que se muestra a continuación) incluye un widget de estado de la historia de JIRA, que es una forma de realizar un seguimiento de la cobertura de los requisitos.

Al observar el estado de JIRA más de cerca, la información al pasar el mouse indica el número de pruebas aprobadas, fallidas, incompletas o faltantes sin pruebas.

Puede profundizar más en el informe de trazabilidad detallado para averiguar qué requisitos faltan, qué pruebas fallan, etc.

Puede investigar más profundizando en el informe de trazabilidad para comprender qué pruebas están tocando esta historia.

Además, puede vincular esta cobertura a las API y la cobertura del código según sea necesario. Puede navegar a las pruebas de API desde aquí para determinar dónde se necesitan cambios y qué pruebas adicionales se requieren. Esta vista global y agregada de la cobertura proporciona la imagen más completa del estado de las pruebas. La cobertura de las pruebas "crece" con el tiempo a medida que los desarrolladores convergen en una aplicación completa, y el nuevo código está "cubierto" por la API y las pruebas unitarias creadas para los requisitos asociados.

Resumen

Las organizaciones de desarrollo de software reconocen la importancia de las pruebas de API, pero a menudo tienen dificultades para adoptar la práctica por completo. Parte de la lucha es construir un conjunto de pruebas porque la creación manual de pruebas es compleja y requiere un conocimiento técnico íntimo. Incluso los equipos que adoptan las pruebas de API tienen el desafío de aumentar la cobertura de sus pruebas de API porque muchas de ellas no están documentadas.

Las herramientas de prueba funcional avanzadas como SOAtest pueden ayudar a automatizar la creación de pruebas de API utilizando un enfoque descendente basado en el análisis del comportamiento en uso de las pruebas manuales y el uso regular de la aplicación. Esta generación de pruebas inteligentes ayuda a los equipos a crear pruebas a partir de sus prácticas existentes de forma rápida y sencilla.

Es posible un enfoque ascendente simultáneo y complementario utilizando la automatización SOAtest para crear pruebas sin script a partir de definiciones de servicio. Junto con un análisis de cobertura completo, puede aumentar la cobertura de las pruebas de API a lo largo del tiempo utilizando técnicas de arriba hacia abajo y de abajo hacia arriba. Dado que las pruebas de API funcionan a un nivel mucho más bajo que las pruebas de IU, puede tener la confianza de que las pruebas consistentes y completas que está creando durarán mucho tiempo.

Escrito por

Chris Colosimo

Como Gerente de Producto en Parasoft, Chris elabora estrategias para el desarrollo de productos de las soluciones de pruebas funcionales de Parasoft. Su experiencia en la aceleración de SDLC a través de la automatización lo ha llevado a implementaciones empresariales importantes, como Capital One y CareFirst.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft