How-To

Continuous Integration Systeme (CI-Systeme) unterstützen durch die kontinuierliche Abarbeitung diverser Teilschritte der Software-Entwicklung die Teams bei der täglichen Arbeit und sind vor allem zur Verbesserung der Qualität gedacht.

Es führt kein Weg daran vorbei: Soll eine Testsuite flexibel, wiederverwendbar und elegant sein, müssen Variablen verwendet werden. Nur wo kann ich Variablen definieren? Welcher der Werte, die ich meiner Variable auf mehrere unterschiedliche Arten vergeben habe, wird letztlich bei der Testausführung genutzt?

Wer sich in QF-Test mit Script-Knoten beschäftigt, ganz gleich ob er jetzt Jython, Groovy oder JavaScript bevorzugt, wird früher oder später über das „QF“-Modul stolpern. Dieses Modul, welches in allen Script-Knoten und Skript-Terminals unter dem Variablennamen qf zur Verfügung stellt, bündelt eine Reihe von Hilfsmethoden, die einem das Leben als Skript-Programmierer erleichtern.

Sie arbeiten mit QF-Test und etwas funktioniert nicht so, wie Sie denken? Dann können Sie (wie sonst vermutlich auch) im Internet suchen oder bei Stackoverflow recherchieren… Schneller sollte es aber über unsere eigenen Kanäle gehen…

Vor ein paar Tagen hatte ich das Vergnügen bei einem Meetup hier in Leipzig dabei zu sein. Das Thema war äußerst interessant – „Erfahrungen bei der Einführung von Testautomatisierung“. Viele Teilnehmer finden, dass Web-UI-Testing sehr fragil ist und es umständlich ist die Tests im „Ok-Status“ zu halten. Deshalb habe ich mich dafür entschieden diese kleine Blogserie mit folgendem Thema zu schreiben: Keine Koordinaten basierten Events und keine Bild basierten Checks! QF-Test kann mehr als das!

Für die einfache Bearbeitung einer Testsuite ist es möglich Knoten farbliche Markierungen zuzuweisen. Diese Funktion ist besonders (aber nicht nur) in Zusammenhang mit komplexen Suchen und Ersetzen Operationen hilfreich – in diesem Fall können die farblichen Markierungen zum Beispiel dafür benutzt werden um anzudeuten welche Schritte noch der Überarbeitung bedürfen und bei welche Schritten die Überarbeitung bereits abgeschlossen ist.

QF-Test nutzt semi-harte Events als Default ein (basierend auf dem Web-Framework, Browser und Browserversion, OS etc.), aber nicht in allen Fällen. Es gibt drei Eventtypen.

In einigen Fällen ist es hilfreich Knoten temporär zu deaktivieren. Hier ist ein kurzer Beitrag, in dem Sie lernen, wie das geht.

Beim Testen einer Anwendung gehört das Überprüfen des aktuellen Zustandes einer Anwendung mit zu den wichtigsten Schritten.

In den meisten Fällen haben wir mit mehr oder weniger einfachen UI-Komponenten zu tun wie z.B. Buttons oder Textfelder. Nichtsdestotrotz müssen wir uns auch oft mit komplexeren UI-Komponenten wie Bäumen, Tabellen und Listen befassen. Diese UI-Komponenten haben Unterelemente.

Sensitive Informationen wie Passwörter sollten vertraulich behandelt werden. Allerdings ist es oft der Fall, dass ein Test ein Login-Formular ausfüllen muss und deshalb das zugehörige Passwort benötigt.

Über das Protokoll liefert QF-Test ein detailliertes Log über die Aktionen, die während eines Testlaufs durchgeführt wurden. Die Übersicht dieses Protokolls kann in anderen Reports zusammengefasst werden wie einem HTML/XML oder JUnit Report.

Prozeduren, die auch Funktion, Routine oder Subroutine genannt werden, werden genutzt, um immer wieder auftretende Aufgaben zu lösen. Genauso können wir auch spezifizieren, dass gewisse aufeinander folgende Aktionen gebraucht werden um eine Aufgabe zu lösen (=Programmierung einer Prozedur). Wenn wir dann dieser Aufgabe begegnen, können wir einfach diese Prozedur aufrufen (und die Prozedur diese Aufgabe für uns erledigen lassen).

Auch in frühen Entwicklungsstadien bietet sich Capture-Replay an. Ein früher Start so erstellter Regressionstests  und die Vergabe eindeutiger Namen / IDs sind die wichtigsten Grundlagen für effiziente (da stabile Wiedererkennung) Testautomatisierung.

Manchmal muss man mathematische Berechnungen in QF-Test durchführen, z.B. um die zu erwartende Höhe eines UI-Elements in Abhängigkeit zur kompletten Fenstergröße oder der exakten Klickposition eines Mausklicks zu berechnen.

Ein hoher Prozentsatz an ausgeführtem Code deutet auf eine geringere Wahrscheinlichkeit für unentdeckte Softwarefehler hin.