Testautomatisierung von mobilen Web- Applikationen im Umfeld agiler Softwareentwicklung

Transkript

1 Goethe Universität Frankfurt Diplomarbeit Testautomatisierung von mobilen Web- Applikationen im Umfeld agiler Softwareentwicklung eingereicht bei Prof. Dr.-Ing. Detlef Krömker, Professur für Graphische Datenverarbeitung von Mahir Tas Eingereicht am 09. September 2013

2 Eidesstattliche Erklärung Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe; die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungskommission vorgelegt und auch nicht veröffentlicht. Frankfurt am Main, den 09. September 2013 Mahir Tas

3 Danksagung mein Dank gilt Prof. Dr. Detlef Krömker, der mir diese Diplomarbeit ermöglicht hat. Bedanken möchte ich mich auch bei meinem Betreuer David Weiß für seine Hilfe in der letzten Sekunde. Weiterhin möchte ich mich bei meiner Frau und meinen Kindern Danken, die mir auch in den schwierigsten Zeiten ein Lächeln auf die Lippen gezaubert haben. Auch möchte ich mich bei meinen Eltern bedanken, für ihre langjährige Unterstützung und Motivation während meines Studiums.

4 Zusammenfassung In der heutigen Zeit werden viele Anwendungen als Webanwendungen entwickelt, weil man sie schneller auf den Markt werfen kann. Neue Methoden wurden entwickelt um den Softwareentwicklungsprozess zu verschlanken, um damit noch schneller und öfter eine Produkt auf den Markt zu bringen. Diese Methoden erschweren die Arbeit von manuellen Tester ungemein. Sie müssen jetzt noch schneller und noch öfter testen. Um dieser Miesere entgegenzuwirken wurden Testautomatisierungsmechanismen und Testautomatisierungswerkzeuge entwickelt. In dieser Arbeit wollte ich zeigen, dass Testautomatisierung in bestehenden Projekten nachträglich noch eingefügt werden kann. Und das diese für eine verbesserte Qualität des Produktes sorgen kann. Ich habe in dieser Arbeit den Testfallkatalog für das Produkt 4Tablet der Firma Deutsche Telekom AG zu 70% mit dem Testwerkzeug Selenium automatisiert.

5 Inhaltsverzeichnis Kapitel Einleitung Motivation Aufgabenstellung und Ziel Aufbau der Arbeit... 1 Kapitel Grundlagen Vorgehensmodelle in der Softwareentwicklung Klassische Vorgehensmodelle Agile Vorgehensmodelle Qualitätssicherung in der Softwareentwicklung Testarten Blackbox Tests Whitebox Tests Teststufen Komponenten- / Unit-Tests Integrationstests Systemtests Abnahmetests Webanwendungen Webanwendungen auf mobilen Endgeräten Kapitel State of the Art Testautomatisierung Testautomatisierungswerkzeuge... 18

6 3.2.1 Bildbasierte Testautomatisierungswerkzeuge Sikuli DOM-basierte Testautomatisierungswerkzeuge Selenium Kapitel Konzept und Implementierung Konzept Implementierung Verwendete Technologien Kapitel Ergebnis... 42

7 Kapitel1 Einleitung 1.1 Motivation 1.2 Aufgabenstellung und Ziel 1.3 Aufbau der Arbeit 1

8 Kapitel 2 Grundlagen 2.1 Vorgehensmodelle in der Softwareentwicklung Ein Vorgehensmodell ist eine allgemeine Anleitung, in der festlegt wird, welche Aktivitäten beim Entwickeln eines Software-Produktes wie und in welcher Reihenfolge durchgeführt werden soll. Ziel ist es den Entwicklungsprozess mit Hilfe von strukturierten und standardisierten Prozessen zu optimieren, die Kommunikation innerhalb des Projektes zu verbessern, Werkzeuge bereitzustellen, die die Entwicklung effizienter gestalten und Automatisierungsmöglichkeiten bieten und dabei helfen, einen Überblick über Zeit, Kosten und Qualität zu behalten[balz1997]. Um diese Ziele zu erreichen werden Software-Projekte in Phasen eingeteilt. Im Folgenden werden zwei Vorgehensmodelle vorgestellt. Das erste Modell ist ein Vertreter aus dem klassischen Vorgehensmodell und das zweite Modell ist ein Vertreter aus dem agilen Vorgehensmodell Klassische Vorgehensmodelle Klassisches Projektmanagement versucht ein Projekt in allen relevanten Aspekten (inhaltliche Arbeitspakete, Zeitbedarf, Kosten und Ressourcenbedarf) möglichst exakt und vollständig vorauszuplanen und die Projektdurchführung dann so zu steuern, dass dieser Plan bestmöglich eingehalten wird: vom Projektstart bis zum Projektabschluss. 2

9 Das Wasserfallmodell Das Wasserfallmodell ist eines der ersten und prominentesten Vorgehensmodelle. Es basiert auf dem Phasenmodell. Dabei werden die Projekte in Phasen bzw. in Arbeitsabschnitte unterteilt. Die Phasen werden sequentiell abgearbeitet und die Ergebnisse jeder einzelnen Phase werden in einem Dokument niedergeschrieben. Eine neue Phase darf ohne Beendigung der vor ihr liegenden Phase nicht begonnen werden. Die gewöhnliche Phasenaufteilung des Projektes aus Sicht des Projektmanagements sieht wie folgt aus [HIND2009]: Vorphase Analyse Konzeption Realisierung Test Abnahme Wenn man das aus Softwareentwicklungssicht betrachtet und die Phasen als Aktivitäten definiert, dann erhalten wir das altbekannte Schaubild (siehe Abbildung 2.1), das wir als Wasserfallmodell kennen. Abbildung 2.1: Das Wasserfallmodell Anforderungsdefinition: Das ist die Planungsphase. Hier werden die Eigenschaften des Produktes und die Lösungsstrategien, wie das Produkt erstellt werden soll, in Form eines Lastenheftes festgehalten. Im Lasten wird auch eine Kosten/Nutzen-Analyse durchgeführt. Dabei 3

10 entscheidet das Management, ob das Projekt rentabel ist oder das Vorhaben doch nicht verfolgt werden sollte. Für die Analyse wird eine grobe Projektplanung erstellt, in der die notwendigen Ressourcen aufgelistet werden[balz1996]. Analyse: In der Analysephase werden die spezifischen Produktanforderungen in Form eines Pflichtenheftes dokumentiert. Das Pflichtenheft enthält folgende Angaben zum Produkt: Funktionsumfang, benötigte Schnittstellen, Leistungsverhalten, benötigte Soft- und Hardware, Dokumentationsrichtlinien und Terminplanung. Das Produkt wird hier vollständig definiert. Das Pflichtenheft bildet eine Vertragsbasis zwischen Auftraggeber und Auftragnehmer[Balz1996]. Entwurf: Die Aufgabe in der Entwurfsphase besteht darin das Problem in kleinere Komponenten zu zerlegen. Die Kommunikation zwischen den einzelnen Komponenten muss analysiert werden. Geeignete Algorithmen und Datenstrukturen müssen gefunden und modelliert werden bis die Softwarearchitektur feststeht. Anhand der Produktdefinition aus dem Pflichtenheft wird die innere Struktur des Softwaresystems festgelegt[balz1996]. Implementierung: In dieser Phase werden die einzelnen Komponenten, die in der Entwurfsphase spezifiziert wurden, vom Entwickler-Team in einer konkreten Programmiersprache implementiert. Die implementierten Komponenten werden mit sogenannten Unit- Tests, manchmal auch Komponententests genannt, auf Fehler getestet. Werden hier keine Fehler entdeckt, dann folgt die Integrationsphase. In der Integrationsphase werden die einzelnen Komponenten zu einem vollständigen System zusammen gefügt. Die Tests, die hier ausgeführt werden und die Schnittstellen zwischen den einzelnen Komponenten überprüfen sollen, werden Integrationstests genannt[balz1996]. Funktionsprüfung: In dieser Phase liegt das Produkt als funktionsfähiges Programm vor. Mit Hilfe von Systemtests wird die Funktionalität des Programms getestet. Anschließend erfolgt der 4

11 Abnahmetest. Hiermit wird überprüft, ob das Produkt die Anforderungen aus dem Pflichtenheft erfüllen[balz1996]. Installation und Wartung: Wenn das Produkt den Abnahmetest besteht und somit den Anforderungen genügt, dann geht es in Produktion. Nach der Installation können Modifikationen nötig werden und dadurch Wartungsarbeiten anfallen. Diese können durch Veränderungen in der Systemumgebung oder auch durch die Erweiterungen der Funktionalität des Produktes hervorgerufen werden[balz1996] Agile Vorgehensmodelle Das Wasserfallmodell ist mit seiner strikten Aufteilung in definierte Phasenübergänge einfach zu verstehen, einfach zu managen und einfach zu überwachen. Dieses starre und stark dokumentenbasierte Modell, deshalb oft auch schwergewichtiges Modell genannt, hat seine Schwachstellen Dech2010. Der Prozess von der Analysephase bis zur Abnahme ist im Wasserfallmodell meistens sehr langwierig. Die Anforderungen an das Produkt können sich in dieser Zeit ändern, denn die Annahme, dass zu Beginn eine abgeschlossene und korrekte Anforderungsdefinition existiert, entspricht nicht der Realität. Je später die Änderung durchgeführt werden muss, desto höher fallen die Kosten für die Veränderung aus (Abbildung 2.3). Nicht selten kommt es sogar vor, dass an dem fertigen Produkt keinerlei Interesse mehr besteht, weil sich der Markt verändert hat. Die Entwicklung wird eingestellt und das Projekt verworfen wird[ecks2004]. 5

12 Abbildung 2.3: Änderungskosten im Wasserfallmodell Aus dem Zweifel, ob es überhaupt möglich ist, Software über so einen langen Zeit hinweg korrekt zu spezifizieren und ob die Umfangreiche Dokumentierung notwendig ist, hat sich Anfang 1990 eine Gegenbewegung zur der klassischen Softwareentwicklung gebildet. Die neuen Modelle wurden leichtgewichtige Modelle genannt. Ihr Ziel war den Softwareentwicklungsprozess flexibler und schlanker zu machen kamen die prominenten Vertreter dieser Verfahren zusammen und formulierten das agile Manifest. Folgende Werte wurden formuliert und dienen als Fundament für alle agilen Methoden und Prozesse: Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt: Individuen und Interaktionen mehr als Prozesse und Werkzeuge Funktionierende Software mehr als umfassende Dokumentation Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung Reagieren auf Veränderung mehr als das Befolgen eines Plans Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein[ 6

13 Basierend auf den agilen Werten wurden 12 agile Prinzipien formuliert: Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. Funktionierende Software ist das wichtigste Fortschrittsmaß. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren ist essenziell. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an [ Durch die Fokussierung auf das Endprodukt und Vernachlässigung der aufwendigen und zeitraubenden Dokumentation kann viel früher mit Entwicklung angefangen werden. Agile Softwareentwicklung basiert auf dem Prinzip der iterativinkrementellen Vorgehensweise, d.h. das Produkt wächst mit jeder Iteration. Jede 7

14 Iteration beinhaltet für sich gesehen alle Phasen aus dem Wasserfallmodell. Jedes Produktinkrement wird somit auch getestet. Nach jeder Iteration liegt eine lauffähige Software vor. Der Kunde kann den Fortschritt immer mit verfolgen, da er in den Entwicklungsprozess eingebunden wird. Er kann Änderungswünsche äußern und somit in der Entwicklungsphase Einfluss ausüben. Nach den Prinzipien der agilen Softwareentwicklung ist dies sogar erwünscht. Diese Faktoren bewirken, dass die Änderungskosten in diesem Fall nicht so hoch ausfallen wie im Wasserfallmodell (Abbildung 2.5). Abbildung 2.5: Änderungskosten im agilen Vorgehensmodell Scrum Scrum ( Gedränge ) ist ein Framework, das das Gesamtsystem aus Meetings, Artefakten, Rollen und Werten bildet. Ken Schwaber stellte 1999 mit seinem Artikel Scrum: A Pattern Language for Hyperproductive Software Development erstmals vor. Das Ziel von Scrum ist es unnötigen Aufwand zu reduzieren, auf Änderungen schnell zu reagieren, wichtiger Features zu priorisieren, in kurzen Zeitabschnitten Ergebnisse zu liefern und die Kommunikation mit dem Kunden zu pflegen, anstatt Zeit und 8

15 Energie die Erstellung und Durchsetzung von Dokumenten zu investieren. Scrum macht keine Vorgaben wie das Produkt entwickelt und welche Softwareentwicklungstechnik eingesetzt werden soll. Das wird dem Team selbst überlassen [Linz]. Das Scrum-Team besteht meistens aus 7-9 Personen und kennt nur die folgen drei Rollen: Der Product Owner: Er ist der Vertreter für den Kunden und spiegelt dessen Bedürfnisse wider. Er legt das gemeinsame Ziel fest und hat die Entscheidung darüber, welche Teilprodukt- Anforderungen, in welcher Iteration, umgesetzt werden sollen. Zur Definition der Ziele erstellt er User Stories, d.h. in Alltagssprache mit maximal zwei Sätzen bewusst kurz gefasste Software-Anforderungen, oder andere Techniken wie UML Anwendungsfälle. Das Entwicklungsteam: Das Entwicklerteam besteht meistens aus Entwicklern, Designern und Qualitätssicherungsspezialisten. Alle Teammitglieder zusammen sind für alle Arbeitsschritte verantwortlich. Jedes Teammitglied steuert mit seiner Expertise dazu bei, dass die Aufgaben erfolgreich umgesetzt werden. Der Scrum Master: Der Scrum Master überwacht die Teamarbeit und sorgt für eine Reibungslose Zusammenarbeit. Er räumt Hindernisse, die die Entwickler bei ihrer Arbeit behindern könnten, aus dem Weg. Er ist stets auf der Suche nach Verbesserungsmöglichkeiten, um die Produktivität und die Zufriedenheit des Teams zu verstärken. Er ist verantwortlich dafür, dass die Scrum-Praktiken umgesetzt und eingehalten werden. Er sorgt für Transparenz innerhalb des Teams. Der Scrum Master sorgt dafür, dass weder der Product Owner noch andere, nicht zum Team gehörende, in den adaptiven Selbstorganisationsprozess des Teams eingreifen. Scrum-Prozess 9

16 Der Scrum-Prozess besteht aus drei auf einander folgenden Phasen. Die erste Phase ist die Vorplanungsphase. In dieser Phase werden die Vorgaben für das Projekt definiert und eine grobe Architektur sowie das Design für das Produkt definiert. In dieser Phase erstellt der Product Owner eine vorab Version des Product Backlogs, das eine Ansammlung von Anforderungen ist. Diese Anforderungen haben nicht denselben Charakter wie sie im Wasserfall haben. Sie haben nicht den Anspruch auf Vollständigkeit. Denn das Backlog wächst und ändert sich genauso wie das zu erstellende Produkt von Iteration zu Iteration. Der Vorplanungsphase schließt sich der eigentliche Prozess an. Diese Phase wird in der Literatur manchmal auch als Game-Phase bezeichnet. In dieser Phase beginnt die Entwicklung des Produktes, das sich über mehrere Iterationen erstreckt. Die Iterationen im Scrum haben eine kurze, aber feste Länge, die das Team vorab festlegt. Eine Iteration heißt im Scrum Sprachjargon Sprint und sie dauert für gewöhnlich 2 bis 4 Wochen. Am Ende jeden Sprints erhält der Kunde ein lauffähiges System, welches sich mit jeder weiteren Iteration dem Endprodukt immer weiter annähert (Abbildung 2.4). Abbildung 2.4: Scrum-Prozess (Quelle: Zu Beginn eines Sprints findet das Sprint Planning Meeting statt. In diesem Meeting stellt der Product Owner dem Team Anforderungen (User-Stories), die er für wichtig hält und hoch priorisiert hat, vor. Das Team schätzt den Aufwand dieser User-Stories. Nach der Aufwandsabschätzung werden diese User-Stories in den Sprint-Backlog 10

17 überführt und damit wird das Sprintziel bestimmt. Der gesamt Umfang des Sprint- Backlogs wird so festgelegt, dass das Team alle User-Stories aus dem Sprint-Backlog innerhalb eines Sprints abarbeiten kann. Das Sprint-Backlog kann als Vertag zwischen dem Team und dem Product Owner angesehen werden. Nach diesem Meeting startet der Sprint und das Team beginnt mit der Umsetzung der User-Stories. Jeden Tag gibt es ein 15-minütiges Daily Scrum Meeting. In diesem Meeting erzählt jedes Teammitglied was es seit dem letzten Daily Scrum Meeting gemacht hat, was es bis zum nächsten Daily Scrum Meeting machen wird. Falls Hindernisse auftauchen werden diese dem Scrum Master gesagt. Es ist dann die Aufgabe des Scrum Masters diese Hindernisse zu beseitigen. Am Ende des Sprints findet das Sprint Review Meeting statt. Hier stellt das Team die Ergebnisse ihrer Arbeit dem Product Owner vor. Nach der Review findet die Retrospektive statt. In der Retrospektive werden Ideen gesammelt, wie der Prozess weiter verbessert werden kann. Im Anschluss an der Retrospektive findet das Sprint Planning Meeting für den nächsten Sprint statt und somit wiederholt sich das Spiel wieder von vorne. 2.2 Qualitätssicherung in der Softwareentwicklung Bevor die Testarten, Teststufen und die Testautomation näher erläutert wird, muss der Begriff Qualität definiert werden. Nach dem ISO-Standard ISO/IEC 9126 wird die Software-Qualität folgenderweise definiert: Software-Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Software-Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht [ISO/IEC 9126]. Qualitätsmerkmale die eine Software aufweisen muss, sind (Abbildung 2.6): Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, 11

18 Wartbarkeit und Portierbarkeit external and internal quality functionality reliability usability efficiency maintainability portability suitability accuracy interoperability security functionality compliance maturity fault tolerance recoverability reliability compliance understandability learnability operability attractiveness usability compliance time behaviour resource utilisation efficiency compliance analysability changeability stability testability maintainability compliance adaptability installability co-existence replaceability portability compliance Abbildung 2.6: Die Qualitätskriterien für Software nach ISO 9126 [ISO/IEC 9126] Funktionalität steht für das Vorhandensein von Funktionen, die festgelegte und vorausgesetzte Erfordernisse erfüllen. Unterpunkte sind: Angemessenheit, Interoperabilität, Ordnungsmäßigkeit, Richtigkeit und Sicherheit Zuverlässigkeit steht für die Fähigkeit einer Software, ihr Leistungsniveau unter festgelegten Bedingungen in einem festgelegten Zeitraum zu halten. Unterpunkte sind: Fehlertoleranz, Reife und Wiederherstellbarkeit Benutzbarkeit steht für die Fähigkeit einer Software, unter festgelegten Bedingungen für einen Benutzer verständlich, erlernbar, anwendbar und attraktiv zu sein. Unterpunkte sind: Bedienbarkeit, Erlernbarkeit und Verständlichkeit Effizienz steht für das Verhältnis zwischen dem Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen. Unterpunkte sind: Verbrauchsverhalten und Zeitverhalten (Performanz) Änderbarkeit steht für den Aufwand, der zur Durchführung vorgegebener Änderungen notwendig ist. Änderungen können Korrekturen von Fehlern, Anpassungen an veränderte Anforderungen oder die Verbesserung der Wartung sein. Unterpunkte sind: Analysierbarkeit, Modifizierbarkeit, Prüfbarkeit und Stabilität 12

19 Mit der Übertragbarkeit ist die Leichtigkeit gemeint, mit der eine Software von einer Umgebung in eine andere übertragen werden kann. Unterpunkte sind: Anpassbarkeit, Austauschbarkeit, Installierbarkeit und Konformität [Franz]. Die oben genannten Merkmale sind zum Teil nicht eindeutig messbar, da sie von verschiedenen Personen unterschiedlich bewertet werden. Sie haben einen subjektiven Charakter [Goll]. Nichtsdestotrotz stellen diese Kriterien einen Rahmen dar, die mit Hilfe von Qualitätsindikatoren bzw. Metriken die Software mess- und bewertbar gemacht. Eine wichtige Maßnahme, um für die Qualität der Software zu sorgen sind Softwaretests Testarten Für die Erstellung von Testfällen gibt es unterschiedliche Verfahren zur Überprüfung des Testobjekts, die sich nach [Spill2004] in zwei Kategorien einteilen lassen: Black-Boxund und White-Box-Verfahren Blackbox Tests Whitebox Tests Teststufen 13

20 Komponenten- / Unit-Tests Integrationstests Systemtests Abnahmetests 2.3 Webanwendungen Webtechnologien World Wide Web Webanwendungen auf mobilen Endgeräten 14

21 Kapitel 3 State of the Art In heutiger Zeit wollen die Kunden mehr Funktionalität in ihren Anwendungen haben. Sie wollen es schneller und billiger geliefert bekommen, während zur gleichen Zeit die Qualität der Software ihren Anforderungen standhalten müssen, wenn nicht sogar diese übertreffen sollen. Die Softwareunternehmen versuchen die Wünsche der Kunden nach schnelleren Lieferungen mit neuen Softwareentwicklungsmodellen, wie z.b. Scrum das in Kapitel 2 besprochen wurde, entgegen zu kommen. Das bedeutet für die Software-Tester enorm viel Arbeit. Mehr Funktionalität bedeutet, dass das Produkt mit jedem Inkrement größer und komplexer wird, was wiederum bedeutet, dass mehr Testfälle für jede Lieferung ausgeführt werden müssen. Im Umkehrschluss bedeuten schnellere Lieferungen weniger Zeit zum Testen. Weitere Lieferungen bedeuten auch mehr Regressionstests. Auf der anderen Seite wollen die Unternehmen Kosten senken. Auf die Qualitätssicherung übertragen bedeutet dies, dass die Tests mit weniger Arbeitsstunden abgeschlossen werden müssen. Es muss mehr getestet, öfter getestet und das Ganze mit weniger Personal getestet werden. So ist kommt es häufig vor, das Nutzer mit fehlerhafter Software konfrontiert werden. In diesem Kapitel werden Werkzeuge beschrieben, mit denen dieser Problematik entgegen gewirkt werden kann. 3.1 Testautomatisierung Testautomatisierung ist die Durchführung von ansonsten manuellen Testtätigkeiten durch Automaten. [ Seidl] 15

22 Dabei geht es immer darum, die Zeit und die Kosten für Software-Tests zu minimieren, die Software-Qualität zu verbessern, die Testabdeckung zu erhöhen und die manuellen Tester bei den arbeitsintensive Tests zu unterstützen. Kosten, Zeitplan und Qualität sind Parameter, die entscheidend für den Erfolg von Software-Entwicklung sind [Dust]. Das Testen einer Software zählt mitunter zu den aufwändigsten und teuersten Arbeitsschritten in der Softwareentwicklung. Die Kosten für das Testen können unter Umständen 30% bis 50% der gesamten Projektkosten ausmachen [Erw2002]. Früher oder später stellt sich die Frage, ob die Tests nicht automatisiert werden sollten. Denn die Testautomatisierung kann den Testaufwand erheblich senken. Die Testautomation erfordert zusätzliche Ressourcen in Form von Testentwickler und Tastwerkzeugen. Diese sind mit Kosten verbunden. Vorab muss kalkuliert werden, ob sich die Testautomation rentiert und die Vor- und Nachteile der Testautomatisierung gegenübergestellt werden. Nachfolgend werden einige Vorteile und Nachteile der Testautomatisierung aufgelistet: (nach [Thaller00]). Vorteile Eine neues Inkrement oder eine neue Versionen der bestehenden Anwendung kann, nach minimalen Änderungen an den Testskripten, erneut getestet werden (Regressionstest). Die Automatisierung bietet die Möglichkeit mehr Tests in weniger Zeit durch zu führen. Tests, die aus Mangel an Zeit und Personal überhaupt nicht möglich wären, können durch Automatisierung ausgeführt werden. Der Test eines Betriebssystems mit 200 Nutzern wäre so ein Fall, das nur schwer oder gar nicht realisierbar ist. Ein solcher Test ist nur möglich, wenn eine Vielzahl von Benutzer durch die Testautomatisierung simuliert werden. Vorhandene Ressourcen werden mit der Testautomatisierung besser genutzt. Durch die Automatisierung langwieriger Tests, die mit vielen manuellen Eingaben verbunden wären, haben die Tester mehr Zeit sich um Tests zu kümmern, die ihre Kreativität erfordern. Automatisierte Tests sind konsistent und wiederholbar. Sie liefern immer das gleiche Ergebnis. Bei einem manuellen Tester ist das nicht der Fall. 16

23 Die geschriebenen Tests können immer wieder verwendet werden. Durch die verkürzte Testphase, kann die Software früher auf dem Markt erscheinen. Die Testautomatisierung ist trotz der genannten Vorteile nicht unproblematisch. Nachteile: Manchmal gehen Teams mit unrealistische Erwartungen an die Automatisierung ran. Neue Methoden mit einem Werkzeug garantieren nicht die Lösung aller Probleme. Wenn bereits manuelle Tests nur selten genutzt werden, macht eine Testautomatisierung wenig Sinn. Die meisten Fehler werden bei der ersten Ausführung des Tests aufdeckt. Bei weiteren Testdurchläufen werden allerdings mit einem automatisierten Test keine neuen Fehlen entdeckt. Ein automatisierter Test, welcher problemlos abläuft, nie ein Fehler meldet, verleitet das Team sich in Sicherheit zu wiegen. Weil kein Fehler gefunden wurde, heißt das nicht, dass kein Fehler in der Software ist. Eine Änderung der Software, die aufwändige Änderungen des Testprogramms zur Folge haben, verbrauchen zu viele Ressourcen. Dann stellt sich die Frage, ob die manuelle Durchführung des Tests nicht einfacher gewesen wäre. Die für den automatisierten Test benötigten Werkzeuge sind selbst auch Software und können Fehler enthalten. Fehler könnten dadurch im Produkt unentdeckt bleiben. Testautomatisierung hat ihre Grenzen da, wo sie unwirtschaftlich wird, d.h. wenn sie ihr Ziel, den hohen Zeitaufwand manueller Tests durch den Einsatz automatisierter Tests zu reduzieren, nicht erfüllt bzw. noch mehr Zeit in Anspruch nimmt, als die manuelle Testdurchführung. Die Testautomation lohnt sich dann, wenn das Testobjekt stabil ist und nur wenigen Änderungen ausgesetzt ist. Jede Änderung am Testobjekt heißt ein Mehraufwand. Die Tests müssen ebenfalls angepasst werden. Das Testobjekt sollte nicht eine 17

24 Komponente sein, die nur sehr selten ausgeführt wird. Denn mit mehrmaligen Wiederholungen der automatisierten Testfälle amortisieren sich die Kosten [Vigenschow]. Ein weiterer Punkt der für die Testautomatisierung spricht, ist die Möglichkeit Tests auf unterschiedlichen Systemen mit unterschiedlicher Konfiguration durchführen zu können. Das kommt besonders häufig bei Tests von Webanwendungen vor. Hier müssen verschiedene Browser in verschiedenen Testsystemen laufen. Tests die nicht automatisiert werden sollten, sind solche die nur selten ausgeführt werden. Tests bei den die menschliche Beurteilung notwendig ist und von einem Werkzeug nicht beurteilt werden kann, sollten ebenfalls nicht automatisiert werden[thaller00]. 3.2 Testautomatisierungswerkzeuge Wenn im Team die Entscheidung zu Gunsten der Testautomatisierung gefallen ist, dann muss schnellstmöglich ein Testautomatisierungswerkzeug gefunden werden. Ein Testtool ist ein automatisiertes Hilfsmittel, das bei einer oder mehreren Testaktivitäten, beispielsweise Planung und Verwaltung, Spezifikation, Aufbau von Ausgangsdateien, Testdurchführung und Beurteilung, Unterstützung leistet. [Pol et al,2000]. Da der Fokus dieser Arbeit auf Testautomatisierung von mobilen Webanwendungen, hier speziell auf Anwendungen die im Webbrowser von mobilen Endgeräten laufen, liegt, werden nachfolgend Testautomatisierungswerkzeuge für diesen Zweck vorgestellt. Auf dem Markt gibt es nur eine Handvoll von Werkzeugen, die dafür in Frage kommen. Es gibt neben diesen Testautomatisierungswerkzeugen auch Werkzeuge, die native Anwendungen auf mobilen Endgeräten testet. Diese werden in dieser Arbeit nicht betrachtet. Diese Testautomatisierungswerkzeuge lassen sich in zwei Klassen einteilen. Zum einen gibt es die bildbasierten Testautomatisierungswerkzeuge zum anderen die DOM-Basierten Testautomatisierungswerkzeuge. Mit jeweils einem Vertreter werden die beiden Verfahren vorgestellt. Beide Testautomatisierungswerkzeuge sind Open-Source-Werkzeuge. 18

25 3.2.1 Bildbasierte Testautomatisierungswerkzeuge Sikuli Sikuli wurde durch die Arbeit von Tom Yeh et al. [Siku2009]. erstmals 2009 vorgestellt. Entwickelt wurde es am Massachusetts Institute of Technology und es steht unter MIT-Lizenz. Sikuli ist ein Werkzeug zum automatisierten Testen von grafischen Benutzeroberflächen (GUI) und setzt für die Tests Bilderkennungsverfahren ein. Anstatt alle Mausbewegungen und Nutzereingaben auf zu zeichnen, wie das von einem Testroboter, auch als Capture & Replay Tool bezeichnet, gemacht wird, verfolgt Sikuli die Idee nur die relevanten Nutzeraktionen festzuhalten. Dafür wird für jede Aktion ein Bildschirmfoto gemacht und spezifiziert. Dann werden Aktionen mit diesen Bildern verknüpft. Diese Aktionen können z.b. das Anklicken des Bildes oder die Eingabe von Text sein. Die Bilder ermöglichen aber auch die Erstellung von Zusicherungen, dabei wird geprüft, ob sich ein bestimmter Bildausschnitt auf dem Bildschirm befindet. Der Kern von Sikuli Script ist eine Java -Bibliothek, die aus zwei Teilen besteht (Abbildung 3.2): 1. Java.awt.Robot: Die Robot Komponente sorgt dafür, dass die Nutzeraktionen an der gewünschte Stelle auf dem Bildschirm ausgeführt werden. 2. C++ Engine: Die Bildverarbeitungs-Engine basiert auf OpenCV (Open Source Computer Vision). Diese Komponente ist verantwortlich für die Suche nach den gegebenen Bildmustern auf dem Bildschirm. 19

26 Abbildung 3.2: Arbeitsweise von Sikuli[SikuWeb] Eine Ebene drüber ist die Jython API, die dem Endanwender ein Satz von klaren Befehlen zur Verfügung stellt, mit denen er ein Testskript erstellen kann. Im Folgenden wird erklärt wie mit Sikuli Tests erstellt werden kann. Dazu muss die Sikuli IDE von der Sikuli-Webseite runtergeladen werden und gestartet werden (Abbildung 3.3). 20

27 Abbildung 3.3: Sikuli Oberfläche Die Sikuli IDE gibt es für Microsoft Windows, für MacOS und für Linux. Die Sikuli- Oberfläche bietet auf der linken Seite eine Auswahl von Skript-Funktionalitäten, die mit der Maus ausgewählt werden können. Wenn sich ein Fotoapparat in der Funktion befindet, dann wird nach dem Auswählen dieser Funktion die Sikuli-Oberfläche ausgeblendet und der Screenshot-Modus aktiviert. Der Bildschirm wird leicht dunkler, so wird dem Nutzer signalisiert, dass er sich im Screenshot-Modus befindet. Der Nutzer kann mit gedrückter linker Maustaste den gewünschten Bildschirmausschnitt als Screenshot aufnehmen. Nach der Aufnahme des Ausschnittes wird der Screenshot- Modus beendet und die Sikuli-Oberfläche wird wieder eingeblendet. Die Funktion mit dem dazu gehörigen Bildausschnitt wird als ein Testschritt auf der rechten Seite angezeigt. Nach diesem Schema kann der Nutzer weitere Testschritte aufnehmen, bis er einen kompletten Testfall vorliegen hat. Sikuli bietet dem Nutzer auch die Möglichkeit Bilddateien im png-format direkt zu laden. Der Run Knopf auf der 21

28 Sikuli-Oberfläche erlaubt dem Nutzer jeden Zwischenzustand seines Tests zu überprüfen. Beim Klicken des Run-Knopfes werden die aufgezeichneten Aktionen des Nutzers Schritt für Schritt wiedergegeben. So kann er überprüfen, ob sein Skript ordnungsgemäß läuft. Ist der Test komplett, kann der Nutzer sein Skript speichern. Beim Speichern wird ein Verzeichnis angelegt. In dieses Verzeichnis werden das Testskript und alle Bilder abgelegt. Das Testskript wird als Python-Datei gespeichert. Dieses Skript kann mit jedem Texteditor geöffnet und bearbeitet werden (Listing 3.1). click("imgs/spotlight.png", 0); wait("imgs/spotlight-input.png"); type(null, "hello world\n", 0); Listing 3.1: Sikuli-Skript in Python Möchte man Sikuli von Java aus benutzen, geht das recht einfach. Dazu muss die Bibliothek sikuli-script.jar dem Java-Projekt hinzugefügt werden (Abbildung 3.4). und in der Java-Klasse die Sikuli Screen Klasse genutzt werden (Listing 3.2). Abbildung 3.4: Sikuli eingebunden im Java-Projekt 22

29 import org.sikuli.script.*; public class TestSikuli { public static void main(string[] args) { Screen s = new Screen(); try{ s.click("imgs/spotlight.png", 0); s.wait("imgs/spotlight-input.png"); s.type(null, "hello world\n", 0); } catch(findfailed e){ e.printstacktrace(); } } } Listing 3.2: Sikuli-Skript eingebunden in Java Mit Sikuli kann ein Tester Testfälle ohne Programmierkenntnis erstellen. Mit der Sikuli IDE, können Test-Skripte schnell erstellt werden. Sikuli ermöglicht die Automatisierung von allem, was auf einem Bildschirm sichtbar ist. Sikuli kann verwendet werden, um eine Webseite, eine Desktop-Anwendung, eine Android- Anwendung oder sogar eine iphone-anwendung zu automatisieren. Neben den vielen Vorteilen hat Sikuli einen entscheidenden Nachteil. Bei Veränderungen an der Benutzerschnittstelle, müssen viele Tests aufwändig nachgebessert werden, da die aufgenommenen Bildausschnitte auf dem Testsystem nicht mehr gefunden werden DOM-basierte Testautomatisierungswerkzeuge Selenium Selenium ist eines der bekanntesten und mächtigsten Testwerkzeuge für das Testen von Webanwendungen. Selenium ist Open-Source Projekt und verfügt über eine große 23

30 Entwicklergemeinde. Selenium ist nicht nur ein Werkzeug, sondern eine Ansammlung von Softwarewerkzeugen. Es besteht aus den folgenden drei Unterprojekten: Selenium IDE (IDE steht für Integrated Development Environment), Selenium 2 (auch Selenium WebDriver genannt) und dem Selenium-Grid Selenium IDE (Abbildung 3.6) ist ein Plug-In für den Mozilla Firefox Browser und bietet eine einfach zu bedienende Benutzeroberfläche, um automatisierte Tests zu erstellen. Selenium IDE ist ein Capture & Replay Testwerkzeug. Mit der Aufnahme- Funktion können die Nutzeraktionen aufgezeichnet werden. Diese können dann als ein wiederverwendbares Skript für spätere Tests exportiert werden. Selenium IDE lässt sich sehr einfach installieren. Mit wenigen Mausklicks ist es schnell installiert und lässt sich als integrierte. Abbildung 3.6: Selenium IDE [SelWeb] 24

31 Über den roten Aufnahme-Knopf wird die Aufnahme gestartet. Danach werden alle Nutzeraktion aufgezeichnet. Die Nutzeraktionen werden tabellarisch aufgelistet und zu einem Testfall zusammengefasst. Abbildung 3.8: Aufgezeichnete Nutzeraktionen[SelWeb] Die Nutzeraktionen können im Browserfenster editiert, ausgeführt, kommentiert und sogar, durch setzen von Breakpoints, debuggt werden. Das Abspielen der Testfälle erfolgt über den Browser, dabei hat man die Option den kompletten Testfall auszuführen oder nur einen einzelnen Schritt. Man kann die Testgeschwindigkeit festlegen und an die Seitenladegeschwindigkeit des Browsers anpassen. Die Tests können jeder Zeit pausiert und wieder gestartet werden. Die IDE bietet natürlich auch die Möglichkeit die Tests abzuspeichern. Mit Selenium IDE können nicht nur statische Seiten, sondern auch Webseiten mit dynamischen Inhalten, wie z.b. JavaScript- und AJAX-Funktionen, getestet werden. Obwohl der Funktionsumfang recht groß ist und dem Nutzer viele Möglichkeiten geboten werden, kann das Werkzeug nicht uneingeschränkt für die Testautomatisierung genutzt werden. So kennt es weder Bedingungen noch Schleifen. Und für die Testausführung wird der Firefox Browser gebraucht. Trotzdem ist es ein guter Einstieg in die Testautomation mit Selenium. Selenium WebDriver bietet eine objektorientierte API mit der sich dynamische Webseiten besser testen lassen. WebDriver nutzt dazu die nativen Befehle, die der Browser zur Verfügung stellt. Die Testfälle können in verschieden höheren 25

32 Programmiersprachen erstellt werden. Der Selenium WebDriver unterstützt unteranderem Programmiersprachen Java, C#, Ruby, Perl, Python und PHP. WebDriver und WebElement sind zwei zentrale Klassen von Selenium WebDriver, die von großer Bedeutung sind. Ein Objekt vom Typ WebDriver wird genutzt, um initial den Webbrowser zu starten und das Testobjekt darin zu öffnen. Alle Elemente auf einer Webseite, die mit HTML darstellbar sind, können in ein Objekt vom Typ WebElement verwandelt werden. Mit WebElement kann ein Element detailliert untersucht werden. Es ist möglich Informationen über den Elementnamen und allen Werten von dem betrachtetem Element von Attributen dieses Elements können geliefert werden. Durch den hierarchischen Aufbau der HTML-Elemente, kann WebElement ebenfalls auf alle untergeordneten Elemente zugreifen. WebElement- Objekte können mit Text gefüllt werden, wenn sie Formularfelder sind, oder angeklickt werden. Das folgende Beispiel[Listing 3.3] zeigt exemplarisch, wie WebDriver und WebElement verwendet wird. package org.openqa.selenium.example; import org.openqa.selenium.by; import org.openqa.selenium.webdriver; import org.openqa.selenium.webelement; import org.openqa.selenium.firefox.firefoxdriver; import org.openqa.selenium.support.ui.expectedcondition; import org.openqa.selenium.support.ui.webdriverwait; public class Selenium2Example { public static void main(string[] args) { // Create a new instance of the Firefox driver // Notice that the remainder of the code relies on the interface, // not the implementation. WebDriver driver = new FirefoxDriver(); // And now use this to visit Google driver.get(" // Alternatively the same thing can be done like this // driver.navigate().to(" // Find the text input element by its name WebElement element = driver.findelement(by.name("q")); // Enter something to search for element.sendkeys("cheese!"); // Now submit the form. WebDriver will find the form for us from the element element.submit(); // Check the title of the page System.out.println("Page title is: " + driver.gettitle()); // Google's search is rendered dynamically with JavaScript. // Wait for the page to load, timeout after 10 seconds (new WebDriverWait(driver, 10)).until(new ExpectedCondition<Boolean>() { public Boolean apply(webdriver d) { return d.gettitle().tolowercase().startswith("cheese!"); } }); 26

33 } } // Should see: "cheese! - Google Search" System.out.println("Page title is: " + driver.gettitle()); //Close the browser driver.quit(); Listing 3.3: Beispiel Code [SeleWeb2] Im Beispiel wird das Input-Element anhand seines Namens gefunden. Es gibt aber auch andere Möglichkeiten ein Element im HTML-Baum zu finden. Man kann sie Anhand der ID, des class-namen, des Link-Textes, des Tag-Namen oder auch mit XPath-Ausdrücken finden. Nach dem das Element gefunden wurde, kann es wie in diesem Fall drauf zugegriffen werden und mit Text befüllt werden. Mit WebDriver lassen sich alle gängigen Browser automatisieren. Automatisierung von Webanwendungen auf mobilen Endgeräten ist ebenfalls möglich. Für die sequentielle Ausführung sehr umfangreicher Tests kann die Ausführungsdauer zu einem Flaschenhals werden. Die Tests müssen parallel ausgeführt werden, um Zeit zu sparen. Selenium-Grid erlaubt die parallele Ausführung mehrerer Testskripte auf verschiedenen Maschinen (Abbildung 3.7). 27

34 Abbildung 3.7: Selenium Grid [SeleWeb] Dieses steuert über den sogenannten Selenium Hub mehrere Maschinen und ermöglicht somit die Parallelität. Der Selenium Hub besitzt Informationen über alle Maschinen, die an dem Hub gekoppelt sind. Er weiß welches Betriebssystem auf der Maschine installiert ist und er weiß welche Browser drauf laufen. Die ankommenden Selenium Befehle leitet er an die jeweiligen Maschinen. Aktuelle Forschung Aktuelle Forschungen auf dem Gebiet der Testautomatisierung versuchen den Automatisierungsgrad durch neue Methoden zu erhöhen. Nachfolgend wird eine Arbeit betrachtet, die sich mit der automatischen Testfallgenerierung befasst. Hierbei wird versucht man den Aufwand für die Erstellung der automatisierten Tests zu 28

35 minimieren. Die Tests sollen nicht von Testern bzw. von Entwicklern erstellt werden, da die Erstellung der Tests mit viel Aufwand verbunden ist. Stattdessen soll die Testfallerstellung vollautomatisiert aus dem Programmcode erstellt werden. Dallmeier et al.[webm2013] beschreiben einen Ansatz, wie Systemtests auf der Ebene der Benutzerschnittstelle erstellt werden können. Dabei betrachten sie Web 2.0 Anwendungen. Sie verfolgen den Black-Box-Ansatz und betrachten nur den Teil der Webanwendung, der im Browser läuft. In ihrer Arbeit stellen sie WebMate, eine Prototypische Implementierung eines Werkzeuges, vor und erläutern anhand dieses Werkzeuges ihren Ansatz. WebMate kann unter Zuhilfenahme von Selenium den Browser steuern, mit der Webanwendung interagieren und den Zustand der Benutzerschnittstelle extrahieren (Abbildung 3.1). Dazu wird nur die URL der zu testenden Webanwendung WebMate übergeben. WebMate braucht für die Testfallerstellung zwei Schritte. Abbildung 3.1: WebMate [WebM2013] 29

36 In der ersten Phase, der sogenannten Explorationsphase, werden alle Bedienelemente in der Webanwendung systematisch identifiziert. In Webanwendungen sind das für gewöhnlich Links, Buttons und Formularfelder. WebMate testet alle Elemente in allen möglichen Zuständen und versucht daraus das sogenannte Bedienungsmodell abzuleiten. Das Bedienungsmodell ist ein endlicher Automat. Die Zustände entsprechen den unterschiedlichen Zuständen der Webanwendung, und Zustandsübergänge sind die von WEBMATE ausgeführten Aktionen, die dazu führen, dass ein Zustand verändert wird. Die Explorationsphase wird so lange ausgeführt bis keine neuen Zustände gefunden werden und alle Bedienelemente erforscht wurden. In der zweiten Phase, der sogenannten Testphase, erstellt WebMate anhand des gelernten Bedienungsmodells die Tests. Schwierigkeiten hat WebMate wenn Elemente mit Java-Script-Anweisungen versehen sind. Da den Elementen zur Laufzeit die sogenannten Handler auch dynamisch hinzugefügt werden können, kann für die Bestimmung aller Bedienelemente der Benutzerschnittstelle nicht garantiert werden. Ausserdem macht WebMate keine Unterscheidung zwischen zwei Seiten, wenn sie die gleiche Funktionalität bieten und fasst diese als eine Seite auf. In diesen Fällen kann es vorkommen, dass nicht alle Seiten der Anwendung besucht werden. Die oben genannten Schwierigkeiten führen dazu, dass die Testfallabdeckung abnimmt. Dallmeier et al. haben WebMate einem Test unterzogen, um ihre Arbeit zu evaluieren. Dabei wurde WebMate mit einem herkömmlichen Webcrawler verglichen. Für den Test wurden 5 Projekte unterschiedlicher Größe als Testobjekte ausgewählt (Tabelle 3.1). Name Projektseite Beschreibung Größe (Quellcodezeilen) DMS dmsnew1.sourceforge.net Dokumentverwaltung 13,513 HippoCMS Inhaltsverwaltung 65,692 itracker Dokumentverwaltung 15,086 JTrac Aufgabenverwaltung 6,940 ScrumIt scrum-it-demo.bsgroupti.ch Projektmanagement 1,448 Tabelle 3.1: Testprogramme für die experimentelle Auswertung. Die Projektgröße ist die Summe der Zeilen aller bei der Programmausführung geladenen Klassen [WebM2013]. 30

37 Der Quellcode aller Testkandidaten ist verfügbar. Der Quellcode wird bei der Analyse der Testabdeckung genutzt. Um die ausgeführten Codezeilen zu ermitteln wird Cobertura[Sourceforge. Cobertura. benutzt. Die Anwendungen werden vor dem Test mit Cobertura instrumentiert. Cobertura zählt währen der Test läuft die ausgeführten Zeilen und berechnet im Anschluss die erreichte Abdeckung. WebMate erreichte bei den Tests für die Anwendung DMS eine Abdeckung von 19,3%, für HippoCMS 42,0%, für ITracker 33,2%, für JTrac 28,6% und für ScrumIt eine Abdeckung von 38,5%. Die Ergebnisse reichen von zwanzig bis zu vierzig Prozent. Das ist für die praktische Nutzung zu wenig. 31

38 Kapitel 4 Konzept und Implementierung 4.1 Konzept Webseiten werden meistens über die Benutzerschnittstelle automatisiert. Die Gründe dafür sind, dass diese Tests für den Tester anschaulicher und greifbarer sind. Sie spiegeln das Verhalten am besten das Verhalten der realen Umwelt wieder. Meistens gibt es gar keine andere Möglichkeit auf der Systemebene zu testen. Und die Tests auf dieser Ebene testen implizit auch die Ebenen da drunter. Deshalb sind sehr beliebt bei Testern [Seidl]. Die Identifizierung von Elementen in Webseiten ist oftmals schwierig. Sie sind nicht eindeutig. Oftmals werden sie Anhand ihrer Position identifiziert. Das birgt natürlich Gefahren. Denn wenn sich am Layout nur geringfügig etwas ändert, so stimmen die Positionen nicht mehr. Deshalb werde ich bei meiner Implementierung versuchen die Tests unabhängig von Fenstergröße und unabhängig von Elementposition zu gestalten. Mein Konzept wird in diesem Fall stabil bleiben. Für die eindeutige Identifizierung der Elemente wurde mit den Entwicklern abgesprochen, dass die Elemente eindeutige Bezeichner bekommen. Man hat sich auf TestId s verständig. Bei meinem Konzept habe ich drauf geachtet, dass meine Tests sich nicht gegenseitig negativ beeinflussen. Deshalb war zu entscheiden, ob die Artefakte, die durch ein Testfall hinterlassen wurde, von diesem selbst wieder rückgängig gemacht wird oder der nachfolgende Test diese Aufgabe übernehmen sollte. Schnell war klar, dass diese Aufgabe der neue Test übernehmen sollte. Denn der vorherige Test könnte, bevor er das Testobjekt wieder auf einen sauber Stand bring Fehlschlagen. Somit wäre das Testobjekt nicht mehr auf einem definierten Anfangszustand. Da das Objekt auf mobilen Endgeräten getestet werden, musste ein Testwerkzeug gefunden werden, dass diese ab testen kann. Das Tool sollte in der Lage sein sowohl Tests auf den IOS- Geräten als auch auf Android-Geräten durchzuführen. Dazu wurde als Werkzeug 32

39 Selenium ausgewählt. Die Tests sollten nicht nur auf diesen Geräten lauffähig sein, sondern sie sollten auch effizient und schnell abgearbeitet sein. Dafür wurde statt JUnit, TestNg als Testframework ausgewählt. TestNg erlaubt das parallele Ausführen von Tests, nebenbei können die Tests mit dem parameter groups gruppiert werden. Damit die Testgeräte nicht ständig per USB Kabel am Testserver hängen, sondern auch über WiFi angesteuert werden können, habe ich den RemoteDriver, das Selenium zur Verfügung stellt, benutzt. Dafür müssen sich natürlich Testserver und die Testgeräte im selben Netzwerk aufhalten. So ist es theoretisch möglich so viele Testgeräte, wie frei IP-Adressen im Netzwerk, auf einmal ansteuern und die Testfälle auf diese aufteilen und parallel ausführen. Mit dieser Möglichkeit können Testdurchläufe, die vorher 1 Std. und mehr gebraucht haben, jetzt nur noch einen Bruchteil davon brauchen. Mit 10 Geräten lässt sich die Laufzeit rechnerisch auf 1/10 reduzieren. Das bedeutet für die Entwickler in einem Scrum-Team, das sie noch schneller Feedback von der Testautomation bekommen. Für die Tests wurde das Page Object Pattern Konzept von Selenium verwendet. Mit diesem Konzept wurden die einzelnen Seiten des Testobjekts, jeweils als eine Java- Klasse definiert. Für jedes Element der betrachten Seite, wird ein Objekt vom Typ WebElement in der dazugehörigen Klasse definiert. Und für jede Nutzeraktion, dass auf diesem Element durchgeführt werden kann, wird eine Methode in der Java-Klasse angelegt. Somit hat man eine eins zu eins Übertragung der Webseite in die Java- Klasse. Damit werden redundante Elemente und Methoden im Projekt vermieden. Und es ist immer klar, wo etwas zu suchen ist. Da die Testautomation automatisch in Continuous Integration-Prozess, nach jedem einchecken von neuen Codeversionen, gestartet werden sollte, musste ein Build- Management-Tool ausgewählt werden. Die Wahl fiel auf Maven. Da Maven nicht nur den kompletten Build-Prozess der Testautomation begleitet, sondern auch sehr nützlich ist in Bezug auf Updates, der in das Projekt eingebunden Bibliotheken. 4.2 Implementierung Abschnitt 4.2 gibt einen Überblick über die in dieser Arbeit verwendeten Technologien und die darauf folgenden Abschnitte zweigen wie das Projekt umgesetzt wurde. 33

40 4.2.1 Verwendete Technologien Dell XPS M1530 Notebook Ipad 2, 3, 4 (IOS) Samsung Tab 10.1 (Android) Eclipse IDE Version: Microsoft Windows 7 (64 Bit) Java, DOM, JavaScript, HTML Selenium WebDriver Maven, TestNg, Jenkins Anlegen des Projekts Der erste Schritt war es, dass Projekt in Eclipse anzulegen. Dazu wurde das Build- Tool Maven benutzt. Maven erzeugt die pom.xml-datei (steht für Project Object Model)(Listing 4.1). Die pom-datei enthält alle Informationen über das Projekt. In der pom-datei werden alle Abhängigkeiten aufgelistet. Die Werkzeuge werden mit Ihrer aktuellen Version angegeben. Falls es in Zukunft eine neuere Version des Werkzeugs erscheint, wird in der pom-datei nur die Versionsnummer des Werkzeugs geändert. Maven sorgt dann automatisch, dass die aktualisierten Bibliotheken des Werkzeugs runtergeladen werden und die alten mir den neueren überschrieben werden. <project xmlns=" xmlns:xsi=" xsi:schemalocation=" <modelversion>4.0.0</modelversion> <groupid>de.telekom</groupid> <artifactid> 4tablet-frontend-tests</artifactid> <version>1.0-snapshot</version> <name> 4tablet Testautomation</name> <dependencies> <dependency> <groupid>org.testng</groupid> <artifactid>testng</artifactid> <version>6.8.5</version> <scope>test</scope> </dependency> <dependency> <groupid>org.seleniumhq.selenium</groupid> 34

41 <artifactid>selenium-java</artifactid> <version>2.33.0</version> </dependency> <build> <pluginmanagement> <plugins> <plugin> <groupid>org.apache.maven.plugins</groupid> <artifactid>maven-surefire-plugin</artifactid> <version>2.15</version>... </project> Listing 4.1: pom.xml Als nächstes wurde das Verzeichnis des Projektes nach dem Prinzip des Page Object Models(siehe Kapitel 4) neu strukturiert. Dazu wurden Packages (Abbildung 4.2) erstellt, die dem Aufbau des Testobjekts entsprechen. Somit landen zusammengehörige Testfälle im selben Package. Abbildung 4.1: Aufteilung des Projektes in Packages 35

42 Als nächstes wurden für die Seiten des Testobjekts, die Java-Klassen angelegt (Abbildung 4.2). Jede Klasse enthält alle Elemente der korrespondieren Seite (Listing 4.2). Jede mögliche Nutzeraktion ist mit einer Methode beschrieben (Listing 4.3) Abbildung 4.2: Page Object Model 36

43 Listing 4.2: Elemente der Webseite als WebElement Objekte 37

44 Listing 4.3: Nutzeraktionen als Methoden Abbildung 4.3 zeigt den Aufbau eines Tests: 38

45 Listing 4.4: Ausschnitt aus einem Testfall Damit die Tests auf einen definierten Zustand zurückgesetzt werden, wird per JavaScript-Injection der Komplette Testaccount resetet. In dieser Klasse, die ich AutomaticStep genannt habe, sind auch alle sonstigen Testschritte, die per JavaScript- Injections Aktionen auf der Seite ausführen. Damit das Einloggen schneller geht wurde dieser Schritt auch mit JavaScript gelöst (Listing 4.5). Listing 4.5: AutomaticSteps.java 39

46 In der Basis Klasse wird der driver vom Typ WebDriver initialisiert. Hier stehen auch die Informationen zu den Testgeräten. Und mit Parameter von TestNg wird der driver nach jedem Test beendet (Listing 4.6). Listing 4.6: Basis Klasse 40

47 Die auszuführen Tests sind in der TestNg.xml-Datei aufgelistet. Hier können die Tests den jeweiligen Testgeräten zugeteilt werden. Man kann Testpakete schnüren. Die Testgeräte sind hier parametrisiert(listing 4.7) Listing 4.7: Testng.xml 41