Resultados de búsqueda para pruebas de caja negra

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.

Probar una aplicación de bases de datos es una tarea laboriosa debido a que su comportamiento no sólo depende de los valores suministrados por el usuario a través de un interfaz, sino que también depende de la estructura y la información almacenada en la base de datos. Por ello, durante el diseño de los casos de prueba se debe considerar tanto la interacción con el usuario como la interacción con la base de datos. Además, la estructura de la base de datos puede tener una gran complejidad, lo que dificulta el diseño de datos de prueba de calidad. Este trabajo describe un enfoque basado en la especificación (caja negra) que guía el diseño de los datos de prueba (entradas del usuario y base de datos de prueba) para una aplicación de bases de datos y que evalúa automáticamente la cobertura alcanzada por dichos datos de prueba. Para ello se modela de forma conjunta la estructura de la base de datos y del interfaz del usuario, dando lugar a un modelo llamado Modelo Integrado de Datos (IDM), y se expresa la funcionalidad requerida mediante un conjunto de reglas de negocio, escritas en términos del IDM, que forman el Modelo de Reglas Integrado (IRM). Posteriormente se aplica un criterio de suficiencia basado en MCDC sobre el IRM para derivar automáticamente las situaciones de interés a probar (requisitos de prueba). Finalmente, se evalúa automáticamente la cobertura alcanzada por los datos de prueba diseñados. El enfoque ha sido aplicado a dos aplicaciones de bases de datos y los resultados muestran que permiten diseñar casos de prueba capaces de detectar fallos significativos.

Una de las tareas más laboriosas que se llevan a cabo durante el diseño de casos de prueba para una aplicación de bases de datos es la preparación de un conjunto adecuado de datos de prueba, el cual permita cubrir los diversos aspectos del comportamiento de dicha aplicación. Estos datos deben incluir la información almacenada en la base de datos y los valores suministrados por el usuario en el interfaz de usuario. En este artículo, se presenta la herramienta DruidaTest, la cual permite guiar la generación de datos de prueba a partir de la especificación del sistema, utilizando un criterio de suficiencia basado en MCDC. Para alcanzar este propósito DruidaTest utiliza un modelo denominado IDM (Integrated Data Model), que integra la estructura de la base de datos y el interfaz de usuario, y un modelo denominado IRM (Integrated Rules Model), que representa la funcionalidad requerida mediante un conjunto de reglas de negocio escritas en términos del IDM. DruidaTest procesa estos modelos para derivar las situaciones de interés a ser probadas (requisitos de prueba), evalúa automáticamente la cobertura alcanzada y proporciona retroalimentación al ingeniero de pruebas para que pueda incrementar la cobertura.