Manueller Test Tutorial

Deutsche Version | English Version

Manuelle Tests

Eigentlich erscheint dieses Thema im Umfeld "Automatisierung" zunächst deplatziert. Dennoch gibt es viele Einsatzgebiete, in denen auch in einem automatisierten Test manuelle Schritte vorkommen (z.B. Einschalten von Geräten, Ablesen von Messwerten, Visuelle Prüfung von Oberflächen etc.)

Außerdem hilft Ihnen expecco bei der Migration: wenn Sie aktuell manuell testen und bereits über Testspezifikationen, Listen oder Tabellen verfügen, können diese in expecco importiert werden und dann als manuelle Tests definiert ablaufen.

Sie erhalten somit, wenn auch immer noch manuell durchgeführt, einerseits automatisch aussagekräftige Berichte, außerdem - und möglicherweise wichtiger noch - die Sicherheit, dass auch alle Testschritte ordnungsgemäß durchgeführt wurden.

Sie können mit expecco auch schrittweise (inkrementell) von rein manuellen, über teilautomatisierte hin zu vollautomatischen Tests migrieren, indem Sie zunächst manuell beginnen, und dann einzelne Schritte oder Testfälle durch automatisch ablaufende Aktionen ersetzen.

Somit erhalten Sie auch bei teilautomatisierten Tests eine Ersparnis, da wiederkehrende Teilvorgänge (wie Login Felder ausfüllen, Dialoge bestätigen, Formulare ausfüllen, Messwerte auslesen etc.) automatisiert schneller laufen, und somit die Testzeit reduzieren.

Wenn Sie ungeduldig sind, sollten Sie gleich zum "Schritt-für-Schritt-Tutorial" unten springen, und die Details später lesen...

Manuelle Testschritte mit automatischen Schritten kombinieren

Manuelle Schritte können beliebig in einem Diagram mit anderen kombiniert werden. Zum Beispiel könnte ein manueller Schritt eine Aufforderung an den Bediener enthalten, den Strom einzuschalten, ein Kabel zu stecken, eine visuelle Inspektion durchzuführen oder eine andere manuelle Aktion durchzuführen.

Ebenso können Teilprüfungen, die (noch) nicht automatisiert sind so erfolgen. Wenn Sie solche Teilprüfungen in separate Aktionen packen, können diese später durch vollautomatisch ablaufende Sequenzen ersetzen, ohne dass Änderungen an Testplänen oder anderen Schritten notwendig werden.

Insbesondere lassen sich solche Schritte auch in einer separaten Bibliothek halten und importieren, sodass später lediglich ein Reimportieren der Bibliothek erfolgen muss.

Der Manual Test Wizard

Wird in expecco ein manueller Testschritt ausgeführt, öffnet sich ein Dialogfenster (sog. "Manual Test Wizard"), der den Bediener führt und Hinweise zum Testablauf anzeigt.

Im Dialogfenster des Wizards haben Tester die Möglichkeit, zu jedem Schritt Kommentare, Dateien und Screenshots als Dokumentation hinzuzufügen. Die Hauptaufgabe des Testers ist es natürlich, das Resultat bzw. den Zustand des Testschrittes zu bestimmen.

Dieser kann bestanden (evtl. mit Hinweisen versehen), fehlgeschlagen oder nicht entscheidbar sein.

Der Zustand "Nicht Entscheidbar" bedeutet, dass der Testschritt nicht ausgeführt werden kann (z.B. weil ein Gerät offline ist) und daher auch nicht festgestellt werden kann, ob das getestete System funktioniert oder nicht. Solche Tests werden später im Report grau dargestellt, und müssen später wiederholt werden.

Die Oberfläche des Wizard teilt sich auf in:

1. Symbolleistenbereich
2. Informationen zum aktuellen Testschritt
3. Anweisungen zu den Testschritten

Die Symbolleiste

Die Symbolleiste enthält Funktionen, um den Testschrittstatus zu definieren, einen Kommentar zu dem jeweiligen Schritt zu editieren und um Dateien bzw. Screenshots anzuhängen.

Besondere Bedeutung haben die "Weiter" Knöpfe (Rechtspfeile); diese bestätigen den aktuellen Schritt und markieren ihn als "Erfolgreich" (grün), "Fehlgeschlagen" (rot) oder "Nicht Entscheidbar" (grau). Der gelbe Knopf markiert ebenfalls "Erfolgreich", doch fragt der Wizard nach einem Kommentar, der im Log als Warnhinweis erscheint.

Die anderen Knöpfe dienen zum Anfügen von Attachments (Messdaten) oder Screenshots.

Informationen zum aktuellen Testschritt

Dieser Bereich zeigt den Namen des aktuellen Testschritts, den Testfall, zu dem er gehört, und den aktuell laufenden Testplan. Manches davon hängt davon ab, ob die Aktion als Teil eines Testplans ausgeführt wird oder als Einzellauf (im ""Test/Demo" Tabs des Editors). Wenn Sie den Testbaustein direkt starten, hat die Ausführung keinen Testplan, und es erscheint "-". Die Blöcke müssen außerdem entsprechend als TEST-CASE und TEST-STEP getaggt, damit es funktioniert (siehe nächster Abschnitt).

Test Step vs. Test Case

Die Anzeige als Testfall oder Testschritt wird von den Etiketten (Tags) der Aktion beeinflusst (TEST-CASE oder TEST-STEP). Dieses hat zwar keinen direkten Einfluss auf die Ausführung, kann aber dem Tester nützliche Zusatzinformation zeigen (i.e. "wo befinde ich mich innerhalb des Tests").

Testfälle werden durch den Tag TEST-CASE (oder TEST_CASE) identifiziert. Einer dieser Tags sollte im Dokumentationsbereich des Testfallblocks in den Etiketten enthalten sein. Wenn Sie den Baustein über die Symbolleiste über dem Projektbaum erstellen, wird das TEST-CASE Etikett automatisch hinzugefügt. Fehlt dieser Tag, wird das Feld Testfall-Information beim Ablauf leer sein; ebenso wenn Sie einen Testschritt direkt im rechten Editor einzeln starten.

Testschritte werden mit dem Tag TEST-STEP gekennzeichnet. Dieser Tag sollte ebenfalls im Dokumentationsbereich des Prüfschrittblocks manuell hinzugefügt werden. Auch dieser Tag wird, wenn der Baustein via Toolbar des Projektbaums erstellt wird, automatisch vergeben.

Bausteine mit TEST-CASE- und TEST-STEP-Tags werden im Projektbereich von expecco mit speziellen Icon-Symbol gekennzeichnet und sind damit hervorgehoben und leichter auffindbar.

Anmerkung:
die Tags "TEST-CASE" (Bindestrich) und "TEST_CASE" (Unterstrich) werden gleich behandelt. Letztere wurden eingeführt, da manche Dritttools diese erzeugen, bzw. keine Bindestriche in Namen erlauben.
Das selbe gilt für "TEST-STEP" vs. "TEST_STEP".

Anweisungen zu denTestschritten

Im unteren Bereich des Wizards erscheint die Beschreibung des aktuellen Testschritts.

Je nachdem, wie diese ursprünglich angegeben wurde, erscheint hier entweder eine Text- oder eine HTML Ansicht, mit den im Schritt angegebenen Texten. Weitere Informationen finden Sie in der Dokumentation zur Manual TestStep API weiter unten.

Einfache textuelle Darstellung:

HTML Inhalt:

Automatisches Schließen wenn nicht mehr benötigt

Standardmäßig bleibt der Wizard geöffnet, wenn ein manueller Testschritt endet, und wartet darauf, dass der nächste manuelle Schritt ausgeführt wird.

Wenn die Checkbox Automatisch schließen wenn beendet in den Ausführungseinstellungen des Projekts gesetzt ist, bleibt der Wizard eine kurze Zeit geöffnet und schließt sich dann selbst, wenn in dieser Zeit kein neuer Schritt gestartet wird. Er öffnet sich allerdings wieder, sobald später ein weiterer Schritt gestartet wird.

Sie finden diese Einstellungen, indem Sie das Projekt auswählen (der oberste Eintrag im linken Baum) und dann zum Tab "Ausführung" wechseln. Die Checkbox befindet sich im Abschnitte "Benutzeroberfläche".

Diese Einstellung bezieht sich sowohl auf den Manual Test Wizard als auch auf das "Kontroll- und Monitor-Fenster" (zur Anzeige des UIs von GUI-Aktionen). In der Standard Library gibt es auch einen Baustein, um den Timeout für das automatische Schließen zu setzen.

Programmatisches Schließen

Die importierte Bibliothek enthält einen Baustein, um den Manual Test Wizard programmatisch zu schließen.

Manual Test Bausteinbibliothek

Manuelle Testsequenzen werden erstellt, indem die einzelnen Testschritte per drag&drop aus der Manual Test Bibliothek in ein Diagram gezogen werden.

In dieser Bibliothek finden Sie die 3 wichtigsten Bausteine um Testschritte durchzuführen, und zusätzliche Hilfsaktionen, z.B. um den Wizard zu öffnen, zu schließen, etc. Diese werden normalerweise nicht benötigt, da der Wizard bei der ersten Ausführung eines manuellen Testschritts automatisch geöffnet wird.

Es kann aber u.U. sinnvoll sein, diesen vorab oder speziell parametrisiert automatisch zu öffnen, oder auch programmatisch wieder zu minimieren oder zu schließen (z.B. um den Bildschirm nicht zu bedecken).

Weiteres finden Sie in der Bibliothek auch Beispiele mit erweiterten Dialogen, die in manuellen Testschritten gezeigt werden können (z.B. mehrfache Eingabefelder). Sie können diese auch als Vorlage für eigene Dialoge nutzen, die Sie mit dem integrierten UI-Builder definieren können.

Manual Test Wizard – Start

Diese Aktion öffnet den manuellen Test Wizard mit individuellen Voreinstellungen zu Größe, Position und Verhalten.

Fehlt dieser Schritt, wird der Wizard automatisch mit den Standardeinstellung bei der Ausführung des ersten manuellen Testschritts geöffnet.

InputPin Parameter:

• origin

definiert die linke obere Ecke des Wizards. Er kann als Punkt mit x y-Koordinaten des Bildschirms angegeben werden.

Beispiel: 20@40 bedeutet 20 Pixel von der linken Bildschirmecke und 40 Pixel von oben. Alternativ ist die Schreibweise Point x:20 y:40 möglich.

• extend:

definiert die Größe des Fensters. Sie können es mit Breiten- und Höhenangaben angeben.

Beispiel: 600@400 bedeutet 600 Pixel Fensterbreite und 400 Pixel Fensterhöhe.

• wizardWindowMode:

definiert ebenfalls die Größe des Wizardfensters; kann folgende Werte haben:

• Normal

der Wizard wird mit den Einstellungen geöffnet, wie sie oben spezifiziert wurden (oder den Standardeinstellungen)

• Minimize

der Wizard wir mit den Standard- oder spezifizierten Einstellungen geöffnet, aber direkt minimiert

• fullScreen

die Einstellungen zur Größe werden ignoriert und der Wizard wird im Vollbildmodus geöffnet

• fullHeight

öffnet den Wizard mit der spezifizierten Breite und der vollen Bildschirmhöhe

• fullWidth

öffnet den Wizard mit der spezifizierten Höhe und der vollen Bildschirmbreite

• fullWidthMinimize

öffnet den Wizard verkleinert am oberen Bildschirmrand mit der vollen Bildschirmbreite

• wizardDecorationMode:

definiert den Fensterrahmen des Wizardfensters; kann folgende Werte haben:

• full

umlaufender Windowmanager-Rahmen inklusive Leiste zum Minimieren, Maximieren und Schließen von Schaltflächen

• None

ohne Windowmanager-Rahmen, für mehr Platz auf dem Bildschirm

• Dialog

umlaufendem Windowmanager-Rahmen inklusive WindowTitle-Leiste mit Schließen-Button.

• allowInconclusive:

Buttons für "Nicht eindeutig" ein-/ausblenden. Wenn ausgeschaltet, können Testschritte nicht mehr als Inconclusive markiert werden.

Manual Test Wizard – Voreinstellungen

Das Layout des Wizard kann auch vor dem Öffnen in den Einstellungen vorgenommen werden. Mit dieser Aktion werden die Einstellungen definiert, welche beim nächsten automatischen Öffnen des Wizards gelten.

Die Parameter sind die selben wie oben in der “Manual Test Wizard – Start” Aktion beschrieben.

Manual TestStep (API)

In der Bibliothek finden Sie für verschiedene Anforderungen diverse vordefinierte Testbausteine. Die 3 wichtigsten sind im Folgenden beschrieben.

Bitte behalten Sie im Gedächtnis, dass die dargestellten Texte nicht notwendigerweise fest vordefiniert sein müssen. Sie könnten natürlich auch von einem anderen Schritt generiert werden. Z.B. könnte der Text aus einer Datenbank oder Datei gelesen werden, oder auch dynamisch aus anderen Textfragmenten zusammengesetzt werden.

Manual TestStep (Text)

Diese Aktion zeigt den Text im Wizard als einfachen (simple) Text.

Im InputPin "testStepDescription" wird der anzuzeigende Text erwartet. Die Eingabe ist reiner Text und wird entsprechend dem Textlayout im Eingabe-Editor angezeigt. Im Wizard erscheint das selbe Layout.

Manual TestStep (HTML)

Diese Aktion zeigt den Text im Wizard in einem HTML-Viewer.

Am InputPin "testStepDescription" wird ein HTML String erwartet. Dazu sind gewisse HTML-Kenntnisse erforderlich, da die Eingabe in HTML-Syntax erfolgt. Sie können aber den Text auch in einen Anhang oder in ein Dokumentations-Element im Baum legen, und z.B. den Dokumentationseditor verwenden um den HTML Text zu bearbeiten.

Hinweis: Der eingebettete HTML-Viewer unterstützt nur eine Teilmenge der HTML-Tags (z.B. wird derzeit das Style-Tag nicht unterstützt, und auch andere HTML Elemente wie Tabellen haben nicht den vollständigen Funktionsumfang).

Der HTML-Viewer zeigt den Text dann formatiert an.

Manual TestStep (SimpleWikiStyle)

Ein in Wikis beliebtes Textformat (sog. "Wikistyle") erlaubt es, auch ohne HTML Kenntnisse einfache Aufzähllisten, Überschriften etc. zu formatieren. Dazu wird der Text im Wikistyle-Format intern zur Anzeige in HTML umgewandelt und so dargestellttellt.

Der InputPin "testStepDescription" definiert den darzustellenden Text in einfacher Wiki-Syntax. Die Testbeschreibung befolgt folgende, einfache Regeln:

• Überschriften

Beginnt eine Zeile mit = wird diese als Überschrift behandelt. Unterkapitel mit '==' und '===':

= <h1>

== <h2>

=== <h3>

• Horizontale Linie

Beginnt eine Zeile mit oder enthält nur als einziges Zeichen ein "–" (minus), so wird diese als horizontale Trennlinien dargestellt:

<hr>

• Listen

Beginnt eine Zeile mit * (Stern) wird sie in eine <li> .. </li> Liste ("Bullet Liste") umgewandelt.

Alle anderen Zeilen bleiben unformatiert. Zusätzlich können Sie aber auch direkt HTML-Format Anweisungen enthalten (also z.B. "... <B>Bold Text</B> ... ").

Auch hier zeigt der HTML-Viewer den Text formatiert an.

Manual TestStep (MarkDown)

Das MarkDown-Textformat kann verwendet werden, um einen formatierten Text mit Überschriften, Aufzählungszeichen und nummerierten Listen usw. zu erstellen, ohne dass HTML erforderlich ist. Dazu wird der MarkDown-Text intern in HTML übersetzt und als solcher dargestellt.

Der Eingabepin testStepDescription erwartet den Text in Markdown-Syntax.

Folgende einfachen Formatierungen werden ausgewertet:

• Überschriften

Eine Zeile, die mit "#" beginnt, wird als Überschrift behandelt.

Die Anzahl der "#"-Zeichen bestimmen die Überschriftenebene. "###" wird interpretiert als "<h3>"

• Horizontale Linie

Eine Zeile beginnend mit "---" erzeugt eine horizontale Linie: <hr>.

• Aufzählungslisten

Eine Zeile, die mit "-", "+" oder "*" beginnt, wird in ein Element einer Aufzählungsliste umgewandelt: (<ul><li>text</li></ul>)

Verschachtelte Listen sind möglich.

• Nummerierte Listen

Eine Zeile, die mit einer Ziffer beginnt, wird ein Element einer nummerierten Liste umgewandelt: (<ol><li>text</li></ol>)

Verschachtelte Listen sind möglich.

• Erzwungener Umbruch

Eine Zeile, die mit einem "\" endet, erzwingt einen Zeilenumbruch.

• Absatz

Bei einer leeren Zeile wird ein neuer Absatz eingefügt.

• Textformattierung
  • Kursiv (*):

  *text* oder _text_: Text wird kursiv dargestellt.

  • Fett (**):

  **text** oder __text__: Text wird fett dargestellt.

  • Kursiv und fett (***):

  ***text*** oder ___text___: Text wird kursiv und fett dargestellt.

  • Code (`):

  `text`: Text wird als Code dargestellt.

Alle anderen Zeilen bleiben unformatiert, so dass Sie einfaches HTML zur Formatierung einbetten können.

Erstellen und Benutzen eigener GUI Layouts

Wenn Sie das Layout Ihrer Testschritte weiter personalisieren möchten, können Sie auch Ihr eigenes GUI erzeugen, um es mit Ihren Inhalten zu füllen. Im Ordner Sample Wizard GUIs der Bibliothek Manual Test Interface finden Sie einige Beispiele, die Sie zur Inspiration oder als Ausgangspunkt für Ihr eigenes Layout verwenden können.

Wie Sie sehen können, bestehen diese Beispiele immer aus dem Testschritt und einem GUI-Baustein. Das Herzstück des Netzwerks des Testschritts ist der Baustein MT - GUI TestStep+. Dieser Baustein übernimmt das Zusammenführen aller Teile. Der erste Eingangspin bekommt den GUI-Baustein. Die übrigen Pins sind Parameter für den Wizard und Aspekte für die GUI. Aspekte sind wie mit Namen versehene Werte; Sie können den Namen eines Aspekts in einer Komponente angeben, z.B. für den anzuzeigenden Text, und wenn der Test dann gestartet wird, wird der Wert dieses Aspekts an dieser Stelle eingefügt.

Der Baustein MT - GUI TestStep+ stellt in den oberen Pins zum einen vordefinierte Aspekte zur Verfügung (für diese gibt es auch Elementarblöcke, die entsprechende Werte ermitteln), zum anderen kann mit der variablen Pingruppe am Ende eine unbegrenzte Zahl an weiteren Aspekten hinzugefügt werden. Der Ausgangspin infoValues gibt ein Dictionary mit den Namen und Werten aller gesetzten Aspekte zurück. Das können Sie verwenden, um die Werte von Benutzereingaben aus dem GUI auszulesen.

Werfen wir also einen Blick auf die Verwendung einiger Widgets, die in den Beispielen der Bibliothek verwendet werden, und wie man diese mit GUI-Editor einrichtet.

• Label

Ein Label ist hilfreich, um einfachen Text anzuzeigen. Seine zwei wichtigsten Felder sind Label Text im Tab Basis, wo Sie einen festen Text für das Label setzen können, und Label Holder im Tab Aspekte, wo Sie einen Aspekt setzen können, der den Text für das Label enthält. In der Widget-Auswahl finden Sie das Label unter Text.

The GUI-Baustein TestStep_GUI with Expected hat oben zwei Labels, eines mit dem Text Current Test Step, der als Label Text gesetzt ist, und eines mit dem Aspekt testStepName, der als Label Holder gesetzt ist. Das zweite Label bekommt seinen Text also über den Pin testStepName von MT GUI TestStep+, wenn man das GUI damit verwendet.

• EditField und TextEditor

EditField und TextEditor können beide zur Texteingabe verwendet werden, wobei EditField für eine einzelne und TextEdit für mehrere Textzeilen geeignet ist. Deren Text wir im Modell gesetzt, das sich im Basis Tab befindet. In der Widget-Auswahl finden Sie beide unter Text'.

Schauen Sie sich den Baustein MT - TestStep with Value Input an. Dessen GUI hat ein EditField mit dem Modell theValue. Im Netzwerk sehen Sie, dass theValue am Pin UI_key[2] mit dem Wert nil definiert ist. Das bedeutet, das Feld ist zu Beginn leer und der Wert, der vom Tester im GUI gesetzt wird, kann am Ausgangspin infoValues mit dem Baustein Collection [ ElementAt ] ausgelesen werden.

Unten im GUI wird ein TextEditor für den Kommentar verwendet. Der Aspekt testSteoComment ist vordefiniert und MT - GUI TestStep+ wird sich selbst darum kümmern und den Kommentar loggen, deshalb sehen Sie davon nichts weiter im Netzwerk.

Um die Beschreibung des Testschritts anzuzeigen verwendet das GUI ebenfalls einen TextEditor, da dieser Scrollbalken anzeigt, wenn der Text mehr Platz braucht als zur Verfügung steht. Dieser textEditor wurde allerdings schreibgeschützt, eine Eigenschaft, die Sie im Tab Details finden.

• Bilder

Es gibt verschiedene Möglichkeiten Bilder zu Ihrem GUI hinzuzufügen. Sie können ein Label verwenden und über dessen Label Holder ein Bild setzen. Das eignet sich besonders für kleinere Bilder wie Icons. Für größere Bilder können Sie eine ArbitraryComponent mit einem ImageView verwenden. In der Widget-Auswahl finden Sie diese unter Embed. Es gibt davon eine Variante, die Scrollbalken verwendet, und eine ohne. Setzen Sie Ihr Bild als Modell und als View / Class ImageView, beides im Basis Tab.

Für ein Anwendungsbeispiel werfen Sie einen Blick auf MT - TestStep with Image Preview. Für diesen Testschritt sind außerdem ein paar Callbacks definiert, um das Aussehen einiger Komponenten weiter anzupassen. Es macht nichts, wenn Sie deren Verwendung nicht verstehen, sie werden nicht unbedingt benötigt.

• ProgressIndicator

Wenn Ihr manueller Test aus einer großen Anzahl an Testfällen besteht, möchten Sie vielleicht einen Fortschrittsbalken hinzufügen, um zu sehen, wie viel bereits erledigt wurde und wie viele Testfälle noch bearbeitet werden müssen. Natürlich gibt es auch andere mögliche Anwendungsfälle, aber diesen können Sie sich in MT - TestStep with Expected & TestCase Progress anschauen.

Der ProgressIndicator bekommt den Fortschritt als Modell. Optional kann auch noch ein Wert für Total (ebenfalls im Basis Tab) gesetzt werden, der sonst automatisch 100 ist. Sie können also entweder eine Prozentzahl als Modell angeben oder einen absoluten Wert und eine Gesamtzahl als Total. Im Tab Details können Sie außerdem den Haken für Show As Proportion setzten, um den Text auf dem ProgressIndicator als Menge von gesamt anstatt einer Prozentzahl anzuzeigen. Oder sie schalten Show Percentage ab, um gar keinen Text anzuzeigen.

MT - TestStep with Expected & TestCase Progress verwendet die vordefinierten Aspekte currentTestCaseIndex und numberOfTestCases als Modell und Total, welche vom Baustein TestCaseProgressInfo berechnet werden. Dieser Aufbau funktioniert nur, wenn er innerhalb eines Testplans verwendet wird; verschachtelte Testpläne funktionieren ebenfalls.

Sie finden den ProgressIndicator in der Widget-Auswahl unter Misc. Dort gibt es auch eine runde Variante, für eine Darstellung ähnlich eines Tortendiagramms.

Manual Test Beispiel (Schritt f. Schritt Tutorial)

Schritt 1: Anlegen einer neuen Testsuite

Öffnen Sie expecco und erstellen Sie eine neue Testsuite (Sie können natürlich auch in jeder anderen Suite manuelle Testschritte einfügen). Dann importieren Sie die ManualTest Bibliothek (dies geschieht auch automatisch, sobald sie einen manuellen Schritt anlegen).

Schritt 2: Anlegen eines Testfalls

Nun wird ein Testfall angelegt. Am einfachsten geht das mit den Toolbar-Menüs; hier wird dem Testfall auch automatisch ein TEST-CASE Etikett angeheftet (sog. "Tag"), und er erscheint mit seinem eigenen Icon-Symbol im Projektbaum.

Anmerkung:

in Hinblick auf die spätere Ausführung der Aktion hat das TEST-CASE Etikett keine Auswirkungen; es ist lediglich ein Etikett, welches die Darstellung im Baum beeinflusst, und es Ihnen leichter macht, Testfälle, Testschritte und Hilfsaktionen zu unterscheiden und schneller zu finden.

Weitere Darstellungsoptionen sind Farbe und spezifische Icons; diese können sie beliebig nach Ihren Wünschen definieren und zur Verbesserung der Übersichtlichkeit nutzen.

Wichtig: geben Sie dem Testfall einen sinnvollen Namen. In der Regel beginnt dieser mit einer Nummer, die sich auf die Testspezifikation oder eine Anforderung bezieht. Zusätzlich sollte der Testfall eine Kurzbeschreibung im Namen haben, damit auch Menschen wissen, was die einzelnen Testfälle machen.

Beispiel: Zum Beispiel "TC-4711 Login mit gültigen Daten".

(Anm.: es hat sich als gute Praxis erwiesen, Aktionen welche Testfälle darstellen als "TC_xxx" zu benennen, Testschritte, welche möglicherweise wiederverwendet werden als "TS_xxx". Sonstigen Hilfsaktionen sollten ihre Funktion im Namen kurz angeben.

Bitte dokumentieren Sie Ihre Aktionen auch (Registerkarte "Dokumentation"), das erleichtert eine spätere Suche, da die Dokumentation als Tooltip ("fly by help") angezeigt wird, wenn Sie die Maus über den Projektbaum oder über Schritte bewegen. Die Dokumentation (auch einzelner Pins) kann auch in Schemaansicht eingegeben werden, wenn Sie den "Doku"-Toggle oben rechts im Editor drücken.

Alternative:
Eine andere Möglichkeit ist es, eine bestehende Aktion nachträglich als Testfall auszuzeichnen, indem ihm das entsprechende Etikett gegeben wird. Klicken Sie dafür zuerst auf "Neue zusammengesetzte Aktion" Anlegen ("New Compound Action"):

navigieren dann zum Tab "Dokumentation" der Aktion und fügen den Tag "TEST-CASE" an die Tagliste an. Bestätigen sie die Änderung durch Klick auf "Übernehmen" unten im rechten Editorfenster.

Das Symbol der Aktion ändert sich nun im Projektbaum zu Testfall.

Durch Hinzufügen des Test-Case Etiketts können Sie auch später noch bereits existierende Bausteine als Testfall markieren (und so im Projektbaum darstellen lassen). Mit dem Popup-Menu des Projektbaums ist es auch möglich, mehrere Aktionen gemeinsam als Testfall zu markieren.

Schritt 3: Erstellen eines Testschrittes für einen Testfall

Navigieren Sie zum Netzwerk (Diagramm-) Tab der Testfall Aktion. Dieses ist zunächst leer, und muss mit einzelnen Schritten gefüllt werden (im Bild unten leider nicht umbenannt und immer noch "New Action").

Schritte können auf mehrere Arten eingefügt werden:

• durch Drag & Drop aus dem Projektbaum,
• durch Copy-Paste aus dem Projektbaum oder einem anderen Netzwerk
• über eine Suche in bestehenden Aktionen (Dialog), direkt im Diagram (Menu: "New Step...").
• über Anlegen einer neuen Aktionen (Dialog), direkt im Diagram (Menu: "New Action...").

Im Folgenden werden die Schritte mit dem Popup-Menü (rechte Maustaste) im Diagrammeditor des Testfalls hinzugefügt. Der Menueintrag "Neue Aktion" öffnet einen Dialog, mit dem einen neue Aktion angelegt und gleich als Testschritt eingefügt wird:

Dies öffnet ein kleines Eingabefenster.

Hier geben Sie den Namen des neuen Testschritts ein. Für die Benennung gelten die selben Regeln wie oben.

Wichtig: Wenn Sie diesen Testschritt später in verschiedenen Testfällen wiederverwenden wollen, sollte der Name nicht die Schrittnummer und die Testfallnummer enthalten. Nehmen Sie in solchen Fällen Namen wie "TS - Open Application".

Nach dem Drücken von "OK", erscheint ein Cursor, mit welchem Sie den Baustein an die gewünschte Stelle plazieren können. Drücken Sie danach "Übernehmen", um die Änderung des Editors am der Testfallaktion zu speichern.

Im Projektbaum erscheint nun auch die neu angelegte Testschrittaktion direkt unter dem Testfall.

Leider erhalten derart im Diagrammeditor angelegte Aktionen nicht automatisch das Testschritt-Etikett. Daher navigieren wir kurz zu der "TS - Anwendung öffnen" Aktion (im englischen Screenshot: "TS - Open Application"), wählen den Dokumentationstab, und fügen den Tag "TEST-STEP" zur Tag-Liste hinzu. Bestätigen Sie durch Klick auf "Übernehmen". In der aktuellen expecco 20.2 Version gibt es dafür nun einen eigenen Menüpunkt sowie eine Auswahlliste im Namensdialog.

Schritt 4: Anzeige des Manuellen Wizards im Testschritt definieren

Im folgenden werden wir definieren, was im "TS - Open Application" Schritt zu tun ist.

Bisher hatten wir noch offen gelassen, ob dies ein manueller oder automatischer Test werden soll. Dies wird jetzt definiert, indem wir einen Baustein aus der Manual Test Bibliothek hinein platzieren.

Anmerkung:

theoretisch hätte man den nun folgenden Manual Test Step auch gleich in die Testfallaktion platzieren können. Das hat aber den Nachteil, dass wir damit schon im Testfall festgelegt hätten, dass es sich um einen manuellen Test handelt, und wir später, sollten wir diesen Testfall automatisieren, dort ändern müssten.

Indem wir die manuelle Aktion in eine separate Testschrittaktion kapseln, können wir dessen Diagram später jederzeit ändern und insbesondere vollautomatisierten, ohne dass wir die Testfälle noch einmal ändern müssen. Wir erhalten dadurch also eine bessere Wartbarkeit, insbes. wenn der Schritt in mehreren Test wiederverwendet wird, werden dann später alle Tests davon profitieren, ohne dass dadurch extra Aufwand ansteht.

Es ist eine gute Praxis, Aktionen die später möglicherweise geändert werden müssen derart zu Kapseln, auch wenn es merkwürdig scheint, lediglich eine einzelne Aktion in einer zusammengesetzten Aktion zu kapseln.

Wählen Sie nun aus, wie der Baustein seine Testlauf-Information präsentieren und wie Sie diese eingeben wollen (i.e. Text/HTML/Wiki). Dafür selektieren Sie die Testschrittaktion im Projektbaum, wechseln zum Netzwerk/Diagramm Tab, und wählen im Popup menu (rechte Maustaste) den Eintrag: "New Step..."
(dismal nicht "New Action", da wir jetzt aus der Liste der verfügbaren Aktionen wählen wollen):

Im Dialogfenster können Sie einen vorhandenen Baustein auswählen. Falls Ihnen die Liste zu lang ist, können Sie die Suche einschränken; z.B. auf einzelne Bibliotheken (in unserem Fall wäre das die "Manual Test Library") oder den Namen (sie können hier z.B. "HTML"oder "Wiki" eingeben) oder auch Etiketten.

Für unser Beispiel wählen Sie die Aktion: "Manual Test Template (WikiStyle)" (die im Screenshot gezeigte Aktion ist veraltet, daher im Screenshot anders).

Mit "OK" wird der Baustein zu Ihrem Testschritt hinzugefügt.

Ein Doppelklick auf den Eingangspin "testStepDescription" wird einen Editor öffnen. Anstatt eines Doppelklicks können Sie auch mit der rechten Maustaste "Freeze as String" auswählen um den Editor zu öffnen.

Geben Sie eine Beschriftung z.B. nach den Wiki-Style-Regeln ein, welche im Wizard nachher angezeigt werden soll.

Dann drücken Sie bitte "OK". Der eingegebene Text sollte nun als Input für den ManualTestStep verbunden sein.

Drücken Sie "Übernehmen" um die Änderungen zu speichern.

Schritt 5: Testfall einzeln ausführen und Anzeige im Wizard verifizieren

Wählen sie den den Testfall im Projektbaum aus und öffnen sie den Tab "Netzwerk".

Drücken Sie den "Play"-Button in der Toolbar des Netzwerkeditors. Das Wizard-Fenster erscheint geöffnet und der Testschritt wird angezeigt:

Die Testausführung wartet nun auf Ihre Eingaben im Wizard. Wenn Sie im Wizard das grüne Play-Symbol drücken, schaltet dieser weiter und stoppt nach der Ausführung des letzten Schrittes (in diesem Fall, einem Einzeltest, gleich nach dem Ersten). Die Testausführung und der Testfall werden als "Passed" markiert (sofern Sie "grün" gedrückt haben).

Der Wizard bleibt geöffnet und kann nun von Hand geschlossen werden.

Schritt 6: Erstellen eines Testplans, und automatisches Öffnen und Schließen des Wizards

Bisher wurde der Testfall im Einzeltestmodus innerhalb des Editors gestartet. Dies ist die normale Vorgehensweise: testen Sie Ihre Aktionen immer in kleinen Abschnitten, damit Sie im Fehlerfall nicht jedes mal eine lange Kette von anderen Aktionen durchklicken müssen.

Anmerkung:

Erst dann sollten Sie Ihre Testpläne, in denen dann mehrerer Testfälle hintereinander ablaufen, in einem Gesamtlauf testen. In unserem Beispiel ist nicht mit Problemen zu rechnen; wenn Sie aber z.B GUI-Tests erstellen, sollte jeder Testfall das System (die Oberfläche) in einem Zustand hinterlassen, in dem der nächste Testfall weiter laufen kann. Typische Fehler in GUI Tests sind z.B. offen gelassene Dialoge oder Popup Fenster, falsche Selektion in Listen etc.

Daher versichern Sie sich im Einzeltest, dass solche Situationen nicht entstehen.

Erstellen eines Testplans

Wählen Sie den neuen Testplan im Projektbaum aus. Ziehen Sie dann die Aktion des Testfalls mittels Drag & Drop in die Liste der Testfälle rechts im Testplan Editor. Wie Sie bemerken, kann ein Testfall in mehreren Testplänen wiederverwendet werden. Daher ist die Position im Projektbaum irrelevant für den Testplan: Sie können den Projektbaum beliebig nach Ihren Vorstellungen organisieren, und ebenso die Listen in den Testplänen unabhängig davon beliebig sortieren.

Wenn Sie möchten, können Sie jetzt obige Schritte mehrfach wiederholen, und mehrere unterschiedliche Testfälle in den Testplan ziehen.

Definieren von Pre- und Postaktionen

Jetzt soll noch eine Aktion erstellt werden die als Pre-Aktion vor der Ausführung des Testplans ausgeführt werden soll; in unserem Fall: Start des Wizards mit definierter Grösse. Zur Erinnerung: wenn Ihnen der Wizard in seiner Defaultgrösse passend ist, brauchen sie dies nicht; wir möchten hier aber z.B. eine Fullscreen Darstellung einstellen.

Nach der Ausführung soll der Wizard in einer Post-Aktion auch wieder automatisch geschlossen werden.

Es gibt dafür mehrere mögliche Lösungen, wobei wir die dritte unten empfehlen:

• (1) Open und Close Aktionen als Testfall in die Liste im Testplan
• (2) Open als Pre-Aktion; Close als Post-Aktion (Felder finden Sie unten im Testplan Editor)
• (3) Wrapper Aktionen Definieren, eine mit nur der Open-Wizard Aktion, eine nur mit Close-Wizard, und diese als Pre/Post Aktionen definieren.

(1) ist schlecht da im Fehlerfall die Abarbeitung des Testplans abgebrochen werden könnte und dann ein Wizardfenster offen bliebe. Das ist kein Problem, wenn Sie vor dem Schirm sitzen und ihn schliessen können; jedoch wird damit eine Vollautomatisierung u.U. Probleme haben, und Fenster auf dem Schirm stehen bleiben.

(2) ist besser, da die Post-Aktion immer ausgeführt wird; auch wenn die Ausführung des Testplans abgebrochen wird.

(3) ist noch besser, da Sie nun mit der eigen definierten Post-Aktion einen Ort haben, an dem später weitere "Aufräumarbeiten" untergebracht werden können (z.B. temporäre Dateien löschen, Strom ausschalten etc.), und Sie später weniger Wartungsaufwand haben, diese in möglicherweise mehreren Testpläne nachzutragen.

Wir werden also zwei neue Aktionen definieren, diese mit "PreAction"und "PostAction" benennen und als solche auch im testplan definieren.

Fügen Sie zur PreAction die "Manual test Wizard -Start" Aktion mittels "New Step" oder Drag & Drop hinzu;
und dann platzieren Sie die "Manual test Wizard -Stop" Aktion in der PostAction.

So könnte eine mögliche Konfiguration aussehen:

Zuletzt definieren wir diese Aktionen im Testplan als Pre- und Post Aktionen. Öffnen Sie dafür den Testplan Editor, und ziehen die jeweilige Aktion in der Felder unten im Editor.

Drücken Sie "Übernehmen" um die Änderungen zu speichern.

Führen Sie nun den Testplan aus, wird der Wizard entsprechend der Konfiguration im Startblock geöffnet, der Testfall ausgeführt und am Ende die Postaction den Wizard wieder schließen.

Weitere Beispiele

In der Manual Test Bibliothek selbst finden Sie einen Beispieltestplan mit mehreren manuellen Schritten.

Auch finden Sie in den mitgelieferten Demobeispilene die Testsuite "ManualTestExample.ets". Diese enthält ein gebrauchsfertiges Beispiel mit einem Setup ähnlich dieser Beschreibung.

---

Copyright © 2014-2024 eXept Software AG