Retos en la prueba de software basado en servicios

Las arquitecturas orientadas a servicios tienen ventajas indudables para el desarrollo y mantenimiento de software, lo que ha provocado un enorme interés y grandes inversiones en la industria en los últimos años. Entre dichas ventajas cabe destacar la posibilidad de construir aplicaciones complejas componiendo servicios preexistentes ofrecidos por terceras partes o la capacidad de definir y utilizar servicios para facilitar la integración de sistemas en entornos empresariales.

Por supuesto yjose garcia faijul como en toda decisión de diseño, elegir una arquitectura orientada a servicios no sólo tiene ventajas sino, también, ciertos inconvenientes que los ingenieros debemos conocer para poder tomar decisiones conducentes a la minimización de los posibles riesgos. En este breve artículo nos centraremos en dos de los retos que se presentan al abordar la prueba de software basado en servicios: la falta de control sobre los servicios y el enlazado dinámico.

Posiblemente el mayor reto al que nos enfrentamos al probar este tipo de software es la falta de control sobre los servicios. En los escenarios en que los servicios se ejecutan en infraestructuras ajenas únicamente el proveedor controla en qué momento se realizan cambios sobre los servicios o sobre la infraestructura. Por tanto la realización de pruebas no garantiza que el comportamiento del servicio continúe siendo adecuado en el futuro y, por otro lado, se limitan las decisiones a tomar en cuanto a pruebas de regresión. Ante este reto se suelen establecer acuerdos de nivel de servicio (Service Level Agreements – SLAs) en los que se establecen los niveles de calidad aceptables e, incluso, posibles penalizaciones ante el incumplimiento de dichos requisitos por parte del proveedor. Sin embargo dichos acuerdos suelen centrarse en aspectos no funcionales por lo que, de momento y en la mayor parte de los casos, es preciso continuar realizando pruebas sobre el comportamiento funcional de los servicios contratados para asegurar que continúan siendo adecuados. Por otro lado y aunque existen estándares que facilitan la automatización de los procesos relacionados con la negociación, contratación y control de los SLAs, en muchos casos los acuerdos únicamente se plasman en documentos y se deben establecer medidas por parte de los clientes para asegurar que los proveedores de servicios cumplen con lo acordado. Una estrategia ampliamente utilizada para realizar esa supervisión del cumplimiento de los acuerdos es la monitorización de la ejecución de los servicios en producción. La problemática derivada de confiar exclusivamente en estrategias de monitorización se plasma en la posible aparición de fallos ante situaciones que habitualmente no suceden y que, por tanto, no se ejecutan ni monitorizan pero pueden ser críticas para el sistema.

Abundando en la falta de control sobre los servicios que ejecuta el software que queremos probar, debemos tener en cuenta que la mayor parte de las pruebas sobre este tipo de sistemas se realizan invocando a réplicas del servicio que realmente se integrará en producción. Aquí podemos encontrarnos con problemas, lógicamente, si existen diferencias significativas entre el servicio desplegado en el entorno de producción y el que se está invocando en las pruebas. También podemos encontrarnos con falta de control sobre el entorno de pruebas, al haber multitud de desarrollos que se están realizando sobre dicho entorno y realizando invocaciones a los servicios de prueba. Puede ser imposible, entonces, conseguir que se configure un determinado servicio en modo de fallo para que no responda o responda con mensajes de error determinados, por lo que determinadas pruebas no podrán hacerse siquiera sobre el servicio de prueba sino que necesitaremos trabajar con invocaciones sobre un mock creado al efecto. En ese sentido cabe recomendar tener en cuenta este aspecto al diseñar entornos de prueba para servicios, en los que el comportamiento de cada servicio debería poder configurarse hasta cierto punto. Por ejemplo pueden establecerse horarios en que los servicios del entorno de prueba se comportan normalmente y otros en que están programados en modo de fallo o, alternativamente, se pueden desplegar en el entorno de pruebas diferentes variantes del mismo servicio, configuradas para responder en diferentes modos de fallo.

Un segundo reto para la prueba de software basado en servicios es el de probar los aspectos derivados de la dinamicidad y adaptación de estos sistemas. En sistemas tradicionales es posible conocer, durante el desarrollo, qué componentes se van a invocar o, al menos, una lista de aquellos que pueden ser invocados. Sin embargo en arquitecturas orientadas a servicios el servicio que se invoca puede haber sido descubierto en tiempo de ejecución. La complejidad asociada no sólo a la prueba sino al propio desarrollo de arquitecturas con enlazado dinámico de servicios hace que los sistemas no suelan incorporar estas características a menos que resulte estrictamente necesario. Sin embargo una característica que sí resulta habitual en estas arquitecturas a nivel empresarial es la utilización de registros en los que se indexan diferentes servicios equivalentes que pueden ser invocados por las aplicaciones. Los ingenieros nos encontramos aquí con dos problemáticas asociadas a las pruebas. Por un lado, al añadir un nuevo servicio al registro sería necesario realizar pruebas sobre todas las aplicaciones que pueden llegar a invocar dicho servicio. Por otro lado y ante cambios en las especificaciones de los servicios o en los interfaces, podremos encontrar diferentes versiones del mismo servicio en el registro utilizadas por diferentes aplicaciones, lo que complica obviamente el diseño de la arquitectura y la comprensión de las dependencias.

La combinación de la falta de control sobre los servicios y el dinamismo de estas arquitecturas pueden conllevar que, en un caso extremo, cualesquiera dos ejecuciones del mismo software basado en servicios podría dar, potencialmente, resultados diferentes siempre. Esta aseveración es una exageración obvia pero posiblemente sea una buena forma de recordar a los profesionales las peculiaridades y la complejidad inherente a las pruebas de este tipo de software.

For more information:

José García Fanjul – Profesor de la Universidad de Oviedo

Email: jgfanjul@uniovi.es.

Twitter: @jgfanjul

Autor: qanewsblog

Sogeti es una compañía tecnológica perteneciente al Grupo Capgemini y especialista en: Testing y Calidad de Software; Soluciones Microsoft y High Tech Consulting. En Sogeti entendemos la importancia de obtener el máximo valor empresarial de sus sistemas de IT, por ello somos líderes mundiales en Testing & QA. Somos creadores de las metodologías estándar del mercado: TMap® (Test Management Approach) y TPI® (Test Process Improvement). ¡Nuestro compromiso es el Testing!

Deja tu comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s