UNIVERSIDAD DE COSTA RICA SISTEMA DE ESTUDIOS DE POSGRADO INCORPORACIÓN DE PRUEBAS BASADAS EN MODELOS PARA SERVICIOS WEB EN UN CONTEXTO DE DESARROLLO ÁGIL: UN CASO DE ESTUDIO EN LA INDUSTRIA Trabajo final de investigación aplicada sometido a la consideración de la Comisión del Programa de Estudios de Posgrado en Computación e Informática para optar al grado y título de Maestría Profesional en Computación e Informática BRENDA AYDIL AYMERICH FUENTES Ciudad Universitaria Rodrigo Facio, Costa Rica 2022 ii Dedicatoria Dedico este trabajo a mi madre, quien ha sido mi soporte constante e incondicional en todo momento. Además, a mi familia que siempre cree en mí. iii Agradecimientos Quiero agradecer a mis profesores guías: la Dra. Alexandra Martínez, el Dr. Luis Quesada y el Dr. Marcelo Jenkins, por el soporte y la guía académica que me brindaron en todo momento. También agradezco al Dr. Christian Quesada, quien colaboró en el planteamiento inicial del trabajo de investigación y en el diseño del caso de estudio. Además, externo un agradecimiento a los participantes del estudio, por su colaboración y el tiempo invertido. iv Hoja de Aprobación v Tabla de Contenidos Dedicatoria ii Agradecimientos iii Hoja de Aprobación iv Tabla de Contenidos v Resumen viii Lista de Tablas ix Lista de Figuras x Capítulo 1. Introducción 1 1.1. Problema 2 1.2. Justificación 2 1.3. Objetivos 3 1.3.1. Objetivo general 3 1.3.2. Objetivos específicos 3 Capítulo 2. Marco Teórico 4 2.1. Pruebas de software 4 2.1.1. Tipos de pruebas de software según su objetivo de prueba 4 2.1.2. Formas de ejecución de las pruebas de software 6 2.2. Modelo 7 2.3. Pruebas basadas en modelos 7 2.4. Taxonomía de las pruebas basadas en modelos 8 2.5. Servicios web 11 2.5.1. Servicios web SOAP 12 2.5.2. Servicios web REST 12 2.5.3. Pruebas para servicios web RESTful 13 2.6. Agilidad 13 2.6.1. Pruebas de software en contextos ágiles 14 Capítulo 3. Trabajo relacionado 15 3.1 Pruebas de servicios web usando MBT 15 3.2 Pruebas de servicios web usando técnicas alternativas a MBT 17 3.3 Automatización de pruebas en ágil 19 Capítulo 4. Metodología 21 4.1. Metodología del mapeo sistemático de literatura 21 4.1.1. Etapa 1: Diseño de la revisión 22 4.1.2. Etapa 2: Ejecución de la revisión 22 vi 4.1.3. Etapa 3: Análisis de resultados de la revisión 22 4.2. Metodología del caso de estudio 23 4.2.1. Etapa 1: Diseño del caso de estudio 23 4.2.2. Etapa 2: Ejecución del caso de estudio 23 4.2.3. Etapa 3: Análisis de resultados del caso de estudio 25 Capítulo 5. Mapeo sistemático de literatura 26 5.1. Objetivo y preguntas de investigación 26 5.1.1. Objetivo GQM 26 5.1.2. Preguntas de investigación 26 5.2. Estrategia de búsqueda y proceso de selección de estudios 27 5.3. Proceso de evaluación de calidad 29 5.4. Proceso de extracción y análisis de datos 30 5.4.1. Extensión de la taxonomía base 31 5.5. Amenazas a la validez 32 5.6.1. Enfoques de MBT aplicados en servicios web (RQ1) 33 5.6.2. Tipos de servicios web probados con MBT (RQ2) 41 5.6.3. Herramientas de MBT usadas para probar servicios web (RQ3) 43 5.6.4. Contextos de aplicación de MBT en servicios web (RQ4) 47 Capítulo 6. Caso de estudio 50 6.1. Objetivo y preguntas de investigación 50 6.1.1. Objetivo 50 6.1.2. Preguntas de investigación 50 6.2. Contexto 50 6.2.1. Selección del sistema bajo pruebas 51 6.2.2. Selección del enfoque para utilizar MBT sobre el SUT 51 6.2.3. Selección de la herramienta de MBT 53 6.3. Proceso y recolección de datos 53 6.4. Métricas de evaluación 56 6.4.1. Métricas de eficiencia y eficacia 57 6.4.2. Métricas de aceptación 57 6.5. Amenazas a la validez 57 6.5.1. Validez constructo 57 6.5.2. Validez interna 58 6.5.3. Validez externa 58 6.5.4. Validez de conclusión 58 6.6. Resultados del caso de estudio 58 vii 6.6.1. Eficacia y eficiencia de aplicar pruebas basadas en modelos para automatizar las pruebas funcionales de servicios web (RQ1) 58 6.6.2. Aceptación al introducir pruebas basadas en modelos (RQ2) 61 6.6.3. Discusión 65 6.6.4. Lecciones aprendidas 67 Capítulo 7. Conclusiones 68 7.1. Trabajo futuro 71 Bibliografía 73 Apéndice A 80 Artículo de investigación 80 Apéndice B 81 Encuesta de conocimiento previo 81 Apéndice C 82 Encuesta de aceptación 82 Apéndice D 83 Datos base extraídos de los artículos 83 Apéndice E 85 Criterios de inclusión y exclusión 85 Apéndice F 86 Criterios de calidad 86 Apéndice G 87 Datos extraídos para las RQ 87 viii Resumen Los equipos ágiles enfrentan dificultades para realizar pruebas de software a profundidad, debido a las cortas iteraciones de desarrollo. Con frecuencia, las pruebas para servicios web se realizan manualmente, consumen mucho tiempo y requieren la experticia de los miembros del equipo. Un enfoque de pruebas basadas en modelos, que permita la automatización de estas pruebas, podría mejorar la eficiencia del proceso y la calidad de los productos. Sin embargo, la adopción de tal enfoque de pruebas no debería interferir en el seguimiento de los valores, principios y prácticas de las metodologías ágiles. En esta investigación se realiza un mapeo sistemático de literatura para determinar los distintos enfoques de pruebas basadas en modelos (MBT) que se han aplicado para probar servicios web, así como las herramientas utilizadas y los contextos de aplicación. Posteriormente, se introduce un enfoque de pruebas basadas en modelos en el contexto de un equipo que trabaja con prácticas ágiles, con el fin de evaluar su impacto en términos de su eficacia, eficiencia y aceptación. Esto se hace mediante un caso de estudio donde se utiliza la herramienta TestOptimal para probar servicios web RESTful. Como parte de la evaluación, se consideran las percepciones de los miembros del equipo, así como los retos y oportunidades asociadas al uso de este tipo de enfoques en equipos ágiles. Entre los principales hallazgos del mapeo sistemático de literatura se tiene: (1) que la mayoría de los enfoques de pruebas basadas en modelos para servicios web hacen pruebas funcionales y usan comúnmente como modelo, notaciones basadas en transiciones, por ejemplo: máquinas de estado; (2) que la fase de ejecución de casos de prueba de MBT es la más apoyada por las herramientas reportadas, y (3) que la mayoría de los servicios web probados con el enfoque de pruebas basadas en modelos pertenecían a contextos que involucran servicios de compra y venta. Por su parte, los resultados del caso de estudio sugieren que las pruebas basadas en modelos permiten aumentar el número de casos de prueba y defectos encontrados. Además, los miembros del equipo consideran que, para incrementar la aceptación de estos enfoques durante el desarrollo de un proyecto ágil, es esencial conocer cómo hacer el modelado y conocer las herramientas de apoyo. A pesar de lograr una mejora en la generación de casos de prueba automatizados y en la detección de defectos, el uso de este enfoque es percibido como una tarea compleja de aplicar. En conclusión, el presente trabajo expone por medio de un mapeo sistemático, una vista con un amplio nivel de detalle, del uso de MBT para servicios web a través del tiempo. Esto, a su vez permitió contribuir en la ampliación del dominio de servicios web en una taxonomía MBT utilizada como base. Además, dado que las pruebas basadas en modelos no han sido ampliamente usadas ni estudiadas en el contexto de servicios web RESTful, y en menor medida, en equipos que implementan prácticas ágiles; se desarrolla un caso de estudio, donde se selecciona, implementa y evalúa un enfoque MBT para un servicio web REST desarrollado por un equipo ágil. ix Lista de Tablas Tabla 1. Criterios de inclusión y exclusión. __________________________________ 28 Tabla 2. Elementos de datos extraídos de los estudios. _________________________ 30 Tabla 3. Clasificación de estudios según el tipo de modelo (nivel 3 de la taxonomía). _ 36 Tabla 4. Clasificación de estudios según el tipo de prueba (nivel 3 de la taxonomía). _ 39 Tabla 5. Clasificación de los estudios según el tipo de servicio web probado. _______ 42 Tabla 6. Herramientas reportadas y uso que se le dio dentro de MBT. _____________ 44 Tabla 7. Clasificación de los estudios según el contexto del servicio web probado. ___ 48 Tabla 8. Resultados de los datos de realizar pruebas manuales contra pruebas MBT. Datos para evaluar eficacia. ______________________________________________ 60 Tabla 9. Resultados de los datos de realizar pruebas manuales contra pruebas MBT. Datos para evaluar eficiencia. ____________________________________________ 61 x Lista de Figuras Figura 1. Taxonomía base. _______________________________________________ 10 Figura 2. Metodología seguida para alcanzar los objetivos de la investigación. ______ 21 Figura 3. Resultado de aplicación de criterios de inclusión y exclusión. ____________ 28 Figura 4. Cantidad de estudios por año. _____________________________________ 29 Figura 5. Taxonomía extendida. ___________________________________________ 31 Figura 6. Estudios mapeados dentro de la taxonomía según el tipo de modelo. ______ 35 Figura 7. Cantidad de estudios por tipo de modelado utilizado para servicios web con MBT. _______________________________________________________________ 36 Figura 8. Uso de tipos de modelos para servicios web a través del tiempo. _________ 37 Figura 9. Estudios mapeados dentro de la taxonomía según el tipo de prueba. _______ 38 Figura 10. Cantidad de estudios por tipo de prueba utilizado para servicios web con MBT. _______________________________________________________________ 39 Figura 11. Uso de tipos de pruebas para servicios web a través del tiempo. _________ 40 Figura 12. Enfoques MBT por tipos de modelo y por tipos de prueba. _____________ 41 Figura 13. Cantidad de estudios por tipo de servicio web. _______________________ 42 Figura 14. Tipos de servicios web probados con MBT a través del tiempo. _________ 42 Figura 15. Porcentaje de estudios que soportaron las distintas fases MBT. _________ 45 Figura 16. Uso de las herramientas a través del tiempo. ________________________ 46 Figura 17. Herramientas con más de un uso reportado. _________________________ 46 Figura 18. Relación entre las herramientas y los distintos tipos de prueba. __________ 47 Figura 19. Contextos de aplicación de los servicios web. _______________________ 49 Figura 20. Proceso de recolección, ejecución y análisis de datos. _________________ 54 Figura 21. Modelo del flujo a probar realizado por el grupo 1 con la herramienta TestOptimal. __________________________________________________________ 59 Figura 22. Modelo del flujo a probar realizado por el grupo 2 con la herramienta TestOptimal. __________________________________________________________ 59 Figura 23. Percepción de facilidad de uso del enfoque MBT y la herramienta. ______ 62 Figura 24. Percepción de utilidad de uso del enfoque MBT y la herramienta. _______ 64 Figura 25. Intención de uso del enfoque MBT y la herramienta. __________________ 65 1 Capítulo 1. Introducción Dada la creciente complejidad en el desarrollo de sistemas de software, la utilización de arquitecturas orientadas a servicios ha emergido como una estrategia muy atractiva dada su capacidad de responder con flexibilidad, adaptabilidad y rapidez a las necesidades cambiantes de las organizaciones [30]. El desarrollo de servicios web basados en REST (representational state transfer), resulta muy útil por su capacidad de ser consumido por diferentes clientes, tales como aplicaciones móviles Android o iOS, así como aplicaciones web, entre otros. Sin embargo, aún hay carencia de conocimiento sobre cómo verificar funcionalmente este tipo de servicios, lo cual puede resultar en la realización de pruebas poco eficientes [19]. En particular, las pruebas manuales para servicios web RESTful presentan un gran desafío debido al tiempo que consume su elaboración y ejecución por la dificultad que presenta el contexto de los servicios web. Algunos de los principales retos que enfrentan estas pruebas son: la falta de una interfaz de usuario, que hace que las entradas y salidas involucradas no sean fácilmente manipulables; el uso de componentes débilmente acoplados, que puede presentar incompatibilidad de datos; y la confiabilidad del medio de comunicación, que puede derivar fallas difíciles de distinguir [12]. Por otro lado, en los entornos de desarrollo ágil se acepta el cambio como una ventaja competitiva para el negocio, donde se trabaja en iteraciones cortas que producen entregas incrementales del producto final. Adicionalmente, generalmente los desarrolladores de un equipo ágil realizan diversas tareas del ciclo de desarrollo y ninguno está totalmente dedicado a hacer pruebas de software [9]. Resulta importante entonces reducir el esfuerzo humano invertido en tareas repetitivas, acelerando así los ciclos de ejecución de pruebas, esto con el fin de adaptarse al cambio con una retroalimentación temprana [13]. Por esta razón, a pesar de que hoy en día aún se implementan pruebas manuales en entornos ágiles [13], es necesario buscar y evaluar opciones para su automatización. Las pruebas basadas en modelos (MBT, por sus siglas en inglés: model-based testing) es una estrategia de automatización de pruebas de software que deriva casos de prueba a partir de los modelos que describen el comportamiento del sistema, los que son diseñados por 2 un profesional especializado en pruebas [15]. MBT se usa principalmente en pruebas funcionales [56] utilizando la técnica de caja blanca (white box) y existe evidencia de que puede ayudar a automatizar el proceso de pruebas en servicios web RESTful [19]. En esta línea, han surgido propuestas para utilizar MBT en entornos ágiles donde se crean modelos sencillos que no dependen de profesionales especializados en pruebas [54]. El documento está estructurado de la siguiente manera: el Capítulo 2, presenta conceptos necesarios para el entendimiento adecuado del estudio; el Capítulo 3, describe los trabajos relacionados; el Capítulo 4 expone la metodología utilizada; el Capítulo 5, desarrolla el mapeo sistemático de literatura y muestra sus resultados; el Capítulo 6, describe el caso de estudio, discute sus resultados y lecciones aprendidas; y, el Capítulo 7, presenta las conclusiones y trabajo futuro. 1.1. Problema El problema por investigar es cómo incorporar un enfoque de pruebas basadas en modelos para automatizar las pruebas funcionales de servicios web implementados por una API RESTful, en el contexto de un equipo de desarrollo ágil. También se desea evaluar la eficacia, eficiencia y aceptación –por parte de los desarrolladores– de dicho enfoque y su herramienta asociada, como una forma de medir el impacto de este enfoque en un contexto de desarrollo ágil. Para ello, es necesario realizar primeramente una revisión de literatura que nos permita identificar los principales enfoques de pruebas basadas en modelos que se han usado para probar servicios web, así como las herramientas empleadas, y sus contextos de aplicación. 1.2. Justificación Las pruebas basadas en modelos no han sido ampliamente usadas ni estudiadas en el contexto de servicios web RESTful, y menos aún en el contexto de equipos que aplican metodologías ágiles de desarrollo. Por lo tanto, un caso de estudio donde se seleccione, implemente y evalúe un enfoque de pruebas basadas en modelos para servicios web desarrollados por un equipo ágil, sería de mucha utilidad tanto para la industria de software como para la academia. 3 1.3. Objetivos 1.3.1. Objetivo general Caracterizar enfoques existentes de pruebas basadas en modelos para servicios web RESTful y evaluar la incorporación de uno de esos enfoques en un contexto de desarrollo ágil. 1.3.2. Objetivos específicos 1. Caracterizar enfoques existentes de pruebas basadas en modelos para servicios web RESTful. 2. Evaluar el impacto de incorporar pruebas basadas en modelos para servicios web, en un equipo que implementa prácticas ágiles, en términos de su eficacia, eficiencia y aceptación. 4 Capítulo 2. Marco Teórico Este capítulo describe los diferentes conceptos y fundamentos teóricos en los que se basa la investigación realizada, incluyendo pruebas de software y sus tipos, pruebas basadas en modelos, servicios web, pruebas de servicios web, agilidad y pruebas en el contexto ágil. 2.1. Pruebas de software Las pruebas de software tienen como objetivo ejecutar un sistema de software en el entorno previsto, con el fin de validar si los resultados obtenidos coinciden con su especificación [60]. Las pruebas de software requieren un ejecutable, lo que las diferencia de las revisiones de código, donde el código fuente se lee y se analiza de forma estática, es decir, sin compilar ni ejecutar [60]. Aquellos comportamientos del software que no coinciden con su especificación representan fallas en el software. Una falla puede provenir del código fuente, en cuyo caso se denomina defecto o error. El sistema también puede fallar al no satisfacer las restricciones del entorno o ambiente. Por ejemplo, si el software necesita demasiada memoria puede que se ejecute con lentitud, o bien, si el software se ejecuta correctamente en un sistema operativo específico, pero no en otros [60]. Para realizar pruebas de software se necesitan personas con habilidades de desarrollo y conocimientos de lenguajes formales, teoría de grafos y algoritmos, pues para diseñar y ejecutar las pruebas se debe considerar la función que calcula el software, su combinación de entradas, y el entorno en el que operará el software. Estas tareas a menudo requieren codificación [60]. 2.1.1. Tipos de pruebas de software según su objetivo de prueba Las pruebas de software se pueden clasificar, según su objetivo de prueba, en los tipos que se describen a continuación. Pruebas funcionales Las pruebas funcionales se basan en la especificación funcional del software y su entorno operativo para seleccionar los escenarios de prueba. Estas pruebas no toman en cuenta la 5 estructura del código ni los flujos de datos ni ningún otro detalle sobre el funcionamiento interno del software a nivel de implementación [60]. Para diseñar estas pruebas típicamente se utilizan técnicas de caja negra, que pueden ir desde el nivel de unidad hasta el nivel de sistema. Pruebas no-funcionales Las pruebas no funcionales se centran en probar características o aspectos que aplican a todo el sistema, es decir, que no están relacionados directamente a una funcionalidad. Algunas características de tipo no-funcional son el rendimiento, la seguridad, y la confiabilidad o robustez [24]. A continuación, se describen algunas pruebas de tipo no- funcional. a) Pruebas de rendimiento: El rendimiento de una aplicación refiere a su capacidad para completar la tarea bajo una alta interacción multiusuario o recursos de hardware limitados. [32] Las pruebas de rendimiento dan seguimiento y registran el nivel de rendimiento durante el estrés bajo, regular o alto. El objetivo de estas pruebas es justificar el rendimiento (capacidad de servicio y tiempo de respuesta) del sistema [32]. Los casos de prueba se diseñan para mostrar que el programa no cumple con los requisitos de rendimiento [37] por lo que basados en los objetivos específicos de rendimiento que tenga la aplicación se crean las pruebas [42, 37] para comparar y evaluar su rendimiento [32]. b) Pruebas de seguridad: La prueba de seguridad es el proceso de intentar diseñar casos de prueba que perturben los controles de seguridad del programa [37]. Para un mayor grado de garantía de la seguridad del software, las pruebas deben ser creadas basadas en el riesgo de la aplicación según la arquitectura del sistema y la mentalidad de un posible atacante. Lo anterior, con el fin de enfocar las pruebas en las áreas en las que un ataque podría tener éxito [42, 37]. c) Pruebas de confiabilidad o robustez: La robustez o confiabilidad en un sistema es el grado en que puede tener un comportamiento aceptable a pesar de condiciones de funcionamiento excepcionales o imprevistas, tales como entradas no válidas, errores o condiciones estresantes del entorno [48]. Estas pruebas se diseñan con base en los objetivos específicos de confiabilidad que tenga el sistema [37]. 6 2.1.2. Formas de ejecución de las pruebas de software Las pruebas de software se pueden ejecutar de forma manual o de forma automatizada [33]. A continuación, se describe cada una de ellas. Pruebas de software manuales Las pruebas de software manuales son aquellas que una persona ejecuta manualmente sin ayuda de alguna herramienta de automatización [63]. Los pasos de las pruebas manuales son: (1) entender la funcionalidad de la aplicación, (2) preparar el plan de prueba, (3) escribir los casos de prueba y ejecutarlos, (4) verificar los resultados reales contra los esperados y (5) preparar el reporte de los defectos encontrados [63]. Algunos sistemas pueden requerir pruebas manuales, por ejemplo, las pruebas de dispositivos reales [37]. Sin embargo, las pruebas manuales son laboriosas y propensas a errores incluso con personal capacitado e instrucciones detalladas [37, 16], además, pueden no soportar la misma clase de revisiones de calidad que se pueden alcanzar con un método automatizado [16]. Pruebas de software automatizadas Las pruebas automatizadas son aquellas que utilizan herramientas para la automatización de actividades de pruebas tales como la ejecución de scripts y la verificación de requerimientos [16]. Las herramientas automatizadas han llegado a incluir funcionalidades de prueba para la interfaz de usuario, comunicaciones de red, fugas de memoria, carga, rendimiento y la cobertura de código [16]. Algunos sistemas pueden requerir pruebas automatizadas para simular ciertos escenarios, por ejemplo, para analizar cómo se comportaría el sistema con una carga de cientos de usuarios usando la aplicación [16]. Las pruebas automatizadas pueden reducir los costos y mejorar la calidad del software, ya que se pueden ejecutar más pruebas en menos tiempo [25]. Sin embargo, también pueden generar costos adicionales, debido al costo de implementación, de mantenimiento y de capacitación al personal a cargo del aseguramiento de la calidad [25]. 7 2.2. Modelo Los modelos utilizados en MBT, representan el comportamiento esperado y algún flujo de trabajo del proceso del sistema bajo prueba, en el contexto de su entorno, en un nivel de abstracción dado [57]. Estos llamados modelos MBT deben ser precisos y completos para que permitan la derivación automatizada de pruebas a partir de los mismos [57]. El modelado tiene como fin hacer explícitos los puntos de control, el comportamiento esperado, los flujos de trabajo, los datos lógicos de prueba, entre otros. Los requerimientos se pueden vincular a los elementos que componen el modelo para lograr una trazabilidad entre los requisitos, el modelo MBT y los casos de prueba generados [57]. 2.3. Pruebas basadas en modelos Las pruebas basadas en modelos (MBT, por sus siglas en inglés model-based testing) son un enfoque que genera automáticamente casos de prueba a partir de un modelo que describe el sistema bajo prueba [15]. Estos modelos del sistema bajo prueba (SUT, por sus siglas en inglés system under test) normalmente son diseñados por profesionales del área de pruebas de software. El enfoque de MBT facilita la gestión de cambios durante el desarrollo del software, ya que el profesional en pruebas solo debe actualizar el modelo y una vez hecho esto, el conjunto de pruebas es regenerado de forma automática, disminuyendo el riesgo de errores por cambios manuales [15]. Cleva et al. [15] propone que el proceso de las pruebas basadas en modelos está compuesto por cuatro etapas. La primera corresponde a la construcción del modelo, el cual representa la forma en que se espera que el sistema bajo prueba ejecute sus funciones. La segunda etapa es la selección de los criterios de prueba que determinan el conjunto de casos de prueba y la generación de los casos de prueba de forma automática a partir del modelo. En la tercera etapa se concretizan esos casos de pruebas para que puedan ser ejecutables en el SUT y en la cuarta etapa se realiza la ejecución de los casos de prueba [15]. Sin embargo, Utting et al. [57] propone que la etapa de concretización de casos de prueba es parte de la fase de ejecución, por lo que, con base en esta propuesta de conceptos, las etapas se listan como sigue: 8 Etapa 1: Especificación del modelo En esta etapa se crea un modelo del comportamiento del sistema bajo prueba. Los requerimientos del sistema, los artefactos de análisis y diseño pueden ser una fuente importante para entender el comportamiento del SUT. Sin embargo, el profesional en pruebas debe también comprender el entorno de ejecución de prueba incluyendo factores como el sistema operativo, la interacción con otros sistemas, y los distintos tipos de bibliotecas [15]. Etapa 2: Generación de casos de prueba En esta etapa, una herramienta debe soportar la generación automática de los casos de prueba. El algoritmo de generación de pruebas depende de la técnica de modelado. Las entradas de la herramienta son el modelo del software y el criterio de selección de pruebas, y con base en esto, se genera un conjunto de casos de prueba [15]. Los casos de prueba generados son abstractos y aún no pueden ser ejecutados ya que están en un nivel de abstracción distinto al SUT. Etapa 3: Ejecución de casos de prueba En esta etapa los casos de prueba abstractos se concretizan para que puedan ser ejecutados en el SUT. Este proceso implica el uso de adaptadores: componentes de software que transforman las entradas y salidas entre dos niveles de abstracción: modelo y SUT, para permitir que se pueda ejecutar un caso de prueba abstracto. Además, en esta etapa se aplican los casos de prueba ejecutables sobre el SUT. Una vez finalizada la ejecución, se analizan los resultados y se toman las acciones para corregir los errores [15]. 2.4. Taxonomía de las pruebas basadas en modelos Varias taxonomías han sido propuestas para clasificar las pruebas basadas en modelos [1,2,3]. En la taxonomía de Utting et al. [58] se realiza un aporte a la comunidad de pruebas por medio de la creación de una taxonomía de seis dimensiones para la caracterización de los diferentes enfoques de MBT, las cuales reflejan el proceso de MBT expuesto por los autores. Además, ofrece un marco para la comparación y evaluación de herramientas de forma cualitativa. En el 2015 Utting et al. [57] realiza una actualización de la investigación en el área realizada anteriormente en el 2012 [59] donde expone los avances recientes en el campo 9 de las pruebas basadas en modelos. En ella se detallan los modelos más actuales usados por la comunidad MBT, el método para la generación de los modelos y pruebas. Asimismo, de forma breve describe hallazgos resultantes de una encuesta a usuarios de MBT en la industria, así como los desafíos a futuro de este método de prueba. Por su parte Marinescu et al. [35] realiza un estado del arte de MBT soportado por herramientas a partir de modelos basados en requerimientos. Adicionalmente, clasifica las herramientas más maduras disponibles para el momento de la publicación por medio de la extensión de la taxonomía de Utting et al. [58]. A las 4 de las dimensiones de Utting et al. [58]: Paradigma del modelo, Criterio de selección de prueba, Método de generación de prueba y Ejecución de prueba, añadió (1) Artefacto de prueba y (2) Mapeo. El estudio de Villalobos et al. [59] expande las dos taxonomías anteriores de Utting et al. [58] y Marinescu et al. [35], y tiene como objetivo identificar y caracterizar los estudios secundarios de MBT en términos de áreas, herramientas, retos, problemas y limitaciones, a través de un mapeo sistemático de literatura. Para la clasificación de los tipos de prueba y los tipos de modelos de MBT, el presente estudio usó la clasificación de las áreas de MBT propuesta en la taxonomía de Villalobos- Arias et al. [59]. Específicamente, se utilizó el área “Especificación de modelo/Paradigma del modelo” para la clasificación de los tipos de modelo y el área “Objetivo de prueba/Tipo de prueba” para la clasificación de los tipos de prueba; áreas mostradas en la Figura 1. 10 Figura 1. Taxonomía base. Seguidamente se describen las subáreas pertenecientes a las dos áreas de MBT mencionadas, “Especificación de modelo” y “Objetivo de prueba” [59], con el fin de ofrecer un punto de referencia conceptual para el posterior análisis de los resultados del mapeo sistemático. Área “Especificación del modelo” Subárea “Paradigma del modelo”: a) Notaciones basadas en estado: modelan un sistema como una colección de variables, que representan una instantánea del estado interno del sistema, más algunas operaciones que modifican esas variables. Cada operación suele estar definida por una precondición y una postcondición, o la postcondición puede escribirse como código explícito que actualiza el estado. [58]. b) Notaciones basadas en transiciones: se enfocan en describir las transiciones entre diferentes estados del sistema. Por lo general, son notaciones gráficas de vértices (nodos) y aristas, como las máquinas de estado finito, donde los vértices representan los principales estados del sistema y las aristas representan las acciones u operaciones del sistema. También se utilizan notaciones textuales o tabulares para especificar las transiciones. Ejemplos de notaciones basadas en transiciones que se utilizan en MBT incluyen las propias máquinas de estado finito, diagramas de estado (por ejemplo, máquinas de estado de UML, diagramas de estado y diagramas de flujo de estado), sistemas de transición etiquetados y autómatas de Entrada/Salida [58]. 11 c) Estocástico: describen un sistema mediante un modelo probabilístico de los eventos y valores de entrada, y tienden a usarse para modelar entornos en lugar del SUT. Por ejemplo, las cadenas de Markov se utilizan para modelar los perfiles de uso esperados, de modo que las pruebas generadas ejerzan ese perfil de uso [58]. Área “Objetivos de prueba” Subárea “Tipo de prueba”: a) Prueba Funcional: busca probar la funcionalidad o comportamiento de un sistema bajo prueba. Los casos de prueba se diseñan según lo requerido en la especificación del software, de manera que, al ejecutar estas pruebas sobre el software en el entorno elegido, se pueda determinar si el resultado de la funcionalidad es el mismo que el esperado [60]. b) Prueba No-funcional: se centran en parámetros de calidad del software tales como el rendimiento, la usabilidad, la accesibilidad, la seguridad y la tolerancia a fallos del sistema, frente a circunstancias específicas y bajo condiciones esperadas o adversas [24]. 2.5. Servicios web Los servicios web son una forma estándar de distribuir servicios a través de Internet [36]. Asimismo, son una característica valiosa que permite combinar diferentes aplicaciones para generar nuevos servicios basados en aplicaciones existentes [34]. Los servicios web son independientes de la plataforma y están poco acoplados, lo que significa que los clientes no necesitan tener un conocimiento previo del servicio web hasta que lo usan [36]. Existen dos tipos de servicios web, uno basado en el principio SOAP y el otro en el principio REST [36]. Con estos servicios se pueden desarrollar distintos tipos de aplicaciones, entre ellos, aplicaciones de tipo conferencia y aplicaciones web [36]. A continuación, se explica cada uno de ellos en detalle: 12 2.5.1. Servicios web SOAP SOAP es una forma en que los servicios web usan XML para intercambiar información estructurada y escrita entre aplicaciones comunicantes. SOAP fue inicialmente el acrónimo de Simple Object Access Protocol. Sin embargo, en la versión 1.2 del protocolo, el W3C dejó de considerarlo un acrónimo por lo que ahora SOAP es en sí mismo un nombre. [34]. Para que una aplicación pueda utilizar una función de otra, debe crear un documento XML correspondiente a los argumentos de la función y enviarlos vía web a la otra aplicación. Esta última extrae los argumentos de la función de este documento XML y ejecuta la función que hospeda. Por último, de la misma forma se devuelve el resultado a la aplicación cliente como XML [34]. XML es textual y detallado, por lo que al usar este lenguaje como medio de intercambio de información, se pierde brevedad, pero a cambio se gana en comprensibilidad para los humanos [34]. SOAP define una forma estándar para el formato y el contenido de los documentos XML que intercambian las aplicaciones. Algunos detalles del formato SOAP son [34]: que los mensajes están en XML, y se componen de encabezado y cuerpo. El encabezado contiene la información del protocolo, mientras que el cuerpo contiene la información o mensaje (carga) que se intercambia en los datos transmitidos: datos de entrada, salida y fallos. 2.5.2. Servicios web REST REST o transferencia de estado representacional, es el estándar de la arquitectura de comunicación basada en web comúnmente aplicado en el desarrollo de servicios web. Esta arquitectura utiliza el protocolo de transferencia de hipertexto (HTTP) para la comunicación de datos [5]. Un API RESTful es el conjunto de servicios que contiene las funciones y procedimientos necesarios para compartir información entre dos sistemas de software utilizando la arquitectura REST. 13 El protocolo HTTP permite cuatro operaciones principales: GET, POST, PUT y DELETE, y está constituido por cuatro componentes: verb/method, resource path, headers y body [5]. Este utiliza formatos de respuesta tales como JSON, XML o HTML, donde el formato JSON es uno de los más utilizados por su simplicidad para ser analizado sintácticamente [38]. 2.5.3. Pruebas para servicios web RESTful Las pruebas funcionales para los componentes de las API RESTful son las que se realizan en primera instancia para asegurar la calidad del servicio web. Existen dos aspectos importantes a considerar en estas pruebas: en primer lugar, respuestas con un cuerpo correcto, es decir, encabezados válidos HTTP y congruentes con el código de estado de la respuesta; y, en segundo lugar, URLs devueltas correctamente [19]. Debido a que los casos de prueba para responder a estas necesidades de prueba son muy similares, el uso de pruebas guiadas por modelos podría ser un gran aliado para evitar errores producto del factor humano al replicar cientos de casos de prueba similares [19]. 2.6. Agilidad La agilidad en el desarrollo de software nace en el año 2001 con el Manifiesto Ágil, que contiene los valores y principios básicos que caracterizan a las metodologías ágiles [62]. El marco de trabajo ágil Scrum es la metodología ágil más utilizada a nivel mundial y es a partir de este que surgen la mayoría de los principios ágiles [3]. Scrum trabaja en iteraciones donde no solo se integran el desarrollo y el aseguramiento de la calidad, sino momentos de inspección del producto y del proceso para su adaptación en la próxima iteración; respondiendo de manera oportuna al cambio para disminuir su riesgo asociado. Las iteraciones son periodos de una semana a un mes, en las cuales se realizan todas las actividades de desarrollo de software terminando con la entrega de un incremento del producto final. El equipo de desarrollo ágil se caracteriza por ser multifuncional, por lo que no tiene roles específicos dedicados únicamente al desarrollo o al aseguramiento de la calidad [47]. El desarrollo ágil está guiado por 4 valores y 12 principios, los cuales buscan que los equipos se enfoquen más en la respuesta al cambio que en cumplir con un plan establecido, en la colaboración con el cliente más que basarse solo en relación contractual, 14 en la generación de productos funcionales más que en generación excesiva de documentación, y en valorar más a las personas y sus interacciones que el proceso y las herramientas utilizadas [3]. Un equipo que se denomine ágil debe basarse en estos valores para formar su propia manera de trabajar con respecto al proceso y al producto. Esto incluye también la forma de realizar las pruebas de software, por lo que cualquier decisión sobre las pruebas no debería poner en riesgo la agilidad del proceso [3]. 2.6.1. Pruebas de software en contextos ágiles Los entornos de desarrollo ágil suelen estar compuestos por pequeños equipos de desarrolladores que también actúan como probadores. En proyectos más grandes con más recursos, los equipos ágiles usualmente están integrados también por probadores dedicados a esta tarea [37]. En ambos casos la agilidad busca que el objetivo común sea avanzar exitosamente en el proyecto, y que todos colaboren en el proceso de diseño, implementación y ejecución del plan de pruebas [37]. Incluso los clientes participan en el diseño de las pruebas de aceptación mediante la especificación de los criterios de aceptación y el detalle de los atributos del programa. En caso de haber probadores dedicados, los desarrolladores colaboran con ellos en la ideación de casos de prueba que verifiquen la funcionalidad de forma automática. Además, usualmente los desarrolladores comienzan escribiendo pruebas unitarias antes de codificar, por lo que desde un inicio están presentes las pruebas del software [37]. Asimismo, algo característico de los entornos ágiles es que las pruebas se integran con los esfuerzos de desarrollo para formar un proceso continuo; por ello, al no ser las pruebas una fase específica, los clientes pueden comenzar con pruebas de aceptación sobre alguna funcionalidad desarrollada y estable, y reportar defectos mientras algunos desarrolladores arreglan estos errores y otros continúan desarrollando funcionalidades [37]. En la agilidad, dados los cortos ciclos de desarrollo y el impulso de la retroalimentación oportuna, se busca que las pruebas sean automatizadas. Como el tiempo es limitado, las pruebas automatizadas son preferibles a los enfoques de pruebas manuales ya que las últimas consumen un tiempo considerable y son propensas a errores propios de la intervención humana. Sin embargo, cabe destacar que las pruebas manuales pueden ser requeridas incluso en entornos ágiles [37]. 15 Capítulo 3. Trabajo relacionado Las pruebas basadas en modelos han sido utilizadas para realizar pruebas en diversos dominios asociados al sistema bajo prueba, tales como aplicaciones web, aplicaciones móviles, sistemas concurrentes, sistemas integrados, sistemas distribuidos y servicios web [59]. En esta sección, se presentan trabajos relacionados que estudian enfoques y herramientas para probar servicios web mediante pruebas basadas en modelos. Asimismo, discutimos estudios que han utilizado este enfoque en entornos ágiles. Para la aplicación de pruebas basadas en modelos en el contexto de servicios web se han explorado distintos enfoques con distintas finalidades. Por ejemplo, se ha utilizado MBT para probar aspectos como la funcionalidad y la seguridad [23, 19, 61, 18, 41], y se han propuesto diferentes métodos para modelar los sistemas y generar los casos de prueba. Entre las estrategias de modelado más predominantes están los modelos UML [61, 41] y las máquinas de estado finito [51, 61, 18]. Con respecto a las herramientas, algunos autores reportan la creación de una solución propia para la generación de casos de prueba, mientras que otros usan frameworks como JUnit y RestAssured para la generación de las pruebas [5]. Asimismo, se describe el uso de diversas herramientas como Swagger [5] y GraphWalker [51] para la creación de los modelos, lo cual es indispensable para la generación de las pruebas. Las secciones subsiguientes detallan los enfoques de MBT expuestos, agrupados según la técnica de prueba utilizada para los servicios web. 3.1 Pruebas de servicios web usando MBT Las pruebas basadas en modelos han sido aplicadas para asegurar la calidad de un servicio web en escenarios de regresión. Khan et al. [26] proponen una metodología que, mediante la comparación de los modelos que representan las interfaces de los servicios antes y después de un cambio, identifica los cambios y sus impactos, lo que ayudaría a determinar cuáles pruebas se deben repetir y cuáles pruebas nuevas deben generarse para asegurar la estabilidad del servicio. Dicha metodología se basa en una técnica de caja negra que utiliza información a nivel de modelo, protocolo de máquinas de estado, diagrama de actividades y contratos visuales; con lo cual identifica la cobertura y la validación de los 16 casos de prueba existentes, así como el flujo de datos; información vital para lograr identificar dependencias y el impacto de los cambios [26]. Endo et al. [18] proponen un proceso para verificar aplicaciones orientadas a servicios utilizando MBT con modelos basados en máquinas de estado finito. Además, pusieron a prueba la aplicabilidad del proceso haciendo un caso de estudio con una herramienta prototipo concluyendo que con este enfoque era posible alcanzar un alto nivel de automatización de las pruebas [18]. Wu et al. [61] presentan una técnica de MBT utilizando máquina de estados finitos extendidos (EFSM, por sus siglas en inglés extended finite-state machine) y diagrama UML para la generación de los modelos. Esto con el fin de detectar fallas que pueden suceder durante la ejecución un servicio web compuesto WS-BPEL el cual es según Wu et al. [61], uno de los lenguajes de integración más populares para la composición de servicios web. Del modelo generado: EFSM-SeTM, se define los criterios de cobertura basado en todos los escenarios posibles de cada estado de transición del servicio web, los cuales son: cobertura de todos los caminos, cobertura de todos los estados, cobertura de todas las transiciones y cobertura de todos los mensajes. Además, presentan cómo se puede definir los criterios de cobertura y la creación de un algoritmo que genera pruebas de caminos [61]. Similar a los autores recién mencionados [61, 18] , para la creación de modelos, Pinheiro et al. [41] proponen un enfoque basado en generar casos de prueba para servicios web RESTful usando una adaptación del protocolo UML de máquinas de estado como el modelo formal. Además, crearon una herramienta que soportaba el enfoque, la cual generaba casos de prueba automáticamente para los criterios de cobertura de estado y transición propios del protocolo de máquina de estados [41]. Hossen et al. [23] hacen uso de las entradas y salidas de una interfaz de servicio web para la generación de un modelo inferido y a partir de él, pruebas que detectan parámetros de entrada que provoquen salidas que confirmen vulnerabilidad. Otros trabajos [7] estudian cómo probar con MBT, sistemas que integran la composición de servicios web. Esto es, cuando un servicio web hace referencia a otro servicio web, lo cual puede seguir ocurriendo de forma recursiva [7]. Este tipo de interacciones genera 17 una gran complejidad a la hora de probar un sistema, pues si ocurre un error, es difícil rastrear dónde se originó. Belli et al. [7] plantean la posibilidad de realizar pruebas automatizadas de este tipo de sistemas utilizando MBT, con el objetivo de detectar defectos en la comunicación y selección de datos en la comunicación entre servicios. Para ello proponen utilizar grafos de secuencia de eventos para composición de servicios web (ESG4WSC por sus siglas en inglés). A partir del grafo se generan tablas de decisión, a partir de las cuales se pueden generar los casos de pruebas de forma automatizada. Para esta automatización, los autores desarrollan su propia herramienta llamada Test suit designer. Los autores demuestran que su metodología puede efectivamente ser utilizada para evaluar servicios web no triviales [7]. 3.2 Pruebas de servicios web usando técnicas alternativas a MBT Las pruebas funcionales para los componentes de las API RESTful son las que se suelen realizar en primera instancia al asegurar la calidad de REST. Según Fertig et al. [19], los aspectos importantes a considerar para este tipo de pruebas son: una respuesta con un cuerpo correcto, es decir, headers HTTP válidos y congruentes con el código de estado de la respuesta; y validar las URLs devueltas. Debido a que los casos de prueba que se necesitan para responder a estas necesidades de prueba son muy similares, los autores proponen el uso de Model-Driven Testing (MDT) como aliado para evitar errores humanos al replicar cientos de casos de prueba similares [19]. Fertig et al. [19] diseñan un modelo para RESTful API con la herramienta Xtext con el fin de probar el beneficio de MDT y generar casos de prueba basados en la descripción obtenida. Además, utilizan Xtend para la generación de plantillas para los casos de prueba [19]. La evaluación de MDT la hacen tomando como puntos de evaluación: la generación de una gran cantidad de casos de prueba para verificar que el esfuerzo merece la pena realizarlo frente a la elaboración de casos de prueba manuales en el aspecto de code coverage y la utilización de solo información acerca del diseño de la API para el modelo, con el fin de que cualquier desarrollador pudiera desarrollar una gran cantidad de casos de prueba sin tener conocimiento de aseguramiento de la calidad. El resultado fue exitoso 18 ya que la cantidad de casos de prueba fue mayor a un mínimo establecido como aceptable comparado con las pruebas manuales y a que no se necesitó información sobre pruebas en el modelo [19]. Fertig et al. [19] prueban un aspecto del SUT no-funcional: la seguridad. Según los autores, existen casos de prueba mínimos que se deben considerar al probar la seguridad de un servicio web [19], por ejemplo, las pruebas de autenticación. Sin embargo, como estas son basadas en combinaciones de estados de nombre de usuario y contraseña, que a su vez tienen los estados “válido”, “inválido”, o “perdido”, se presenta el mismo inconveniente mencionado para las pruebas funcionales, es decir, una gran cantidad de casos de prueba con estrecha similitud, lo que puede acarrear errores si se realizan exhaustivamente de forma manual. Los autores proponen entonces usar MDT para generar un caso de prueba por cada combinación distinta [19]. En los trabajos anteriores, la mayoría de los autores se concentran en la evaluación de servicios web utilizando pruebas de caja negra. Dado que para consumir un servicio web usualmente el cliente solo considera entradas y salidas y no tiene acceso al software, esta tendencia es esperable. Aun así, Arcuri [5] presenta un caso de estudio en el cual implementa una herramienta de automatización para pruebas de caja blanca a servicios web RESTful, usando cobertura de código a nivel de instrucción (statement coverage). Aunque explícitamente el autor no hace uso de MBT para llevar a cabo el proceso, la metodología planteada para utilizar la herramienta es similar a la descrita por los autores que aplican MBT en la sección 3.1. Arcuri [5] indica que para realizar el proceso se debe iniciar por definir cuáles métodos del API existen. Para esto sugiere usar Swagger como herramienta para modelar el servicio web, la cual genera una representación JSON de los diferentes objetos que acepta el API [5]. Una vez que se tiene esta representación, se puede pasar a generar los casos de prueba. El autor define un caso de prueba como una consulta HTTP que se realiza al servidor. Se considera que la aplicación tiene un defecto si para alguno de los casos de uso, el servidor retorna un código 500 [5]. Por otro lado, para hacer pruebas de cobertura de código el autor utilizó dos principios. Primero, empleó librerías que se encargaban de rastrear las líneas de código alcanzadas durante la ejecución de un programa, con el fin de evaluar las partes del software que 19 efectivamente fueron ejecutadas por los casos de pruebas [5]. Esto lo hizo interceptando las clases de Java al ser cargadas en el ambiente de ejecución, y agregando las métricas de rastreo con diferentes librerías. Segundo, usó heurísticas conocidas como “branch distance”, las cuales predicen el comportamiento de una condición para que el nodo sea alcanzado por otros nodos, para así crear los casos de prueba que maximizarían la cobertura de código. Haciendo uso de estos dos principios, el autor implementa una herramienta de código abierto llamada EvoMaster, la cual genera diferentes casos de prueba para la validación funcional y de cobertura de código en JUnit, a partir del modelo de la aplicación realizado con la herramienta Swagger [5]. Para hacer el llamado al API, utiliza la librería de RestAssured, herramienta comercial para realizar pruebas a servicios web. Los resultados que obtuvo en cuanto a pruebas funcionales fueron efectivos en encontrar defectos, sin embargo, la cobertura de código en las pruebas no superó el 41% [5]. 3.3 Automatización de pruebas en ágil Para la automatización de las pruebas en entornos ágiles se han utilizados diversos enfoques de pruebas basadas en modelos. Por ejemplo, Sivanandan et al. [51] aplican pruebas basadas en modelos mediante un marco de trabajo formado por un generador de pruebas de interfaz de usuario basado en modelos construidos a partir de máquinas de estados finitos (GraphWalker) y un marco de trabajo para automatización de pruebas de aceptación llamado Robot, el cual facilita la ejecución de pruebas independientemente de la experticia del desarrollador. Ellos concluyen que el desarrollo de software ágil y las pruebas basadas en modelos obtienen beneficios mutuos, mejorando la flexibilidad, cobertura y mantenibilidad de las pruebas [51]. Por su lado, Reider et al. [44], proponen la escogencia de ciertos requerimientos que representen el comportamiento del sistema para la elaboración de los modelos y una posterior priorización en la ejecución de las pruebas, con el fin de asegurar la retroalimentación temprana y eficiente de sus resultados en un entorno ágil. Thopate et al. [54] diseñan un modelo llamado Chameleon que se adapta a los cambios de los casos de prueba para responder de mejor manera al dinamismo de los desarrollos 20 ágiles, y además permite la adición de casos de prueba manuales para evitar dependencias de conocimientos especializados en pruebas automatizadas. En términos generales, para la aplicación de pruebas basadas en modelos en proyectos ágiles los enfoques buscan adaptarse al cambio respondiendo con modelos que sean sencillos de actualizar y que a su vez no dependan de personas especializadas para realizar las pruebas. Sin embargo, es posible que exista resistencia al uso de pruebas basadas en modelos en entornos ágiles, dado que invertir en automatización de pruebas bajo el constante cambio que sufren los casos de prueba en entornos ágiles se puede considerarse arriesgado [54]. A pesar de que todos estos estudios trabajan temáticas relacionadas con la presente investigación ya que detallan enfoques de MBT en servicios web con diversos tipos de pruebas y modelos, así como en entornos ágiles; hay falta de información sobre el impacto de incorporar pruebas basadas en modelos para servicios web RESTful en desarrollos ágiles, en términos de eficacia, eficiencia y aceptación por parte de los miembros del equipo. 21 Capítulo 4. Metodología La metodología seguida para lograr los objetivos planteados se ilustra en la Figura 2, donde el primer objetivo específico se abordó mediante un mapeo sistemático de literatura, y el segundo objetivo específico se abordó mediante un caso de estudio. El mapeo sistemático se orientó a comprender los enfoques existentes de pruebas basadas en modelos para servicios web RESTful, mientras que el caso de estudio se enfocó en aplicar un enfoque de MBT en un contexto ágil y analizar su impacto. Las siguientes secciones detallan las actividades de cada una de estas metodologías. Figura 2. Metodología seguida para alcanzar los objetivos de la investigación. 4.1. Metodología del mapeo sistemático de literatura Por medio de un mapeo sistemático de literatura, se caracterizaron los enfoques encontrados para realizar pruebas basadas en modelos para servicios web. A pesar de que en un inicio se hizo una primera revisión de literatura para servicios web RESTful, una vez se hizo la actualización para el año 2022, se expandió su alcance para incluir también los servicios web que no eran de tipo REST con el fin de evitar perder una cantidad importante de información proveniente de estudios que no utilizan REST y poder brindar un panorama más amplio del uso de MBT sobre servicios web independientemente de sus principios arquitectónicos o protocolos. 22 En el mapeo sistemático se detallarán los aspectos que prueba el servicio web (funcionalidad, seguridad, etc.), el tipo de modelado que utiliza, el tipo de servicio web que evalúa, la herramienta utilizada y el contexto en el que se aplicó. El mapeo sistemático de literatura se llevó a cabo siguiendo el protocolo sistemático propuesto por Petersen y la guía de revisiones sistemáticas de Kitchenham [29] y de casos de estudio de Runeson [45]. 4.1.1. Etapa 1: Diseño de la revisión Siguiendo el proceso para el mapeo sistemático de literatura propuesto por Kitchenham [5], el proceso consistió en las siguientes tareas: 1. Definición del objetivo GQM de investigación 2. Definición de las preguntas de investigación 3. Definición del proceso de búsqueda, que incluye: a. Selección de la base de datos de búsqueda b. Selección de la hilera de búsqueda c. Criterios de inclusión y exclusión de los resultados de la búsqueda d. Criterios de calidad de los artículos e. Datos por extraer de los artículos para responder al objetivo 4.1.2. Etapa 2: Ejecución de la revisión En esta etapa se utilizó el resultado de la etapa de diseño para procesar los estudios resultantes de la búsqueda con el fin de responder las preguntas de investigación planteadas. Esta etapa de ejecución, incluyendo la extracción y análisis de los datos, se realizó durante el primer semestre de 2022, de manera que el mapeo sistemático de literatura fuera lo más actualizado posible. 4.1.3. Etapa 3: Análisis de resultados de la revisión En la etapa de análisis de resultados se resumió la información de forma que se contestaran las preguntas de investigación planteadas en la etapa de diseño. Se elaboraron tablas de mapeo y gráficos por cada pregunta de investigación. En particular, se analizaron: (1) los enfoques de MBT que se han aplicado en el contexto de servicios web, es decir, los tipos de prueba y modelos utilizados, así como (2) los tipos de servicios web que han sido probados mediante enfoques MBT, (3) las herramientas de MBT que se han 23 empleado para probar servicios web y (4) los contextos de aplicación de los enfoques MBT en servicios web. 4.2. Metodología del caso de estudio 4.2.1. Etapa 1: Diseño del caso de estudio Una vez se obtuvieron los resultados del mapeo sistemático, se revisaron los enfoques de MBT implementados sobre servicios web categorizados según los atributos propuestos, se les hizo un análisis con la intención de seleccionar un enfoque MBT apto para aplicar al SUT y el contexto de desarrollo. 4.2.2. Etapa 2: Ejecución del caso de estudio El proceso con el cual se guio la aplicación del enfoque seleccionado en el equipo de desarrollo y se recolectó los datos de la aplicación, se divide a su vez en tres etapas, descritas a continuación: Trabajo previo a) Recolección de datos actuales de pruebas Para evaluar la eficiencia y la eficacia del enfoque definido, se hizo una comparación en cuanto a la cantidad de los defectos encontrados y tiempo utilizado para el proceso de pruebas. Para esto, se recolectaron los datos de las pruebas realizadas por el equipo de desarrollo en alguna versión específica del servicio web, en cuanto a casos de prueba generados, la cantidad de defectos encontrados, tiempo dedicado para el modelado, generación de casos de prueba y su correspondiente ejecución. A partir de estos datos, se escogió el módulo que tuviera la mayor cantidad de defectos encontrados para ser modelada con el enfoque MBT. b) Confección del material y encuestas a realizar Para llevar a cabo la aplicación, se generaron dos encuestas: Una encuesta que se aplicó previo a realizar una inducción sobre MBT y el enfoque a utilizar, con la cual se tenía como objetivo, conocer el grado de experiencia de los desarrolladores con pruebas de software y MBT. Una segunda encuesta que se aplicó al finalizar todo el proceso, con la cual se obtuvo la percepción de los desarrolladores en cuanto a facilidad, utilidad e intención de uso del enfoque. 24 Además de las encuestas, también se construyó material de apoyo con el cual se realizó la inducción. Este constó de una presentación sobre el tema y ejemplos de cómo llevar a cabo el modelado de los módulos de un sistema. Finalmente, también se construyó el modelado para el módulo de la aplicación seleccionado con el fin de aplicar el enfoque MBT, con el cual los desarrolladores trabajarían en caso de no lograr realizar el propio modelado. Inducción del enfoque Para lograr que el equipo de desarrollo aplicara correctamente el método seleccionado, fue necesario que todos los integrantes comprendieran los pasos a seguir para realizar pruebas basadas en modelos, así como los pasos para utilizar la herramienta. Para ello, se planteó una sesión de inducción con los integrantes del equipo, que constó de dos partes principales: a) Encuesta de conocimiento y experiencia probando software y MBT Antes de la explicación, se aplicó la encuesta previa. Esto con el objetivo de recolectar datos que indicaran el grado de conocimiento y experiencia previa de los desarrolladores con pruebas de software, pruebas basadas en modelos y con la herramienta seleccionada para MBT. b) Presentación y explicación del enfoque a utilizar La segunda parte de la inducción fue una presentación explicando los beneficios de MBT, su proceso y cómo se aplicaría en la herramienta seleccionada. Se realizó una práctica por los desarrolladores para familiarizarse con la herramienta. Ejecución del enfoque El equipo se dividió en dos, balanceando el conocimiento y experiencia en pruebas de software y MBT. Cada subgrupo hizo el modelado y automatización de las pruebas del módulo previamente seleccionado del servicio web. a) Modelado La primera parte de la sesión consistió en que los subgrupos modelaran con la herramienta el módulo del sistema. Como previamente se mencionó, en caso de que algún subgrupo no lograra el modelado, se le proporcionaría el modelo previamente realizado por los investigadores. b) Casos de prueba y ejecución 25 Una vez cada equipo tuviera su modelo, se procedió con la generación de casos de prueba y la ejecución de estos. Se recolectaron los datos de cada uno en cuanto a los defectos encontrados, pruebas generadas y los tiempos requeridos para generar el modelo, los casos de prueba a partir de estos y la ejecución de estos. c) Encuesta de aceptación Finalmente, a cada desarrollador se le aplicó una encuesta para conocer el nivel de aceptación del enfoque en cuanto a su utilidad, facilidad e intención de uso. 4.2.3. Etapa 3: Análisis de resultados del caso de estudio Evaluación del impacto de la incorporación del enfoque MBT seleccionado La evaluación del impacto en la incorporación del enfoque MBT se hizo tomando en cuenta la eficacia y la eficiencia de la aplicación de este sobre el SUT y la aceptación de los desarrolladores basándose en las respuestas obtenidas con respecto a la utilidad y facilidad e intención de uso del enfoque. Se realizó una comparación de los datos del método tradicional que tiene el equipo para realizar pruebas y los datos obtenidos a partir de la aplicación por parte de los equipos del enfoque MBT para evaluar la eficacia basado en la cantidad de defectos encontrados, y la eficiencia basada en la comparación del tiempo requerido para llevar a cabo el proceso de pruebas. Finalmente, tomando en consideración los resultados de la segunda encuesta, se describió la aceptación percibida según los datos recolectados. 26 Capítulo 5. Mapeo sistemático de literatura En este capítulo se detalla el proceso seguido para el mapeo sistemático de literatura, los resultados y su análisis. El proceso se realizó con base en las guías de Petersen et al. [4] y Kitchenham et al. [5]. 5.1. Objetivo y preguntas de investigación Para este mapeo sistemático se planteó el siguiente objetivo GQM y sus respectivas preguntas de investigación: 5.1.1. Objetivo GQM Analizar los enfoques existentes de MBT para servicios web con el propósito de caracterizarlos con respecto al tipo de modelado que utiliza, el tipo de prueba realizada, la herramienta empleada, el tipo de servicio web que prueba, y el contexto de aplicación. Por enfoque entendemos la combinación del tipo de modelado y el tipo de prueba aplicados a un servicio web mediante pruebas basadas en modelos. 5.1.2. Preguntas de investigación A continuación, se exponen las preguntas de investigación planteadas con el fin de que, al contestarlas, se pueda concretar el objetivo general del mapeo sistemático. RQ1. ¿Cuáles enfoques de MBT se han aplicado en el contexto de servicios web? RQ1.1 ¿Cuáles tipos de modelado de MBT se han utilizado para probar servicios web? RQ1.2 ¿Cuáles tipos de pruebas han permitido realizar los enfoques de MBT sobre servicios web? RQ2. ¿Cuáles tipos de servicio web han sido probados mediante enfoques de MBT? RQ3. ¿Cuáles herramientas de MBT se han empleado para probar servicios web? RQ4. ¿Cuáles han sido los contextos de aplicación de enfoques MBT en servicios web? 27 5.2. Estrategia de búsqueda y proceso de selección de estudios La cadena de búsqueda se formó a partir del objetivo planteado, dejándolo abierto a cualquier tipo de servicio web, utilizando cualquier variante de nombre para pruebas basadas en modelo (model based testing) o de servicios web de tipo REST. Enfatizando la necesidad de que esté presente el proceso de pruebas basado en modelos, un enfoque de servicio web y que sea un estudio del dominio del software. (“mbt” OR "model based test*" OR "model-based test*") AND ("web service" OR "rest* service" OR "api rest") AND (“software” OR “application”) La búsqueda con la hilera expuesta anteriormente se ejecutó en la base de datos SCOPUS debido a que esta base indexa artículos de la ACM e IEEE. Además, de la base de ScienceDirect pero sin el texto completo. El número de artículos recuperado tras ejecutar la hilera de búsqueda expuesta en esta sección es de 69. Los mismos, se tabularon en una hoja de cálculo la cual contiene mediante columnas: el DOI, el año de publicación, los autores, el título (información que se puede observar en el Apéndice D), así como el resumen de los artículos. Los estudios fueron ordenados por la fecha de publicación (de la más reciente a la más antigua). Asimismo, mediante columnas en la hoja de cálculo, se añadió un espacio para la identificación de cada criterio de inclusión y exclusión, criterios de calidad y datos a extraer. Una vez ordenados los estudios, se les aplicó el proceso de selección con base en los criterios de inclusión y exclusión (I/E), el proceso de evaluación de calidad sobre la lectura completa del estudio y la extracción de datos según el plan diseñado tal y como se describe a continuación. El proceso de inclusión y exclusión se hizo sobre el título y resumen de los artículos y se realizó lectura completa cuando estas secciones no dejaban claro la naturaleza del estudio. La Tabla 1 muestra los criterios I/E utilizados. 28 Criterios de inclusión Criterios de exclusión I1. Artículos en idioma inglés E1. Artículos no disponibles en texto completo I2. Estudios primarios que presenten enfoques de MBT para servicios web E2. Estudios secundarios o terciarios E3. Publicaciones no relacionadas con el dominio de ingeniería de software Tabla 1. Criterios de inclusión y exclusión. Se excluyeron publicaciones que cumplían con la fórmula (E1 OR E2 OR E3) y se incluyeron los que cumplían con la fórmula (I1 AND I2) de la Tabla 1. Al aplicar estos criterios de inclusión y exclusión (I/E), se obtuvo un total de 24 artículos. La Figura 3 muestra un resumen de este proceso de búsqueda y selección de estudios. Los estudios incluidos para análisis están comprendidos entre los años 2007 y 2019, y su distribución se muestra en la Figura 4. En el Apéndice E, se puede visualizar los resultados del proceso de inclusión y exclusión aplicado a los estudios. Figura 3. Resultado de aplicación de criterios de inclusión y exclusión. Las razones por las cuales los estudios fueron excluidos al no cumplir el criterio I2, son variadas, las cuales se definen a continuación: Artículos que (1) probaban servicios que no eran servicios web sino servicios de infraestructura, o de cloud, (2) que eran un adelanto de un estudio completo, (3) que no probaban un modelo de la aplicación sino un modelo arquitectural, (4) que mostraban un enfoque o herramienta para MBT pero que no lo probaban sobre un servicio web. (5) Asimismo, fueron excluidos todos aquellos documentos que correspondían a la unificación de todos los artículos presentados en conferencias, documento que contenía palabras clave coincidentes mas no artículos relacionados. (6) Un solo estudio fue excluido por ser en idioma español. Ningún artículo fue excluido por no estar disponible en texto completo ya que, si no estaba disponible por medio de la base de datos, se procedió a hacer la búsqueda por 29 medio de un navegador web para encontrar los textos completos disponibles principalmente en ResearchGate. La lista completa de los estudios incluidos y analizados puede accederse desde el enlace: https://docs.google.com/spreadsheets/d/149GjktqfZ2RjWuSMFMuBXQvizkjG8hIRp5GX6FtBRRk/edit?usp=sharing Figura 4. Cantidad de estudios por año. 5.3. Proceso de evaluación de calidad La evaluación de la calidad de los estudios se realizó con base en el nivel de detalle que ofrecían sobre los aspectos que buscaban analizar las preguntas de investigación. Los criterios de calidad que se definieron para la clasificación de los estudios fueron los siguientes: Q1. ¿El artículo describe detalladamente el enfoque de MBT usado en servicios web? Q2. ¿El artículo detalla el tipo de servicio web bajo prueba y su contexto de aplicación? Q3. ¿El estudio sigue una metodología rigurosa? La puntuación para cada criterio de calidad se asignó en una escala de 0 a 2, donde 0 = No cumple el criterio de calidad, 1 = Cumple el criterio parcialmente y 2 = Cumple el 30 criterio totalmente. De acuerdo con esta escala, el puntaje máximo de calidad que podía obtener un estudio era 6 puntos, y el mínimo 0 puntos. Una vez realizada la evaluación de calidad sobre cada uno de los 24 estudios seleccionados, se encontró que todos obtuvieron un puntaje de calidad igual o superior a 3, con una mediana de 6 y un promedio de 5.4, lo que representa un nivel de calidad alto, es decir, los estudios presentan un buen nivel de detalle para responder las preguntas de investigación. El puntaje asignado en la evaluación de calidad puede visualizarse en el Apéndice F. 5.4. Proceso de extracción y análisis de datos El proceso de extracción de los elementos necesarios para contestar las preguntas de investigación se realizó según se muestra en la Tabla 2. El formulario completo de extracción puede ser consultado en el Apéndice G. Pregunta de investigación que apoya la extracción Elementos extraídos RQ1. ¿Cuáles enfoques de MBT se han aplicado en el contexto de servicios web? Tipo de modelado que utiliza y tipo de prueba RQ2. ¿Cuáles tipos de servicio web han sido probados mediante enfoques de MBT? Tipo de servicio que se prueba con MBT RQ3. ¿Cuáles herramientas se han empleado para probar mediante MBT servicios web? Herramientas empleadas RQ4. ¿Cuáles han sido los contextos de aplicación de enfoques MBT en servicios web? Contexto de aplicación Tabla 2. Elementos de datos extraídos de los estudios. Para el proceso de análisis y clasificación de los datos, se optó por usar una taxonomía existente de pruebas basadas en modelos [59] y extenderla para las RQs 1 y 2. La extensión fue necesaria para poder incluir categorías reportadas por los estudios analizados que no estaban previamente en la taxonomía base, y así lograr una clasificación más completa. En el caso de la RQ3, las herramientas se clasificaron con base en las principales etapas del proceso de MBT (descritas en el Marco Teórico). Para la RQ4, se usó una agrupación propia al no existir una taxonomía estándar para contextos. 31 5.4.1. Extensión de la taxonomía base Durante la ejecución del mapeo sistemático de literatura, se vio la necesidad extender la taxonomía base para incluir tipos de prueba y tipos de modelo que no existían en la taxonomía base de Villalobos et al. [59] pero sí estaban reportadas dentro de los estudios analizados. Esto implicó la creación de nuevas subáreas en las áreas “Paradigma del modelo” y “Técnica de prueba”, las cuales se indican con flechas azules en la Figura 5. Figura 5. Taxonomía extendida. A continuación, se describen aquellas subáreas de la taxonomía extendida a las cuales se hace referencia posteriormente en esta investigación. Área “Especificación del modelo” Subárea “Paradigma del modelo” A. Grafo de secuencia de eventos (ESG, por sus siglas en inglés): es un grafo dirigido que se utiliza para modelar las interacciones entre los eventos del software [15]. Los vértices representan eventos, es decir, solicitudes o respuestas, y las aristas son la secuencia válida de esos eventos [9, 15]. Para representar valores de parámetros, estos grafos se complementan con tablas de decisión [9]. Este tipo de modelo se utiliza para el análisis y la validación de los requisitos de la interfaz de usuario antes de la implementación y prueba del código [10]. 32 Área “Objetivos de prueba” Subárea “Técnica de prueba” A. Prueba de conformidad: busca la corrección de la implementación del software con respecto a su especificación formal, funcional o estándares [39, 55]. Un caso de prueba de conformidad funcional para un servicio web, consta de tres partes: (1) una secuencia de invocaciones a operaciones del servicio web, desde un estado inicial “S0” a un estado adecuado “S”. (2) una invocación de prueba de una sola operación del servicio web en estado S para producir un nuevo estado S′ y, (3) una “secuencia de verificación” que valida que el estado S′ deseado, se refleja en la implementación del servicio web [39, 58]. En cada paso del caso de prueba se le asocia un valor esperado por cada parámetro de salida de la operación del servicio web. En la ejecución de pruebas, cada operación del servicio web es invocada con los valores de entrada escogidos, y se comparan los valores devueltos por el servicio web con los parámetros de salida esperados [39]. B. Prueba de caja negra: técnica basada en especificaciones del sistema, tales como requerimientos formales, especificaciones, historias de usuario o casos de uso. Centra las pruebas en las entradas y salidas del sistema bajo prueba. Esta técnica puede usarse tanto para pruebas funcionales como para las no-funcionales [21, 7, 37]. Bajo esta técnica, solo se pueden observar las entradas y salidas del SUT, pero no lo que sucede a lo interno del SUT [21, 7]. C. Prueba de hipótesis: se utiliza para evaluar si las frecuencias observadas durante los procesos de ejecución de las pruebas corresponden a las probabilidades especificadas en el modelo del SUT creado para las pruebas [11]. 5.5. Amenazas a la validez Las decisiones tomadas durante el proceso de selección de los estudios, en particular la inclusión y exclusión de estudios, así como la evaluación de calidad, se hicieron con base en el protocolo de mapeo previamente definido y acordado por los investigadores (docentes asesores de esta investigación), lo cual permitió tener una referencia objetiva. Sin embargo, cabe señalar que las decisiones fueron tomadas por un solo investigador (la estudiante), lo cual representa una amenaza a la validez. 33 Similarmente, otra amenaza es que la extracción y clasificación de los datos a partir de los estudios analizados también fue realizada por un solo investigador (la estudiante). Para mitigar esta amenaza, se hicieron varias revisiones con otro investigador (docente supervisora de la investigación) para verificar que las categorías utilizadas fueran apropiadas, incluyendo las que se agregaron como extensión de la taxonomía base. En el caso del análisis de la RQ4, los resultados se agrupan con base en una taxonomía propia, no previamente publicada, por lo que hay riesgo de que las categorías utilizadas no sean las que mejor representen contextos de uso de los servicios web. 5.6 Resultados del mapeo sistemático de literatura En esta sección se presentan los resultados del mapeo sistemático de literatura, correspondientes a cada pregunta de investigación. En particular, se muestran primero los enfoques MBT que se han aplicado en el contexto de servicios web (RQ1), luego los tipos de servicios web que han sido probados por medio de estos enfoques (RQ2), posteriormente las herramientas utilizadas en el proceso de MBT para servicios web (RQ3), y finalmente, los contextos de aplicación en los cuales esta combinación de MBT y servicios web han tenido cabida (RQ4). 5.6.1. Enfoques de MBT aplicados en servicios web (RQ1) Para reportar los enfoques de MBT que se han aplicado para servicios web, se extrajo de los estudios información relacionada con el tipo de modelado que se aplicó sobre el servicio web, y el tipo de prueba que se le realizó. Seguidamente se presentan los resultados obtenidos para los tipos de modelado (RQ 1.1), los tipos de prueba realizados (RQ 1.2) y, por último, los enfoques de MBT para servicios web según el tipo de prueba y el tipo de modelado. Tipos de modelado de MBT utilizados para probar servicios web (RQ 1.1) Como se mencionó en la sección de la metodología, se agregaron subáreas de modelos a la taxonomía base [59] con el fin de visibilizar todos los modelos reportados, surgiendo de esta manera los siguientes subtipos de modelo: 34 • Modelo de prueba de secuencia de máquina de estado finito extendido (EFSM- SeTM, por sus siglas en inglés: Extended Finite State Machine-Sequence Test Model) • Autómata-Cronometrado (Timed-Automata) • Autómatas cronometrados estocásticos (STA, por sus siglas en inglés: Stotastical Timed-Automata) • Autómatas cronometrados UPPAAL (UPPAAL timed – automata) • Sistema de transición simbólica (STS, por sus siglas en inglés: Symbolic Transition System) • Sistema de transición simbólica de E/S (ioSTS, por sus siglas en inglés: I/O Symbolic Transition System) • “Entradas, salidas, condiciones previas, efectos” (IOPE, por sus siglas en inglés: inputs, outputs, preconditions, effects) • Procesos de decisión de Markov (MDP, por sus siglas en inglés: Markov Decision Processes) • Grafos de secuencia de eventos (ESG, por sus siglas en inglés: Event Sequence Graphs), • Grafos de secuencia de eventos para composiciones de servicios web (ESG4WSC, por sus siglas en inglés: Event Sequence Graphs for WSC) Con el objetivo de un mejor entendimiento de la categorización de cada modelo, la Figura 6 muestra en dónde se ubican los estudios según el tipo de modelo utilizado, con base en la taxonomía en la cual se apoya este estudio [59] y su versión extendida. Solo se toman las áreas de la taxonomía que tienen al menos un estudio a categorizar y entre más oscuro sea el color de la casilla, más estudios reportaron usar ese tipo de modelo. 35 Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5 Nivel 6 Especifica ción de modelo Paradigma de modelo Basado en estados o notaciones pre-post OCL de UML: FRA13 (1) Notaciones basadas en transiciones Máquina de estado finito (FSM), Máquina de estado finito extendido (EFSM): END11, KIR15, FOR17, KIR14, AIC19.2, KUE14, SUN14 (7) Modelo de prueba de secuencia de máquina de estado finito (EFSM-SeTM): WU13 (1) Grafos de estado: (Máquinas de estado UML, diagramas de estado de Statemate, diagramas de flujo de estado de Simulink): HER17, CAS12 (2) Autómata-Finito Autómata- Cronometrado Autómatas cronometrados estocásticos (STA) AIC19.1, SCH17 (2) Autómatas cronometrados UPPAAL MAÂ17, SIA17, SIA16 (3) Sistema de transición simbólica (STS): ANI13 (1) Sistema de transición simbólica de E/S (ioSTS): SAL14 (1) Autómata E/S “Entradas, salidas, condiciones previas, efectos” (IOPE): PAR07 (1) Estocástico Cadenas de Markov Procesos de Decisión Markov (MDP): CAM19 (1) Grafos de secuencia de eventos (ESG): BEL10 (1) Grafos de secuencia de eventos para composiciones de servicios web (ESG4WSC): BEL14, END13, BEL11 (3) Figura 6. Estudios mapeados dentro de la taxonomía según el tipo de modelo. Al agruparse por el nivel 3 de la taxonomía, la categoría “Notaciones basadas en transiciones” es el tipo de modelo que agrupa la mayor cantidad de estudios, con 18 estudios que lo reportan. En segundo lugar, está la categoría “Grafos de secuencia de eventos”, con 4 estudios que reportan este tipo de modelo. Las categorías “Estocástico” y “Basado en estados o notaciones pre-post" solo reportan un estudio en cada una. La Tabla 3 muestra estos resultados, agrupados por el nivel 3 de la taxonomía. La Figura 7 ofrece una representación gráfica de estos mismos resultados. 36 Tipo de modelo Estudios Cantidad Notaciones basadas en transiciones AIC19.2, AIC19.1, SCH17, HER17, FOR17, MAÂ17, SIA17, SIA16, KIR15, KIR14, KUE14, SUN14, SAL14, ANI13, WU13, CAS12, END11, PAR07 18 Grafos de secuencia de eventos BEL14, END13, BEL11, BEL10 4 Estocástico CAM19 1 Basado en estados o notaciones pre-post FRA13 1 Tabla 3. Clasificación de estudios según el tipo de modelo (nivel 3 de la taxonomía). Figura 7. Cantidad de estudios por tipo de modelado utilizado para servicios web con MBT. Para finalizar el análisis de los tipos de modelo utilizados y reportados por los estudios bajo investigación, en la Figura 8 se puede apreciar el uso de los distintos tipos de modelos a través del tiempo (nuevamente, usando las categorías de modelos del nivel 3 de la taxonomía). En esta figura se puede observar no solo que los modelos de “Notaciones basadas en transiciones” son los más utilizados, sino que su uso se ha mantenido en el tiempo, incluso con tendencia a incrementar, como en el año 2017. Lo contrario se puede observar con los modelos de tipo “Grafos de secuencia de eventos”, pues a pesar de que se usaron entre los años 2010 y 2014, no se volvieron a usar más desde entonces. También 37 se puede observar que el modelo “Basado en estados o notaciones pre-post" solo aparece una vez en el 2013 y después no se vuelve a reportar más. Por otro lado, el modelo “Estocástico” aparece recientemente en el año 2019, lo que sugiere un nuevo campo de investigación. Figura 8. Uso de tipos de modelos para servicios web a través del tiempo. Los estudios que prueban servicios web de tipo REST (SIA16, SIA17, KUE14) utilizan modelos de la categoría “Notaciones basadas en transiciones”, específicamente el modelo Autómatas cronometrados UPPAAL (UTA) para pruebas de Robustez (prueba no- funcional) y Máquina de estado finito extendido (EFSM) para prueba funcional. Tipos de prueba realizados con enfoques de MBT sobre servicios web (RQ 1.2) Los estudios analizados reportaron haber realizado pruebas funcionales, de conformidad, de caja negra, de rendimiento, de robustez, de confiabilidad, de hipótesis, y de seguridad. En consistencia con la taxonomía utilizada, algunas de estas se refieren expresamente a tipos de prueba (funcional, no-funcional), mientras que otras se refieren más bien a la técnica de prueba utilizada (caja negra, conformidad, hipótesis), según se puede constatar en el nivel 3 de la taxonomía mostrada en la Figura 5. Como algunos estudios solo mencionaban la técnica utilizada para las pruebas, pero no el tipo, se infirió su clasificación en alguno de los tipos de de la taxonomía, según su objetivo de prueba. Por 38 ejemplo, el estudio FRA13 que reportó usar la técnica caja negra para probar el SUT, se clasificó como de tipo de prueba funcional, ya que este era su objetivo final. La Figura 9 muestra dónde se ubican los estudios analizados, según el tipo de prueba en la taxonomía usada. Cabe señalar que solo se toman las categorías de la taxonomía que tienen al menos un estudio reportado. En una escala de azules se marcan las casillas que mapean estudios: entre más oscuro el color, más investigaciones reportan ese tipo de prueba. El artículo ANI13 reportó 2 tipos de pruebas en su investigación: No-Funcional y Funcional, por lo que se va a manejar un total de 25 menciones a tipos de prueba en las tablas y figuras agrupadas a nivel 3, expuestas en esta sección. Nivel 1 Nivel 2 Nivel 3 Nivel 4 Objetivo de prueba Tipo de prueba Prueba Funcional: SUN14, FOR17, HER17, END13, BEL10, ANI13, KIR14, KIR15, WU13, FRA13, BEL14, BEL11, PAR07, AIC19.2 KUE14, SAL14, CAM19 (17) Prueba No-Funcional Prueba de Rendimiento: SCH17, MAÂ17, AIC19.1 (3) Prueba de Seguridad: ANI13 (1) Prueba de Confiabilidad/ Robustez: CAS12, SIA16, SIA17, END11, ANI13 (5) Figura 9. Estudios mapeados dentro de la taxonomía según el tipo de prueba. Al agruparse por el nivel 3 de la taxonomía, la clasificación de los estudios según el tipo de prueba se reduce a dos categorías: “Prueba No-Funcional" y “Prueba Funcional”. La categoría de “Prueba Funcional” es la que agrupa más cantidad de estudios, para un total de 17 estudios que reportan este tipo de pruebas. En segundo lugar, está la categoría de “Prueba No-Funcional", con 9 estudios que la reportan. Estos resultados se muestran en la Tabla 4, y pueden visualizarse de forma gráfica en la Figura 10. 39 Tipo de prueba Estudios Cantidad Prueba Funcional FOR17, HER17, KIR15, SUN14, KIR14, WU13, END13, ANI13, BEL10, BEL14, FRA13, BEL11, AIC19.2, SAL14, KUE14, PAR07, CAM19 17 Prueba No-Funcional AIC19.1, SCH17, MAÂ17, SIA17, SIA16, ANI13, CAS12, END11 8 Tabla 4. Clasificación de estudios según el tipo de prueba (nivel 3 de la taxonomía). Figura 10. Cantidad de estudios por tipo de prueba utilizado para servicios web con MBT. Para finalizar el análisis de los tipos de prueba utilizados y reportados por los estudios bajo investigación, en la Figura 11 se puede apreciar la evolución de los distintos tipos de prueba a través del tiempo. En esta figura se puede observar que ambos tipos de pruebas (funcional y no-funcional) se han mantenido en el tiempo, con una leve predominancia de las pruebas funcionales al inicio (2007 y 2010) y luego entre los años 2013 y 2014. 40 Figura 11. Uso de tipos de pruebas para servicios web a través del tiempo. Los estudios que prueban servicios web de tipo REST (SIA16, SIA17, KUE14) reportaron el uso de pruebas de tipo funcional (KUE14) y no-funcional (SIA16 y SIA17), específicamente de robustez. Enfoques de MBT para servicios web según el tipo de prueba y tipo de modelado La Figura 12 muestra la relación entre los tipos de prueba y los tipos de modelo utilizados por los enfoques de MBT para servicios web, en los estudios analizados. De esta figura se puede observar que el tipo de modelo “Notaciones basadas en transiciones” ha sido usado tanto para realizar pruebas de tipo funcional como no funcional. Por otro lado, los tipos de modelo "Estocástico”, “Basado en estados o notaciones pre-post", y “Grafos de secuencia de eventos” solo se han usado para pruebas funcionales del SUT. 41 Figura 12. Enfoques MBT por tipos de modelo y por tipos de prueba. 5.6.2. Tipos de servicios web probados con MBT (RQ2) Los resultados sobre el tipo de servicios web probado mediante MBT se reportan en la Tabla 5, y se pueden visualizar de forma gráfica en la Figura 13. Se puede observar que la mayoría de los estudios (15) reportan haber probado servicios de tipo SOAP, mientras que solo tres estudios reportan haber usado servicios de tipo REST. Si bien no todos los artículos analizados reportaban de forma explícita el tipo de servicio web probado, en algunos casos se pudo inferir a qué tipo de servicio web pertenecía el SUT, mediante una lectura minuciosa del estudio. Sin embargo, hubo 6 artículos para los que no fue posible hacer esta inferencia, por falta de detalle en el artículo. Algunos estudios detallaron el uso de MBT en composiciones de servicios web, obteniendo de esta forma, un dato adicional del uso que se le puede dar a las pruebas basadas en modelos sobre servicios web. Tipo de servicio web Estudios que lo reportan Cantidad SOAP AIC19.1, AIC19.2, HER17, KIR15, BEL14, SAL14, SUN14, KIR14, FRA13, ANI13, END13, BEL11, END11, BEL10, PAR07 15 REST SIA17, SIA16, KUE14 3 No reportado CAM19, FOR17, SCH17, MAA17, WU13, CAS12 6 42 Tabla 5. Clasificación de los estudios según el tipo de servicio web probado. Figura 13. Cantidad de estudios por tipo de servicio web. En la Figura 14 se puede observar la evolución en el tiempo de los tipos de servicios web que se han usado como SUT bajo el enfoque de MBT. En esta figura se observa que el tipo de servicio web SOAP no solo ha sido el más utilizado con MBT (entre los estudios analizados), sino que ha sido el que ha tenido mayor permanencia en el tiempo, desde el año 2007 hasta el 2019, tomando fuerza en el 2014 con 4 reportes de uso. En ese mismo año, 2014, aparece el primer estudio que reporta usar un SUT que es de tipo servicio REST, con un enfoque de MBT. El uso de REST con MBT se retoma en los años 2016 y 2017, siendo entonces una combinación más reciente que SOAP. Figura 14. Tipos de servicios web probados con MBT a través del tiempo. 43 5.6.3. Herramientas de MBT usadas para probar servicios web (RQ3) Las herramientas de MBT utilizadas para probar servicios web en los estudios analizados se listan en la Tabla 6. Tres artículos no mencionaron ninguna herramienta [53, 61, 20], mientras que otros estudios utilizaron más de una herramienta (típicamente una en cada fase del proceso de MBT). Las últimas tres columnas de la Tabla 6 indican la fase del proceso de MBT que apoyó cada herramienta. Los valores posibles para estas columnas fueron: Sí (la herramienta dio soporte completo a la fase), No (la herramienta no fue utilizada para soportar la fase) y Parcialmente (la herramienta ofreció soporte parcial a la fase). De la Tabla 6 se puede observar que la herramienta más usada fue Eclipse, con 4 estudios que reportaron usar alguna parte de Eclipse para las diferentes fases de MBT. En particular, se reportó el uso del editor Elipse Papyrus UML [22] y el editor de modelo Eclipse GMF [31] para la creación y la edición de los modelos, así como el framework Eclipse [17] y Eclipse Metrics [18] para la fase de ejecución pruebas. En segundo lugar, de uso estuvieron las herramientas FSCheck [1, 2, 46] y Test Suite Designer [7, 8, 17], con 3 estudios cada una. En tercer lugar, estuvieron las herramientas Uppaal Tron [50, 49], ErunTE [8, 17] y SoapUI [17, 4], con 2 estudios cada una. Es importante destacar que solo una herramienta, HYPpOTesT [22], soporta las tres fases del proceso de MBT. Las herramientas que se clasificaron con soporte parcial a la etapa de “Especificación del modelo” no permitían crear el modelo dentro de la herramienta propiamente, pero sí permitían recibir un modelo creado previamente como entrada para las etapas posteriores. Hubo siete herramientas fueron creadas por los mismos investigadores para soportar las fases de MBT de su estudio; estas fueron: WSCLim, HYPpOTesT, JstateModelTest y otras cuatro a las que no se les dio nombre. 44 Fase de MBT que soporta Herramienta Estudios que la usan Cant. Especificación del modelo Generación de casos de prueba Ejecución de casos de prueba Eclipse END11, END13, HER17, KUE14 4 Sí No Sí FSCheck AIC19.1, AIC19.2, SCH17 3 Parcialmente Sí Sí Test Suite Designer (TSD) BEL11, END13, BEL14 3 Sí Sí No Uppaal Tron SIA16, SIA17 2 Parcialmente Sí Sí Event Runner for Test Execution (ERunTE) BEL14, END13 2 No No Sí SoapUI ANI13, END13 2 No No Sí HYPpOTesT CAM19 1 Sí Sí Sí MaTeLo HER17 1 Parcialmente Sí Sí TRON2UPPAL SIA17 1 No No Sí WSCLim MAA17 1 No No Sí Broker@Cloud KIR15 1 No No Sí CloudPaste (Cloud PASsive TEsting) SAL14 1 No No Sí TTworbench KUE14 1 No No Sí Selenium KIR14 1 No No Sí Creada por los investigadores: Un monitor proxy. SAL14 1 No No Sí QuickCheck FRA13 1 No Sí Sí JTorX ANI13 1 Sí Sí No LoadUI ANI13 1 No No Sí Wireshark ANI13 1 No No Sí Creada por los investigadores: Prototipo extensión de JTorX. ANI13 1 No Sí Sí JUnit END13 1 No No Sí Creada por los investigadores: Prototipo para probar el enfoque. CAS12 1 Sí Sí No Creada por los investigadores: Prototipo para la ejecución y análisis de pruebas. BEL11 1 No No Sí JStateModelTest END11 1 No Sí Sí ETES Tool BEL10 1 No No Sí Rational Functional Tester PAR07 1 No No Sí Tabla 6. Herramientas reportadas y uso que se le dio dentro de MBT. 45 La Figura 15 resume gráficamente los resultados de la Tabla 6. De esta figura se puede observar que la fase de “Ejecución de casos de prueba” es la que tiene más soporte de herramientas, ya que un 88.5% de las herramientas reportadas apoyaron esta fase del proceso de MBT. En segundo lugar, se situó la fase de “Generación de casos de prueba”, que fue apoyada por un 38.5% de las herramientas identificadas. Finalmente, la fase de “Especificación del modelo” tuvo apoyo del 19.2% de las herramientas de forma completa, y del 11.5% de las herramientas de forma parcial. Figura 15. Porcentaje de estudios que soportaron las distintas fases MBT. La Figura 16 muestra el año en que se reporta el uso de cada herramienta. De aquí se puede observar que el año 2013 fue donde se reportó la mayor cantidad de herramientas, por lo que fue un año donde se exploraron más herramientas distintas para apoyar el proceso MBT en servicios web. Entre ellas destaca SoapUI, que fue utilizada por dos estudios para la fase de ejecución de pruebas. Por otro lado, la herramienta FSCheck ha sido la más usada desde el 2017, año en el que se reportó su uso por primera vez. Esto podría indicar que es una herramienta que responde a las necesidades actuales de la comunidad para generar casos de prueba y probar servicios web con MBT. Asimismo, la herramienta HYPpOTesT es de muy reciente creación (2019), por lo que es posible que más estudios la usen en el futuro, ya que tiene la versatilidad de soportar todas las fases de MBT. Finalmente, Eclipse es la herramienta que ha permanecido más a lo largo del tiempo, reportándose su primer uso en el 2011 y su último uso en el 2017. Otras herramientas como Rational Functional Tester o ETES Tool solo se reportaron una vez (2007 y 2010, respectivamente) y luego no volvieron a ser usadas. 46 Figura 16. Uso de las herramientas a través del tiempo. En la Figura 17 se reportan las herramientas que fueron utilizadas más de una vez por los distintos estudios, las cuales podrían ser las de mayor interés para la comunidad de pruebas de servicios web con MBT. Cabe destacar que dentro de las herramientas con más de un reporte de uso mostradas en la Figura 16, hay algunas que fueron utilizadas más de una vez por el mismo autor en dos distintos estudios. Este es el caso de Eclipse, FSCheck, Test Suite Designer, y Uppaal Tron. Figura 17. Herramientas con más de un uso reportado. 47 Herramientas utilizadas según el tipo de prueba La Figura 18 muestra la relación directa entre las herramientas reportadas en los estudios analizados y los tipos de prueba que éstas ayudaron a realizar usando MBT en servicios web. La mayor cantidad de herramientas (25 herramientas) se utilizaron para realizar pruebas de tipo Funcional. En esta categoría destacan especialmente Eclipse (usada en 3 estudios), SoapUI y Test Suite Designer (empleadas en 2 estudios cada una). Por otra parte, para las pruebas de tipo No-Funcional se usaron 11 herramientas, entre las que resaltan Uppaal Tron y FSCheck como las más usadas para este fin, y soportan al menos una fase de MBT en más de un estudio. FSCheck y Eclipse son las únicas herramientas que se usaron para efectuar ambos tipos de pruebas: funcionales y no-funcionales. Eclipse, además, es la herramienta que cuenta con más usos entre las investigaciones analizadas. Figura 18. Relación entre las herramientas y los distintos tipos de prueba. 5.6.4. Contextos de aplicación de MBT en servicios web (RQ4) Esta sección reporta los contextos de aplicación identificados en los estudios analizados, entendiendo “contexto” como el dominio de aplicación del servicio web al cual se le 48 realizaron pruebas con MBT. Los estudios se clasificaron con base en una categorización propia de los dominios, derivada de lo que reportaban los estudios. La Tabla 7 muestra los estudios y la cantidad identificada para cada categoría de contexto. La Figura 19 resume estos resultados de forma gráfica. De la Figura 19 se puede observar que la mayoría (siete estudios) de los servicios web a los cuales se les aplicó pruebas basadas en modelos, pertenecían al dominio de Compras. Cuatro estudios probaron servicios web del dominio de Reservaciones, incluyendo reservación de habitaciones en hoteles o vuelos. Tres estudios probaron servicios web del dominio Automotriz. Dos estudios reportaron que sus servicios web pertenecían al dominio Financiero (p.ej., servicios de cajeros) y otros dos reportaron que estaban relacionados con la Gestión (p.ej., tareas de administración de proyectos). Los restantes cinco estudios probaron servicios web en los dominios de Salud, Red Social, Red de Telefonía, Internet de las Cosas y Televisión. Los estudios dedicados a probar servicios web de tipo REST se desarrollaron en dominios muy variados: Reservaciones, Red Social, e Internet de las Cosas. Contexto Estudios que lo reportan Cantidad Compras CAM19, HER17, FOR17, KIR15, SAL14, KIR14, WU13 7 Reservaciones SIA16, BEL14, CAS12, BEL10 4 Automotriz AIC19.1, AIC19.2, SCH17 3 Financiero ANI13, BEL11 2 Gestión END11, PAR07 2 Salud MAÂ17 1 Red Social SIA17 1 Red de Telefonía SUN14 1 Internet de las Cosas KUE14 1 Televisión FRA13 1 No reportado END13 1 Tabla 7. Clasificación de los estudios según el contexto del servicio web probado. 49 Figura 19. Contextos de aplicación de los servicios web. 50 Capítulo 6. Caso de estudio En este capítulo se detalla el diseño del caso de estudio, los resultados y su análisis. El diseño del caso de estudio se realizó siguiendo los lineamientos para estudios experimentales propuestos por Wohlin et al. [45]. En este caso de estudio analizamos el proceso que introduce pruebas basadas en modelos para servicios web en un equipo que implementa prácticas ágiles. El caso de estudio completo fue publicado en el artículo referenciado en el apéndice A [6]. 6.1. Objetivo y preguntas de investigación Para el caso de estudio se planteó el siguiente objetivo con sus respectivas preguntas de investigación. 6.1.1. Objetivo Evaluar el impacto de incorporar pruebas basadas en modelos para servicios web, en un equipo que implementa prácticas ágiles, en términos de su eficacia, eficiencia y aceptación. 6.1.2. Preguntas de investigación RQ1: ¿Cuál es la eficacia y eficiencia de aplicar pruebas basadas en modelos para automatizar las pruebas funcionales de servicios web? RQ2: ¿Cuál es la aceptación por parte de los profesionales al introducir pruebas basadas en modelos en un proyecto de desarrollo ágil? 6.2. Contexto El estudio se realiza en una organización de desarrollo de software pequeña, la cual es un emprendimiento costarricense que desarrolla aplicaciones móviles en distintas tecnologías. Los miembros del equipo que participan en la aplicación del proceso de pruebas basadas en modelos son cuatro desarrolladores de un equipo de desarrollo los cuales se reparten 51 las diferentes tareas en cuanto al análisis, diseño, implementación y pruebas de los servicios web implementados utilizando el marco de trabajo Scrum. Los participantes del estudio son graduados en ingeniería eléctrica con edades entre 23 y 24 años y trabajan en los mismos límites geográficos y zona horaria. Tienen aproximadamente dos años de experiencia profesional en tareas de desarrollo y poca experiencia en procesos de pruebas de software. 6.2.1. Selección del sistema bajo pruebas El SUT utilizado en el estudio es un servicio RESTful, desarrollado con el fr