¿Qué son las pruebas basadas en modelos?

Por: Equipo editorial Equipo editorial
Hours Actualizado

⚡ Resumen inteligente

Las pruebas basadas en modelos comprueban el comportamiento en tiempo de ejecución del software comparándolo con las predicciones realizadas por un modelo absoluto.tracmodelo del sistema, generando casos de prueba automáticamente a partir de máquinas de estados finitos, diagramas de estados o notaciones UML en lugar de hacerlo manualmente.

  • 🧭 Idea central: Un modelo describe el comportamiento esperado, y cada caso de prueba se deriva de ese modelo en lugar de escribirse individualmente.
  • 🔀 Dos marcos de referencia: La generación offline crea el conjunto de pruebas antes de la ejecución, mientras que la generación online produce los pasos sobre la marcha durante la ejecución.
  • 📐 Notaciones del modelo: Máquinas de estados finitos, diagramas de estados, tablas de decisión, gráficos de flujo de datos y de control, y diagramas UML.
  • ⚙️ Proceso de trabajo: Construir el modelo, seleccionar criterios de cobertura, generar abstracRealizar pruebas t, concretarlas en scripts, ejecutarlas y luego asignar veredictos.
  • 🛠️ Estampación: GraphWalker, fMBT, Conformiq, MaTeLo, MBTsuite y Spec Explorer generan rutas a partir de grafos dirigidos o modelos de estado.
  • 🇧🇷 Compensación: El mantenimiento disminuye y la cobertura aumenta, pero la técnica exige habilidades de modelado y una inversión inicial en aprendizaje.
Descubre más

Pruebas basadas en modelos que derivan automáticamente casos de prueba a partir de un modelo de comportamiento del sistema.

¿Qué son las pruebas basadas en modelos?

Pruebas basadas en modelos Es una técnica de prueba de software donde el comportamiento en tiempo de ejecución del software bajo prueba se compara con las predicciones de un modelo. Un modelo es una descripción del comportamiento de un sistema, expresada en términos de secuencias de entrada, acciones, condiciones, salida y el flujo de datos desde la entrada hasta la salida. Un modelo útil debe ser comprensible, reutilizable y compartible, y debe describir con precisión el sistema bajo prueba.

Existen numerosos modelos disponibles, y cada uno describe un aspecto diferente del comportamiento del sistema. Algunos ejemplos comunes son:

Las pruebas basadas en modelos describen cómo se comporta un sistema en respuesta a una acción determinada por el modelo. Se proporciona la acción y luego se comprueba si el sistema responde como predice el modelo. Cualquier divergencia entre ambos indica un defecto en el software o un error en el modelo, y vale la pena detectar ambos.

Es un método formal ligero para validar un sistema, y ​​se aplica a las pruebas de hardware con la misma facilidad que a las pruebas de software. Debido a que las pruebas provienen de una especificación de comportamiento en lugar de del código, la técnica se sitúa con el prueba de caja negra familia de técnicas de prueba de software.

Ejemplo de prueba basada en modelos

La forma más sencilla de interpretar un modelo de comportamiento es seguirlo paso a paso. El siguiente diagrama representa una pequeña tarea de edición de texto, donde cada recuadro representa un estado en el que puede encontrarse la aplicación y cada flecha representa una acción que puede realizar el usuario.

Ejemplo de prueba basada en modelos que modela los estados y las acciones de escribir un poema en el Bloc de notas.

El modelo explica un enfoque simplificado para escribir poesía en el Bloc de notas y las posibles acciones relacionadas con cada paso. Para cada acción, como iniciar la aplicación, escribir un poema o guardar el archivo, se realiza una acción. caso de prueba Se puede generar y verificar el resultado. Recorrer un camino diferente a través del mismo diagrama, por ejemplo, comenzando y terminando sin guardar, produce un caso de prueba diferente sin costo de diseño adicional, lo cual constituye el argumento económico a favor de toda la técnica.

Tipos de MBT

Existen dos tipos de marcos de pruebas basados ​​en modelos, y la diferencia entre ellos radica simplemente en el momento en que se generan los pasos de la prueba:

  • Sin conexión / a priori: Generación de conjuntos de pruebas antes de ejecutarlos. Un conjunto de pruebas es una colección de casos de prueba, y en este modo el conjunto se almacena, revisa y vuelve a ejecutar como cualquier otro. pruebas de automatización de activos.
  • En línea / sobre la marcha: Generación de conjuntos de pruebas durante la ejecución de las mismas, donde el siguiente paso se elige en función de cómo respondió realmente el sistema al paso anterior.

La generación offline es adecuada para entornos regulados que requieren un conjunto de pruebas revisables y repetibles. La generación online es adecuada para sesiones exploratorias prolongadas contra sistemas con estado, ya que el generador puede reaccionar a la respuesta real en lugar de a la prevista.

Cómo funcionan las pruebas basadas en modelos

Independientemente del marco de trabajo utilizado, la técnica sigue las mismas cinco etapas. Cada etapa produce un artefacto que la siguiente etapa consume, razón por la cual el modelo, y no el script de prueba, se convierte en lo que el equipo mantiene.

  • Paso 1: Construir el modelo. Traducir los requisitos o una especificación a un resumentracModelo t del comportamiento esperado, que define los estados, las transiciones entre ellos y las entradas que desencadenan cada transición.
  • Paso 2: Elija los criterios de selección de la prueba. Los criterios le indican al generador cuándo debe detenerse. Los más comunes son la cobertura de todos los estados, que visita cada estado al menos una vez; la cobertura de todas las transiciones, que ejecuta cada flecha al menos una vez; y la cobertura de rutas o flujos de datos para una exploración más profunda.
  • Paso 3: Generar abstraccasos de prueba t. La herramienta recorre el modelo y emite secuencias de abs.tract pasos que satisfacen los criterios elegidos, junto con el resultado esperado en cada paso.
  • Paso 4: Concretizar el abstracpruebas t. Una capa adaptadora mapea cada abstract pasar a una acción real contra el sistema, como una interacción de interfaz de usuario, un API llamada o un mensaje de protocolo. Este mapaping Se escribe una sola vez y se reutiliza en cada prueba generada.
  • Paso 5: Ejecutar y asignar veredictos. Las pruebas concretas se realizan contra el sistema bajo prueba, cada respuesta observada se compara con la predicción del modelo y se registra un veredicto de aprobado o reprobado. traced de vuelta al elemento del modelo que lo produjo.

El tracLa capacidad creada en el paso 5 es la recompensa práctica. Cuando un requisito cambia, el modelo cambia y las pruebas afectadas se regeneran en lugar de reescribirse, razón por la cual los equipos que realizan pruebas frecuentes pruebas de regresión frente a una especificación estable, el beneficio es mayor.

No te pierdas

Diferentes modelos en pruebas

Para comprender la Terapia Basada en Modelos (MBT), es necesario entender algunos de los modelos que se explican a continuación. Cada uno de ellos implica un intercambio entre poder expresivo y esfuerzo, por lo que la elección depende de la complejidad del comportamiento que se esté evaluando.

Máquinas de estado finito

Este modelo ayuda a los evaluadores a determinar el resultado en función de la entrada seleccionada. Diversas combinaciones de las entradas pueden dar lugar a un estado correspondiente del sistema.

El sistema tendrá un estado específico y un estado actual, que estará regido por un conjunto de datos de entrada proporcionados por los evaluadores.

Consideremos el siguiente ejemplo. Un sistema permite a los empleados iniciar sesión en una aplicación. El estado actual del empleado es "Fuera" y cambia a "Entrada" una vez que inicia sesión en el sistema. En el estado "Entrada", el empleado puede ver, imprimir y escanear documentos en el sistema.

Aquí se muestra la máquina de estados para ese ejemplo, con cada flecha etiquetada según la entrada que provoca la transición.

Modelo de máquina de estados finitos que muestra los estados de entrada y salida de un sistema de inicio de sesión de empleados.

Gráficos estatales

Un diagrama de estados es una extensión de la máquina de estados finitos y puede utilizarse para sistemas complejos y en tiempo real. Los diagramas de estados describen diversos comportamientos del sistema, tienen un número definido de estados y el comportamiento del sistema se analiza y representa en forma de eventos para cada estado. La extensión relevante en la práctica es la jerarquía: un diagrama de estados permite estados anidados y paralelos, de modo que una máquina que requeriría docenas de estados planos puede representarse de forma compacta.

Por ejemplo, en la herramienta de gestión de defectos, los defectos se registran con el estado "Nuevo". Una vez que los desarrolladores corrigen un defecto, su estado cambia a "Corregido". Si un defecto no se corrige, su estado cambia a "Reabierto". Los diagramas de estados deben diseñarse de manera que se active un evento para cada estado.

El ciclo de vida de un defecto se representa a continuación, donde cada estado se muestra como un estado y cada acción del flujo de trabajo como el evento que mueve el defecto entre ellos.

Diagrama de estados del ciclo de vida de un defecto que pasa por los estados Nuevo, Corregido y Reabierto.

Lenguaje unificado de modelado UML)

Lenguaje unificado de modelado UML) UML es un lenguaje de modelado estandarizado de propósito general. Incluye un conjunto de técnicas de notación gráfica que se utilizan para crear modelos visuales que pueden describir comportamientos de sistemas muy complejos.

UML tiene notaciones como:

  • Actividades
  • de comidas
  • Procesos de negocio
  • Componentes
  • Lenguaje de programación

Los diagramas de actividad y de máquina de estados son los que los generadores de pruebas leen con mayor frecuencia, como ilustra el modelo UML de ejemplo que se muestra a continuación.

Notación de diagrama UML utilizada como modelo fuente para generar casos de prueba.

Herramientas de prueba basadas en modelos

Un modelo en papel no genera nada por sí solo. Se necesita un generador para recorrer el modelo y generar rutas de prueba, y el mercado de herramientas se divide en generadores de código abierto y plataformas comerciales de diseño de pruebas.

  • GraphWalker — una herramienta de código abierto que lee modelos con forma de grafos dirigidos y genera rutas de prueba a partir de ellos, con generadores y condiciones de parada seleccionables.
  • fMBT — un conjunto de herramientas de prueba basadas en modelos de código abierto de Intel que admite la generación y ejecución de pruebas contra modelos de estado.
  • Conformiq — un producto comercial de diseño de pruebas automatizadas que deriva casos de prueba y scripts a partir de modelos gráficos de comportamiento.
  • MaTeLo y MBTsuite — plataformas comerciales destinadas a modelos de uso estadístico y a generar pruebas en marcos de automatización existentes.
  • Explorador de especificaciones - MicrosoftLa extensión de pruebas basadas en modelos de para Visual Studio, ampliamente citada en la literatura sobre pruebas de protocolos.

La selección depende menos de las listas de funcionalidades que de dos preguntas: qué notación puede utilizar el equipo y si la herramienta puede generar pruebas para el marco de automatización ya en uso. Un generador que produce conjuntos de pruebas que nadie puede ejecutar añade un paso al proceso en lugar de eliminarlo.

Pruebas basadas en modelos frente al diseño de pruebas tradicional

Vale la pena destacar el contraste con el diseño de pruebas escritas a mano, porque ambos enfoques fallan en aspectos diferentes, en lugar de que uno sea simplemente mejor que el otro.

Aspecto Pruebas basadas en modelos Diseño de pruebas tradicional
Fuente de los casos de prueba Generado automáticamente a partir de un modelo de comportamiento. Escrito individualmente por un evaluador a partir de los requisitos.
Efecto de un cambio de requisitos Actualizar el modelo, regenerar las pruebas afectadas. Localice y edite manualmente cada caso de prueba afectado.
Global Comparado con criterios de modelos como todos los estados o todas las transiciones. Se evalúa en función de los requisitos y depende del criterio del evaluador.
Costo inicial Alto: habilidad de modelado, configuración de herramientas y una capa adaptadora Bajo: un probador puede comenzar a escribir inmediatamente
Mejores ajuste Sistemas con estado, de larga duración y con especificaciones estables. Proyectos cortos, artículos puntuales y trabajos exploratorios.
Modo de fallo principal Un modelo erróneo o desactualizado genera silenciosamente pruebas erróneas. Las brechas y los duplicados se acumulan en un conjunto grande de datos.

La evolución que se describe a continuación sitúa la técnica en su contexto: la ejecución manual de pruebas dio paso a la ejecución automatizada, y los enfoques basados ​​en modelos llevan la automatización un nivel más arriba, al propio diseño de las pruebas.

Evolución de las pruebas de software desde la ejecución manual hasta la automatización y las pruebas basadas en modelos.

Desafíos de las pruebas basadas en modelos

La implementación de MBT en una organización requiere una inversión considerable de dinero y esfuerzo. A continuación se presentan las desventajas de MBT en Ingeniería de software:

  • Los evaluadores necesitan habilidades de modelado que el diseño de pruebas tradicional no exige.
  • La curva de aprendizaje es larga y el primer proyecto suele costar más de lo que ahorra.
  • El modelo en sí puede resultar difícil de comprender y revisar, especialmente una vez que crece.
  • Un modelo que se desvía de las especificaciones genera pruebas erróneas, aunque parezcan fiables.
  • La capa adaptadora que convierte el ABStracLos pasos que se convierten en acciones reales deben escribirse y mantenerse por separado.
  • El tamaño del modelo crece rápidamente, por lo que un modelo de estado sin restricciones puede generar más rutas de las que cualquier equipo puede ejecutar.

Ninguna de estas razones justifica evitar la técnica, pero en conjunto explican por qué la MBT generalmente se introduce primero en un subsistema estable en lugar de en todo un sistema. ciclo de vida de las pruebas de software En seguida.

Ventajas de las pruebas basadas en modelos

En comparación con esos costos, los beneficios de la TMB son:

  • Fácil mantenimiento de los casos de prueba y del conjunto de pruebas, ya que se edita el modelo en lugar de las pruebas individuales.
  • Reducción de costes a lo largo de la vida útil de un proyecto de larga duración.
  • Disposición prueba de cobertura, puesto que el generador explora caminos que una persona omitiría.
  • Los distintos conjuntos de pruebas generados pueden ejecutarse en cualquier número de máquinas en paralelo.
  • Detección temprana de defectos, ya que las ambigüedades surgen mientras se construye el modelo, antes de que se ejecute cualquier código.
  • Un aumento en el número de defectos encontrados con el mismo esfuerzo de prueba.
  • Ahorro de tiempo en el diseño de pruebas una vez que existen el modelo y el adaptador.
  • Mayor satisfacción laboral para los evaluadores, ya que el esfuerzo se desplaza de la creación repetitiva de scripts al modelado y el análisis.

Los evaluadores construyen modelos mentales mientras trabajan, y MBT simplemente traslada esos modelos mentales al papel, donde pueden revisarse, versionarse y reutilizarse. La posición de esta técnica junto con los demás enfoques disponibles se detalla en tipos de pruebas de software.

Preguntas Frecuentes

Caja negra. Las pruebas se derivan de un modelo de comportamiento específico, no del código fuente. La técnica se convierte en caja gris solo cuando el modelo se construye a partir de documentos de diseño internos en lugar de requisitos externos.

Solo se deben generar pruebas para el comportamiento que lo justifique. Modele un flujo de trabajo con estado, como la extracción de datos o el ciclo de vida de un defecto, al nivel más básico que aún permita distinguir resultados reales. Modelar todo produce una explosión de estados que nadie puede ejecutar.

El modelo debe estar bajo control de versiones junto con el código, con un propietario designado y una etapa de revisión en el mismo proceso de cambio que la especificación. Un modelo sin propietario se desvía, y un modelo desviado genera pruebas fiables pero erróneas.

No. Un generador solo explora lo que describe el modelo, por lo que todo lo que este omite queda sin probar. Las sesiones exploratorias siguen siendo la forma en que los equipos descubren comportamientos que nadie especificó, y a menudo revelan las deficiencias que el modelo luego incorpora.

Sistemas con estado de larga duración y especificación escrita: protocolos de comunicación, controladores integrados y automotrices, dispositivos médicos, flujos de trabajo bancarios y equipos de telecomunicaciones. Estos ámbitos combinan una especificación estable con demasiadas secuencias legales como para enumerarlas manualmente.

Cuando las especificaciones cambian más rápido de lo que el modelo puede adaptarse, cuando la funcionalidad es pequeña o de corta duración, o cuando nadie en el equipo puede mantener la notación, los casos escritos a mano resultan más económicos a lo largo del proyecto.

El aprendizaje automático infiere modelos de estado preliminares a partir de registros de producción y sesiones grabadas, señala las transiciones que el modelo nunca cubre y clasifica las rutas generadas según el historial de defectos para que las secuencias de mayor riesgo se ejecuten primero. Los ingenieros siguen validando el modelo inferido.

Sí, principalmente para la capa del adaptador: los métodos de paso, los objetos de página y las aserciones que vinculan abstracmodelar acciones a llamadas reales. Decidir qué debe contener el modelo y qué criterios de cobertura importan sigue siendo una cuestión de diseño.

Resumir este post con: