Development Testing Softwarearchitektur

Testautomatisierung schnell und komfortabel

Der jüngste World Quality Report [WQR] betont: Die IT-Industrie platziert die Effizienzsteigerung des Testens durch Automatisierung an die Spitze der Rangliste von notwendigen Verbesserungen, und trotzdem ist in den letzten Jahren kein deutlicher Fortschritt auf diesem Gebiet erkennbar. Auch die Sonderausgabe für Deutschland [WQR-DE] titelt: „Test Automation: Popular, but work in progress“. Für die Herausforderung, Testen effizient und umfassend zu automatisieren, ist scheinbar noch kein „silver Bullet“ gefunden worden. Das Problem liegt in einem immer noch mäßigen Kosten-Nutzenverhältnis der Testautomatisierung.

Matthias Hamburg

Author

István Forgács

Author

26.05.2023
Lesezeit: 12 Minuten
176 Views

Wie in der Glossar-Kolumne über „Die Begriffswelt der Testautomatisierung“ diskutiert, bedeutet Testautomatisierung mehr als nur die automatische Durchführung von Tests. Dazu gehört auch die Automatisierung der vorangehenden Testrealisierung und des Testentwurfs. Im Kontext des kontinuierlichen Testens hat das eine besonders hohe Relevanz. In diesem Beitrag schauen sich die Autoren die Gründe an, warum der Fortschritt langsam ist, und stellen einen neuen, vielversprechenden Lösungsansatz vor.

Die Bedeutung des modellbasierten Testens

Wer nur die Testdurchführung automatisiert, wird die gleichen Testfälle bei jeder Version des Systems unter Test (SuT) unverändert durchführen, und läuft damit unweigerlich in das Pestizid-Paradoxon: Je öfter man den gleichen Test unverändert durchführt, desto mehr neue Fehlerzustände bleiben unentdeckt [GTB-b].

Dieser Ansatz deckt den oben erwähnten Bedarf an Effizienzsteigerung durch Automatisierung kaum ab. Darüber hinaus kann selbst die Automatisierung der Testausführung ineffizient sein. Unerfahrene Automatisierer verwenden gerne die lineare Skripterstellung: ein einfaches Verfahren ohne Verwendung von Kontrollstrukturen in Testskripten [GTB-d]. Dabei ist die Skripterstellung scheinbar effizient, verletzt aber das DRY-Prinzip (Don‘t Repeat Yourself). Das hat erhöhte Wartungsaufwände der Testskripte zur Folge. Die professionellere, heute verbreitete Alternative ist die strukturierte Skripterstellung: Ein Verfahren, das eine Bibliothek wiederverwendbarer (Teil-) Skripte aufbaut und nutzt. Dadurch wird jedoch der Automatisierungscode wesentlich komplexer und benötigt mehr Zeit zum Entwickeln.

Wie Bloor Research [Bloor] feststellt: Die Automatisierung des Testentwurfs kann die Geschwindigkeit und Effizienz von Tests erheblich steigern. Richtig eingesetzt, kann sie auch die Erfahrung der Endbenutzer drastisch verbessern. Die Werkzeuge für den Testentwurf sind die modellbasierten Testwerkzeuge (MBT). Sie generieren die Arbeitsergebnisse des Testens aus Modellen. Dabei kann es sich um abstrakte oder konkrete Testfälle, Testdaten, Testskripte oder andere Arbeitsergebnisse handeln. Bei den Modellen kann es sich um unterschiedliche Teile der Testbasis handeln. Für das Testen benötigen wir möglicherweise spezielle Modelltypen, aber in der Praxis werden die verbreiteten Software-Engineering-Modelle verwendet.

Zu den Modellen, die das Verhalten des SuT beschreiben, gehören die Verhaltensdiagramme des UML-Standards (Zustandsdiagramme, Aktivitätsdiagramme, Sequenzdiagramme), erweiterte endliche Automaten (EFSM, extended finite-state machines) und Geschäftsprozessmodelle nach dem Standard BPMN (Business Process Modeling Notation).

Herausforderungen beim modellbasierten Testen

Ein gemeinsames Merkmal der beliebtesten Modelle ist, dass sie als Graphen dargestellt werden können [GTB-c]. Auch textuelle Modelle wie Anwendungsfälle werden gerne zunächst in UML-Aktivitätsdiagramme oder -Sequenzdiagramme konvertiert. Durch das Durchlaufen der Pfade im Graphen auf verschiedene Arten können verschiedene Stufen der Überdeckung gewählt werden. Die Testfälle können so generiert werden, dass sie die vorgegebene Überdeckung erfüllen. Hier liegt der Vorteil der Automatisierung des Testentwurfs: Anstatt die Testfälle einen nach dem anderen ad hoc zu erstellen, werden sie auf der Grundlage eines akzeptierten Modells und von Überdeckungskriterien generiert.

Ein häufiges Problem des MBT ist, dass traditionelle Methoden Codierung erfordern. Beim Durchlaufen eines Graphen werden teilweise ungültige Testfälle erzeugt. So ist es beispielsweise nicht möglich, das zweite Auto einer Reservierung hinzuzufügen und dann das dritte zu löschen. Um dieses Problem zu lösen, werden Wächterbedingungen hinzugefügt. Diese sind jedoch Code. Wenn eine Wächterbedingung eine Ausgabe des SuT enthält, dann sollte auch diese Ausgabe codiert werden. Wenn es sich um eine komplexe Funktion handelt, ist auch der für das Testmodell entwickelte Wächter-Code komplex, und wie soll man ihn testen?

Ein weiteres Problem ist, dass für eine vollständige Testcodegenerierung das Verhaltensmodell des SuT nicht ausreicht. Das MBT-Modell muss weitere Informationen für die Testrealisierung enthalten. Jeder Klick, jede Auswahl, jeder Eingabe- und Ausgabewert muss im Modell enthalten sein. Die Erstellung dieser Modellteile vor der Realisierung kann viel Doppelarbeit verursachen, wenn sich die tatsächliche Realisierung von der geplanten unterscheidet. Die Erstellung dieser Modelle nach der Realisierung widerspricht hingegen dem Shift-left-Prinzip.

Die beliebteste Antwort auf die oben genannten Herausforderungen ist die Nutzung von zustandslosen Modellen. Diesen immer leicht anwendbaren Ansatz verwenden die beliebtesten und am weitesten verbreiteten MBT-Werkzeuge. Einige Beispiele dieser Werkzeuge sind Broadcom Agile Requirements Designer, Eggplant, Perfecto und Curiosity. Das Problem mit dieser Art von Modellen ist, dass die Tests nur einen Teil der Fehlerzustände aufdecken, selbst wenn ein stärkeres Überdeckungskriterium (z. B. kombinatorisch) gewählt wurde.

Die Nutzung der zustandsabhängigen Verhaltensmodelle, wie zum Beispiel Zustandsdiagrammen, findet mehr und kompliziertere Fehler, birgt jedoch zusätzliche Herausforderungen. Zustände können schwer zu identifizieren sein, und das Zustandsmodell kann schnell sehr komplex werden. Werkzeuge, die zustandsbasierte Modelle unterstützen, sind zum Beispiel Smartesting, Opkey und Conformiq Creator.

Generieren von Testfällen in zwei Phasen

Zweiphasige modellbasierte Tests zielen darauf ab, die Herausforderungen beim MBT zu lösen.

In der ersten Phase beschränkt sich der Testanalyst auf die Modellierung derjenigen Aspekte der Testbasis, die für eine Generierung der abstrakten Testfälle erforderlich sind. Aus diesem Analysemodell generiert das Automatisierungssystem abstrakte Testfälle, die auf der Testbasis (meist Spezifikation) beruhen und bei jeder konkreten Realisierung anwendbar sind.

In der zweiten Phase unterstützt das Werkzeug den Testautomatisierer bei der Erfassung der nötigen Daten der Testrealisierung, einschließlich der konkreten Eingaben, GUI-Aktionen, und der Prüfung der erwarteten Ergebnisse. Als Ergebnis entstehen die Automatisierungsskripte, die schnell erstellt und leicht wartbar sind.

Im Folgenden möchten wir das Verfahren genauer erläutern.

Phase 1: Abstrakte Testfälle generieren

In dieser Phase werden abstrakte Testfälle aus dem Verhaltensmodell des SuT generiert. Die Phase kann beginnen, sobald die Spezifikation, welche als Testbasis dient, erstellt ist. Hierbei kommt der Vorteil des MBT, dass die Spezifikation durch Modellierung und Testfallgenerierung früh verifiziert wird, voll zum Tragen. Auf diese Weise können die meisten Fehler, Missverständnisse usw. beseitigt werden, was in dieser Phase des Softwarelebenszyklus sehr günstig ist [GTB-c].

Abstrakte Testfälle haben abstrakte Vorbedingungen, Eingabedaten, erwartete Ergebnisse, Nachbedingungen und Aktionen (falls anwendbar). Solche Testfälle können von Menschen ausgeführt werden, aber daraus kann noch kein ausführbarer Testcode erzeugt werden. Listing 1 zeigt ein Beispiel.

Listing 1: Skript eines abstrakten Testfalls mit zwei Schritten

Die erste Zeile ist die Vorbedingung. Die zweite Zeile ist ein Label, das die Anforderung R4 mit dem Modell und dem Testfall verbindet. Die vierte Zeile besteht aus einem Modellschritt. Der erste Teil „Artikel hinzufügen, sodass der Preis unter 10 bleibt“ ist eine Benutzeraktion, der zweite Teil „Prüfen, ob Preis <10“ ist eine Validierung der erwarteten Ergebnisse, und der dritte Teil „Bezahlen ist nicht möglich“ ist die Nachbedingung. Ein Tester, der sich mit der Grenzwertanalyse auskennt, fügt dem Warenkorb Artikel hinzu, bis der Gesamtpreis die 10 erreicht. Wenn er das Ergebnis validiert, wird er prüfen, ob das System das Bezahlen nun zulässt.

Die Ausführung dieser Testschritte ist für den Tester, der die Preise der Artikel kennt, einfach, aber für eine Maschine, die die Testverfahren kennen, den Text der Modellschritte verstehen und die Preise auf dem Bildschirm (oder durch Lesen und Interpretieren der Spezifikation) erkennen müsste, ist es derzeit kaum möglich.

Aus dem obigen Modell wird ein einziger Test generiert, der aus den beiden Modellschritten besteht. Das Modell kann leicht modifiziert werden, um diese Schritte in zwei einzelnen Testfällen auszuführen (Listing 2).

In der Notation des Beispiels ermöglicht die Einrückung, einen Testfall fortzusetzen oder einen neuen zu beginnen.

Listing 2: Skript mit zwei parallel ausführbaren abstrakten Testfällen

Modellschritte sind unabhängig von der Implementierung und sehr kompakt. Sie sollten nur die nötigsten Informationen enthalten, die der Tester für die manuelle Ausführung braucht. Auf diese Weise bleibt das Modell kompakt und kann leichter verstanden und gereviewt werden.

Phase 2: Konkrete Testfälle generieren

Die nächste Phase ist die Generierung der auszuführenden Testskripte. Dies kann durch manuelle Ausführung der abstrakten Testfälle erfolgen. Während der Ausführung generiert das MBT-Werkzeug ein konkretes Modell on the fly, siehe Abbildung 1.

Abb. 1: Während der Ausführung eines abstrakten Testschritts „Artikel so hinzufügen, dass der Preis unter 10 bleibt“ wird ein konkretes Modell generiert

Der Tester führt die aktuellen Aktionen oder Antworten des abstrakten Testfalls aus, hier „Artikel hinzufügen, damit der Preis unter 10 bleibt“.

Hier ist das konkrete Modell für die Realisierung eine Gherkin-ähnliche Beschreibung, kann aber auch etwas anderes sein. Betrachten wir den ersten Schritt:

Selektor

„Go shopping“ ist der Selektor, der das Go shopping UI-Element identifiziert, und „#pressed“ bedeutet einen Klick darauf. Die Validierung der erwarteten Ergebnisse ist etwas schwieriger, da der Tester den Validierungstyp oder das -ergebnis selbst auswählen muss. Um zum Beispiel zu überprüfen, ob die Schaltfläche „Bezahlen“ inaktiv ist, kann der Tester zuerst die Schaltfläche „Bezahlen“ auswählen, dann aus der angebotenen Liste auswählen, dass es sich um eine Validierung handelt (THEN), und schließlich das erwartete Ergebnis #non-active wählen, siehe Abbildung 2.

Abb. 2: Der Tester erfasst in der GUI des Werkzeugs das erwartete Ergebnis, dass der Button „Pay“ inaktiv ist

Auf diese Weise können Tester ganz einfach ein konkretes Modell erstellen, das alle Informationen für die Testskriptgenerierung enthält. Ein Werkzeug kann Testskripte für jede Programmiersprache und jeden Test Runner generieren.

Schlussfolgerung

Modellbasiertes Testen in zwei Phasen ist ein neuer Ansatz der Testautomatisierung, der nicht nur effizient automatisiert, sondern auch gut in das ISTQB-Framework des Testprozesses [GTB-b] und der Testautomatisierung [GTB-d] passt.

Die Tester können die Tests auf der abstrakten Ebene analysieren und Modelle erstellen, aus denen die abstrakten Testfälle generiert werden. Das ist keine leichte Aufgabe, vor allem wenn zustandsbasiertes Verhalten involviert ist. Aber die Analyse ist der kreative Teil des Testens, der Spaß macht und zu einer höheren Codequalität führt.

Ein klarer Vorteil des modellbasierten Testens in zwei Phasen ist, dass es sich um eine DRY-Testlösung handelt. Das bedeutet, dass einige Testschritte in mehreren Testfällen vorkommen können, der Tester muss sie aber nur einmal realisieren (manuell ausführen und das Skript generieren lassen). Beim zweiten Auftreten desselben Schrittes wird dieser vom Werkzeug automatisiert ausgeführt.

Die zweite Phase der Testrealisierung nutzt die Technologie der Automatisierung ohne manuelles Skripten.

Die Zwei-Phasen-Modellierung ist damit eine echte Shift-left-Lösung, die für zustandsabhängige und zustandslose Fälle verwendet werden kann. Sie ist auch eine effiziente Methode zur Fehlervermeidung. Die Testautomatisierung wird auf diese Weise nicht nur schnell, sondern auch sehr komfortabel, da die Tester die Ergebnisse nicht im Voraus berechnen müssen, sondern sie einfach nur überprüfen können, was viel einfacher ist. Schließlich ist diese Methode für Tester geeignet, da sie zwar einen Testentwurf, aber keine Programmierkenntnisse erfordert.