X
BLOG

¿Cuáles son los diferentes tipos de pruebas para microservicios?

¿Cuáles son los diferentes tipos de pruebas para microservicios? Tiempo de leer: 8 minutos

Los métodos completos, precisos y eficientes de probar microservicios son esenciales en el mundo actual orientado a Internet y aplicaciones móviles. En esta pieza, miramos:

  • Qué hacen los microservicios.
  • Cómo lo hacen.
  • Los diferentes tipos de pruebas de software de microservicios disponibles.

Descripción general de microservicios

Cuando una persona interactúa con un sitio web o usa una aplicación, numerosas funciones operan "debajo de la superficie". Cuando compra un producto en Amazon, por ejemplo, compra el artículo, observa el precio, el tamaño, el color y otras opciones. Luego haga su selección y muévase al área de pago.

A partir de ahí, elige las opciones de entrega y pago y finalmente completa la transacción. Mientras tanto, numerosos microservicios están funcionando. Esto incluye la interacción con el cliente, pero también la compleja programación que se ejecuta sin ser vista en la aplicación o el sitio web, lo que hace que la transacción parezca fluida y fácil.

Arquitectura

Los microservicios es una arquitectura de programación que permite a los desarrolladores diseñar aplicaciones flexibles y altamente escalables, como el ejemplo anterior, pero también facilita negocios e industrias como salud, finanzas, seguros, telecomunicaciones, IoT y aplicaciones de inteligencia artificial. Este método descompone una aplicación, dividiéndola en servicios separados (microservicios) que ejecutan funciones específicas.

Cada microservicio realiza y se conecta con otros, y se comunica con ellos, utilizando API estándar (interfaces de programación de aplicaciones). Esto permite a los desarrolladores escribir servicios en varias tecnologías utilizando diferentes lenguajes. Por tanto, los microservicios son flexibles y escalables. Además, cada microservicio tiene un trabajo específico que hacer y, por lo tanto, es pequeño y relativamente simple. (El término microservicio se refiere a la función singular del servicio, no a su tamaño físico).

A los desarrolladores les gusta usar la arquitectura de microservicios debido a sus características modulares, lo que hace que sea más fácil de desarrollar y probar que la arquitectura monolítica. El uso generalizado de implementaciones sin servidor de función como servicio y nativas de la nube, como Microsoft Azure Cloud Functions y AWS Lambda, ha creado el entorno ideal para que los microservicios prosperen en el mundo de la TI actual. Los microservicios en estas implementaciones permiten agilidad y tiempos de entrega más rápidos.

De alguna manera, los microservicios, que incidentalmente tienen sus raíces en la arquitectura monolítica, surgieron en respuesta a la necesidad de abordar el tráfico de usuarios altamente errático. Cuando los desarrolladores dividen las funciones de la aplicación en servicios separados, las funciones se reducen o crecen según sea necesario para ayudar a garantizar que haya suficiente potencia de procesamiento disponible. Esto puede complicarse cuando la aplicación desarrolla su propio terreno de red dinámico y en constante cambio. Como resultado, se requieren pruebas funcionales rigurosas.

¿Son las pruebas de microservicios complejas?

Las pruebas de microservicios pueden ser complicadas. Con las herramientas de prueba, el conocimiento y el enfoque adecuados, se puede hacer menos. Veamos algunos de los elementos que pueden hacer que las pruebas de microservicios sean complejas.

El enfoque

En muchos aspectos, la prueba automática de microservicios es como el enfoque de prueba para aplicaciones que los desarrolladores de software han construido sobre arquitecturas tradicionales. Los microservicios emplean tecnologías conocidas como REST y corredores de mensajes para los cuales los escritores de software ya utilizan las mejores prácticas y herramientas de prueba bien establecidas durante el desarrollo de software.

El desafío especial que presentan los microservicios es la gran cantidad de servicios que componen una aplicación. Además del hecho de que los microservicios son interdependientes. Una consideración adicional es que estos servicios deben seguir funcionando incluso cuando otros servicios de los que dependen no estén disponibles o no respondan adecuadamente.

Principales estrategias de prueba de microservicios

Las pruebas de software de microservicios garantizan que los microservicios hagan lo que se supone que deben hacer de manera eficiente y oportuna. En toda la industria, los tres tipos principales de pruebas de software para microservicios son:

  • Prueba funcional para probar la lógica empresarial y el comportamiento del servicio. Esto es más complicado que realizar pruebas en una arquitectura monolítica tradicional porque los microservicios no tienen una interfaz de usuario para facilitar las pruebas. La interfaz que se va a probar representa algún tipo de cliente remoto que se comunica a través de HTTP o algún otro protocolo.
  • Prueba de carga para exponer áreas de la aplicación que no están diseñadas correctamente y pueden causar choques debido al alto volumen de tráfico. En microservicios, cada llamada a un servicio viaja por la red, lo que significa que otra actividad en la red puede afectar los tiempos de respuesta.
  • Ensayos de resiliencia para averiguar cómo reacciona el software ante posibles fallas de infraestructura. Por ejemplo, si un servidor que ejecuta un servicio específico no está disponible, si falla o si parte de una red deja de pasar tráfico. En estos casos, el desarrollador debe probar para determinar si la aplicación de microservicios puede continuar ejecutándose en los puntos finales y en otros lugares.
Tres estrategias para maximizar el ROI de las pruebas de microservicios

Tipos específicos de pruebas de microservicios

Cuando un desarrollador necesita probar el sistema, puede hacerlo con relativa facilidad porque los microservicios están separados, aunque funcionan juntos. Por el contrario, cuando los programadores construyen servicios sobre monolitos o arquitectura monolítica, el código de la aplicación está inextricablemente vinculado, lo que hace que las pruebas sean difíciles y lentas.

Para realizar las pruebas básicas mencionadas anteriormente, los desarrolladores emplean lo siguiente.

Examen de la unidad

Una práctica que a menudo se pasa por alto cuando se prueban microservicios es examen de la unidad. Estas pruebas verifican que los métodos y las clases que escriben los desarrolladores funcionan como se esperaba. Si bien las pruebas unitarias son una tarea altamente técnica para los desarrolladores, un conjunto sólido de pruebas unitarias proporciona una red de seguridad crítica para detectar las consecuencias no deseadas cuando los desarrolladores cambian el código. Y paga dividendos al alertar a los desarrolladores sobre exactamente en qué parte del código han roto la funcionalidad existente.

Esta es una práctica valiosa para escribir software de alta calidad. Sin embargo, las pruebas unitarias por sí solas no son suficientes. Como analogía, el hecho de que todas las partes de un motor estén mecanizadas con una especificación perfecta no significa que el motor funcionará y funcionará como se espera.

Prueba de componentes

Esta prueba de microservicios no se concentra en cómo el desarrollador escribió el código de microservicios, sino que se enfoca en ejecutar el microservicio como una caja negra y probar el tráfico que se mueve a través de la interfaz. Desde la perspectiva de un único microservicio, ahora está probando el motor para asegurarse de que cumple con sus requisitos.

En la mayoría de los casos, está probando un servicio REST. Por lo que desea pruebas automatizadas que actúen como clientes del servicio, enviando varias solicitudes positivas y negativas al servicio y verificando las respuestas que devuelve el servicio.

Un desafío es que puede ser complejo y difícil probar microservicios de forma aislada porque a menudo llaman a muchos otros microservicios para responder a la solicitud de su cliente de prueba. Para probar un microservicio, es posible que necesite docenas más implementadas y disponibles para que su microservicio hable y lo pruebe correctamente.

La virtualización de servicios viene al rescate, lo que permite a los probadores simular otros microservicios para probar el microservicio de forma aislada, simplificando así el entorno de prueba y facilitando la automatización de la prueba. Esto puede involucrar resguardos y dobles de prueba. Piense en la virtualización de servicios como conectar el motor de un automóvil en un laboratorio a una transmisión artificial para que pueda verificar que se conecta correctamente y entrega la potencia esperada al resto del automóvil sin realmente ponerlo en un automóvil.

Pruebas de integración

Al usar la virtualización de servicios para simplificar y estabilizar las pruebas del microservicio como un componente individual, también desea probar que el microservicio funciona con los otros microservicios REALES involucrados. Los desarrolladores a menudo hacen esto en una etapa de "QA" o "integración", donde muchos de los sistemas requeridos en el ecosistema general se implementan e integran juntos. Con esta práctica de prueba, está comenzando a ensamblar el automóvil para asegurarse de que todas las piezas encajen y funcionen juntas, pero aún no lo está probando en la carretera.

Pruebas de extremo a extremo

También se llama prueba del sistema. En algún momento, una gran red de microservicios tiene puntos de entrada donde interactúan los usuarios finales de la aplicación. Por ejemplo, una aplicación de Netflix en su Apple TV habla con microservicios dentro del centro de datos de Netflix. Pero representan solo una pequeña parte de su funcionalidad principal, que son componentes pequeños e individuales responsables de cosas específicas como un servicio de recomendaciones, un servicio de transmisión de video, un servicio de detalles de cuenta, etc. Así que esta también es una oportunidad para probar microservicios.

A menudo es dolorosamente lento y de alto mantenimiento probar estas interacciones automáticamente, ya sea web o móvil. Para las rutas críticas y los recorridos del usuario, es imprescindible, pero poder representar estas transacciones completas o de un extremo a otro desde la perspectiva del usuario final como una secuencia de llamadas de microservicio tiene muchos beneficios.

Básicamente, elimina la interfaz de usuario y simula todas las llamadas a la API que la interfaz de usuario hace a su arquitectura de microservicios para que pueda verificar que todos los microservicios funcionan juntos correctamente para el contexto de requisitos comerciales / de usuario final más amplio. Ahora está conduciendo el automóvil en la carretera, poniéndose en el lugar de sus clientes y asegurándose de que el automóvil cumpla sus promesas.

Cuadro resumen de tipos específicos de pruebas para microservicios

Tipo de pruebaQue haceBeneficiosInconvenientes
Prueba unitariaLas pruebas que escriben los programadores de clases y métodos representarán con precisión el proyecto cuando se construya e implemente.Hace que la codificación sea más ágil, mejora la calidad del código y revela errores desde el principio. Los cambios son relativamente fáciles.Los desarrolladores son responsables de las pruebas unitarias, lo que agrega gastos generales al costo de un proyecto. Esto puede dificultar la justificación de una gestión que priorice el costo sobre la calidad.
Prueba de componentesEjecuta el microservicio como una caja negra, probando el comportamiento de la interfaz.Los equipos de desarrollo pueden garantizar que sus microservicios funcionen correctamente al principio del ciclo de lanzamiento porque las pruebas se pueden realizar antes en el proceso. Autosuficiencia.Puede ser difícil probar microservicios de forma aislada.
Examen de integraciónEstimula la interacción entre módulos; prueba que el microservicio funciona con los otros microservicios REALES involucrados.Ayuda a encontrar problemas relacionados con la interacción entre módulos. Ayuda a asegurarse de que los módulos y sus resultados sean apropiados para el proyecto.La mayor complejidad de un entorno de prueba más completo empuja las pruebas más lejos y retrasa la retroalimentación a los desarrolladores. Las pruebas de integración más grandes también pueden presentar problemas para encontrar la causa principal de un defecto.
Prueba de extremo a extremoElimina la interfaz de usuario y simula todas las llamadas a la API.Prueba la transacción completa y verifica que todos los microservicios funcionen juntos.La complejidad, el costo y la velocidad de las pruebas aumentan; Depender únicamente de las pruebas de un extremo a otro es demasiado lento para un desarrollo de software ágil.

Soluciones Parasoft

Las herramientas de software de prueba de microservicios automatizadas para probar microservicios que ofrece Parasoft abordan casi todos los problemas potenciales de microservicios.

  • Pruebas de sistema / de un extremo a otro. Parasoft SOAtest tiene tecnología de IA que analiza el tráfico API registrado cuando los usuarios ejercitan la interfaz de usuario de una aplicación. Al tomar planes de prueba con los que menos probadores técnicos y analistas comerciales están más familiarizados y al registrar las llamadas API subyacentes que realiza un programa, Parasoft cierra la brecha entre el uso de API y el diseño de API. Esto ayuda a los evaluadores a agilizar el proceso en la capa de API.
  • Pruebas de integración. SOAtest es el marco de prueba de API (“microservicios”) de Parasoft que admite más de 120 formatos de mensajes y protocolos. Ya sea que la arquitectura de su sistema sea moderna o heredada, puede probar fácilmente sus puntos de integración.
  • Prueba de componentes. Parasoft SOAtest permite a los probadores crear clientes de prueba que envían mensajes de solicitud al microservicio y luego verifican las respuestas que regresan. Parasoft Virtualize es un producto complementario responsable de la virtualización de servicios, que simula un punto final que se comporta como si fuera real. Juntos, SOAtest y Virtualize permiten una estrategia de automatización coherente para las pruebas de componentes de microservicios.
  • Examen de la unidad. Parasoft Jtest tiene un flujo de trabajo de creación de pruebas unitarias automatizado e interactivo dentro del IDE (entorno de desarrollo integrado) del desarrollador que reduce a la mitad la inversión de tiempo de las pruebas unitarias. La generación de código JUnit de Jtest utiliza la larga historia de tecnología de análisis de código de Parasoft para examinar el código Java del microservicio y generar los simulacros apropiados (versiones falsas de servicios externos [o internos]) para que el desarrollador pueda probar un método o clase en particular, aislado de otros capas del código. La capacidad de simular dependencias externas es fundamental cuando los desarrolladores se enfrentan al desafío de lograr altos niveles de cobertura de código con sus pruebas unitarias.

Verificación de requisitos no funcionales

Además de las pruebas de microservicios unitarios y funcionales, es importante que los desarrolladores también verifiquen los requisitos no funcionales. Específicamente para pruebas de seguridad, carga y rendimiento mientras se emplean el esquema y las métricas adecuados. Prueba automatizada de microservicios El software de Parasoft también es su fuente para estos.

Pruebas de seguridad

Los piratas informáticos pueden explotar áreas bajo el paraguas de los microservicios. Por lo tanto, los desarrolladores deben probar los microservicios a fondo para que estén protegidos contra las vulnerabilidades de seguridad. Parasoft Jtest tiene tecnología de análisis de código estático que escanea el código fuente subyacente e identifica las debilidades de codificación segura para que los desarrolladores puedan corregirlas. Parasoft también permite a los evaluadores reutilizar los casos de prueba funcionales que han escrito en SOAtest para realizar pruebas de penetración del microservicio.

¿Qué es el análisis estático? Herramientas de análisis de código

Pruebas de carga y rendimiento

Para asegurarse de que el microservicio pueda mantener los SLA (acuerdos de nivel de servicio), los desarrolladores deben comprender cómo funcionan los SLA bajo carga y también determinar los puntos de ruptura.

Parasoft SOAtest incluye un módulo llamado Prueba de carga que permite al evaluador reutilizar las pruebas funcionales que ha escrito y ejecutarlas como una prueba de carga y rendimiento. Esto ahorra tiempo al reutilizar lo que los probadores ya han desarrollado en lugar de “reinventar la rueda” y potencialmente usar múltiples herramientas.

Cinco consejos para probar microservicios

A continuación, se incluyen cinco consejos que le ayudarán a desarrollar una estrategia de prueba de microservicios. Tenga en cuenta que estas son sugerencias. Como todos los tipos de planes de prueba, debe considerar las especificaciones de su configuración.

  1. Considere cada servicio como un módulo de software. Realice pruebas unitarias en un servicio como lo haría con cualquier código nuevo. En la arquitectura de microservicios, cada servicio se considera una caja negra. Por lo tanto, pruebe cada uno de manera similar.
  2. Determine los vínculos fundamentales en la arquitectura y pruébelos. Por ejemplo, si existe un vínculo sólido entre el servicio de inicio de sesión, la interfaz que muestra los detalles del usuario y la base de datos para obtener los detalles, pruebe estos vínculos.
  3. No se limite a probar escenarios de caminos felices. Los microservicios pueden fallar y es importante simular escenarios de fallas para generar resiliencia en su sistema.
  4. Haz tu mejor esfuerzo para probar en todas las etapas. La experiencia ha demostrado que los probadores que utilizan una combinación diversa de prácticas de prueba, comenzando en el desarrollo y progresando a través de alcances de prueba más grandes, no solo aumentan la posibilidad de que los errores se revelen, sino que lo hacen de manera eficiente. Esto es particularmente cierto en entornos virtuales complicados donde existen pequeñas diferencias entre varias bibliotecas y donde la arquitectura de hardware subyacente puede producir resultados imprevistos e indeseables a pesar de la capa de visualización.
  5. Utilice “pruebas canarias” en código nuevo y pruebe en usuarios reales. Asegúrese de que todo el código esté bien instrumentado. Y también utilice toda la supervisión que ofrece su proveedor de plataforma. Esto cumple con las pruebas de "cambio a la izquierda" con las pruebas de "cambio a la derecha" porque también está probando "en la naturaleza".

Conclusión

Los fundamentos de las pruebas de microservicios no son nuevos en comparación con los servicios web tradicionales o las pruebas SOA, pero la importancia de hacerlo solo se ha vuelto más crítica en los sistemas modernos. Las soluciones de Parasoft cubren las preocupaciones esenciales de las pruebas de microservicios, haciendo que el software sea más seguro, más eficiente, menos propenso a fallas y, en última instancia, mejor en todos los aspectos. Esto puede mejorar sustancialmente los flujos de trabajo y reducir los esfuerzos de depuración.

Llegar al equipo de Parasoft ahora para obtener las poderosas soluciones que su empresa merece.

Texto blanco sobre fondo azul marino: 3 pasos clave para una prueba de microservicios eficaz con un botón rojo debajo que dice Ver seminario web bajo demanda

Escrito por

Wilhelm Haaker

Wilhelm, un arquitecto de soluciones senior con conocimiento de nivel experto en todo el conjunto de productos de Parasoft, se especializa en estrategias de automatización de pruebas para sistemas abiertos, aplicaciones web y microservicios, junto con SOA para desarrolladores e ingenieros de pruebas funcionales y de rendimiento.

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

Prueba Parasoft