Las pruebas basadas en modelos son una aplicación del diseño basado en modelos para diseñar y, opcionalmente, ejecutar artefactos para realizar pruebas de software o pruebas de sistemas . Los modelos se pueden utilizar para representar el comportamiento deseado de un sistema bajo prueba (SUT) o para representar estrategias de prueba y un entorno de prueba. La imagen de la derecha muestra el primer enfoque.
Un modelo que describe un SUT suele ser una presentación abstracta y parcial del comportamiento deseado del SUT. Los casos de prueba derivados de un modelo de este tipo son pruebas funcionales en el mismo nivel de abstracción que el modelo. Estos casos de prueba se conocen colectivamente como una suite de pruebas abstracta . Una suite de pruebas abstracta no se puede ejecutar directamente contra un SUT porque la suite está en el nivel de abstracción incorrecto. Una suite de pruebas ejecutable debe derivarse de una suite de pruebas abstracta correspondiente. La suite de pruebas ejecutable puede comunicarse directamente con el sistema bajo prueba. Esto se logra asignando los casos de prueba abstractos a casos de prueba concretos adecuados para la ejecución. En algunos entornos de prueba basados en modelos, los modelos contienen suficiente información para generar suites de pruebas ejecutables directamente. En otros, los elementos de la suite de pruebas abstractas deben asignarse a declaraciones específicas o llamadas de método en el software para crear una suite de pruebas concreta. Esto se llama resolver el "problema de mapeo". [1] En el caso de las pruebas en línea (ver a continuación), las suites de pruebas abstractas existen solo conceptualmente, pero no como artefactos explícitos.
Las pruebas se pueden derivar de los modelos de diferentes maneras. Debido a que las pruebas suelen ser experimentales y se basan en heurísticas, no se conoce un único método óptimo para la derivación de pruebas. Es habitual consolidar todos los parámetros relacionados con la derivación de pruebas en un paquete que suele conocerse como "requisitos de prueba", "propósito de prueba" o incluso "caso(s) de uso". Este paquete puede contener información sobre las partes de un modelo en las que se debe centrar la atención o las condiciones para finalizar las pruebas (criterios de detención de pruebas).
Debido a que los conjuntos de pruebas se derivan de modelos y no del código fuente, las pruebas basadas en modelos generalmente se consideran una forma de prueba de caja negra .
Las pruebas basadas en modelos para sistemas de software complejos aún son un campo en evolución.
Especialmente en la ingeniería basada en modelos o en la arquitectura basada en modelos de Object Management Group ( OMG ) , los modelos se construyen antes o en paralelo con los sistemas correspondientes. Los modelos también se pueden construir a partir de sistemas completos. Los lenguajes de modelado típicos para la generación de pruebas incluyen UML , SysML , lenguajes de programación convencionales, notaciones de máquinas finitas y formalismos matemáticos como Z , B ( Event-B ), Alloy o Coq .
Existen varias formas conocidas de implementar pruebas basadas en modelos, que incluyen pruebas en línea , generación fuera de línea de pruebas ejecutables y generación fuera de línea de pruebas implementables manualmente . [2]
Las pruebas en línea significan que una herramienta de pruebas basada en modelos se conecta directamente a un SUT y lo prueba dinámicamente.
La generación fuera de línea de pruebas ejecutables significa que una herramienta de prueba basada en modelos genera casos de prueba como activos legibles por computadora que luego pueden ejecutarse automáticamente; por ejemplo, una colección de clases de Python que incorpora la lógica de prueba generada.
La generación fuera de línea de pruebas implementables manualmente significa que una herramienta de prueba basada en modelos genera casos de prueba como activos legibles para humanos que luego pueden ayudar en pruebas manuales; por ejemplo, un documento PDF en un lenguaje humano que describe los pasos de prueba generados.
La eficacia de las pruebas basadas en modelos se debe principalmente al potencial de automatización que ofrecen. Si un modelo es legible por máquina y formal en la medida en que tiene una interpretación de comportamiento bien definida, los casos de prueba pueden, en principio, derivarse mecánicamente.
A menudo, el modelo se traduce o se interpreta como un autómata de estados finitos o un sistema de transición de estados . Este autómata representa las posibles configuraciones del sistema bajo prueba. Para encontrar casos de prueba, se buscan rutas ejecutables en el autómata. Una posible ruta de ejecución puede servir como caso de prueba. Este método funciona si el modelo es determinista o puede transformarse en uno determinista. Se pueden obtener casos de prueba valiosos fuera de lo nominal aprovechando transiciones no especificadas en estos modelos.
Dependiendo de la complejidad del sistema bajo prueba y del modelo correspondiente, el número de caminos puede ser muy grande, debido a la enorme cantidad de configuraciones posibles del sistema. Para encontrar casos de prueba que puedan cubrir un número apropiado, pero finito, de caminos, se necesitan criterios de prueba para guiar la selección. Esta técnica fue propuesta por primera vez por Offutt y Abdurazik en el artículo que inició las pruebas basadas en modelos. [3] Se han desarrollado múltiples técnicas para la generación de casos de prueba y Rushby las analiza. [4] Los criterios de prueba se describen en términos de gráficos generales en el libro de texto de pruebas. [1]
La demostración de teoremas se utilizó originalmente para la demostración automática de fórmulas lógicas. Para los enfoques de prueba basados en modelos, el sistema se modela mediante un conjunto de predicados , que especifican el comportamiento del sistema. [5] Para derivar casos de prueba, el modelo se divide en clases de equivalencia sobre la interpretación válida del conjunto de predicados que describen el sistema bajo prueba. Cada clase describe un cierto comportamiento del sistema y, por lo tanto, puede servir como un caso de prueba. La partición más simple es con el enfoque de forma normal disyuntiva en el que las expresiones lógicas que describen el comportamiento del sistema se transforman en la forma normal disyuntiva .
La programación de restricciones se puede utilizar para seleccionar casos de prueba que satisfagan restricciones específicas mediante la resolución de un conjunto de restricciones sobre un conjunto de variables. El sistema se describe por medio de restricciones. [6] La resolución del conjunto de restricciones se puede realizar mediante solucionadores booleanos (por ejemplo, solucionadores SAT basados en el problema de satisfacibilidad booleano ) o mediante análisis numérico , como la eliminación gaussiana . Una solución encontrada mediante la resolución de las fórmulas del conjunto de restricciones puede servir como caso de prueba para el sistema correspondiente.
La programación de restricciones se puede combinar con la ejecución simbólica. En este enfoque, un modelo de sistema se ejecuta simbólicamente, es decir, se recopilan restricciones de datos sobre diferentes rutas de control y luego se utiliza el método de programación de restricciones para resolver las restricciones y producir casos de prueba. [7]
Los verificadores de modelos también se pueden utilizar para la generación de casos de prueba. [8] Originalmente, la verificación de modelos se desarrolló como una técnica para verificar si una propiedad de una especificación es válida en un modelo. Cuando se utiliza para realizar pruebas, se proporciona al verificador de modelos un modelo del sistema bajo prueba y una propiedad para probar. Dentro del procedimiento de prueba, si esta propiedad es válida en el modelo, el verificador de modelos detecta testigos y contraejemplos. Un testigo es una ruta donde se satisface la propiedad, mientras que un contraejemplo es una ruta en la ejecución del modelo donde se viola la propiedad. Estas rutas se pueden utilizar nuevamente como casos de prueba.
Las cadenas de Markov son una forma eficiente de manejar las pruebas basadas en modelos. Los modelos de prueba realizados con cadenas de Markov pueden entenderse como un modelo de uso: se denominan pruebas basadas en modelos de uso/estadísticos. Los modelos de uso, es decir, las cadenas de Markov, se construyen principalmente con 2 artefactos: la máquina de estados finitos (FSM) que representa todos los posibles escenarios de uso del sistema probado y los perfiles operativos (OP) que califican la FSM para representar cómo se usa o se usará estadísticamente el sistema. El primero (FSM) ayuda a saber qué se puede probar o se ha probado y el segundo (OP) ayuda a derivar casos de prueba operativos. Las pruebas basadas en modelos de uso/estadísticos comienzan con el hecho de que no es posible probar exhaustivamente un sistema y que el fallo puede aparecer con una tasa muy baja. [9] Este enfoque ofrece una forma pragmática de derivar estáticamente casos de prueba que se centran en mejorar la fiabilidad del sistema bajo prueba. Las pruebas basadas en modelos de uso/estadísticos se ampliaron recientemente para que sean aplicables a los sistemas de software integrados. [10] [11]