Prueba de restricciones de recursos en aplicaciones compuestas

Las limitaciones de recursos inherentes a los entornos empresariales heterogéneos de hoy en día pueden impedir la capacidad de un equipo de QA / desarrollo para construir conjuntos de pruebas. En última instancia, esto perjudica la capacidad del equipo para entregar y desarrollar aplicaciones seguras, confiables y compatibles a tiempo y dentro del presupuesto. A medida que las aplicaciones continúan haciéndose cada vez más complejas y ciertamente más distribuidas, este problema se agrava significativamente.

Los esfuerzos para garantizar la calidad de las aplicaciones heterogéneas de hoy se ven obstaculizados no solo por las restricciones de disponibilidad del sistema innatas a las arquitecturas distribuidas de las aplicaciones, sino también por las restricciones humanas asociadas con la forma en que dichos sistemas se desarrollan, prueban y evolucionan.

Restricciones del sistema

Las aplicaciones heterogéneas de hoy involucran varios componentes; por ejemplo, considere el siguiente diagrama de una arquitectura de aplicación empresarial común:

Los esfuerzos para probar dichas aplicaciones suelen retrasarse (y a menudo se interrumpen) porque uno o más componentes están incompletos, evolucionando, son inestables, inaccesibles o no están disponibles para la prueba. Tales dificultades se derivan de las siguientes limitaciones:

• Acceso a aplicaciones distribuidas
  Los procesos comerciales están habilitados por una interacción compleja de sistemas distribuidos. Probar un caso de uso que aprovecha un solo sistema es complejo ... y si el caso de uso llama a varios sistemas distribuidos, la complejidad aumenta exponencialmente.
• Acceso a los servicios de socios
  Las arquitecturas orientadas a servicios permiten a las organizaciones aprovechar las “unidades de trabajo” distribuidas como servicios a través de los límites organizacionales. Para poder ejercitar aplicaciones internas, la organización debe tener una forma de modelar el comportamiento de estos servicios (unidades de trabajo) para probarlos convenientemente.
• Acceso a servicios nuevos o en evolución
  Una arquitectura orientada a servicios introduce a una organización en un estado de cambio constante. Desde la perspectiva de las pruebas, esto puede resultar muy frustrante, ya que el acceso a los servicios en evolución puede ser limitado o no estar completamente disponible.
• Capacidad para simular fallas y problemas de rendimiento.
  Los sistemas orientados a servicios deben probarse en condiciones de falla para garantizar que las aplicaciones fallan correctamente cuando un componente dependiente no responde o no cumple con las métricas de calidad de servicio requeridas desde una perspectiva de desempeño. Si las aplicaciones dependientes se utilizan o replican, es muy difícil simular tales condiciones en un entorno de prueba. Además, es costoso replicar los sistemas dependientes en entornos de prueba de rendimiento. Como resultado, es importante virtualizar las características de rendimiento del sistema dependiente, así como su funcionalidad comercial.

Restricciones humanas

Además, las siguientes limitaciones humanas agravan la dificultad de realizar pruebas exhaustivas con el tiempo y los recursos dados:

• Cambio de servicios o componentes de la aplicación
  El impacto de cambiar los servicios puede tener ramificaciones desconocidas si se modifican o se desaprueban funciones específicas. Tener la capacidad de modelar pruebas y ejecutar escenarios hipotéticos basados ​​en los cambios planificados es importante para mantener el proyecto en marcha.
• El plazo ajustado y el desarrollo se retrasan
  Es un hecho bien conocido que el desarrollo de software no es una ciencia exacta. Rara vez el desarrollo entrega su solicitud a QA antes de la fecha límite en el plan del proyecto. Tener la capacidad de emular la funcionalidad específica del comportamiento para crear conjuntos de regresión para "probar alrededor" de la funcionalidad cambiante es fundamental para que el control de calidad satisfaga los plazos del proyecto determinados.
• Cambios de última hora en la aplicación
  Los cambios de última hora en la aplicación son muy comunes en cualquier ciclo de vida de desarrollo de software. El plan de prueba no debería tener que esperar necesariamente para ejercitar la aplicación en el contexto de los cambios planificados.

Superar las limitaciones de las pruebas con la virtualización de servicios

La virtualización de servicios es clave para superar las limitaciones de las pruebas que sufren los proyectos de foso. Al simular servicios que están fuera de su control o que no están disponibles, la virtualización de servicios permite a los usuarios acceder a entornos de prueba completos y realistas, lo que permite a los equipos desarrollar y probar sus aplicaciones antes y de forma más completa. Al aplicar la virtualización de servicios en entornos de prueba, las organizaciones pueden reducir o eliminar la dependencia de dependencias no disponibles, inestables o costosas, como servicios de terceros, bases de datos, mainframes, etc. Virtualización de Parasoft proporciona una solución intuitiva de virtualización de servicios que facilita a los usuarios crear, escalar y compartir servicios virtuales.

El uso de servicios virtuales significa una recuperación más rápida del cambio tan rápido (o más rápido) que sus contrapartes reales. Los evaluadores pueden usar flujos de trabajo automatizados para actualizar fácilmente los servicios virtuales afectados y probar los datos según sea necesario. Las herramientas automatizadas también pueden realizar un seguimiento de todos estos cambios, con versiones almacenando todos los datos relevantes como archivos comparables que son compatibles con los sistemas de control de versiones estándar.

Un aspecto clave de la automatización de pruebas y la virtualización de servicios es la creación y reutilización de activos de prueba no solo para pruebas funcionales, sino también para otras pruebas críticas, como pruebas de seguridad y rendimiento. Además, es posible crear rápidamente servicios virtuales sobre la marcha e inyectarles lógica empresarial y datos de prueba para respaldar el desarrollo de API locales. Los servicios virtuales se benefician de una configuración basada en archivos, lo que los hace fáciles de compartir entre el desarrollo y el control de calidad para la reproducción y el soporte de defectos.