Las pruebas basadas en modelos son una aplicación de diseño basado en modelos para diseñar y, opcionalmente, también ejecutar artefactos para realizar pruebas de software o 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 enfoque anterior.
Un modelo que describe un IVU suele ser una presentación parcial y abstracta del comportamiento deseado del IVU. Los casos de prueba derivados de dicho modelo son pruebas funcionales en el mismo nivel de abstracción que el modelo. Estos casos de prueba se conocen colectivamente como un conjunto de pruebas abstractas . Un conjunto de pruebas abstractas no se puede ejecutar directamente contra un SUT porque el conjunto está en el nivel incorrecto de abstracción. Una suite de pruebas ejecutabledebe derivarse de una serie de pruebas abstractas correspondiente. El conjunto de pruebas ejecutables puede comunicarse directamente con el sistema bajo prueba. Esto se logra mapeando los casos de prueba abstractos con 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 conjuntos de pruebas ejecutables directamente. En otros, los elementos de la serie de pruebas abstractas deben asignarse a declaraciones específicas o llamadas a métodos en el software para crear una serie de pruebas concretas . A esto se le llama resolver el "problema de mapeo". [1] En el caso de las pruebas en línea (ver más abajo), los conjuntos de pruebas abstractas existen solo conceptualmente, pero no como artefactos explícitos.
Las pruebas se pueden derivar de modelos de diferentes formas. Debido a que las pruebas suelen ser experimentales y se basan en heurísticas, no existe un mejor enfoque conocido para la derivación de pruebas. Es común consolidar todos los parámetros relacionados con la derivación de pruebas en un paquete que a menudo se conoce como "requisitos de prueba", "propósito de la prueba" o incluso "caso (s) de uso". Este paquete puede contener información sobre las partes de un modelo en las que debe centrarse, o las condiciones para finalizar la prueba (criterios de parada de la prueba).
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 siguen siendo un campo en evolución.
Modelos
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áquina finitas y formalismos matemáticos como Z , B ( Event-B ), Alloy o Coq .
Implementación de pruebas basadas en modelos
Hay 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 prueba basada en modelos se conecta directamente a un SUT y lo prueba de forma dinámica.
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 se pueden ejecutar 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 por humanos que luego pueden ayudar en las pruebas manuales; por ejemplo, un documento PDF en lenguaje humano que describe los pasos de prueba generados.
Derivando pruebas algorítmicamente
La efectividad de las pruebas basadas en modelos se debe principalmente al potencial de automatización que ofrece. Si un modelo es legible por máquina y formal en la medida en que tiene una interpretación conductual bien definida, los casos de prueba pueden, en principio, derivarse mecánicamente.
De máquinas de estados finitos
A menudo, el modelo se traduce o se interpreta como un autómata de estado finito o un sistema de transición de estado . Este autómata representa las posibles configuraciones del sistema bajo prueba. Para encontrar casos de prueba, se busca en el autómata rutas ejecutables. 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 valiosos casos de prueba 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 rutas puede ser muy grande, debido a la gran cantidad de configuraciones posibles del sistema. Para encontrar casos de prueba que puedan cubrir un número apropiado, pero finito, de rutas, 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 ha analizado. [4] Los criterios de prueba se describen en términos de gráficos generales en el libro de texto de prueba. [1]
Demostración del teorema
La demostración de teoremas se utilizó originalmente para la demostración automatizada 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 determinado 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 .
Programación lógica de restricciones y ejecución simbólica
La programación de restricciones se puede utilizar para seleccionar casos de prueba que satisfagan restricciones específicas resolviendo un conjunto de restricciones sobre un conjunto de variables. El sistema se describe mediante 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 al resolver el conjunto de fórmulas de restricciones puede servir como casos 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, recolectando restricciones de datos sobre diferentes rutas de control, y luego usando el método de programación de restricciones para resolver las restricciones y producir casos de prueba. [7]
Comprobación de modelo
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 usa para probar, se proporciona al verificador de modelos un modelo del sistema bajo prueba y una propiedad para probar. Dentro del procedimiento de verificación, si esta propiedad es válida en el modelo, el verificador de modelos detecta testigos y contraejemplos. Un testigo es un camino donde se satisface la propiedad, mientras que un contraejemplo es un camino en la ejecución del modelo donde se viola la propiedad. Estas rutas se pueden usar nuevamente como casos de prueba.
Generación de casos de prueba mediante el uso de un modelo de prueba de cadena de Markov
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 denomina prueba basada en modelos de uso / estadístico. Los modelos de uso, por lo que las cadenas de Markov, se construyen principalmente a partir de 2 artefactos: la máquina de estado finito (FSM) que representa todos los escenarios de uso posibles del sistema probado y los perfiles operativos (OP) que califican al FSM para representar cómo es o será el sistema. ser utilizado estadísticamente. El primero (FSM) ayuda a saber qué puede ser o ha sido probado y el segundo (OP) ayuda a derivar casos de prueba operacionales. Las pruebas basadas en modelos estadísticos / de uso parten de los hechos que no es posible probar exhaustivamente un sistema y que la falla 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 confiabilidad del sistema bajo prueba. Las pruebas basadas en modelos estadísticos / de uso se ampliaron recientemente para que sean aplicables a los sistemas de software integrados. [10] [11]
Ver también
- Lenguaje específico de dominio (DSL)
- Modelado específico de dominio (DSM)
- Arquitectura basada en modelos (MDA)
- Ingeniería basada en modelos (MDE)
- Análisis y diseño orientado a objetos (OOAD)
- Prueba de partición de tiempo (TPT)
Referencias
- ^ a b Paul Ammann y Jeff Offutt. Introducción a las pruebas de software. Prensa de la Universidad de Cambridge, 2008.
- ^ Pruebas prácticas basadas en modelos: un enfoque de herramientas Archivado el25 de agosto de 2012en Wayback Machine , Mark Utting y Bruno Legeard, ISBN 978-0-12-372501-1 , Morgan-Kaufmann 2007
- ^ Jeff Offutt y Aynur Abdurazik. Generación de pruebas a partir de especificaciones UML. Segunda Conferencia Internacional sobre el Lenguaje Unificado de Modelado (UML '99), páginas 416-429, Fort Collins, CO, octubre de 1999.
- ^ John Rushby. Generación de pruebas automatizadas y software verificado. Software verificado: teorías, herramientas, experimentos: Primera conferencia IFIP TC 2 / WG 2.3, VSTTE 2005, Zurich, Suiza, 10 al 13 de octubre. págs. 161-172, Springer-Verlag
- ^ Brucker, Achim D .; Wolff, Burkhart (2012). "Sobre pruebas basadas en teoremas probadores" . Aspectos formales de la informática . 25 (5): 683–721. CiteSeerX 10.1.1.208.3135 . doi : 10.1007 / s00165-012-0222-y .
- ^ Jefferson Offutt. Generación automática de datos de prueba basada en restricciones. Transacciones IEEE sobre ingeniería de software, 17: 900-910, 1991
- ^ Antti Huima. Implementación de Conformiq Qtronic. Pruebas de software y sistemas de comunicación, notas de clase en ciencias de la computación, 2007, volumen 4581/2007, 1-12, DOI: 10.1007 / 978-3-540-73066-8_1
- ^ Gordon Fraser, Franz Wotawa y Paul E. Ammann. Prueba con verificadores de modelos: una encuesta. Pruebas, verificación y confiabilidad de software, 19 (3): 215–261, 2009. URL: [1]
- ^ Helene Le Guen. Validation d'un logiciel par le test statistique d'usage: de la modelisation de la decision à la livraison, 2005. URL: ftp://ftp.irisa.fr/techreports/theses/2005/leguen.pdf
- ^ Böhr, Frank (2011). "Pruebas estadísticas basadas en modelos de sistemas integrados". 2011 IEEE Cuarta Conferencia Internacional sobre Talleres de Pruebas, Verificación y Validación de Software . págs. 18-25. doi : 10.1109 / ICSTW.2011.11 . ISBN 978-1-4577-0019-4.
- ^ https://www.amazon.de/Model-Based-Statistical-Continuous-Concurrent-Environment/dp/3843903484/ref=sr_1_1?ie=UTF8&qid=1334231267&sr=8-1
Otras lecturas
- Perfil de prueba OMG UML 2; [2]
- Bringmann, E .; Krämer, A. (2008). "Pruebas basadas en modelos de sistemas automotrices" (PDF) . 2008 Conferencia Internacional sobre Pruebas, Verificación y Validación de Software . Conferencia internacional sobre pruebas, verificación y validación de software (ICST). págs. 485–493. doi : 10.1109 / ICST.2008.45 . ISBN 978-0-7695-3127-4.
- Pruebas prácticas basadas en modelos: un enfoque de herramientas , Mark Utting y Bruno Legeard, ISBN 978-0-12-372501-1 , Morgan-Kaufmann 2007.
- Pruebas y análisis de software basados en modelos con C # , Jonathan Jacky, Margus Veanes, Colin Campbell y Wolfram Schulte, ISBN 978-0-521-68761-4 , Cambridge University Press 2008.
- Pruebas basadas en modelos de la serie de conferencias avanzadas de sistemas reactivos , LNCS 3472, Springer-Verlag, 2005. ISBN 978-3-540-26278-7 .
- Hong Zhu; et al. (2008). AST '08: Actas del 3er Taller Internacional sobre Automatización de Pruebas de Software . Prensa ACM. ISBN 978-1-60558-030-2.
- Santos-Neto, P .; Resende, R .; Pádua, C. (2007). "Requisitos para las pruebas basadas en modelos de sistemas de información". Actas del simposio 2007 de ACM sobre informática aplicada - SAC '07 . Simposio de Computación Aplicada . págs. 1409-1415. doi : 10.1145 / 1244002.1244306 . ISBN 978-1-59593-480-2.
- Roodenrijs, E. (primavera de 2010). "Las pruebas basadas en modelos agregan valor" . Métodos y herramientas . 18 (1): 33–39. ISSN 1661-402X .
- A Systematic Review of Model Based Testing Tool Support , Muhammad Shafique, Yvan Labiche, Universidad de Carleton, Informe técnico, mayo de 2010.
- Zander, Justyna; Schieferdecker, Ina; Mosterman, Pieter J. , eds. (2011). Pruebas basadas en modelos para sistemas integrados . Análisis, Síntesis y Diseño Computacional de Sistemas Dinámicos. 13 . Boca Ratón: CRC Press . ISBN 978-1-4398-1845-9.
- 2011/2012 Encuesta a usuarios de pruebas basadas en modelos: resultados y análisis. Robert V. Binder. Asociados de verificación de sistemas, febrero de 2012