Testautomatisierung. Automatisierung der Erstellung und Ausführung von Softwaretests

INHALT

1. Einleitung
1.1 Grundlagen
1.2 Ansätze zur Testautomatisierung
1.2.1 Keyword-Driven Testing
1.2.1 Data-Driven Testing
1.2.2 Capture & Replay
1.3 Veränderung der Testpyramide
1.4 Motivation von Testautomatisierung

2. Continuous Integration (CI)
2.1 Vorteile von CI
2.2 Voraussetzungen für CI
2.3 Nachteile von CI
2.4 Continuous Delivery / Deployment
2.5 Circle-CI
2.6 Add-Ons für Circle-CI

3. Grenzen der Testautomatisierung
3.1 Technische Grenzen
3.2 Wirtschaftlichkeit
3.3 Weitere Probleme
3.4 Crowdtesting

4. Fazit

Quellenverzeichnis

1. EINLEITUNG

Die Bedeutung von Softwaretests steigt im Software-Lebenszyklus immer weiter an. Durch kurze Entwicklungszyklen wird das manuelle Testen der einzelnen Komponenten und deren Integration schier unmöglich. Deshalb bietet sich die Automatisierung dieser Test nicht nur an, sondern wird existenziell um auch bei agilen Projekten die Qualität des (Zwischen)-Produktes sicherstellen zu können und um am immer weiterwachsenden Markt mithalten zu können. Die Testautomatisierung beschreibt dabei nicht nur das automatisierte Ausführen der Softwaretests, sondern beinhaltet auch die Automatisierung der anderen Komponenten des Softwaretests, wie die Erstellung von Testfällen, die Testdokumentation oder die Auswertung der Softwaretests. Der Fokus soll in dieser Ausarbeitung aber auf der Automatisierung der Erstellung und Ausführung von Softwaretests liegen.

1.1 GRUNDLAGEN

Die Softwaretests können in drei Stufen eingeteilt werden: Unit-Tests, Schnittstellen- /Integrations-Tests und GUI-Tests. Unit-Tests testen einzelne Komponenten der Software, sodass sich bei auftretenden Fehlern die Fehlerquelle sehr gut identifizieren lässt. Schnittstellen und Integrationstests sollen dagegen die Fehlerfreiheit von dem Zusammenspiel der einzelnen Komponenten garantieren. Im Rahmen von GUI-Tests wird die Funktionalität der Software nur über Eingaben in die Benutzeroberfläche überprüft, was zu verschiedenen Fehlern führen kann, da diese Black-Box Tests nicht die Fehlerquelle identifizieren können und nicht alle Fehler aufdecken können. Die Notwendigkeit und der Umfang der verschiedenen Testansätze können sich natürlich je nach Projekt stark unterscheiden. Besonders die Unit-Tests sind bereits in vielen Projekten Standard. Jedoch dies nur in manueller Form, was bedeutet, dass sie bei jeder Änderung am Code manuell ausgeführt werden müssen, was dazu führen kann, dass diese aufgrund des oft anfallenden Aufwands, nicht regelmäßig ausgeführt werden.

1.2 ANSÄTZE ZUR TESTAUTOMATISIERUNG

Im Folgenden möchte ich die Ansätze Data-Driven-Testing, Keyword-Driven-Testing und Capture&Replay vorstellen, die einem behilflich sein können, um seine Anforderungen an die Software zu validieren, indem man mit diesen Verfahren Tests erstellt, die sich gut für die Automatisierung eignen. Außerdem möchte ich auf das Robot-Framework genauer eingehen, mit welchem sich sehr einfach Tests zusammenbauen lassen.

Das Keyword-Driven Testing basiert darauf zu testende Abläufe in einzelne Keywords zu unterteilen. Einen Mehrwert bietet es vor allem dadurch, dass sich diese Keywords beliebig kombinieren lassen, wodurch sich auch ohne Programmierkenntnisse einfach Testfälle erstellen lassen. Dadurch dass die Tests so feingranular aufgeteilt sind, sind diese einfach zu warten, da die Tests bei einer Änderung im Produkt nur an einer Stelle geändert werden müssen und nicht an jeder Stelle, an der die Änderung getestet wird.

Ein Framework, welches das Konzept des Keyword-Driven-Testing umsetzt, ist das Robot Framework. Dieses bietet vordefinierte Keywords wie Log oder Take Screenshot, um die Testergebnisse zu dokumentieren, aber zum Beispiel auch boolesche Operatoren 18. Außerdem stehen verschiedene Libraries bereit, die unteranderem die Einbindung von Selenium Browser-Tests oder Android-Tests erlauben. Die Keywords lassen sich um Argumente ergänzen, sodass man den gleichen Test mit verschieden Konfigurationen, wie zum Beispiel unterschiedlichen Browsern oder URLs laufen lassen kann, ohne dafür einen neuen Test schreiben zu müssen (siehe Abb. 1 & 2).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Keyword-Definition im Robot-Framework

1.2.1 DATA-DRIVEN TESTING

Der Data-Driven Testing Ansatz wird verwendet um den gleichen Test mit einer großen Anzahl an unterschiedlichen eingeben zu testen. Durch diese Methode lassen sich viele verschiedene Fehler aufdecken, die bei einem geringen Testdatensatz vielleicht nicht gefunden worden wären. Die Datensätze können zum Beispiel in Tabellenform in Excel gespeichert werden. Der Ansatz eignet sich ideal für die Validierung von Eingabefeldern und für Regressionstests, da die Tests durch die großen Datenmengen zu zeitintensiv für ein manuellen Test wären. Dadurch ist der Mehrwert einer Automatisierung dieser Tests auch besonders hoch, da man den Prozess nicht nur beschleunigt, sondern erst möglich macht. In Abbildung 3 sieht man wie der Testdatensatz (Data File) durch ein Anwendungsskript (Driver Script), welches die Implementierung der Testfälle enthält, gegen die zu testende Anwendung (Application Under Test). Der Output der Testanwendung wird dann mit dem Daten aus dem Testdatensatz verglichen und auf Korrektheit geprüft.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Data-Driven Testing Konzept

1.2.2 CAPTURE & REPLAY

Mit Hilfe des Capture & Replay Verfahrens lassen sich Testskripte erzeugen indem man die gewünschten Aktionen in der zu testenden Anwendung ausführt und parallel aufnimmt. Die aufgenommen Klicks und Eingaben werden automatisch in Skripten gespeichert, die sich im Nachhinein auch ohne eine erneute Aufzeichnung bearbeiten lassen. Der Vorteil dieses Verfahren ist, dass sich ohne Programmkenntnisse Testskripte erstellen lassen. Dem entgegen steht ein sehr hoher Wartungsaufwand, bedingt dadurch, dass einige Aktion für jeden Test neu aufgezeichnet werden müssen, wodurch Änderungen an der Software zu einer Vielzahl von Neuaufnahmen führen. Des Weiteren können die Tests erst aufgezeichnet werden, wenn die Software soweit fertig ist, dass es eine Benutzeroberfläche gibt, wodurch das Verfolgen eines Test-First Ansatzes nicht möglich ist. Des Weiteren ist dieser Ansatz nur für Anwendungssysteme mit grafischer Benutzeroberfläche geeignet.

Das Selenium-Framework basiert auf dem Capture & Replay Verfahren und ist spezialisiert auf die Aufzeichnung von Webseiten, es gibt aber auch die Möglichkeit mit Selendroid Android Anwendungen aufzuzeichnen 33.

1.3 VERÄNDERUNG DER TESTPYRAMIDE

Nach der klassischen Testpyramide (siehe Abb. 4) liegt der Fokus auf dem Finden von Fehlern in der zu testenden Anwendung. Dies wird besonders durch den hohen Anteil der manuellen Tests der Benutzeroberfläche sichtbar. In diesem Kontext kann es sich zum Beispiel um eine grafische Benutzeroberfläche wie eine Webanwendung, ein Hardwareprodukt, Sprachassistenten, aber auch um Eingaben in eine Kommandozeile handeln. Je nachdem wie der Endnutzer das Produkt bedienen soll. Der Aufwand ist durch die große Anzahl von manuellen Tests dementsprechend hoch. Dadurch bedeutet eine Veränderung der Benutzeroberfläche oder der Befehle für das Command-Line-Interface, dass viele Tests angepasst werden müssen. Die Integrations- und Unit-Tests spielen hier eine geringe Rolle als die manuellen Tests. In agilen Projekten ist der Ansatz der klassischen Testpyramide deshalb nicht mehr geeignet und auch eine Testautomatisierung gestaltet sich hinsichtlich des Wartungsaufwands schwierig.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Die klassische Testpyramide

In Anpassung an immer kürze Release-Zyklen und dem Drang nach Automatisierung der Softwaretests wurde die agile Testpyramide von Mike Cohn entwickelt 9. Der neue Ansatz strebt nach einer höheren Testabdeckung und der Fokus verschiebt sich vom Finden von Fehlern auf die Vorbeugung von Fehlern. Dies soll durch eine verstärkte Konzentration auf Unit-Tests erfolgen. Dadurch erhofft man sich die Fehler direkt an der Quelle zu finden, ohne dass sie erst durch die Integration der Komponenten sichtbar werden. Außerdem soll verstärkt die API und die Domain-Logik getestet werden, sodass dies nicht erst mittels aufwendiger User-Interface Tests geschehen musss. Durch diesen Aufbau wird durch die höhere Anzahl der Unit-Tests nicht nur die Testabdeckung erhöht, sondern die Tests lassen sich auch einfacher automatisieren, dadurch dass er Anteil der Interface-Tests sinkt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Die agile Testpyramide

1.4 MOTIVATION VON TESTAUTOMATISIERUNG

Das manuelle Testen von Anwendungen gestaltet sich durch den hohen Zeitaufwand und die benötigte Anzahl an Testern sehr kostenintensiv. Von der Automatisierung der Softwaretests erhofft man sich durch eine Reduzierung des manuellen Aufwands eine Einsparung eines großen Teils dieser Kosten. Außerdem werden einige Tests, die vorher durch einen zu hohen Aufwand gar nicht realisierbar waren, erst möglich wodurch die Testabdeckung und somit auch das Vertrauen in die Anwendung erhöht wird. Durch die Reduzierung der manuellen Tests kann der Fokus der Entwickler wieder stärker auf die Entwicklung der eigentlichen Anwendung gelegt werden, wobei der Aufwand zu Beginn, die Tests zu automatisieren, natürlich auch nicht vernachlässigt werden darf. Die Tester können die gewonnene Zeit nutzen, um kreativ explorativ zu testen oder sich Gedanken um neue Testfälle machen. Ein weiterer Vorteil ist, dass man zu jedem Zeitpunkt einen Überblick hat wie funktionsfähig die Anwendung zum aktuellen Zeitpunkt ist und es lassen sich Aussagen über die Codequalität und die Fehlerhäufigkeiten machen. Da manuelle Tests bei ständigem Wiederholen der gleichen Aktionen irgendwann zu Flüchtigkeitsfehlern führen darf man den automatisierten Tests mehr Vertrauen schenken. Durch all diese Maßnahmen und Vorteile erhöht sich auch im Endeffekt die Gesamtqualität der Anwendung, da Fehler früher erkannt und dementsprechend auch früher behoben werden können. Dies ist besonders effektiv, da das Wissen über den geschriebenen Code dann noch frisch ist im Gegensatz dazu, einen Fehler in einem alten Feature zu analysieren und zu beheben. Einer der wohl wichtigste Punkte in Bezug auf die Veränderung hin zu agilen Projekten, ist dass man viel schneller Feedback über neue Features einholen kann. Ohne die Automatisierung der Tests wäre eine schnelle agile Entwicklung nahe zu unmöglich.

2. CONTINUOUS INTEGRATION (CI)

Die Continuous Integration stammt ursprünglich aus dem Extreme Programming (XP) und meint das kontinuierliche Integrieren von Änderungen von verschiedenen Entwicklern 19. Der Code soll nun bei jedem neuen Feature in das Version Control System eingecheckt werden. Dabei wird bei jedem Check-In der Code direkt kompiliert und für den Zweck der Automatisierung entscheidend: Die Tests werden bei jedem Check-In des Codes ausgeführt. Nur so ist es in agilen Projekten möglich ständig aktuelles Feedback zu jeder Änderung zu erhalten. Die Reihenfolge der einzelnen Komponenten die nach dem Check-In des Codes ausgeführt werden, sollten sich nach der Komplexität des einzelnen Task in aufsteigender Reihenfolge richten. Denn wenn der Code gar nicht erst kompiliert, müssen die Unit Tests nicht ausgeführt werden und wenn die Unit Tests fehlschlagen, muss man nicht auf das Ergebnis der Integrations-Tests warten (siehe Abbildung 6). Zur Philosophie der CI gehört auch direkt auf auftretende Fehler zu reagieren, solange das Wissen noch frisch ist. Es handelt sich um einen Kreislauf, da der Entwickler nach dem Report der Ergebnisse, auf diese reagieren muss und seinen Code ändern und abschließend wieder hochladen muss.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Continuous Integration Zyklus

[...]