El autor Alberto Martin-Lopez ha publicado 8 artículo(s):

Los servicios web suelen imponer dependencias entre parámetros (también llamadas dependencias inter-parámetro) que restringen el modo en que dos o más parámetros de entrada pueden combinarse para formar una llamada válida. Desafortunadamente, los lenguajes de especificación de servicios web actuales como OpenAPI Specification (OAS) no proporcionan soporte para describir dichas dependencias formalmente, lo que dificulta enormemente la interacción con estos servicios de forma automática, sin necesidad de intervención humana. Investigadores y desarrolladores piden abiertamente soporte para el modelado y la validación de las dependencias inter-parámetro en APIs web, pero esto no es posible hasta que no conozcamos profundamente el alcance de este tipo de dependencias, y cómo emergen en la práctica +IBQ-este es el objetivo de nuestro trabajo. En este artículo, presentamos un estudio exhaustivo de la presencia de dependencias inter-parámetro en APIs web industriales. El estudio est+AOE basado en una revisión de más de 2.500 operaciones de 40 APIs reales pertenecientes a diversos dominios de aplicación. Confirmamos que las dependencias son la norma y no la excepción, con un 85+ACU de las APIs revisadas conteniendo algún tipo de dependencia inter-parámetro. Como la principal contribución de nuestro estudio, presentamos un catálogo de siete tipos de dependencia que se encuentran de manera sistemática en APIs REST.

Autores: Alberto Martin-Lopez / Sergio Segura / Antonio Ruiz-Cortés / 
Palabras Clave: dependencias entre parámetros - restricciones - servicios web

Las Interfaces de Programación de Aplicaciones (APIs) web tienen un papel clave en la integración de aplicaciones, por lo que validar su correcto funcionamiento es crucial. La mayoría de técnicas de generación de casos de prueba en este ámbito son de caja negra y suelen evaluarse con APIs sin código fuente disponible. Por ello, no es posible emplear pruebas de mutación tradicional, y no podemos cuantificar la efectividad de las pruebas si la API no expone ningún error.Este artículo propone un enfoque de caja negra para evaluar la capacidad de detección de errores de las pruebas para APIs web: en lugar de crear variantes defectuosas del código del programa (pruebas de mutación tradicionales), se crean mutantes de las salidas del programa (respuestas HTTP). JSONMutator es la herramienta implementada para llevar a cabo estas mutaciones. Los oráculos de pruebas se aplican sobre dichos mutantes y, a medida que las pruebas fallan, la cobertura de mutación aumenta. Experimentos preliminares sugieren que la herramienta es efectiva para crear mutantes a partir de la salida de APIs web y que existe correlación entre la cobertura de mutación de caja negra y caja blanca.

Autores: Ana B. Sánchez / Alberto Martin-Lopez / Sergio Segura / Antonio Ruiz-Cortés / 
Palabras Clave: APIs Web - JSON - pruebas de mutación

La generación automática de casos de prueba para APIs REST es un tema de investigación muy activo. La mayoría de técnicas emplean un enfoque de caja negra basado en la generación aleatoria de peticiones a partir de la especificación de la API. Dichas técnicas tienen una limitación importante: ignoran las dependencias inter-parámetro (restricciones entre parámetros que se deben cumplir para que la petición a la API sea válida), ya que no están soportadas por los lenguajes de especificación actuales. Como resultado, la mayoría de peticiones generadas automáticamente viola alguna dependencia y es rechazada por la API. En este artículo, proponemos un método para entrenar eficientemente un clasificador que prediga la validez de las peticiones, para as+AO0 poder descartar las inválidas antes de invocar a la API. Nuestra técnica aprende a medida que genera casos de prueba, de forma que el porcentaje de llamadas válidas aumenta progresivamente hasta un 90+ACU en APIs comerciales como GitHub y Stripe. Estos resultados prometedores sugieren que nuestra propuesta podría mejorar significativamente la generación automática de casos de prueba para APIs REST.

Autores: A. Giuliano Mirabella / Alberto Martin-Lopez / Sergio Segura / Luis Valencia-Cabrera / Antonio Ruiz-Cortés / 
Palabras Clave: APIs RESTful - pruebas software - servicios web

Web APIs following the REST architectural style (so-called RESTful Web APIs) have become the de-facto standard for software integration. As RESTful APIs gain momentum, so does the testing of them. However, there is a lack of mechanisms to assess the adequacy of testing approaches in this context, which makes it difficult to measure and compare the effectiveness of different testing techniques. In this work-in-progress paper, we take a step forward towards a framework for the assessment and comparison of testing approaches for RESTful Web APIs. To that end, we propose a preliminary catalogue of test coverage criteria. These criteria measure the adequacy of test suites based on the degree to which they exercise the different input and output elements of RESTful Web services. To the best of our knowledge, this is the first attempt to measure the adequacy of testing approaches for RESTful Web APIs.

Autores: Alberto Martin-Lopez / Sergio Segura / Antonio Ruiz-Cortés / 
Palabras Clave: coverage criteria - REST - Testing - web services

La generación automática de casos de prueba para APIs REST es un tema de investigación muy activo. La mayoría de técnicas emplean un enfoque de caja negra basado en la generación aleatoria de peticiones a partir de la especificación de la API. Dichas técnicas tienen una limitación importante: ignoran las dependencias entre parámetros. Como resultado, la mayoría de peticiones viola alguna dependencia y son rechazadas por la API. En este artículo, proponemos inferir automáticamente dichas dependencias únicamente a partir de la especificación de la API y sus entradas y salidas. Nuestra técnica aprende a medida que genera casos de prueba, de forma que el porcentaje de llamadas válidas aumenta progresivamente hasta alcanzar una precisión del 90+ACU en APIs comerciales como GitHub o YouTube. Estos prometedores resultados sugieren que nuestra propuesta podría mejorar significativamente la generación automática de casos de prueba para APIs REST.

Autores: A. Giuliano Mirabella / Alberto Martin-Lopez / Sergio Segura / Luis Valencia Cabrera / Antonio Ruiz-Cortés / 
Palabras Clave: APIs RESTful - pruebas software - servicios web

Las técnicas de pruebas automatizadas para APIs REST suelen seguir un enfoque de caja negra, donde los casos de prueba se derivan de la especificación de la API. Estas técnicas muestran resultados prometedores, pero ignoran las restricciones entre los parámetros de entrada de la API (llamadas dependencias inter-parámetro), ya que estas no pueden describirse formalmente en los lenguajes de especificación actuales. Como resultado, las herramientas de caja negra recurren a la fuerza bruta para la generación de casos de prueba válidos, es decir, aquellos que satisfacen todas las dependencias inter-parámetro. Esto no es solo extremadamente ineficiente, sino que además es improbable que funcione con muchos servicios del mundo real, donde las dependencias inter-parámetro son complejas y abundantes. En este artículo, presentamos RESTest, un framework de pruebas automatizadas de caja negra para APIs REST. Entre sus principales características, RESTest soporta la especificación y el análisis automático de las dependencias inter-parámetro de la API, lo que permite utilizar resolutores de restricciones para la generación automática de casos de prueba válidos. Esto permite detectar más errores, y más rápido, mediante una evaluación más exhaustiva de las combinaciones válidas e inválidas de los parámetros de la API, y el uso de oráculos de prueba antes no disponibles. Los resultados de nuestra evaluación en 6 APIs comerciales muestran que RESTest puede generar de manera eficiente hasta un 99+ACU más de casos de prueba válidos en comparación con técnicas de pruebas aleatorias, un 60+ACU de media. Lo que es más importante, RESTest revel+APM más de 2.000 fallos no detectados por pruebas aleatorias, encontrando errores en todos los servicios probados.

Autores: Alberto Martin-Lopez / Sergio Segura / Antonio Ruiz-Cortés / 
Palabras Clave: pruebas de caja negra - Resolución de restricciones - REST - servicios web

Las Interfaces de Programación de Aplicaciones (APIs) web desempeñan un papel clave en la integración de aplicaciones, por lo que validar su correcto funcionamiento resulta crucial. La mayoría de técnicas de generación de casos de prueba en este ámbito son de caja negra y con frecuencia se evalúan con APIs para las que no se dispone del código fuente. En este escenario, no es posible emplear pruebas de mutación tradicionales, por lo que no es posible cuantificar la efectividad de las pruebas si la API no expone ningún error. En este artículo, proponemos un enfoque de caja negra para evaluar la capacidad de detección de errores de las suites de pruebas para APIs web: en lugar de crear variantes defectuosas del código del programa (API), como en las pruebas de mutación tradicionales, se crean mutantes de las salidas del programa (respuestas HTTP). Los oráculos de pruebas se aplican sobre dichos mutantes y, a medida que las pruebas fallan, la cobertura de mutación aumenta. Experimentos preliminares sugieren que existe correlación entre la cobertura de mutación de caja negra y caja blanca.

Autores: Ana B. Sánchez / Alberto Martín-López / Sergio Segura / Antonio Ruiz-Cortés / 
Palabras Clave: APIs Web - JSON - pruebas de mutación

Los servicios web suelen imponer dependencias entre parámetros (también llamadas dependencias inter-parámetro) que restringen el modo en que dos o más parámetros de entrada pueden combinarse para formar una llamada válida. Desafortunadamente, los lenguajes de especificación de servicios web actuales como OpenAPI Specification (OAS) no proporcionan soporte para describir dichas dependencias formalmente, lo que dificulta enormemente la interacción con estos servicios de forma automática, sin necesidad de intervención humana. En este artículo, presentamos una estrategia para la especificación y el análisis automático de dependencias inter-parámetro en APIs web. En primer lugar, presentamos un lenguaje específico de dominio (DSL), llamado Inter-parameter Dependency Language (IDL), para la especificación de dependencias entre parámetros en servicios web. A continuación, proponemos un mapping para traducir un documento IDL a un problema de satisfacción de restricciones (CSP), habilitando el análisis automático de especificaciones IDL mediante operaciones de razonamiento estándar basadas en CSP. Concretamente, presentamos un catálogo de siete operaciones de análisis en documentos IDL permitiendo, por ejemplo, comprobar si una determinada petición satisface todas las dependencias del servicio. Por último, presentamos una suite de herramientas para la especificación y el análisis de IDL, incluyendo un editor, un parser, una extensión de OAS, una librería basada en programación con restricciones, y una completa suite de pruebas. En conjunto, estas contribuciones sientan las bases de una nueva generación de aplicaciones en áreas tales como generación automática de código y pruebas de servicios web.

Autores: Alberto Martin-Lopez / Sergio Segura / Carlos Müller / Antonio Ruiz-Cortés / 
Palabras Clave: analisis automático - API web - dependencia inter-parámetro - DSL - REST