[Es gibt mehrere lesenswerte Texte dazu. Stack Overflow lässt mich nicht mehr als einen Artikel posten, daher habe ich sie in einem Blog-Post zusammengefasst, der am Ende dieser Antwort verlinkt ist.]
Zuerst eine kurze Notiz zu den Begriffen. Ich neige dazu, James Bachs Definition von Testing als "ein Produkt in Frage zu nehmen, um es zu bewerten" zu verwenden. Alle Tests beruhen auf/mental/Modellen der zu testenden Anwendung. Der Begriff Modellbasiertes Testen wird jedoch typischerweise verwendet, um die Programmierung eines Modells zu beschreiben, das durch Automatisierung untersucht werden kann. Zum Beispiel könnte man eine Anzahl von Zuständen angeben, in denen sich eine Anwendung befinden kann, verschiedene Pfade zwischen diesen Zuständen und bestimmte Aussagen darüber, was beim Übergang zwischen diesen Zuständen geschehen soll. Dann können Skripte halb-zufällige Permutationen von Übergängen innerhalb des Zustandsmodells ausführen und möglicherweise interessante Ergebnisse protokollieren.
Hier sind echte Kosten: ein nützliches Modell zu erstellen, Algorithmen für die Erkundung zu erstellen, Systeme zu protokollieren, die es ermöglichen, interessante Fehler zu durchforsten usw. Ob die Kosten vernünftig sind, hat viel mit was zu tun sind die Fragen, die Sie beantworten möchten? Beginnen Sie im Allgemeinen mit "Was möchte ich wissen? Und wie kann ich das am besten lernen? "Anstatt nach einer interessanten Technik zu suchen.
Alles, was gesagt wurde, einige ausgezeichnete Tester haben eine Menge Laufleistung aus automatisierten modellbasierten Tests bekommen. Manchmal haben wir wichtige Fragen zu der zu testenden Anwendung, die am besten durch automatisierte, semi-randomisierte Tests in großem Umfang untersucht werden.Harry Robinson (einer der führenden Theoretiker und Befürworter modellbasierter Tests) beschreibt ein sehr farbenfrohes Beispiel, bei dem er viele interessante Fehler in Google-Wegbeschreibungen mit einem modellbasierten Test entdeckte (geschrieben mit Rubys Watir-Bibliothek). 1
Robinson hat MBT erfolgreich bei Unternehmen wie Bell Labs, Microsoft und Google verwendet und hat eine Reihe hilfreicher Aufsätze. [2]
Ben Simo (ein anderer großartiger Denkdenker und Autor) hat auch viel zu schreiben über modellbasiertes Testen geschrieben. [3]
Abschließend noch ein paar Vorsichtshinweise: Um eine Strategie gut zu nutzen, muss man sowohl ihre Stärken als auch ihre Schwächen erforschen. Zu diesem Zweck spricht James Bach hervorragend über die Grenzen und Herausforderungen von Model-Based Testing. Dieser Blogbeitrag von Bachs Links zu seinem stundenlangen Vortrag (und den zugehörigen Folien). [4]
Ich schließe mit einer Notiz über, was Boris Beizer das Pestizid-Paradox nennt: "Jede Methode, die Sie verwenden, um Fehler zu verhindern oder zu finden, hinterlässt einen Rückstand von subtileren Fehlern, gegen die diese Methoden unwirksam sind." Skript-Tests (ob ausgeführt von ein Computer oder eine Person) sind besonders anfällig für das Pestizidparadoxon und neigen dazu, immer weniger nützliche Informationen zu finden, wenn das gleiche Skript ausgeführt wird. Die Leute gehen manchmal zu modellbasierten Tests über, die denken, dass sie das Pestizidproblem umgehen. In einigen Kontexten kann das modellbasierte Testen sehr viel mehr Bugs enthalten als ein vorgegebener Satz von Tests ... aber man sollte bedenken, dass es durch das Pestizid-Paradox immer noch grundlegend eingeschränkt wird. Sich an seine Grenzen erinnernd - und beginnend mit Fragen, die MBT gut anspricht - hat das Potential, eine sehr leistungsfähige Teststrategie zu sein.
Links zu allen Aufsätzen oben erwähnt sind hier zu finden: http://testingjeff.wordpress.com/2009/06/03/question-about-model-based-testing/