Seminario web destacado: Presentación de la prueba CT de Parasoft C/C++ para pruebas continuas y excelencia en el cumplimiento | Vea ahora

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

Logotipo del cubo de Parasoft 300x300
Abril 14, 2020
8 min leer

Se puede evitar tener un software que no se comunique bien con otros servicios a través de la API si se toma en serio las pruebas de API en su organización. Aquí, descubrimos cómo la automatización puede ayudarlo a crear conjuntos de pruebas de API de alta cobertura. Siga leyendo para obtener más información.

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 integrales para identificar defectos en múltiples capas de su aplicación y garantizar una experiencia perfecta para el cliente. Tipos de 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 la derecha Herramientas de prueba API y procesos implementados, su equipo obtendrá todos los beneficios de la automatización. Sin ellos, las pruebas de API pueden volverse abrumadoras rápidamente.

Para Agencias y Operadores

  • 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 múltiples API. Algunos son muy conocidos. Algunos incluso podrían estar documentados. A menudo hay muchas piezas móviles bajo el capó que dificultan el inicio de las pruebas de API.

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.

Con herramientas como Parasoft Recorder, puede capturar y modelar las interacciones API que ocurren debajo del capó de la aplicación. Luego, el Generador de pruebas de API inteligente de SOAtest utiliza inteligencia artificial para organizar el tráfico complejo en patrones de uso de API. Esto hace posible crear un conjunto de pruebas de API utilizando pruebas de interfaz de usuario web para extraer, filtrar y crear escenarios de prueba de API.

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 el análisis del tráfico de la API en escenarios de prueba se extienden a las pruebas de interfaz de usuario automatizadas con herramientas como Selenium. Cualquier uso de la aplicación que inicie llamadas a la API, ya sea de forma manual o automática, se puede utilizar para crear pruebas de API. También es posible vincular escenarios registrados a 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 especificación API, la mayoría de los servicios tienen una definición en un documento Swagger o WSDL. SOAtest puede leer estas definiciones y crear una plantilla de escenario de prueba API. Incluye un caso de prueba para todos los clientes en 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 ninguna. Saber dónde faltan pruebas nos permite dirigir nuestros esfuerzos a una prueba ascendente basada en la definición del servicio, o posiblemente a 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 anda 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.

Desafíos y mejores prácticas de las pruebas de API