© Excellent backgrounds/Shutterstock.com
Java Magazin
Teil 1: Automatisiertes Testen: ein Erfahrungsbericht

Automatisch, praktisch, gut


Insbesondere im agilen Umfeld mit kurzen Releasezyklen oder Continuous Delivery ist ein automatisierter Test fast unabdingbar. Hier ist es ohne immensen Testaufwand unmöglich, für jedes Release einen kompletten manuellen Regressionstest zu realisieren. JUnit-Tests haben für die Komponententests bereits vielfach Einzug gehalten. Geplante automatisierte Oberflächen- und Behaviour-Tests sind dagegen eher die Ausnahme.

Video: Die Last mit den Tests – Lasttests mit Gatling

Artikelserie

Teil 1: Automatisiertes Testen: ein Erfahrungsbericht

Teil 2: ScalaTest-Implementierung: Unerwartete Folgen und ihre Auswertung

Das strategische automatisierte Testen fristet in der Softwareentwicklung vielfach noch ein Schattendasein. Dabei ist es für wiederholbare Smoke- und Regressionstests sehr sinnvoll. Außerdem eignen sich nicht alle Tests und Prüfungen für menschliche Wahrnehmung und menschliches Verhalten, also für die manuelle Ausführung. Ungeeignet sind z. B. Prüfungen, bei denen Texte verglichen werden müssen, insbesondere wenn diese nicht in der Muttersprache sind oder darüber hinaus noch über ein anderes Alphabet verfügen. Auch wenn innerhalb eines großen Menüs ein Punkt fehlt oder Überschriften zwar vorhanden sind, aber den falschen Text haben, sind dies Punkte, die einem menschlichen Betrachter vermutlich nicht auffallen – wenn er nicht ausgerechnet danach sucht. Bei Anbietern automatisierter Testtools kommt das automatisierte Testen gerne wie eine Lichtgestalt daher. Entsprechend hochgeschraubte Erwartungen bauen sich auf.

Unsere Anwendung läuft aktuell auf verschiedenen Plattformen (Multiplattform, Android/iOS, Desktop/Mobile) in zehn Übersetzungen (Multi Language) und auf vier unterschiedlichen Domänen (Multi Domain, COM Host, türkischer Host, brasilianischer Host, russischer Host). Anvisierte Wunschvorstellung war, für jeden Test bei dessen Aufruf festzulegen, auf welchen Plattform-Browser-Kombinationen (1 – x), für welche Sprachen (Angabe der zu prüfenden Sprachen, 1 – y) und für welche Domänen (1 – z) dieser laufen soll. In der vollen Ausprägung muss jeder Test x*y*z-mal laufen.

Wie alles begann

Folgende Ausgangssituation liegt vor: Für die vielen Workflows im Backend gibt es Unit-Tests. Improvements werden mit Features abgesichert, sodass sie leicht abgeschaltet werden können. Die Überprüfung der Anforderungen des Kunden bezüglich Aussehen und Verhalten der Anwendung wird manuell durchgeführt. Hierfür werden vom Kunden in den Implementierungstickets...

Java Magazin
Teil 1: Automatisiertes Testen: ein Erfahrungsbericht

Automatisch, praktisch, gut

Insbesondere im agilen Umfeld mit kurzen Releasezyklen oder Continuous Delivery ist ein automatisierter Test fast unabdingbar. Hier ist es ohne immensen Testaufwand unmöglich, für jedes Release einen kompletten manuellen Regressionstest zu realisieren. JUnit-Tests haben für die Komponententests bereits vielfach Einzug gehalten. Geplante automatisierte Oberflächen- und Behaviour-Tests sind dagegen eher die Ausnahme.

Dennis Rieks, Angi Mathea, Daniel Börgers


Insbesondere im agilen Umfeld mit kurzen Releasezyklen oder Continuous Delivery ist ein automatisierter Test fast unabdingbar. Hier ist es ohne immensen Testaufwand unmöglich, für jedes Release einen kompletten manuellen Regressionstest zu realisieren. JUnit-Tests haben für die Komponententests bereits vielfach Einzug gehalten. Geplante automatisierte Oberflächen- und Behaviour-Tests sind dagegen eher die Ausnahme.

Video: Die Last mit den Tests – Lasttests mit Gatling

Artikelserie

Teil 1: Automatisiertes Testen: ein Erfahrungsbericht

Teil 2: ScalaTest-Implementierung: Unerwartete Folgen und ihre Auswertung

Das strategische automatisierte Testen fristet in der Softwareentwicklung vielfach noch ein Schattendasein. Dabei ist es für wiederholbare Smoke- und Regressionstests sehr sinnvoll. Außerdem eignen sich nicht alle Tests und Prüfungen für menschliche Wahrnehmung und menschliches Verhalten, also für die manuelle Ausführung. Ungeeignet sind z. B. Prüfungen, bei denen Texte verglichen werden müssen, insbesondere wenn diese nicht in der Muttersprache sind oder darüber hinaus noch über ein anderes Alphabet verfügen. Auch wenn innerhalb eines großen Menüs ein Punkt fehlt oder Überschriften zwar vorhanden sind, aber den falschen Text haben, sind dies Punkte, die einem menschlichen Betrachter vermutlich nicht auffallen – wenn er nicht ausgerechnet danach sucht. Bei Anbietern automatisierter Testtools kommt das automatisierte Testen gerne wie eine Lichtgestalt daher. Entsprechend hochgeschraubte Erwartungen bauen sich auf.

Unsere Anwendung läuft aktuell auf verschiedenen Plattformen (Multiplattform, Android/iOS, Desktop/Mobile) in zehn Übersetzungen (Multi Language) und auf vier unterschiedlichen Domänen (Multi Domain, COM Host, türkischer Host, brasilianischer Host, russischer Host). Anvisierte Wunschvorstellung war, für jeden Test bei dessen Aufruf festzulegen, auf welchen Plattform-Browser-Kombinationen (1 – x), für welche Sprachen (Angabe der zu prüfenden Sprachen, 1 – y) und für welche Domänen (1 – z) dieser laufen soll. In der vollen Ausprägung muss jeder Test x*y*z-mal laufen.

Wie alles begann

Folgende Ausgangssituation liegt vor: Für die vielen Workflows im Backend gibt es Unit-Tests. Improvements werden mit Features abgesichert, sodass sie leicht abgeschaltet werden können. Die Überprüfung der Anforderungen des Kunden bezüglich Aussehen und Verhalten der Anwendung wird manuell durchgeführt. Hierfür werden vom Kunden in den Implementierungstickets...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang