Vea cómo la solución de calidad continua de Parasoft ayuda a controlar y administrar los entornos de prueba para ofrecer software de alta calidad con confianza. Regístrese para la demostración >>

BLOG

Desafíos y estrategias de prueba de microservicios

Desafíos y estrategias de prueba de microservicios Tiempo de leer: 11 minutos

Los microservicios han sido una tendencia de la industria durante años, pero las organizaciones no están aprovechando los beneficios del enfoque y están luchando con lanzamientos fallidos. Estas fallas a menudo se reducen a la dificultad de probar las interfaces entre los servicios para obtener la calidad, la seguridad y el rendimiento que se espera.

Al final, es un fracaso probar estas API de una manera lo suficientemente sólida. El lado positivo es que los conceptos de prueba y las soluciones entre las pruebas de SOA heredadas y las pruebas de microservicios son los mismos. Si puede resolver sus problemas de prueba de API, puede mejorar sus lanzamientos de microservicios.

Tres pasos clave para realizar pruebas de microservicios eficaces

Una presentación mundial de API

Ver ahora

Los microservicios presentan nuevos desafíos

En estos días, es común ver cientos, si no miles, de microservicios agrupados para definir una arquitectura moderna.

Los sistemas empresariales altamente distribuidos tienen implementaciones grandes y complejas, y esta complejidad en la implementación a menudo se considera una razón para NO implementar microservicios. De hecho, la complejidad dentro del monolito que está descomponiendo se está desmoronando en un entorno de implementación aún más complejo.

Para decepción de los no iniciados, la complejidad en realidad no desaparece y, en cambio, se está transformando en un nuevo tipo de complejidad.

Fitch ofrece alta cobertura de código y calidad para aplicaciones de microservicios

Si bien los microservicios prometen aumentar la eficiencia del desarrollo paralelo, presentan su propio nuevo conjunto de desafíos. Aquí hay unos ejemplos.

  • Muchas más interacciones para probar en la capa de la API, mientras que antes las pruebas de la API se limitaban solo a probar puntos finales expuestos externamente.
  • Obstáculos de desarrollo paralelo que limitan los beneficios de tiempo de comercialización de romper el monolito. Las dependencias de otros servicios y entornos de implementación complejos reducen el paralelismo en la realidad.
  • Impactos en los métodos tradicionales de prueba que tuvieron éxito dentro del monolito (como las pruebas de interfaz de usuario de extremo a extremo) ahora deben cambiar a la capa API.
  • Más puntos potenciales de falla debido a los datos y la computación distribuidos, lo que hace que la resolución de problemas y el análisis de la causa raíz sean difíciles y complejos.

3 pasos clave para las pruebas de microservicios

¿Cuáles son los tres pasos clave para las pruebas de microservicios? Para describirlos simplemente, estos pasos son:

  1. Record
  2. Monitorizar
  3. De Esterilización

El registro, la supervisión y el control lo ayudarán a implementar enfoques de prueba que descubre qué pruebas crear al mismo tiempo que lo ayuda a automatizar las pruebas de componentes cuando hay API posteriores de las que necesita aislarse.

La tecnología que permite hacer esto es la virtualización de servicios. La virtualización de servicios da vida a estos 3 conceptos a través de una característica fundamental: los servidores proxy de mensajes.

El uso de servidores proxy de mensajes en su entorno de implementación le permite monitorear y registrar los flujos de mensajes entre las API, así como también controlar los destinos donde se envían los mensajes.

Proxy de mensaje

¿Cómo funciona un proxy de mensajes?

Está diseñado para escuchar un punto final o cola determinado y luego reenviar los mensajes que recibe a un punto final o cola de destino. Básicamente, es un intermediario para sus API. Usted elige activamente inyectar uno entre sus sistemas integrados. Una vez que esté en su lugar, estará listo para comenzar a aprovecharlo.

Gráfico que muestra un proxy de mensaje que se muestra como un globo terráqueo con papeles volando desde él hacia varias computadoras portátiles a su alrededor. Bajo cero en una computadora portátil que se vincula a burbujas de todas las características clave de la virtualización de servicios, desde la generación de administración de datos de prueba hasta la autenticación y seguridad, y muchas más.
Características clave de la virtualización de servicios

Pruebas de API y microservicios

Probar las API y superar los desafíos que representan no es tan diferente ya sea que su entorno esté altamente distribuido, algo distribuido o mayormente monolítico. Cuanto mayor sea el número de integraciones que existan, más agudos serán algunos de los desafíos, pero los enfoques fundamentales son los mismos.

Al pensar en un API o microservicio como una caja negra, podemos desglosarlo en los clientes de su servicio y las dependencias de su servicio. Probar su API como una caja negra significa que su arnés de prueba está actuando como un cliente para su servicio cuyo trabajo es verificar que recibe las respuestas correctas. Las dependencias son con lo que su servicio necesita integrarse para funcionar correctamente. Se deben realizar optimizaciones tanto en el lado del cliente como entre las dependencias.

Antes de explorar estas optimizaciones, comencemos en la fase de diseño, donde se planifica el microservicio y donde debe comenzar la estrategia de prueba.

El ciclo de vida del microservicio

Fase de diseño: definir requisitos de claridad

Una mejor práctica de desarrollo de API bien aceptada es implementar una definición de servicio durante la fase de diseño. Para los servicios RESTful, se suele utilizar la especificación OpenAPI.

Sus clientes utilizan estas definiciones de servicio para comprender qué recursos y operaciones admite su servicio y cómo su servicio espera recibir y enviar datos. Dentro de las definiciones de servicio para los servicios REST habrá esquemas JSON que describen la estructura de los cuerpos de los mensajes, para que las aplicaciones cliente sepan cómo trabajar con su API.

Pero las definiciones de servicio no solo son importantes para ayudar a otros equipos a comprender cómo funciona su API, sino que también tienen un impacto positivo en su estrategia de prueba.

Puede pensar en la definición de servicio como un contrato. Esa es la base para comenzar a construir una estrategia para el gobierno de API. Uno de los mayores desafíos en las pruebas de API, al igual que cualquier prueba de software, es lidiar con el cambio.

Con la popularidad de las prácticas ágiles, el cambio nunca ha sido tan rápido. Hacer cumplir estos contratos es el primer paso para poner orden en el caos cuando intentas pelear con muchos equipos que están creando API y luego esperan que todas estas API funcionen bien entre sí.

Validación y cumplimiento de contratos

¿Cómo se hace para hacer cumplir un contrato?

Como parte de cualquier suite de regresión automatizada, debe verificar si la definición de servicio que ha escrito su equipo tiene algún error. Swagger y OpenAPI tienen sus propios esquemas que definen cómo se debe escribir la definición del servicio. Puede usarlos para automatizar estas comprobaciones al principio del ciclo de vida de desarrollo de la API.

Luego, además de verificar el contrato en sí, desea verificar que las respuestas que devuelve su servicio también se ajusten al contrato. Su marco de prueba de API debe tener soporte incorporado para detectar instancias en las que su API devuelve una respuesta que se desvía del esquema de definición de su servicio.

Piensa en esto, de esta manera. Un automóvil se compone de miles de piezas individuales que deben encajar perfectamente.

Si el equipo responsable de la unidad de potencia entrega un motor que se desvía de las especificaciones de diseño, es probable que tenga grandes problemas cuando intente conectar la transmisión que construyó un equipo diferente porque estaban haciendo referencia al diseño del motor para saber donde los pernos deben alinearse.

Eso es lo que estás buscando aquí. Estos son los tipos de problemas de integración que un buen gobierno de API puede ayudarlo a evitar. Diseñar y cumplir con estos contratos debe ser una de las primeras preocupaciones de su práctica de prueba de API.

Los contratos de definición de servicios también pueden ayudar a que su proceso de prueba sea más resistente al cambio. El tiempo que lleva refactorizar los casos de prueba para los cambios en una API podría tener un gran impacto en las pruebas, de modo que se excluya del sprint.

Esto es un riesgo tanto para la calidad como para la seguridad. También significa tiempo no programado para pruebas adicionales. Cuando se usa un marco de prueba de API, debe ayudar a los equipos a refactorizar en masa los casos de prueba existentes a medida que cambia el diseño de una API para que puedan mantenerse al día con el ritmo rápido de las pruebas ágiles y en sprint. Los contratos de servicio y las herramientas adecuadas pueden hacer que esto sea mucho menos doloroso.

Fase de implementación: aplicar las mejores prácticas

El desarrollo de microservicios no implica un pase gratuito para omitir las pruebas unitarias. El código es código y las pruebas unitarias son una práctica de calidad fundamental. Ayuda a los equipos a detectar regresiones de forma rápida, temprana y de una manera que los desarrolladores pueden corregir fácilmente, sin importar el tipo de software.

La fea verdad es que los equipos de software con prácticas de prueba unitaria inexistentes o reactivas tienden a tener resultados de mala calidad. Los gastos generales de las pruebas unitarias se consideran demasiado y, por lo tanto, muchos gerentes y líderes no le dan prioridad.

Esto es desafortunado porque el mercado de herramientas ha madurado donde la vida de un desarrollador es mucho más fácil y más productiva mientras que las pruebas unitarias y la compensación entre costo y calidad es mucho menor de lo que solía ser. Las pruebas unitarias forman la base de una práctica de prueba sólida y no deben ser defraudadas.

Además, las prácticas de calidad del software para desarrolladores han madurado con estándares de codificación dedicados para el desarrollo de API. En 2019, la organización internacional sin fines de lucro OWASP lanzó el OWASP Top 10 API Estándar de seguridad.

Los estándares de codificación como este ayudan a los equipos de microservicios a evitar antipatrones comunes de seguridad y confiabilidad que podrían introducir riesgos comerciales en sus proyectos. Intentar adoptar un estándar de codificación sin herramientas es casi imposible.

Afortunadamente, las herramientas modernas de análisis estático, también conocidas como herramientas de prueba de seguridad de aplicaciones estáticas (SAST), se mantienen al día con los estándares de la industria y serán compatibles con este estándar. Los desarrolladores pueden escanear su código mientras lo escriben y como parte de su proceso de integración continua para asegurarse de que no se pierda nada.

Fase de prueba de componentes: uso de proxies para dependencias de API

La prueba de componentes implica probar su microservicio de forma aislada. Lograr un verdadero aislamiento tiene desafíos como saber qué hacer con las dependencias de su microservicio. Además, una de las cosas más difíciles de anticipar como desarrollador de microservicios es comprender exactamente cómo otros sistemas utilizarán su API.

Es probable que las aplicaciones cliente de su API encuentren usos creativos de sus microservicios que nunca se consideraron. Esto es tanto una bendición comercial como una maldición de ingeniería, y exactamente por qué es importante gastar energía para comprender los casos de uso de su API.

El control de la API durante la fase de diseño es un primer paso importante, pero incluso con contratos bien definidos y la validación automatizada del esquema de las respuestas de su microservicio, nunca podrá predecir por completo cómo van las necesidades del producto de extremo a extremo. evolucionar y cómo afectará eso a los microservicios dentro de su dominio.

La grabación, el monitoreo y el control lo ayudarán a implementar enfoques de prueba que descubran de manera eficiente qué pruebas se necesitan y, al mismo tiempo, lo ayudarán a automatizar las pruebas de componentes cuando haya API posteriores de las que necesite aislarse. La tecnología habilitadora hacer esto es virtualización de servicios.

La virtualización de servicios da vida a estos tres conceptos a través de una característica fundamental: los servidores proxy de mensajes. El uso de proxies de mensajes le permite monitorear y registrar los flujos de mensajes entre las API, así como controlar los destinos donde se envían los mensajes.

Gráfico que muestra cómo se ubica el proxy de mensajes entre el cliente de la API y el extremo de la API con d para registrar, monitorear y controlar el tráfico de la API.
Un proxy de mensajes se ubica entre los clientes y los puntos finales para registrar, monitorear y controlar el tráfico de la API.

Servicios orquestados vs coreografiados

Los servicios orquestados y coreografiados (o reactivos) son términos sofisticados que describen patrones de mensajería síncrona o asíncrona.

Si su servicio se comunica mediante un agente de mensajes con protocolos como AMQP, Kafka o JMS, entonces está probando un servicio coreografiado o reactivo.

Si está probando una interfaz REST o GraphQL, es un servicio orquestado o síncrono.

A los efectos de esta publicación, realmente no importará con qué protocolo y patrón de intercambio de mensajes se esté enfrentando. Sin embargo, es posible que le resulte más difícil aplicar estos principios con la mensajería asíncrona si su marco de pruebas de API no es compatible con los protocolos que su organización ha elegido adoptar.

Capturar escenarios de uso del cliente

Es difícil para un equipo de microservicios predecir cómo otros equipos usarán su API. Sabemos que las pruebas totalmente integradas y de extremo a extremo son costosas y lentas. El uso de las capacidades de proxy de mensajes que se encuentran en las herramientas de virtualización de servicios le permite registrar el tráfico proveniente de las aplicaciones cliente ascendentes para que pueda capturar escenarios de uso realistas que mejoran significativamente su conocimiento de qué pruebas deben ejecutarse dentro de su canalización de CI/CD sin requerir que esas aplicaciones cliente estar siempre presente para desencadenar ese tráfico.

En otras palabras, la grabación le permite reproducir estos escenarios de integración para pruebas de regresión automatizadas que son mucho más simples y fáciles de administrar que pedirles a los clientes que ejecuten sus pruebas, que prueban transitivamente su API. Esta es la razón por la que las herramientas que combinan la virtualización de servicios con las pruebas de API son tan populares. Facilitan el registro de este tráfico de API y luego lo aprovechan para pruebas de escenarios de API que están bajo su control.

Gráfico que muestra un monitor a la izquierda que genera tráfico de API que se dirige a un proxy de mensajes y luego a otro monitor a la derecha que muestra un escenario de prueba de API.
Los clientes generan tráfico de API que se registra mediante servidores proxy de mensajes. Este tráfico se organiza en escenarios de prueba de API.

Hacer que las dependencias sean manejables

Probar su servicio rápidamente se vuelve difícil debido a su dependencia de otras API en un entorno de prueba, lo que genera problemas de disponibilidad, datos de prueba realistas y capacidad.

Esto puede hacer que el esfuerzo de prueba quede fuera del sprint y dificultar que los equipos detecten problemas de integración lo suficientemente pronto como para que tengan tiempo de resolverlos. Este es el caso de uso tradicional para la virtualización de servicios, donde la tecnología permite simular o simular las respuestas de las API descendentes (al hacerlo, crea una versión virtual del servicio) proporcionando aislamiento para que pueda probar completamente su API antes y más fácilmente con su canalización de CI/CD.

Gráfico que muestra a una persona de control de calidad, un desarrollador y un ingeniero de pruebas de rendimiento que intentan probar un microservicio en un entorno real con su costo, limitaciones de datos de prueba y limitaciones de capacidad.
Intentar probar un microservicio en su entorno real es difícil debido a la falta de implementación paralela, las limitaciones de los datos de prueba y la falta de capacidad.

Cuando los proxies de mensajes se implementan en un entorno, los equipos pueden registrar el tráfico de la API y luego crear servicios virtuales que respondan fiel y realistamente al microservicio (incluidas las transacciones con estado en las que la dependencia simulada debe manejar correctamente las operaciones PUT, POST y DELETE) sin tener la información real. dependencia disponible.

La virtualización de servicios con estado es una característica importante para crear el servicio virtual más realista que cubra todos sus casos de uso de prueba.

Gráfico que muestra servicios de pruebas de ingenieros de pruebas de rendimiento, desarrolladores y personas de control de calidad utilizando la virtualización de servicios para un entorno de pruebas realista.
La virtualización de servicios desvincula el servicio bajo prueba del entorno operativo y, al mismo tiempo, proporciona un entorno de prueba realista.

Fase de prueba integrada: control del entorno de prueba

Ahora vamos a alejar un poco más el alcance de la prueba a la prueba de integración. En esta etapa, a veces denominada prueba de integración del sistema o etapa SIT, el entorno de prueba es un entorno similar al de producción que garantiza que no se pase por alto ningún defecto.

Debe esperar que los proxies de mensajes proporcionen control sobre si desea una conexión aislada o del mundo real a las dependencias. Otro aspecto del control es asegurarse de que los servidores proxy de mensajes se puedan administrar fácilmente a través de la API. Las organizaciones con una gran madurez en sus procesos de CI/CD están automatizando los flujos de trabajo de implementación y destrucción en los que el control programático del proxy de mensajes es un requisito imprescindible.

¿Qué optimizaciones puede extraer de la visibilidad, u observabilidad, que exponen los servidores proxy de mensajes cuando se encuentra en la fase de prueba de integración?

Aquí es donde las capacidades de monitoreo son esenciales para una solución de virtualización de servicios que admita pruebas automatizadas. El monitoreo de los proxies de mensajes expondrá el funcionamiento interno de estos flujos de trabajo complejos para que pueda implementar una mejor prueba que le diga dónde está el problema, no solo que existe un problema.

Considere, por ejemplo, un sistema de procesamiento de pedidos que necesita verificar múltiples servicios posteriores como sistemas de inventario, facturación y envío para cumplir con un pedido. Para una entrada de prueba dada, puede afirmar contra cierto comportamiento detrás de escena que ayuda a los desarrolladores a identificar por qué falla una prueba. Cuando su equipo dedica menos tiempo a averiguar por qué ocurrió un problema, tienen más tiempo para solucionarlo.

Gráfico que muestra el flujo de integración de socios para el flujo de trabajo de pedidos de compra para microservicios de productos, facturación y envío.
La virtualización de servicios permite la afirmación del comportamiento para ayudar a probar o depurar escenarios que serían difíciles de replicar en un entorno operativo.

Otras aplicaciones

Las interfaces de usuario web y móviles modernas se construyen sobre las API y aquí se encuentra otra oportunidad para capturar el tráfico de API de las pruebas de interfaz de usuario para ayudarlo a impulsar las pruebas de escenario de API. Es posible que estas API frontend no estén bien documentadas o probadas en comparación con los servicios principales de su arquitectura, ¡pero esa es una razón más para probarlas!

Traducir una prueba de IU de un extremo a otro en su prueba de API correspondiente puede ser una tarea abrumadora si se realiza manualmente. AI puede reducir significativamente la inversión de tiempo en esta tarea cuando se utiliza la herramienta adecuada.

Las API se han convertido en la base de cómo las organizaciones brindan funcionalidad a sus usuarios rápidamente. Pero la funcionalidad no es la única preocupación que mantiene a su administración despierta por la noche.

Resistencia, actuacióny seguridad son todos requisitos no funcionales que continúan captando la atención del público con titulares aterradores. Muchas organizaciones tienen iniciativas de cambio a la izquierda para tratar de reorganizar su proceso de entrega de software para dar cuenta de estas altas prioridades. El uso de un marco que sea adecuado para cubrir las pruebas funcionales y no funcionales sin la necesidad de conglomerar media docena de herramientas reducirá los gastos generales de las pruebas.

Desmitificando los Microservicios

Los microservicios llegaron para quedarse. Desafortunadamente, las organizaciones no están aprovechando los beneficios del enfoque. Todo se reduce a la dificultad de probar las interfaces entre los sistemas distribuidos (es decir, las API) para obtener la calidad, la seguridad y el rendimiento que se espera.

Lo que se necesita es un enfoque para las pruebas de microservicios que permita el descubrimiento, la creación y la automatización de pruebas de componentes. Las tecnologías habilitadoras son servidores proxy de mensajes y virtualización de servicios que están estrechamente integrados con un marco de prueba de API rico en características.

Los proxies de mensajes permiten registrar el tráfico de API, monitorear para descubrir escenarios y casos de uso, y controlar para administrar y automatizar conjuntos de pruebas de API. Junto con la virtualización de servicios, las pruebas automatizadas de microservicios se convierten en una realidad alcanzable.

Tres pasos clave para realizar pruebas de microservicios eficaces

Vea la presentación bajo demanda ahora

 

Escrito por

Wilhelm Haker

Wilhelm Haaker, director de ingeniería de soluciones de Parasoft, administra un equipo global de ingenieros de soluciones dedicados a las soluciones web y en la nube de Parasoft. Su equipo ayuda a las organizaciones a modernizar sus procesos de prueba y desarrollo de software y a optimizar la automatización de pruebas para iniciativas de transformación Agile, API first y migración a la nube.

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