[Hay varios ensayos que vale la pena leer sobre esto. Stack Overflow no me permite publicar más de uno, así que los agregué en una publicación de blog, vinculada al final de esta respuesta.]
Primero, una nota rápida sobre los términos. Tiendo a usar la definición de Testing de James Bach como "cuestionar un producto para evaluarlo". Todas las pruebas dependen de/mental/modelos de la aplicación bajo prueba. Sin embargo, el término Pruebas Basadas en Modelos generalmente se usa para describir la programación de un modelo que puede explorarse a través de la automatización. Por ejemplo, uno podría especificar un número de estados en los que puede estar una aplicación, varias rutas entre esos estados y ciertas afirmaciones sobre lo que debería ocurrir en la transición entre esos estados. Entonces uno puede tener scripts ejecutando permutaciones semi-aleatorias de transiciones dentro del modelo de estado, registrando resultados potencialmente interesantes.
Aquí hay costos reales: crear un modelo útil, crear algoritmos para explorarlo, registrar sistemas que le permitan a uno pasar por fallas interesantes, etc. Si los costos son razonables tiene mucho que ver con qué son las preguntas que quieres responder? En general, comience con "¿Qué quiero saber? ¿Y cómo puedo aprender mejor sobre esto? "En lugar de buscar un uso para una técnica interesante.
Dicho todo esto, algunos excelentes evaluadores han obtenido un gran rendimiento de las pruebas automatizadas basadas en modelos. A veces tenemos preguntas importantes acerca de la aplicación bajo prueba que se exploran mejor mediante pruebas semialeatorizadas automáticas y de alto volumen.Harry Robinson (uno de los principales teóricos y defensores de las pruebas basadas en modelos) describe un ejemplo muy colorido en el que descubrió muchos errores interesantes en las indicaciones de conducción de Google utilizando una prueba basada en modelos (escrita con la biblioteca Watir de ruby). 1
Robinson ha utilizado MBT con éxito en compañías como Bell Labs, Microsoft y Google, y tiene varios ensayos útiles. [2]
Ben Simo (otro gran pensador y escritor de pruebas) también ha escrito bastante valioso sobre las pruebas basadas en modelos. [3]
Por último, algunas advertencias: para hacer un buen uso de una estrategia, es necesario explorar sus fortalezas y sus debilidades. Con ese fin, James Bach tiene una excelente charla sobre los límites y desafíos de las Pruebas Basadas en Modelos. Esta publicación de blog de los enlaces de Bach a su charla de una hora (y las diapositivas asociadas). [4]
Terminaré con una nota sobre lo que Boris Beizer llama Pesticide Paradox: "Cada método que utiliza para prevenir o encontrar errores deja un residuo de errores más sutiles contra los cuales esos métodos son ineficaces". Pruebas con guiones (ya sean ejecutadas por una computadora o una persona) son particularmente vulnerables a la paradoja del pesticida, tendiendo a encontrar información cada vez menos útil cada vez que se ejecuta el mismo guión. La gente a veces recurre a las pruebas basadas en modelos pensando que soluciona el problema del pesticida. En algunos contextos, las pruebas basadas en modelos pueden encontrar un conjunto mucho más grande de errores que un conjunto dado de pruebas escritas ... pero uno debe recordar que aún está fundamentalmente limitado por la paradoja de los pesticidas. Recordando sus límites, y comenzando con las preguntas que MBT aborda bien, tiene el potencial de ser una estrategia de prueba muy poderosa.
Enlaces a todos los ensayos mencionados anteriormente se pueden encontrar aquí: http://testingjeff.wordpress.com/2009/06/03/question-about-model-based-testing/