A**
B***
C
A**
B***
C
https://doi.org/10.22463/2011642X.2120
Recibido: 11 de julio 2016 - Aprobado: 02 de diciembre 2016
Forma de citar:
Beltrán Galvis, N; Engarita Sanguino, C; GómezLlanez, C. "Método de pruebas de integración en arquitecturas orientadas a servicios", Ingenio, vol.12, no. 1, pp. 9-20, 2016.
Las nuevas tendencias en los avances tecnológicos apuntan a la integración de sistemas y gran parte de las empresas lo están haciendo o desean hacerlo; con base en esto, las empresas contratan expertos informáticos que les indiquen las estrategias a seguir para la implementación de lo último en tecnología, conduciéndolos irremediablemente a los Web Services o sistemas con Arquitecturas Orientadas a Servicios (SOA), soportados en la hipótesis de mantener interoperabilidad entre los sistemas actuales de la organización. LosSOA dentro de su metodología de desarrollo cuentan con una etapa de prueba, donde se verifica la calidad de los distintos componentes desarrollados, esta etapa es abordada con procesos de pruebas de arquitecturas tradicionales, enfocando sus esfuerzos en asegurar la calidad en el nivel de unidades y no en el nivel de integración, entendiendo por integración al proceso de consumo de las interfaces de los servicios que son expuestos. En el siguiente artículo se propone un método para el diseño y ejecución de pruebas de integración en arquitecturas orientadas a servicios, con un caso de estudio donde se aplica el método descrito, con los resultados de la aplicación del método descrito en un proyecto en la Universidad Simón Bolívar sede Cúcuta, Colombia.
Palabras clave:Pruebas de Software, Pruebas de Integración, Arquitecturas Orientadas a Servicios, Web Service.
The new tendencies in the technological advances point to the integration of systems and a great part of the companies are doing it or want to do it; Based on this, companies hire IT experts who will indicate the strategies to follow for the implementation of the latest technology, inevitably leading them to Web Services or systems with Service Oriented Architectures (SOA), supported by the hypothesis of maintaining interoperability between the current systems of the organization. The SOAs within their development methodology have a test stage, where the quality of the different components developed is verified, this stage is approached with testing processes of traditional architectures, focusing their efforts on ensuring quality at the level of units and not at the level of integration, understanding by integration to the process of consumption of the interfaces of the services that are exposed. The following article proposes a method for the design and execution of integration tests in service-oriented architectures, with a case study where the described method is applied, with the results of the application of the described method in a project at the University Simón Bolívar headquarters Cúcuta, Colombia.
Keywords: Software Test, Integration Test, Service Oriented Architecture, Web Service.
As novas tendências nos avanços tecnológicos apontam para a integração de sistemas e grande parte das empresas estão fazendo ou querem fazer; Com base nisso, as empresas contratam especialistas em informática para indicar as estratégias a seguir para a implementação da tecnologia de ponta, conduzindo-as inevitavelmente a Web Services ou sistemas com Arquiteturas Orientadas a Serviços (SOA), amparados na hipótese de manutenção da interoperabilidade entre os sistemas atuais da organização. Os SOAs dentro da sua metodologia de desenvolvimento possuem uma fase de teste, onde é verificada a qualidade dos diferentes componentes desenvolvidos, esta fase é abordada com processos de teste de arquitecturas tradicionais, focando os seus esforços na garantia da qualidade ao nível das unidades e não ao nível da integração, entendimento por integração ao processo de consumo das interfaces dos serviços que estão expostos. O artigo a seguir propõe um método para o desenho e execução de testes de integração em arquiteturas orientadas a serviços, com um estudo de caso onde o método descrito é aplicado, com os resultados da aplicação do método descrito em um projeto na Universidade Sede Simón Bolívar Cúcuta, Colômbia.
Palavras-chave: Teste de software, teste de integração, arquiteturas orientadas a serviços, serviço da web.
Las Arquitecturas Orientadas a Servicios (SOA) han tomado fuerza para dar solución a lo anterior, soportados en la hipótesis de mantener interoperabilidad entre los sistemas actuales de la organización, a través del uso generalmente de Servicios Web.
Los SOA (Service Oriented Architecture) dentro de su metodología de desarrollo cuentan con una etapa de pruebas, donde se verifica la calidad de los distintos componentes desarrollados. Aunque las pruebas de software están determinadas por la naturaleza de las aplicaciones, es importante saber que las mismas no están claramente definidas en SOA, debido a la poca madurez, así como las pocas herramientas disponibles, por lo que esta etapa es abordada con procesos de pruebas de arquitecturas tradicionales, enfocando sus esfuerzos en asegurar la calidad en el nivel de unidades y no en el nivel de integración. Además las pruebas sobre aplicaciones tradicionales se centran en la lógica del negocio, utilizando la interfaz del usuario,el equipo de desarrollo puede probar los defectos en el sistema a nivel de escritorio, dado que los sistemas basados en interfaz gráfica de usuario no son demasiado dependientes unos de otros, los defectos se pueden encontrar con mayor facilidad, contenerlos, aislarlos, y repararlos, pero en SOA, no se puede esperar un escenario en el que las aplicaciones son desarrolladas por un mismo equipo, los servicios se basan en tecnologías heterogéneas y el uso de componentes distribuidos para crear los procesos de negocio de la organización, además los servicios no tienen interfaz de usuario. Basado en esto debemos identificar dos escenario en las arquitecturas SOA, el primero donde tenemos control de las partes que componen el servicio ya que tenemos acceso a los componentes porque estos son de nuestra empresa y el segundo cuando los servicios pertenecen a otro equipo por lo tanto solo tenemos acceso a la interfaz.
2. METODOLOGÍAPara realizar este trabajo se inicia buscando las fuentes bibliográficas que contienen información del objeto de estudio, luego se procede a tomar las definiciones más relevantes de autores que se encuentren en el área de la ingeniería del software; se realiza una documentaciónde las técnicas de pruebasde software en servicios web y pruebas de integración, y se elabora un estado del arte con respecto al objeto de estudio, lo que sirve de aporte al marco teórico de esta investigación.
Consecutivamente se procede a diseñar cada una de las fases que contiene el método propuesto y así mismo se realiza la validación del método a través de un ejemplo.
En esta sección se enmarcan algunas bases conceptuales y teóricas de las pruebas de software y los servicios Web.
2.1 PRUEBAS DE SOFTWARELas Pruebas de Software se han convertido en una actividad de gran importancia dentro de la Ingeniería de Software, elementoque nos brinda la oportunidad detectar fallos y evaluar las características del software. Las pruebas han evolucionado a lo largo del tiempo, han pasado de ser una simple etapa en el proceso de desarrollo a constituirse en un conjunto de etapas que controlan la duración del ciclo de vida, la calidad y la confiabilidad del software desarrollado.
Actualmente con el incremento del desarrollo de productos de software, y las tendencias de aseguramiento de la calidad en los mismos, se ha considerado la importancia de las Pruebas de Software como proceso de aseguramiento de la calidad dentro de la Ingeniería de Software, tanto así que la fase de pruebas es una de las más costosas del ciclo de vida software. Un caso concreto son los métodos XP, Scrum y OpenUP que aplican ciclos de desarrollo iterativos y que se basan en los principios definidos por el modelo de desarrollo guiado por pruebas (TDD). Las pruebas son una disciplina compleja, conformada por muchos elementos técnicos y de gestión, los cuales son definidos en (Gelvez, 2010).
Ámbito de las pruebas: corresponde a la etapa o alcance de las pruebas, unitarias, de componentes, de integración, de sistema, de validación, de aceptación (Paul Baker, 2008).
Tipos de prueba: de acuerdo a las dimensiones que deseanevaluar se clasifica en funcionales, de usabilidad, confiabilidad, integridad, rendimiento, infraestructura y regresión (Ahmad K. Shuja, 2007).
Ciclos de aplicación: en (Paul Baker, 2008) se tratan como un proyecto relacionado con el proceso de desarrollo, definiendo las fase de requisitos, diseño, especificación, implementación, validación, ejecución y evaluación.
Proceso de pruebas: hay diversos procesos, en (Mark Utting, 2007) se describen los mas usados, como prueba manual, grabación, basadas en secuencia de comandos, automatizadas, basadas en modelos.
2.2 SERVICIOS WEB Y SOAEn (Krafzid, Banke, & Slama, 2005) se definen cuatro abstracciones básicas para el estilo SOA: servicios, aplicaciones front-end, repositorio de servicios y bus de servicios. El paradigma descubrir-ligar-invocar es la base del enfoque para el desacoplamiento de servicios, donde los productores de servicios los registran en el repositorio, los consumidores de servicios los buscan en el repositorio, y si existen obtienen una referencia para realizar el ligamiento e invocarlos.
Según (Krafzid, Banke, & Slama, 2005) un servicio consiste en una implementación que provee lógica de negocio y datos, un contrato de servicio que especifica las interfaz que expone físicamente la funcionalidad. Según (Gelvez, 2010) un servicio es una pieza de código independiente que en conjunto representan un entorno de aplicación. Los servicios poseen unas características únicas que les permiten formar parte de una arquitectura orientada a servicios, son autónomos e independientes de otros servicios y permiten crear funcionalidades aisladas del negocio (representan la lógica de una unidad de negocio).
Los servicios representan grupos lógicos de operaciones relacionadas con algún concepto del negocio. Las aplicaciones front-end consumen los servicios y/o los exponen, el repositorio de servicios almacena los contratos de servicios, y el bus de servicios interconecta las aplicaciones front-end y los servicios. Además los servicios pueden clasificarse según su propósito en servicios orientados a procesos que realizan los procesos de negocio, servicios intermediarios, básicos y públicos empresariales (B2B). Aparecen dos nuevas capas de abstracción: procesos de negocio y servicios, en las que se modelan los tipos de servicios y su composición.
Se hace necesario contar con una metodología para desarrollo de software con enfoque SOA que permita realizar un diseño acorde a los requerimientos planteados. Una metodología para desarrollo con enfoque SOA se propone en (Delgado & Garcia, 2010).
2.3 PRUEBAS DE INTEGRACION DE SERVICIOSEn En (Torry Harris Bussiness Solutions, 2007) se menciona algunos aspectos importantes:
* Determinar las variaciones de los datos utilizados para probar el servicio.En (IBM, 2015) se plantean los inconvenientes de las aplicaciones de integración y definen una mejor estrategia, basados en el hecho de que en un SOA la lógica de las aplicaciones está ubicada dentro del nivel intermedio, funcionando con un número indeterminado de tecnologías, residiendo fuera del departamento o incluso fuera de la empresa. Por este motivo, las pruebas de extremo a extremo, incluso en el entorno de prueba, dependen de terceros. Si un sistema externo crítico no se encuentra disponible, tendrá el potencial de interrumpir el ciclo de aplicación de pruebas en caso de que el equipo no esté preparado.
Para poder estar preparados, la literatura incluye el concepto de falsos servicios, como una estrategia que permita a los testers garantizar la disponibilidad de la funcionalidad, con el solo uso de la interfaz del servicio.
Los falsos servicios ayudan a los equipos a reducirla dependencia respecto de los involucrados cuando se ejecuta la prueba de integración. El equipo puede crear servicios que se comportan de manera similar a los servicios reales.Estos servicios son generados usando los esquemas reales (WSDL y compatibles) del servicio original. Luego se dota al falso servicio de un conjunto de respuestas, que se utiliza para responder a la solicitud del falso servicio. Las respuestas pueden ser aleatorias, consistir en una operación por turnos o basarse en ciertas reglas o directivas.
Los falsos servicios se utilizan si el servicio real no está disponible, esto garantiza que la aplicación de pruebas no se vea afectada por retardos en la implementación de los servicios. De igual forma estos falsos servicios ayudan a generar un ambiente de pruebas más controlado.
En (IBM, 2015) proponen mantener suites de pruebas de integración automatizadas y guiarse por un marco de pruebas de servicios definido por ellos.
Dentro del marco de pruebas se definen algunas capacidades comunes que se deben desarrollar:
* La capacidad de producir agentes de prueba en ausencia de la interfaz de usuario de una aplicaciónEn (Facundo, 2015) definen un proceso de automatización de las pruebas de integración a través de la creación de un framework para la automatización de pruebas, sin necesidad de crear los servicios finales.
Todo el proceso de las pruebas de integración se basa en las interfaces que interconectan a los servicios, por lo tanto es necesario realizar el análisis de los elementos que componen.
3.RESULTADOSEl método es un conjunto de pasos que genera uno o varios resultados; también se define como un procedimiento que presenta un inicio y un fin.
El desarrollo de este método permite a las personas encargadas de realizar pruebas en arquitecturas orientadas a servicios, tener una guía para el diseño y ejecución de pruebas de integración.
Se recomienda a la persona que desee implementar este método seguir las siguientes recomendaciones:
Seguir cada fase de forma ordenada.
Mantener comunicación con el equipo de desarrollo sobre las actividades realizadas.
En la ¡Error! No se encuentra el origen de la referenciase presenta el desglose del método propuesto el cual se divide en cuatro fases: 1) Conocimiento global del entorno de desarrollo, 2) Diseño de los casos de prueba de integración de los servicios, 3) Implementación de la prueba de integración de servicios, 4) Ejecución de la prueba y análisis de resultados y las actividades correspondientes a cada fase.
En esta sección se enmarcan algunas bases conceptuales y teóricas de las pruebas de software y los servicios Web.
A continuación se describirán cada una de las fases que componen al método para pruebas de integración para arquitecturas orientadas a servicios.
3.1 Fase 1 -Conocimiento del entorno de desarrolloDentro de esta actividad se deben tener varios ítems para poner a punto el entorno donde se ejercitara el software bajo pruebas:
* Configurar las herramientas que serán utilizadas para este procesoPara poder determinar el tamaño del software bajo prueba, se deben definir los servicios que van a ser consumidos por la aplicación. Para este proceso se propone la Figura 2 que contiene la plantilla de Historia del Servicio, la misma se utiliza para cada servicio y se define cada método y requerimiento cubierto.
1Apache Ant es una herramienta usada en programación para la realización de tareas mecánicas y repetitivas, normalmente durante la fase de compilación y construcción.
Algo importante que el probador debe incluir son los parámetros de entrada y parámetros de salida de cada método, los cuales deben ser abstraídos de la WSDL del servicio. Es importante identificar los métodos a través de la WSDL, ya que teóricamente, si el servicio al interior cambia, la WSDL debe mantenerse igual.
3.1.3 Elaborar plan de pruebasEn esta guía se recomienda realizar pruebas de todos los servicios que hacen parte del proyecto, pero estodepende del tamaño del mismo, para lo cual se podría basar en algunos criterios como nivel de criticidad o nivel de utilización de los mismos, de esta forma se probarían los que sean más críticos para el proyecto o los que más se utilicen.
3.2.2 Definición de baterías de casos y requisitos de pruebasPara trabajar con falsos servicios se utiliza la herramienta SoapUI2, que en base al archivo WSDL puede crear la simulación de las operaciones o solicitudes del servicio, generar una respuesta con un valor especifico y ejecutar un servidor interno al cual se conecta el software al momento de consumir el servicio. En la Figura 3 se observa la ejecución de un falso servicio para un método que realiza la suma de dos números.
A través del proceso anterior se puede garantizar que los desarrolladores puedan consumir el servicio así el mismo no se encuentre desarrollado o disponible.
Durante esta fase se deben definir los resultados de las pruebas que servirán como oráculo3de la prueba para la comprobación de las mismas. Estos datos deben ser utilizados en la realización de las baterías de pruebas, al momento de definir las comprobaciones.
3.3 Fase 3 -Implementación de la Prueba de integración de serviciosAl finalizar esta tarea se obtiene una plantilla del caso de prueba que será utilizada para la construcción del caso de prueba como se observa en la Figura 4. El ejemplo muestra un caso de prueba típico para un servicio, en el cual durante la fase de ejecución deben inyectarse los datos de prueba, reemplazando los signos “?” por valores.
La plantilla anterior fue creada utilizando la herramienta SoapUI, que utiliza la dirección de la WSDL de la interface del servicio, para crear el archivo XML.
Igualmente se deben definir las aserciones o comprobaciones del caso de prueba; estas comprobaciones se realizan sobre la respuesta del servicio y pueden ser referentes a la validez del mensaje SOAP, a la calidad del servicio o a la coincidencia de resultados y utilizan los valores de comprobación definidos en fases anteriores.
3.3.2 La preparación de datos de la prueba
En esta fase se deben resolver las dependencias para que el ambiente de pruebas se pueda ejecutar de forma independiente a través de la creación de falsos servicios (Mock Services)con herramientas como SoapUI.
3.4 Fase 4 -Ejecución de la Prueba y análisis de resultadosEl contexto del proyecto es la Universidad Simón Bolívar de la Ciudad de Cúcuta Norte de Santander y con el apoyo del Departamento de Sistemas y su equipo de desarrolladores, quienes posibilitaron la aplicación de este método.
Se diseña un método que a través de sus fases guía al equipo de desarrollo para que puedan diseñar e implementar un conjunto de pruebas que se aplican a las interfaces que participan en los proyectos SOA, como parte del proceso de pruebas de integración. El método además de apoyar el proceso de diseño e implementación de las pruebas, intenta documentar el mismo a través del uso de plantillas que generan trabajo adicional, aspecto que debe evaluarse al momento de conocer el equipo de desarrollo y determinar si el mismo está dispuesto a aplicar el método.
El método propuesto se enfoca en la evaluación de las interfaces que participan en el proyecto apoyándose en un conjunto de herramientas, permitiendo que los distintos desarrolladores puedan trabajar en la capa de entrega al consumir los servicios sin preocuparse por la finalización de la capa de exposición de funcionalidades o servicios.
En la validación del modelo se logró apoyar el proceso de desarrollo de un aplicativo para la Universidad Simón Bolívar sede Cúcuta,pero se presentaron algunos inconvenientes referentes al proceso de configuración de las herramientas para la ejecución de pruebas, debido a que la configuración de las mismas no es tan sencilla, hay poca documentación en español y la persona encargada del proceso de pruebas no había trabajado herramientas como Ant para la generación de Scripts.
Al momento de aplicar las plantillas del proceso de prueba, el equipo encargado del proyecto no estuvo totalmente de acuerdo y se encontró una resistencia evidente, debido a que el equipo encargado de la realización del proyecto está compuesto en su mayoría por desarrolladores y no están acostumbrados a realizar un proceso de pruebas y documentación.
Dentro de los aspectos a destacar se tiene el proceso de desarrollo debido a que con la creación de los falsosservicios, los desarrolladores trabajaron directamente en la aplicación sin preocuparse por la funcionalidad o disponibilidad de los servicios, esto permitió que los procesos tanto a nivel del cliente como a nivel de los servicios se realizaran paralelamente.
6. BIBLIOGRAFÍAAhmad K. Shuja, J. K. (2007). IBM Rational Unified Process Reference an Certification Guide: Solution Designer.
Delgado, A., & Garcia, I. (2010). Metodologías de desarrollo para Service Oriented Architectures con Rational Unified Process. Metodologías de desarrollo para SOAs con RUP, 126-131
Gelvez, H. A. (2010). Contribucion a la gestion de los procesos depruebas de software y servicios.
IBM. (2015). IBM Developer Works. Obtenido de http://www.ibm.com/developerworks/ssa/library/ws-SOAbestpractices/
Krafzid, D., Banke, K., & Slama, D. (2005). Enterprise SOA Service-Oriented Architecture: Best Practices. Prentice Hall.
Mark Utting, B. L. (2007). Practical Model-Based Testing a Tools Aproach. San Francisco: Morgan Kaufmann.
Paul Baker, Z. R. (2008). Model-Driven Testing Using the UML Testing Profile. Springer.
SWEBOK.(2004).Guide to the Software Engineering Body of Knowledge.
Torry Harris Bussiness Solutions. (2007). SOA Test Methodology. Obtenido de Torry Harris.
* Magister. Correo: nelsonbeltran@ufps.edu.co
** Ingeniero. Correo: carlosreneas@ufps.edu.co
*** Magister. Correo: claudiaygomez@ufps.edu.co
