Seite 2: Beispiele

Inhaltsverzeichnis

Praxisbeispiele zeigen das Potenzial

Die möglichen KDT-Einsatzszenarien sind vielfältig. Ein erstes Beispiel zeigt die Verwendung bei der Testfalldefinition, die sich durch wenige Keywords auszeichnet und sowohl für manuelle als auch automatische Tests nutzen lässt. Der Einsatz bei der Testfalldefinition beginnt häufig mit der Einführung formaler Vorgaben zur Definition manueller oder auch automatischer Testabläufe, zum Beispiel durch die Fachabteilung.

Abschnitt	Aktion	Daten	Ergebnis und Fehler-/Erfolgs-Konditionen
Einloggen
	Eingabe Nutzerkennung	Testuser-264B
	Eingabe "Passwort"	<siehe anbei: Login-Info.xls>
	Abwahl "Eingeloggt bleiben"
	Klick auf "Anmelden"		Login erfolgreich
Neuen Bestellvorgang starten
	Menü-Auswahl "Vorgänge | Bestellungen | Neu"		– Maske für neuen Bestellvorgang erscheint – Keine Fehlermeldung "Anlegen von Bestellvorgängen für diesen Nutzer nicht erlaubt"
	Fallunterscheidung Nachricht "Vorheriger Vorgang noch nicht abgeschlossen" erscheint
Fall: Abbrechen von altem Bestellvorgang	Fall: Nachricht erscheint und alter Bestellvorgang wird angezeigt
	Menü-Auswahl "Element | Abbrechen"		Bestätigungs-Dialog erscheint "Sind sie sicher?"
	Klick auf "Ja"		Dialog verschwindet und leere Maske für neuen Bestellvorgang erscheint
	Ende Fallunterscheidung
Neuer Vorgang – Schritt 1	Eingabe "Bestelltitel"	Testbestellung_<aktuelles Datum und Zeit>
	<etc.>

KDT bei der Testfalldefinition: ein Anwendungsbeispiel (Quelle: Micro Focus)

Diese Definition ist zumeist (noch) nicht auf Maschinenlesbarkeit ausgelegt, sondern für die bessere Verständlichkeit und bessere Wiederverwendbarkeit gedacht. Zumeist ist das einfach und pragmatisch umgesetzt – mit einer Reihe fest vorgegebener Aktionswörter und Regeln, die die maximale Länge von Aktionszeilen festlegen, sowie einem Template für das Format; zum Beispiel kann nur Excel erlaubt sein. Beispiele für solche Aktionswörter sind:

• Eingabe – für Textfelder;
• Klick auf/Rechts-Klick auf – für Buttons und Werkzeugleistenelemente;
• Menü-Auswahl – für normale Menüs und Popup-Menüs;
• Anwahl/Abwahl/alleinige Auswahl – Optionsfelder, Listen und Mehrfachauswahlen;
• Fallunterscheidung/Fall/Ende Fallunterscheidung – konditionale Testabläufe.

Da die Testfall-Definitionen nicht automatisiert interpretiert werden, ist kein Zwang vorhanden, die definierten Aktionswörter mit einer hundertprozentigen Zuverlässigkeit und Vollständigkeit für alle Testsituationen zu entwickeln. Wenn in fünf Prozent aller Schritte die definierten Aktionen nicht ausreichen, ist immer noch ein "Rückfall" auf die natürlichsprachliche Definition möglich – ohne dass dabei der grundsätzliche Ansatz beeinträchtigt wird.

Obwohl diese KDT-Form fast trivial erscheint, ist ihr Nutzen vor allem bei einer großen Anzahl von Tests und einer langen Lebensdauer von individuellen Testfällen nicht zu unterschätzen. Einfache weitere Verfeinerungen können zum Beispiel den Umgang mit Varianten und verschiedenen Eingabedaten (Data-Driven Testing) abdecken. Um eine Erhöhung der Komplexität zu vermeiden, wird das im Allgemeinen nicht durch zusätzliche Aktionswörter realisiert, sondern beispielsweise durch das Verwenden mehrerer Arbeitsblätter in einer Excel-Datei.

Gerade bei manuellen Tests wird die KDT-Beschreibung häufig durch natürlichsprachliche Zusatzangaben zum Umgang mit Testdaten angereichert. Dabei ist jedoch strikt darauf zu achten, dass keinerlei Testlogik in diese Datendefinition eingebettet wird. Der gesamte Testfall an sich darf nur in der KDT-Form definiert werden.

Funktionale Automatisierung mit semantischem KDT

Ein zweites Beispiel ist die funktionale Automatisierung mit semantischem KDT, bei der ebenfalls nur wenige Keywords benötigt werden. Semantisches KDT ist einerseits am leichtesten zu erklären, jedoch zugleich auch am anspruchsvollsten in der praktischen Umsetzung. Es handelt sich um eine Weiterentwicklung des oben beschriebenen Verfahrens für manuelles KDT hin zur Testautomatisierung.

Keyword	CRM-Login einfach
Typ	Low-Level
Eingabe-Parameter	Username Passwort Eingeloggt bleiben
Ausgabe-Parameter
Erfordert Zustand	NICHT CRM eingeloggt
Erzeugt Zustand	CRM eingeloggt
Führt Login in CRM durch. Bei Fehler Abbruch des Tests.

Keyword	CRM-Start-und-Login
Typ	Mid-Level
Eingabe-Parameter	Username Passwort
Ausgabe-Parameter
Erfordert Zustand
Erzeugt Zustand	CRM eingeloggt
Bricht alle Aktionen ab, falls CRM schon läuft (Low-Level "CRM-Zurück-zu-Hauptmaske"). Startet CRM, falls App nicht schon läuft (Low-Level "CRM-Start"). Loggt aus, falls andere Nutzer schon eingeloggt sind (Low-Level "CRM-Logout"). Login mit angegebenen Daten (Low-Level "CRM-Login-Einfach").

Keyword	Ende-zu-Ende_Bestellung
Typ	High-Level
Eingabe-Parameter	Pfad auf Excel mit Testdaten
Ausgabe-Parameter
Erfordert Zustand
Erzeugt Zustand
Kunden-Login zu Webshop (Mid-Level "Webshop-Start-und-Login") Erzeugt Kunden-Bestellung für bestehenden Kunden (High-Level "Webshop-Neue Bestellung") Mitarbeiter-Login zu CRM (Mid-Level "CRM-Start-und-Login") Neue Bestellung zur Lieferung freigegeben (High-Level "CRM-Neue-Bestellung-prüfen-und-ausliefern") Kunde überprüft Bestellstatus (Mid-Level "Webshop-Lieferstatus prüfen") Kunden-Logout (Mid-Level "Webshop-Logout-und-Beenden") Mitarbeiter-Logout (Mid-Level "CRM-Logout-und-Beenden")

Funktionale Testautomatisierung mit KDT-Ansatz und Low-Level-, Mid-Level- und High-Level-Keywords im Kontext einer Kundenbestellung (Quelle: Micro Focus)

Hierbei steht eine möglichst kleine Menge fest vorgegebener Keywords zur Verfügung. "Eingabe" hat beispielsweise die Aufgabe, einen Wert in ein per Feldnamen angegebenes Textfeld einzugeben. Dabei wird der technische Aspekt der Automatisierung möglichst komplett abstrahiert, wie einige Beispiele zeigen:

• Es kann sich um eine beliebige Anwendung handeln: Browser, Java, .NET etc.
• Das Textfeld wird möglichst anhand sichtbarer Kriterien identifiziert – interne technische IDs werden vermieden.
• Es kann sich um ein einzeiliges Textfeld, eine Combobox, ein Memofeld, ein Feld mit formatiertem Rich Text oder Ähnliches handeln.
• Das Feld kann außerhalb des aktuell sichtbaren Bereichs liegen.

Zusätzlich sollte die Behandlung behebbarer Fehler wie nicht vorhersagbar erscheinenden Popup-Fenstern umsetzbar sein, ohne dabei die semantischen KDT-Skripte unnötig mit diesen Details zu belasten.

Schließlich soll sich ein automatisiertes semantisches KDT-Skript genauso einfach und übersichtlich gestalten lassen wie eine manuelle KDT-Definition. Daraus ergibt sich der wichtigste Vorteil dieses Verfahrens – nichttechnische Nutzer können ohne Unterstützung der Test-IT eigene Testautomatisierungen erstellen und modifizieren. Wenn ihnen das beschriebene manuelle KDT-Verfahren vertraut ist, ist hierfür auch kaum ein Lernaufwand nötig.

Trotz der logischen Ähnlichkeit unterscheiden sich beide Ansätze deutlich, vor allem im Hinblick auf die verwendeten Werkzeuge. Allerdings lassen sich die Inhalte manueller KDT-Definitionen meist gut wiederverwenden und bedürfen lediglich zusätzlicher Ergänzungen wie der Fehlerbehandlung oder dem Ersetzen der fünf Prozent natürlichsprachlicher Definitionen.

Die Herausforderungen bei diesem Testverfahren liegen vor allem in der möglichst technikunabhängigen Automatisierung sowie in der Umsetzung von komplexer Logik, Gültigkeitsprüfungen und Berechnungen. In der Praxis werden beide Punkte absichtlich nicht zu 100 Prozent erreicht – der Aufwand wäre zu hoch bei einem zu geringen effektiven Nutzen. So sind die semantischen Keywords typischerweise ausreichend intelligent, um alle beim Kunden zu testenden Applikationen automatisieren zu können. Kommt jedoch beispielsweise eine neue Anwendung hinzu, die auf einem komplett anderen Darstellungs-Framework aufbaut, sind die Keywords in der Regel hierfür anzupassen.

Zu beachten ist auch, dass eine vollständig generische Umsetzbarkeit beliebig komplexer Berechnungen und Prüfungen nicht von Vorteil ist – die hierfür nötigen Formeleditoren wären für nichttechnische Nutzer nur schwer verwendbar. Anstelle dessen wird für solche Situationen zumeist die Test-IT eingebunden, die eine solche komplexe Logik dann als nichtsemantische, situationsspezifische Keywords umsetzt. Solange dieses Vorgehen die Ausnahme bleibt, ist dieser pragmatische Ansatz nicht von Nachteil.