En la ingeniería de software , la virtualización de servicios o la virtualización de servicios es un método para emular el comportamiento de componentes específicos en aplicaciones heterogéneas basadas en componentes, como aplicaciones impulsadas por API , aplicaciones basadas en la nube y arquitecturas orientadas a servicios . Se utiliza para proporcionar desarrollo de software y control de calidad / pruebas.los equipos acceden a los componentes del sistema dependientes que se necesitan para ejecutar una aplicación bajo prueba (AUT), pero que no están disponibles o son de difícil acceso para fines de desarrollo y prueba. Con el comportamiento de los componentes dependientes "virtualizados", las pruebas y el desarrollo pueden continuar sin acceder a los componentes activos reales. Los proveedores, los analistas de la industria y las publicaciones de la industria reconocen que la virtualización de servicios es diferente a la burla. [1] [2] Consulte aquí para obtener una comparación de las herramientas de simulación de API .
Descripción general
La virtualización de servicios emula el comportamiento de los componentes de software para eliminar las restricciones de dependencia en los equipos de desarrollo y prueba. Tales restricciones ocurren en entornos complejos e interdependientes cuando un componente conectado a la aplicación bajo prueba es:
- No completado aún
- Sigue evolucionando
- Controlado por un tercero o socio
- Disponible para pruebas solo en capacidad limitada o en momentos inconvenientes
- Difícil de aprovisionar o configurar en un entorno de prueba
- Necesario para el acceso simultáneo de diferentes equipos con una configuración de datos de prueba variada y otros requisitos
- Uso restringido o costoso para pruebas de carga y rendimiento [3]
Aunque el término "virtualización de servicios" refleja el enfoque inicial de la técnica en la virtualización de servicios web , la virtualización de servicios se extiende a todos los aspectos de las aplicaciones compuestas: servicios, bases de datos , mainframes , ESB y otros componentes que se comunican mediante protocolos de mensajería comunes. [4] [5] [6] Otras herramientas similares se denominan API simuladores, herramientas de API burlarse, sobre el alambre dobles de prueba .
La virtualización de servicios emula solo el comportamiento de los componentes dependientes específicos que los desarrolladores o evaluadores deben ejercitar para completar sus transacciones de un extremo a otro. En lugar de virtualizar sistemas completos, virtualiza solo porciones específicas de comportamiento dependiente críticos para la ejecución de tareas de desarrollo y prueba. Esto proporciona la lógica de aplicación suficiente para que los desarrolladores o evaluadores obtengan lo que necesitan sin tener que esperar a que el servicio real se complete y esté disponible. Por ejemplo, en lugar de virtualizar una base de datos completa (y realizar toda la administración de datos de prueba asociada, así como configurar la base de datos para cada sesión de prueba), usted monitorea cómo la aplicación interactúa con la base de datos, luego emula el comportamiento de la base de datos relacionada (el SQL consultas que se pasan a la base de datos, los conjuntos de resultados correspondientes que se devuelven, etc.). [7] [8]
Solicitud
La virtualización de servicios implica la creación e implementación de un "activo virtual" que simula el comportamiento de un componente real que se requiere para ejercitar la aplicación bajo prueba, pero al que es difícil o imposible acceder para propósitos de desarrollo y prueba.
Un activo virtual sustituye a un componente dependiente al escuchar las solicitudes y devolver una respuesta adecuada, con el rendimiento adecuado. Para una base de datos, esto podría implicar escuchar una declaración SQL y luego devolver las filas de la fuente de datos. Para un servicio web, esto puede implicar escuchar un mensaje XML a través de HTTP , JMS o MQ y luego devolver otro mensaje XML. La funcionalidad y el rendimiento del activo virtual pueden reflejar la funcionalidad / rendimiento real del componente dependiente, o puede simular condiciones excepcionales (como cargas extremas o condiciones de error) para determinar cómo responde la aplicación bajo prueba en esas circunstancias.
Los activos virtuales suelen ser creados por:
- Grabación de la comunicación en vivo entre componentes a medida que el sistema se ejercita desde la aplicación bajo prueba (AUT)
- Proporcionar registros que representen la comunicación histórica entre componentes.
- Analizar las especificaciones de la interfaz de servicio (como un WSDL )
- Definir el comportamiento manualmente con varios controles de interfaz y valores de fuente de datos
Luego, se configuran aún más para representar datos, funciones y tiempos de respuesta específicos.
Los activos virtuales se implementan localmente o en la nube (pública o privada). Con los entornos de desarrollo / prueba configurados para usar los activos virtuales en lugar de los componentes dependientes, los desarrolladores o evaluadores pueden entonces ejercitar la aplicación en la que están trabajando sin tener que esperar a que los componentes dependientes se completen o sean fácilmente accesibles. [4] [5] [8]
Los analistas de la industria informan que la virtualización de servicios es más adecuada para "talleres de TI con experiencia significativa en 'omitir' pruebas de integración debido a 'software dependiente', y con un arnés de prueba razonablemente sofisticado. [9]
Relación con los golpes y las burlas
Un enfoque alternativo para trabajar alrededor de las restricciones de acceso del entorno de prueba descritas en la introducción de este artículo es que los miembros del equipo desarrollen códigos auxiliares de métodos u objetos simulados que sustituyan a los recursos dependientes. La deficiencia de este enfoque se hizo evidente a principios de la década de 2000 con el surgimiento de la arquitectura orientada a servicios . [10] La proliferación de aplicaciones compuestas que dependen de numerosos servicios dependientes, además del aumento del desarrollo de software ágil tras la publicación del Manifiesto Ágil en 2001, hizo que fuera cada vez más difícil para los desarrolladores o probadores desarrollar manualmente el número, el alcance y la complejidad de stubs o simulacros necesarios para completar las tareas de desarrollo y prueba para el desarrollo de aplicaciones empresariales modernas. [11]
El primer paso en la evolución de stubbing a la virtualización de servicios fue la tecnología empaquetada en herramientas de prueba SOA desde 2002. [12] Las primeras implementaciones de virtualización de servicios se diseñaron para automatizar el proceso de desarrollo de emulaciones simples tipo stub para que las aplicaciones compuestas pudieran ser probado de manera más eficiente. [13] A medida que los sistemas empresariales continuaron haciéndose cada vez más complejos y distribuidos, los proveedores de herramientas de software cambiaron el enfoque de los stubbing a la virtualización de servicios más centrada en el entorno. [3] Si bien el stubbing todavía se puede completar mediante el desarrollo manual y la gestión de stubs, lo que se conoce como "virtualización de servicios" se completa utilizando una de las tecnologías de virtualización de servicios comerciales disponibles en el mercado (COTS) como plataforma para el desarrollo. y despliegue de sus "activos de virtualización de servicios". [11]
Agile y DevOps
La creciente popularidad [14] del desarrollo de software ágil y DevOps ha creado una demanda de un nuevo conjunto de herramientas para brindar virtualización de servicios a las comunidades que trabajan de esta manera. [15] Prácticas como la entrega continua y el alejamiento del desarrollo de mainframe y monolitos hacia arquitecturas más distribuidas basadas en microservicios encajan bien con las capacidades de virtualización de servicios. Los equipos ágiles y de DevOps prefieren trabajar con herramientas livianas que tienen menos sobrecarga acumulada y sin restricciones de licencia engorrosas. [dieciséis]
Ver también
- Comparación de herramientas de simulación API
- Prueba doble
Referencias
- ^ Virtualización de servicios como alternativa a la burla , por Jonathan Allen, eBizQ 22 de abril de 2013
- ^ La virtualización de servicios surge para cumplir con los obstáculos de prueba de servicios , por George Lawton, SearchSOA 15 de mayo de 2012
- ^ a b Virtualización de servicios para aplicaciones modernas por Gaurish Hattangadi, Revista de estrategia virtual, 28 de noviembre de 2010
- ^ a b Gestión de entornos de prueba por Liz McMillan, Cloud Computing Journal, diciembre de 2011
- ^ a b Virtualización del comportamiento de las aplicaciones por Elizabeth White, Cloud Computing Journal, diciembre de 2011
- ^ Virtualización de base de datos para desarrollo y prueba por Wayne Ariola, ST & QA Magazine, marzo de 2012
- ^ Una introducción a SOA y virtualización Archivado el22 de noviembre de 2011en Wayback Machine por John Michelsen, WebServices.org, agosto de 2007
- ^ a b La próxima generación de gestión del entorno de prueba por Wayne Ariola, Virtualization Journal, 12 de julio de 2011
- ^ Pruebas de Parasoft y "Virtualización de servicios": una buena idea de Wayne Kernochan, Pensamientos de un analista de software de TI, 22 de febrero de 2013
- ^ Pruebas en entornos orientados a servicios por Ed Morris et al, Instituto de ingeniería de software, marzo de 2010
- ^ a b La virtualización de servicios está ayudando a las organizaciones a obtener el valor comercial de las pruebas realizadas por Chandranshu Singh, ovum, 31 de marzo de 2014
- ^ La herramienta de prueba del servicio web de Parasoft debería ayudar al desarrollo por Theresa Lanowitz Gartner , 1 de mayo de 2002
- ^ La virtualización SOA se vuelve real por Rich Seeley, SearchSOA, 28 de noviembre de 2007
- ^ Tendencias de Google ágiles y DevOps
- ^ Foro de virtualización de servicios de próxima generación, 13 de septiembre de 2017
- ^ Radar tecnológico de Thought Works: soluciones para grandes empresas