Testfallverwaltung

Die Testfallverwaltungssicht stellt die zentrale Oberfläche zur Strukturierung und Verwaltung bestehender Testfälle bzw. zur Anlage neuer Testfälle dar.

Diese Sicht öffnet man über den Navigationsmenü-Punkt „Test Cases“ (s. Abb. 1 1).

Die Testfallverwaltungssicht zeigt tabellarisch alle verfügbaren Testfälle an 2 und bietet folgende Interaktions-Tasten an:

3 „Add“ Taste zur Erstellung eines neuen Testfalls

4 „Edit“ Taste zum Bearbeiten des ausgewählten Testfalls in „Test Case Designer“

5 „Clone“ Taste zum Klonen des ausgewählten Testfalls

6 „Delete“ Taste zum Löschen des ausgewählten Testfalls

7 „Run“ Taste zum Ausführen des ausgewählten Testfalls

Test Case Designer

Überblick über Test Case Designer

Der SimplyTest Test Case Designer ist ein wichtiger Baustein der TestOrbit-Plattform zur visuellen Definition und Automatisierung eines Testfalls ohne Programmierkenntnisse.

Man gelangt zum „Test Case Designer“ über mehrere Interaktionspfade:

• Durch Klick auf die „Add“ Taste in der Testfall Verwaltungssicht
• Durch Klick auf die „Edit“ Taste in der Testfall Verwaltungssicht
• Durch Anklicken der „Link“ Taste des aufgelisteten Testfalls auf der „Test Results“ Seite
• Durch Anklicken der „Link“ Taste des aufgelisteten Testfalls im „Execution Suite Editor“

Bevor die einzelnen Funktionalitäten des Test Case Designers beschrieben werden, stellt die nachfolgende Liste die wichtigsten Bereiche des Designers vor (s. Abb. 2).

1 Test Case Details: Bereich zur Eingabe allg. Testfall-Eigenschaften, wie. z.B. Testfall Name und Beschreibung, aber auch Testdaten

2 Test Steps: Liste aller fachlichen Testschritte, die das zu testende Szenario abbilden. Jeder Testfall besteht aus 1 bis n Testschritten.

3 Test Step Details: Bereich zur Eingabe allg. Testschritt-Eigenschaften, wie. z.B. Testschritt Name und Beschreibung, aber auch testschritt-spezifischer Testdaten

4 Automation Commands: Liste aller technischen Schritte (Automation Commands), die einen fachlichen Schritt abbilden und so den Automatisierungsablauf umsetzen. Jeder fachliche Testschritt besteht aus 1 bis n Automation Commands.

5 Test Case Toolbar: Leiste mit allgemeinen Tasten zum Speichern der Änderungen am Testfall und Verlassen des Test Case Designer.

Testfall Eigenschaften

Der Bereich zur Verwaltung der Testfall-Eigenschaften (s. Abb. 2 1) enthält nur wenige Felder:

• Name: Dieses Feld enthält den fachlichen Namens des Testfalls, der in Berichten und vielen anderen Stellen verwendet wird. Es wird dringend empfohlen, eindeutige und nachvollziehbare Namen für die Testfälle einzutragen, und zwar am besten gleich beim Anlegen eines neuen Testfalls.
• Description: Feld zur ausführlichen Beschreibung des Zwecks des Testfalls
• Input Parameters: Bereich zur Definition der Testdaten, die allen Testschritten des Testfalls zur Verfügung stehen. Die Verwaltung dieser Testdaten wird im folgenden Kapitel näher erläutert.

Testdaten und Eingabeparameter verwalten

Die Testdaten auf Ebene eines Testfalls (im Bereich Testfall-Eigenschaften) stehen allen Testschritten des Testfalls zur Verfügung.

Der Anwender hat die Möglichkeit auf 2 verschiedene Arten die Testdaten und Testparameter zu spezifizieren (s. Abb. 3):

1 Der „Internal Test Data“ Tab-Reiter verwaltet die Testdaten, die explizit in einem Testfall angelegt werden. Für andere Testfälle sind diese Testdaten unsichtbar.

2 Der „External Test Data“ Tab-Reiter ermöglicht die Verwaltung der Testdaten, die von außen über externe Quellen, wie. z.B. Excel Dateien, referenziert werden. Diese externen Datenquellen können natürlich in mehreren Testfällen zum Einsatz kommen.

Durch Klick auf die „Add“ Taste 3, die in beiden Tab-Reitern zur Verfügung steht, fügt man neue Testdaten mittels eines eingeblendeten Wizards hinzu.

---

Der Wizard zum Einfügen interner Testdaten sieht wie folgt aus (s. Abb. 4):

1 Im Feld „Name“ wird die logische Bezeichnung der Testdatenvariable eingetragen, die später an vielen Stellen im Testfall verwendet werden kann. Daher sollte man auch hier eine kompakte aber verständliche Bezeichnung wählen.

2 Im Feld „Value“ wird explizit der Wert dieser Testdatenvariable eingetragen, der bei der Testdurchführung verwendet wird.

---

Der Wizard zum Einfügen externer Testdaten sieht wie folgt aus (s. Abb. 5):

1 Im ersten Schritt wird die Art der Datenquelle für externe Testdaten ausgewählt. Zurzeit steht nur Microsoft Excel zur Verfügung (mit Unterstützung von XLS und XLSX Datenformaten).

2 Im zweiten Schritt gibt man den Ort/Pfad zur gewählten Datenquelle an. Im Fall von Excel wählt man den Pfad zur Excel Datei aus, die man durch Klick auf die „Upload“ Taste 3 auswählt und in einem isolierten Verzeichnis auf den Server hochlädt. Dadurch kann die Testdurchführung später auch auf Systemen erfolgen, die keinen Zugriff auf die ursprüngliche Datenquelle haben.

4 Durch die „Apply“ Taste wird die Referenz auf die auf den Server hochgeladene Datenquelle zum Testfall hinzugefügt.

---

Sobald mindestens eine interne oder externe Testdatenquelle hinzugefügt wurde, sieht man in der eingeblendeten Übersichts-Liste (s. Abb. 6 1) die Kurzinformationen 2 darüber und kann außerdem folgende Verwaltungsoperationen ausführen:

3 Die „Show Data“ Taste zeigt die über externe Datenquelle referenzierten Datenmengen in einer Tabelle 7 an (nur für externe Testdaten verfügbar).

4 Die „Reload Data“ Taste lädt die über externe Datenquelle referenzierten Datenmengen erneut (nur für externe Testdaten verfügbar).

5 Die „Edit“ Taste zur Bearbeitung des ausgewählten Testdaten-Eintrags

6 Die „Delete“ Taste zum Löschen des ausgewählten Testdaten-Eintrags

Testschritte einfügen und bearbeiten

Wie bereits in der Übersicht kurz erwähnt, besteht jeder Testfall aus einem oder mehreren Schritten. Ein Testschritt ist dabei ein zentraler Bestandteil eines Testfalls, der den logischen und fachlichen Teil des Testfall-Ablaufs abbildet.

Die Liste aller Testfallschritte wird im Bereich Test Steps (s. Abb. 7 2) angezeigt.

Dieser Bereich stellt folgende Interaktionsmöglichkeiten zur Verfügung:

2 Die „Add“ Taste fügt einen neuen Testschritt zum Testfall hinzu (am Ende der Liste)

3 Die „Import“ Taste fügt einen neuen Testschritt aus einer Testschritt-Bibliothek als eine Referenz hinzu (am Ende der Liste)

4 Die „Clone“ Taste erstellt einen Klon des ausgewählten Testschrittes und fügt diesen unterhalb dieses Schrittes in die Liste ein

5 Die „Clone“ Taste löscht den ausgewählten Testschritt

6 Die „Export“ Taste exportiert den ausgewählten Testschritt in die Testschritt-Bibliothek zur Verwendung in anderen Testfällen

7 Die „Move“ Pfeiltasten zum Ändern der Reihenfolge der Testschritte in der Liste der Schritte

---

Durch Klick auf die Taste „Add“ wird ein neuer Testschritt hinzugefügt und auf der rechten Seite des Test Case Designers wird ein Wizard zur Auswahl des Types des Testschrittes angezeigt (s. Abb. 8). Der Typ des Testschrittes bestimmt die Technologie, mit der die Automation Commands dieses Testschrittes mit der zu testenden Applikation interagieren sollen. Im Wesentlichen handelt es sich um die Selektion der Automatisierungstechnologie.

Pro logischen Testschritt kann nur ein Driver ausgewählt werden, so dass alle Automation Commands eines Schrittes über die gleiche Art und Weise mit der zu testenden Applikation interagieren. Falls innerhalb eines logischen Schrittes mit mehreren Automatisierungstechnologien gearbeitet werden soll, splitten Sie den Testschritt in mehrere kleinere Testschritte auf.

Nach der Auswahl der Technologie für einen neuen Testschritt oder beim Selektieren eines existierenden Testschrittes in der Testschrittliste werden auf der rechten Seite die Details dieses Schrittes („Test Step Details“ Abb. 2 3) samt seinen Automation Commands (Abb. 2 4) angezeigt.

Der Bereich „Test Step Details“ zur Verwaltung der Testschritt-Eigenschaften (s. Abb. 2 3) enthält nur wenige Felder:

• Enabled: Mit der „Enabled“ Check-Box steuert man, ob der aktuelle Schritt aktiv ist oder deaktiviert und bei der Testdurchführung ignoriert wird.
• Name: Dieses Feld enthält den fachlichen Namen des Testschrittes, der in Berichten verwendet wird. Es wird empfohlen eindeutige und nachvollziehbare Namen für die Testschritte einzutragen, und zwar am besten gleich beim Anlegen eines neuen Testschrittes.
• Description: Feld zur ausführlichen Beschreibung des Zwecks des Testschrittes
• Input Parameters: Bereich zur Definition der Testdaten, die in diesem und ggf. auch in nachfolgenden Testschritten des Testfalls zur Verfügung stehen. Die Verwaltung dieser Testdaten erfolgt analog zur Testdatenverwaltung auf der Testfall-Ebene, mit der Ausnahme, dass aktuell nur interne Testdaten auf Ebene der Testschritte erlaubt sind.

Automatisierungskommandos erstellen und bearbeiten

Jeder Testschritt enthält eine Folge von „Automation Commands“, welche die eigentliche technische Automatisierung der einzelnen Aktionen innerhalb des logischen Schrittes umsetzen (s. Abb. 2 4). So wird z.B. ein logischer „Login“ Schritt durch die Folge „technischer“ Aktionen, wie z.B. „Benutzernamen eintragen, Passwort eintragen und Login-Taste anklicken“, abgebildet. Jede dieser Aktionen stellt ein Automatisierungskommando dar und wird in sequenzieller Reihenfolge ausgeführt.

Eine komprimierte Liste aller Automation Commands (s. Abb. 9 1) eines Testfalls wird durch Klick auf die „Collapse“ Taste 3 dargestellt.

Durch Klick auf die „Expand“ Taste 4 werden alle Automation Commands mit ihren technischen Details angezeigt.

Um die Details nur eines Kommandos einzublenden, klickt man auf dessen „Expand“ Taste 5.

Mit der „Add“ Taste 2 erstellt man ein neues Automation Command und fügt es zur Liste hinzu.

Nach dem Anlegen eines neuen logischen Testschrittes wird automatisch das erste Kommando, gemäß der ausgewählten Automation Technologie, zum Testschritt hinzugefügt.

Die Details eines Automation Commands werden mittels eines speziellen Editors bereitgestellt (s. Abb. 10), der immer unterschiedliche Eigenschaften zur Gestaltung der Automatisierung in Abhängigkeit der gewählten Technologie anbietet. Die verschiedenen „Automation Command Editoren“ zur Automatisierung der SuTs unterschiedlicher Technologien werden ausführlich im Abschnitt „Driver Dokumentation“ behandelt.

Der in der Abb. 10. dargestellte „Automation Command Editor“ für die Automatisierung der Weboberflächen bietet z.B. die Felder zur Auswahl der UI Aktion 1 (hier Eingabe von Text) und des Ziel-Objektes auf der Web-Oberfläche mittels eines UI Identifiers 2 sowie den einzutragenden Wert 3.

Unabhängig von der Automatisierungs-Technologie bietet jeder Automation Command Editor stets die allgemeinen Aktionen zur Verwaltung der Commands an, wie z.B:

4 Die „Clone“ Taste zum Duplizieren des ausgewählten Kommandos

5 Die „Delete“ Taste zum Löschen des ausgewählten Kommandos

6 Die „Move“ Pfeiltasten zum Ändern der Reihenfolge der Kommandos innerhalb des Testschrittes

Um die Automation Command Editoren dennoch möglichst einheitlich bereitzustellen, werden die in diesen Editoren bereitgestellten Masken mittels Tab-Reiter strukturiert. Dabei gibt es einerseits Masken und Bereiche, die in allen Editoren verfügbar sind und anderseits auch spezifische Eigenschaften, die naturgemäß nur für bestimmte Technologien relevant sind.

So besitzt üblicherweise jeder Automation Command Editor Typ die Tab-Reiter „Basic“, „Advanced“ und „Extras“, die in den folgenden Kapiteln vorgestellt werden.

„Basic“ Tab-Reiter

Innerhalb des Tab-Reiters „Basic“ werden üblicherweise in allen Automation Command Editoren die für die gewählte Automatisierungstechnologie wichtigsten und relevantesten (und damit auch spezifischen) Masken bereitgestellt.

„Advanced“ Tab-Reiter

Innerhalb des Tab-Reiters „Advanced“ werden in allen Automation Command Editoren die allgemeinen Editoren zur Verwaltung von Eingabe- und Ausgabe-Parametern sowie zur Definition von Assertions angeboten (s. Abb. 11). Diese Editoren werden in den nachfolgenden Unterkapiteln näher beschrieben.

Außerdem können manche Automatisierungs-Driver in Advanced Tab-Reiter weitere, für die Definition der Automatisierung relevante, Masken anbieten, die jedoch im Unterschied zu Basic-Feldern entweder seltener verwendet werden oder fortgeschrittene Möglichkeiten bereitstellen. Diese driver-spezifischen advanced Felder werden im Abschnitt „Driver Dokumentation“ näher vorgestellt.

Eingabeparameter der Automation Command

Auch auf der Ebene der Automation Commands lassen sich Testdaten via „Input Parameter Editor“ definieren.

Zum Anlegen neuer Testdaten klickt man auf die Taste „Add“ (s. Abb. 11 1), worauf sich der bereits bekannte „Input Parameter Editor“ öffnet (s. Abb. 12).

1 Im Feld „Name“ wird die logische Bezeichnung der Testdatenvariable eingetragen, die beim Zugriff bzw. bei der Referenzierung des Parameters verwendet wird.

2 Im Feld „Value“ wird explizit der Wert der Testdatenvariable eingetragen, der bei der Testdurchführung verwendet wird.

3 In Unterschied zu internen Testparametern auf der Testfall Ebene, kann man die Sichtbarkeit der Testparameter auf der Command Ebene nur auf das aktuelle Kommando einschränken, so dass diese Parameter nicht in nachfolgenden Kommandos dieser oder folgender Testschritte sichtbar sind. Das erfolgt durch das Setzen des Feldes „Visibility“ auf den Wert „Private“.

4 Mit der „Apply“ Taste speichert man die Definition des Testdaten-Eingabeparameters.

Assertions definieren

Nach der Ausführung eines Automatisierungskommandos möchte man häufig die Korrektheit der Ausführung Validieren, z.B. durch die Überprüfung des Ergebnisses der Ausführung.

Zu diesem Zweck bietet TestOrbit die Möglichkeit an, für jedes Automation Command eine oder mehrere Assertions zur Validierung zu definieren.

Zum Anlegen neuer Assertions klickt man auf die Taste „Add“ (s. Abb. 11 2), worauf sich ein „Assertion Wizard“ öffnet (s. Abb. 13), der den Anwender bei der Definition einer Assertion über mehrere Wizard-Schritte unterstützt.

Im ersten Schritt werden folgende Eingabefelder angeboten:

1 Über die Checkbox „Negation“ steuert man, ob die Assertion-Prüfung negiert werden soll oder nicht.

2 Im Feld „Expected Value“ wird das erwartete Ergebnis, das bei der Prüfung herauskommen soll, angegeben.

3 Im Feld „Assertion Message“ wird eine Meldung angegeben, die im Fehlerfall protokolliert werden soll.

4 Durch den Klick auf die Taste „Next“ gelangt man zum nächsten Schritt.

Im 2. Wizard-Schritt wird ein Verfahren für die Extraktion der Ergebnisse der Kommandodurchführung ausgewählt (s. Abb. 14).

Es stehen spezielle Methoden zur Extraktion der Ergebnisfragmente auf einem Roh-Text, aus einer Tabelle, oder aus einer JSON Struktur zur Verfügung. Die Entscheidung hängt von dem Format des Ergebnisses ab, das die zu testende Applikation zurückliefert. Bei Unsicherheiten kontaktieren Sie die Entwickler der betroffenen Applikation.

Nach der Auswahl der Extraktionsmethode gelangt man zum letzten Wizard Schritt (s. Abb. 15), in dem zuerst eine für das gewählte Extraktionsverfahren spezifische Variante selektiert werden muss.

Anschließend werden die Felder eingeblendet, die zur Spezifikation dieser Extraktionsregel benötigt werden. Hier wird z.T. auf technischer Ebene spezifiziert, wie die Extraktion der Daten aus dem Ergebnis der Kommandoverarbeitung erfolgen soll (s. Abb 15).

Zum Speichern der Assertion Definition klickt man auf die Taste „Apply“, woraufhin sich der „Assertion Wizard“ schließt und die neue Assertion in einer Liste angezeigt wird (s. Abb.16). Diese Liste bietet eine kurze Zusammenfassung der Assertion-Definition 1 an und stellt außerdem die allgemeinen Operationen zum Editieren 2 und Löschen 3 der Assertion bereit.

Ausgabeparameter definieren

Nach der Ausführung eines Automatisierungskommandos möchte man häufig das Ergebnis der Ausführung oder dessen Fragment extrahieren und in einer „Output“ Variable zur Weiterverwendung in Folgeschritten speichern.

Zu diesem Zweck bietet TestOrbit die Möglichkeit an, für jedes Automation Command eine oder mehrere Ausgabeparameter zu definieren.

Zum Anlegen eines neuen „Output Parameter“ klickt man auf die Taste „Add“ (s. Abb. 11 3), worauf sich ein „Output Parameter Wizard“ öffnet (s. Abb. 17), der den Anwender bei der Definition eines neuen Output Parameters über mehrere Wizard-Schritte unterstützt.

Im ersten Schritt werden folgende Eingabefelder angeboten:

1 Im Feld „Name“ wird die logische Bezeichnung der Ausgabevariable eingetragen, über die in späteren Schritten auf den Wert der Variable zugegriffen werden soll.

2 Durch den Klick auf die Taste „Next“ gelangt man zum nächsten Schritt.

Im 2. Wizard-Schritt wird ein Verfahren für die Extraktion der Ergebnisse der Kommandodurchführung ausgewählt, genauso wie im Assertion Wizard (s. Abb. 14)

Nach der Auswahl der Extraktionsmethode gelangt man zum letzten Wizard Schritt, in dem zuerst eine für das gewählte Extraktionsverfahren spezifische Variante selektiert werden muss.

Anschließend werden die Felder eingeblendet, die zur Spezifikation dieser Extraktionsregel benötigt werden, genauso wie im Assertion Wizard (s. Abb. 15)

Zum Speichern der Output Parameter Definition klickt man auf die Taste „Apply“, woraufhin sich der „Output Parameter Wizard“ schließt und der neue Ausgabeparameter in einer Liste angezeigt wird, analog zu der Liste der Assertions, mit den gleichen Verwaltungsaktionen (s. Abb.16).

Extraction Rules Übersicht

Da die gemeinsamen Extraktionsmethoden und Regeln sowohl bei der Definition von Assertions als auch Ausgabeparametern eine zentrale Rolle spielen, werden sie an dieser Stelle detaillierter vorgestellt.

„Data Table Rule“

Die „Data Table Rule“ wird für die Extraktion der Daten aus einer Ergebnis-Tabelle eingesetzt. Dabei ermöglicht diese Extraktion den Zugriff auf eine spezifische Zelle der Tabelle, die mit folgenden Varianten spezifiziert wird.

• Variante „By Column Name“ (s. Abb. 18 1)

2 Im Feld „Row Index“ wird die Position der Zeile (0-basiert) angegeben, aus der die Daten extrahiert werden sollen.

3 Im Feld „Column Name“ wird der Name der Spalte angegeben, aus der die Daten extrahiert werden sollen.

• Variante „By Column Index“ (s. Abb. 19 1)

2 Im Feld „Row Index“ wird die Position der Zeile (0-basiert) angegeben, aus der die Daten extrahiert werden sollen.

3 Im Feld „Column Index“ wird die Position der Spalte (0-basiert) angegeben, aus der die Daten extrahiert werden sollen.

„JSON Extraction Rule“

Die „JSON Extraction Rule“ wird für die Extraktion der Daten aus einem Ergebnis im JSON Format eingesetzt. Dabei ermöglicht diese Extraktion den Zugriff auf die einzelnen Objekte und deren Werte innerhalb des JSON-Objektbaumes.

Der Zugriff auf die gesuchten Objektwerte wird dabei mittels eines sogenannten JSONPath Ausdrucks beschrieben. JSONPath ist ein offener Standard. Das Traversieren entlang der JSON Struktur erfolgt hierbei mit einem Punkt. Umfangreiche Infos und die Dokumentation der verfügbaren JSONPath Ausdrücke findet man hier.

Der Editor für JSON Expression Rules ist in Abb. 20 dargestellt und bietet nur ein Feld „Search Expression“ zur Eintragung des gewünschten JSONPath Ausdruckes an:

Im abgebildeten Beispiel wurde ein Extraktionsausdruck mittels JSONPath definiert, der aus einem JSON Ergebnis der Testdurchführung zum 1. Listenelement ([0]) im Ergebnis navigiert und von dort aus den Unterknoten „line_items“ selektiert, der eine Liste mit mehreren Elementen repräsentiert. Aus dieser Liste wird ebenfalls das 1. Listenelement ([0]) selektiert, indem man schlussendlich das Attribut „name“ sucht und dessen Wert als Ergebnis der JSONPath Extraktion zurückliefert.

„Regular Expression Rule“

„Regular Expression Rule“ wird für die Extraktion der Daten aus einem Text-Format eingesetzt und kann als eine generische Methode betrachtet werden die nicht-binären Ergebnis-Daten durchzusuchen und daraus ein Fragment zu extrahieren.

Die Suche erfolgt dabei mittels eines Quasi-Standards für die Suche in Texten, den sogenannten Regular Expressions. Ausführliche Informationen über die Verwendung von Regular Expressions finden Sie hier.

Der Editor für Regular Expression Rules bietet zwei Varianten an, die nachfolgend vorgestellt werden.

• Variante „By Regular Expression“ (s. Abb. 21 1)

2 Im Feld „Search Expression“ wird ein benutzerspezifischer Regular Expression Ausdruck eingegeben, der den gewünschten Text extrahieren soll.

Im abgebildeten Beispiel wurde ein Extraktionsausdruck verwendet, der ein Text-Fragment sucht, der durch „TEXTVOR“ und „TEXTNACH“ umschlossen ist.

Aus dem Testergebnis „Frank mag Eis“ würde der Ausdruck (?<=Frank ).+?(?= Eis) mag extrahieren.

Um den ganzen Inhalt des Testergebnisses zu extrahieren, genügt der Ausdruck „.*„.

• Variante „By Text Boundaries“ (s. Abb. 22 1)

Diese Variante bietet lediglich eine syntaktische Vereinfachung der generischen „By Regular Expression“ Variante an und ermöglicht eine schnelle und einfache Definition der Suchanfrage für die wichtigsten Use Cases bei der Extraktion der Ergebnisfragmente am Anfang, am Ende oder in der Mitte des Textes anhand der benachbarten, umschließenden Textfragmente.

2 Im Feld „Preceding Text“ wird ein Textfragment angegeben, das sich vor dem gesuchten Textblock befindet. Um das Ergebnis von Anfang an zu extrahieren, lässt man dieses Feld leer.

3 Im Feld „Following Text“ wird ein Textfragment angegeben, das nach dem gesuchten Textblock folgt. Um das Ergebnis bis zum Ende zu extrahieren, lässt man dieses Feld leer.

Im abgebildeten Beispiel wird aus einem Text (hier vermutlich einem Ergebnis in XML Format) ein Fragment extrahiert, welches sich zwischen beiden Textblöcken „<AddResult“> und „</AddResult“> befindet.

„Text Extraction Rule“

„Text Extraction Rule“ setzen auf „Regular Expression Rule“ auf und ermöglichen ebenfalls eine Extraktion der Daten aus einem Text-Format mittels eines benutzerspezifischen Regex Ausdrucks. In den meisten Fällen werden „Text Extraction Rules“ in Zusammenhang mit Assertions eingesetzt, um zu prüfen, ob ein bestimmter Text in dem Ergebnis vorkommt.

Der Editor für „Text Extraction Rules“ ist in Abb. 23 dargestellt und bietet nur ein Feld „Regex Search Expression“ zur Eintragung des gewünschten Regular Expression Ausdruckes an:

Im abgebildeten Beispiel will man explizit prüfen, ob das Ergebnis den Text „this text part should be present“ darstellt und trägt genau diesen Text ein. Man sieht, dass für solche verbreiteten Use Cases die Verwendung von komplexen regulären Ausdrücken gar nicht benötigt wird.

„Extras“ Tab-Reiter

Der Tab-Reiter Extras bietet besondere Attribute zur Steuerung der Testdurchführung des Kommandos an (s. Abb. 25), die nachfolgend näher erläutert werden.

Continue on Error

Mit Hilfe der Check Box „Continue on Error“ kann gesteuert werden, ob die Testdurchführung trotz fehlgeschlagener Durchführung dieses Kommandos trotzdem fortgesetzt werden soll. Damit überschreibt man das defensive Standard-Verhalten der Testdurchführung, die im Fehlerfall sofort die Testdurchführung anhält und abbricht.

Bei aktivierter „Continue on Error“ Check Box (s. Abb. 25 1) wird die Fehlerrobustheit erhöht, allerdings empfiehlt es sich diese Funktionalität in der Praxis nur für die tatsächlich unkritischen Aktionen zu aktivieren.

Capabilities

Mit „Capabilities“ wird ein mächtiges Konstrukt zur Verfügung gestellt, mit dessen Hilfe die fachlichen und technischen Anforderungen bzw. Voraussetzungen für die Durchführung eines Kommandos definiert werden. Man könnte Capabilities als eine Liste der Anforderungen an die Testumgebung betrachten. So könnte man z.B. mittels Capabilities festlegen, dass ein Schritt bzw. ein Kommando nur auf einem Rechner mit Betriebssystem „Windows 10“ ausgeführt werden kann (technische Anforderung) oder über eine gewisse „Data Node“ laufen muss (fachliche Anforderung).

Dabei stellen diese Capabilities keine festgelegten „magischen“ Ausdrücke dar, sondern können von Anwendern selbst durch beliebige „Key-Value“-Paare vorgegeben werden. Im Kapitel „Umgebungsverwaltung“ wird genauer erläutert, wie man die dazu passenden Gegenparts auf der „End Points“ Seite mit identischen „Key-Value“-Paaren konfigurieren muss.

Das Anlegen neuer Capabilities erfolgt durch Klick auf die „Add“ Taste (s. Abb. 25 2). Daraufhin öffnet sich ein einfacher „Capability Editor“ (s. Abb. 26), der folgende Eingabefelder anbietet:

1 Im Feld „Name“ wird eine frei wählbare Bezeichnung der Capability eingetragen, welche die logische Anforderung repräsentiert (z.B. „Node Type“)

2 Im Feld „Value“ wird der Wert der Anforderung an die Testumgebung eingetragen, der erfüllt sein muss, um die Testdurchführung zu starten (z.B. „Data Node“)

3 Durch Klick auf „Apply“ wird die definierte Capability gespeichert und in der Liste der Capabilites dargestellt (s. Abb. 25). Jede Capability dieser Liste kann mittels Aktionstasten „Edit“ und „Delete“ bearbeitet werden.

Wiederverwendung der Testfragmente mittels „Steps Library“

Die Testsammlungen zur Verifizierung des korrekten Verhaltens einer fachlichen Software-under-Test Komponente bestehen meistens aus einer Menge Testfälle, die viele ähnliche Schritte aufweisen und sich nur in bestimmten Verarbeitungspfaden unterscheiden. Zur Vermeidung der Definition vieler redundanter logischer Testschritte, bietet TestOrbit eine komfortable Funktionalität zur Extraktion der gleichen wiederverwendbaren Testfragmente als logische Testschritte in einer „Steps Library“ und anschließender Wiederverwendung dieser Schritte in vielen Testfällen an. Als häufiges Use Case für so einen wiederverwendbaren logischen Schritt dient z.B. die Login-Funktionalität, die in sehr vielen Testfällen einer typischen Geschäftsapplikation benötigt wird und intern aus einer Folge technischer Schritte, wie „Benutzernamen eintragen, Passwort eintragen und Login-Taste anklicken“ besteht. Genau diese einzelnen Schritte möchte man ein einziges Mal zentral verpackt als einen logischen Schritt generisch abspeichern und in vielen Tests wiederverwenden.

Diese Vorgehensweise spart nicht nur Zeit durch das Vermeiden redundanter Definitionen identischer Testschritte in mehreren Testfällen, sondern erhöht gleichzeitig die Wartbarkeit dieser Testfälle, da die Definition der gemeinsamen Schritte nur ein Mal an zentraler Stelle vorgenommen wird und bei Änderung auch nur an dieser Stelle angepasst werden muss, ohne die Korrekturen in jedem einzelnen Testfall durchzuführen.

Wiederverwendbaren Schritt in „Steps Library“ exportieren

Das Erzeugen eines wiederverwendbaren logischen Schrittes erfolgt direkt aus dem „Test Case Designer“ heraus , und zwar durch Klick auf die „Export“ Taste des gewünschten Test Steps in der Test Steps Liste (s. Abb. 7 6). Daraufhin öffnet sich ein einfacher Export Dialog (s. Abb. 27 1), in dem man bei Bedarf die automatisch aus dem Testschritt übernommene Bezeichnung 2 des wiederverwendbaren „Shared Steps“ anpassen kann.

Anschließend klickt man auf die Taste „Export“ 3, um den Schritt zu exportieren und zur „Steps Library“ hinzuzufügen.

Hinweis:

Nach dem erfolgreichen Export des Testschrittes in „Steps Library“, tauscht „Test Case Designer“ automatisch die alte lokale Version durch die Referenz auf den neuen wiederverwendbaren Schritt aus der „Shared Step Library“ aus. Das erkennt man an der grünen Hintergrundfarbe des Testschrittes (s. Abb. 28). Wichtig: Da der Testfall dadurch modifiziert wurde, muss am Schluss noch der Testfall gespeichert werden.

Wiederverwendbare Schritte in „Steps Library“ verwalten

Alle Testschritte, die man aus dem „Test Case Designer“ mittels der Export Funktionalität exportiert hat, werden zur „Steps Library“ hinzugefügt, über die man diese wiederverwendbaren Schritte einsehen und verwalten kann.

Zur „Steps Library“ gelangt man über den Navigationsmenüpunkt „Steps Library“ (s. Abb. 29).

Diese Sicht zeigt tabellarisch alle verfügbaren wiederverwendbaren Schritte 1 an und bietet folgende Interaktion-Tasten an (ähnlich wie die Testfallverwaltungssicht in Abb. 1):

2 Die „Edit“ Taste zum Bearbeiten des ausgewählten Testschrittes in „Test Case Designer“

3 Die „Clone“ Taste zum Klonen des ausgewählten Testschrittes

4 Die „Delete“ Taste zum Löschen des ausgewählten Testschrittes

5 Die „Run“ Taste zum Ausführen des ausgewählten Testschrittes

Hinweis:

Die „Run“-Funktionalität auf der „Shared Step“-Ebene kann sinnvoll sein, um schnell nur den gemeinsamen Testschritt allein zu testen, allerdings sollte an dieser Stelle beachtet werden, dass nur die Testschritte ohne generische Parameter korrekt ausgeführt werden können. Zum Testen der wiederverwendbaren Testschritte mit generischen Parametern muss weiterhin ein „Wrapper“ Testfall angelegt werden, der den benötigten „Shared Step“ importiert und die generischen Parameter über Testdaten auflöst.

Wiederverwendbaren Schritt aus „Steps Library“ importieren

Zur Wiederverwendung eines existierenden Schrittes aus der „Steps Library“ stellt der „Test Case Designer“ eine Import Funktionalität zur Verfügung, die man durch Klick auf die Import Taste im „Test Steps“ Bereich (s. Abb. 7 3) aufruft. Daraufhin öffnet sich ein einfacher Import Dialog (s. Abb. 30 1), in dem man den gewünschten wiederverwendbaren Schritt 3 auswählt.

Anschließend klickt man auf die Taste „Import“ 3, um den Schritt zu laden und zur Liste der Testschritte des aktuellen Testfalls im Test Case Designer hinzuzufügen.

Datengetriebene Tests

TestOrbit unterstützt die Definition und Durchführung datengetriebener Tests, als ein weiteres wichtiges methodisches Element, um die Anzahl redundanter Testfälle mit identischem Ablauf aber variierenden Testdaten zu reduzieren und damit die Wartbarkeit und Übersichtlichkeit der Test Suiten deutlich zu erhöhen.

Ein datengetriebener Test zeichnet sich dadurch aus, dass er über ein und denselben Ablauf mit verschiedenen Testdaten viele unterschiedliche (fachliche) Use Cases der zu testenden Applikation überprüfen kann. Es bietet sich daher an, den Testablauf nur ein einziges Mal zu definieren ( vergleichbar mit einem Template ) und die darin verwendeten variablen Ansteuerungsparameter als externe Testdatensätze zu hinterlegen. Alle Datensätze haben dabei in der Regel die gleiche Anzahl der „Spalten“, welche die verwendeten generischen Parameter abbilden und während der Testdurchführung mit den konkreten Werten ersetzen.

Typischerweise lässt sich das Model der datengetriebenen Datensätze mit folgender Datenstruktur beschreiben:

Datensatz Nummer

Parameter 1

Parameter 2

Ein Beispiel für die Testdatensätze könnte so aussehen:

0	Land	Kontinent
1	Deutschland	Europa
2	Frankreich	Europa

Die Testdaten enthalten in diesem Fall 2 Datensätze für jeweils 2 unterschiedliche Ausprägungen des Testfalls, die jeweils 2 Parameter enthalten: Land und Kontinent. Die erste Zeile beschreibt in der Regel die Anzahl und die Namen der Parameter und die nachfolgenden Zeilen die Werte für die konkreten Testfall-Instanzen. Die Testdurchführung würde den Testfall für jede dieser Instanzen von einander isoliert starten und die Parameter-Platzhalter im Testfall mit den Werten aus diesen Datensätzen zur Laufzeit auflösen, so als ob man von Anfang an 2 ähnliche Testfälle mit konkreten Werten definiert hätte.

Exakt diese Methodik wendet auch TestOrbit bei der Unterstützung von datengetriebenen Tests an und ermöglicht dem Benutzer im Test Case Designer eine externe Datenquelle mit passenden „datengetriebenen“ Datensätzen zu hinterlegen. Wie man solche externe Testdaten mittels Excel Tabellen referenziert, wurde im Kapitel „Testdaten und Eingabeparameter verwalten“ detailliert beschrieben (s. Abb. 5).

Beim Ausführen eines datengetriebenen Testfalls erkennt TestOrbit automatisch, dass es sich um einen datengetriebenen Testfall handelt und ermittelt die Anzahl der definierten Testfall-Instanzen anhand der Datensätze der externen Testdatenquelle. Für jeden Datensatz wird eine eigene unabhängige Instanz des Testfalls gestartet. Jede Instanz wird mit entsprechender „Test Data ID“ gekennzeichnet. Die konkreten Werte, die bei der Testdurchführung eingesetzt wurden, lassen sich über die Test Results Ansicht auf der Kommando-Ebene nachvollziehen.