Modellierung und teilautomatisierte Ausführung von Tests für Android-Benutzeroberflächen

Transkript

1 TU Dresden Dresden, 21. Juni 2012 Fakultät Informatik Institut für Software- und Multimediatechnik Professur Softwaretechnologie Modellierung und teilautomatisierte Ausführung von Tests für Android-Benutzeroberflächen Großer Beleg Stefan Prasse Matrikelnummer: Betreuender Hochschullehrer: Betreuender Mitarbeiter: Jun.-Prof. Dr. Thomas Schlegel Dipl.-Inf. Georg Püschel

2

3 Eigenständigkeitserklärung Hiermit versichere ich an Eides statt, die vorliegende Arbeit selbstständig, ohne fremde Hilfe und ohne Benutzung anderer als der von mir angegebenen Quellen angefertigt zu haben. Alle aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche gekennzeichnet. Dresden, 21. Juni 2012 Stefan Prasse 3

4

5 Inhaltsverzeichnis 1. Einleitung Motivation Aufgabe Aufbau dieser Arbeit Grundlagen Softwarequalität Qualitätsmanagement Vorgehens- und Reifegradmodelle Softwaretest Testen von Benutzeroberflächen Testdaten Verwandte Arbeiten Testsprachen Testdatenintegration GUI Modellierung Testwerkzeuge Konzept Evaluierungs-App Testmetamodell Testsprache Architektur Adapter Implementierung Werkzeuge EMFText Android Robotium Testframework Ecore Metamodell EMFText Testsprache Adapter Anbindung Android Adapter

6 Inhaltsverzeichnis 6. Evaluierung Zusammenfassung und Ausblick 59 A. Literaturverzeichnis 61 B. Abbildungsverzeichnis 65 C. Anhang 67 C.1. Code Listings

7 1. Einleitung 1.1. Motivation Jährlich ermittelt der oft zitierte Chaos Report der Standish Group die Prozentzahl misslungener IT-Projekte. Aufgrund deren großen Anteil (1994: 53% 1 ) wird seit Mitte der neunziger Jahre mehr in Softwarequalität investiert. Das prüfen von Software beansprucht heutzutage, je nach Projekt, ca. 50% der Entwicklungskosten[SL04, S.15]. Dennoch scheitern auch aktuell noch viele IT-Projekte oder enden mit Zeit- oder Kostenverzug 1. Zwar ist dies in erster Linie ein Management-Problem, aber Qualitätsmanagement bildet im Management Prozess einen entscheidenden Teil, sodass Techniken der Softwarequalität einen wichtigen Bestandteil des Entwicklungszykluses darstellen. Nachdem zunächst Webapplikationen den Markt für native Desktopanwendungen geschwächt haben, sind es seit wenigen Jahren vor allem mobile Anwendungen, sogenannte Apps, die hohe Absatzzahlen unter den Privatkonsumenten verzeichnen. So wurden im vierten Quartal 2010 zum ersten Mal mehr Smartphones verkauft als PCs 2. Dabei stehen die Softwareanbieter vor der Herausforderung ihre Apps auf einer Vielzahl von Hardwareplattformen und Betriebssystemen bereitzustellen. iphone und ipad basieren auf einer verhältnismäßig stabilen Hardware, mit ios bringt Apple allerdings alljährlich eine neue Version seines Betriebssystems heraus. Microsoft hingegen hat einen relativ langen Entwicklungszyklus für sein Betriebssystem Windows Phone, welches aber auf den Smartphones verschiedenster Anbieter installiert ist. Android wiederum bietet sowohl kurze Entwicklungszyklen beim Betriebssystem, als auch die Unterstützung für unterschiedliche Hardware. Und dies sind noch nicht alle möglichen Plattformen für mobile Geräte. Mit HP, RIM, Nokia und anderen existieren viele weitere Firmen, die es in diesem Markt zu beachten gilt. Für das Qualitätsmanagement bedeutet dies, dass auch die Testframeworks diese Vielfalt unterstützen müssen. Ziel ist es dabei mit möglichst einem Framework alle Plattformen abzudecken, um die Kosten zu reduzieren. Testframeworks sind wichtig, um manuelle Tests durch Automatisierung abzulösen. Die Testautomatisierung ist notwendig geworden, da Software heutzutage Komplexitäten erreicht, bei denen manuelle Tests zu zeit- und kostenaufwändig sind, sollen sie das komplette Produkt abdecken. Die Umsetzung automatischer Tests ist zwar zunächst teurer, aber Tests können danach meist schneller und wiederholt ausgeführt werden. So steigt der finanzielle und zeitliche Nutzen von automatischen Tests mit jeder Ausführung[FG99, S.5]. Im Falle von Apps für

8 1. Einleitung mobile Anwendungen kann von der automatischen Ausführung derselben Tests auf den verschiedenen Plattfomen profitiert werden. Aufgrund der hohen Kosten im Bereich des Softwarequalitätsmanagements, ist die Testautomatisierung ein wichtiges Thema im Gebiet des Software-Test, sowohl im wissenschaftlichen, als auch im praktischen Umfeld. Da auch grafische Benutzeroberflächen (Graphical User Interface, GUI) einer großen Heterogenität unterliegen, sind bestimmte Vorkehrungen im Testframework zu treffen. Verschiedene Displaygrößen und Deklarationssprachen für Oberflächenelemente sind problematisch für die Tester. Für die Testautomatisierung von Benutzeroberflächen werden bisher oft Capture-Replay Methoden eingesetzt. Diese sind aber gerade bei unterschiedlichen Displaygrößen und Softwareänderungen fehleranfällig, da sie nur Positions- und Aktionsdaten der einzelnen Elemente speichern und so aufgezeichnete Testfälle wiedergeben. Der Vorteil der automatischen Ausführung der aufgezeichneten Testfälle verfällt, sobald auch nur ein Element in der GUI in seiner Position geändert wird. Dabei ist es während der Entstehung von Software normal, dass sich deren Oberfläche im Verlauf der Entwicklung ändert, da stetig Funktionen hinzugefügt werden, weswegen die Oberfläche teilweise neu strukturiert werden muss. Um die Testfälle universeller einsetzen zu können und gleichzeitig änderungsresistenter zu machen, bietet sich das Keyword-driven Testing an, welches im Rahmen dieser Arbeit noch genauer vorgestellt wird. Für die Automatisierung der Tests ist es wichtig, dass die geschriebenen Testskripte nicht geändert werden müssen, um sie oft unter gleichen Bedingungen ausführen zu können. Jede Anpassung der Testskripte reduziert die Profitabilität der Testautomatisierung. Mithilfe des Keyword-driven Testing und der Lokalisierung der Oberflächenelemente über beständigere Eigenschaften als deren Koordinaten, ist es möglich automatische Tests zu entwerfen, die auch bei Änderungen der zu testenden App profitabel bleiben. Ziel dieser Arbeit ist es daher ein Testframework zu entwerfen und umzusetzen, welches es erlaubt änderungsresistente Testfälle für Benutzeroberflächen zu schreiben, die automatisch auf verschiedenen Plattformen ausgeführt werden können. Die originale Aufgabenstellung findet sich im folgenden Unterkapitel Aufgabe 8

9 Juniorprofessur Software Engineering ubiquitärer Systeme Jun.-Prof. Dr.-Ing. Thomas Schlegel Hintergrund Beleg-/Diplomarbeit Institut für Software- und Multimediatechnik Modellierung und (teil-)automatisierte Ausführung von Test für Android-Benutzeroberflächen Die Vielfalt von Hardware, Betriebssystemen und Middleware auf mobilen Geräten stellt Tester vor neue Herausforderungen bei immer kürzeren Entwicklungszyklen. Jede Plattform bringt dabei eigene, deklarative Technologien zur Definition der Benutzeroberfläche mit. Die konventionelle Vorgehensweise zum automatisierten Test solcher Oberflächen ist Capture and Replay. Benutzerinteraktionen werden dabei einmalig aufgezeichnet und können später als Testfall automatisch wiederholt werden. Diese Methode hat jedoch einen erheblichen Nachteil: Sobald sich die Benutzeroberfläche ändert, werden die erzeugten Testscripte invalid, da sie nur Positions- und Aktionsdaten speichern und nicht mit dem geänderten UI-Model synchronisiert werden können. Deshalb eignet sich das Verfahren kaum für Regressionstests. Aufgabenstellung Im Rahmen dieser Arbeit soll daher ein Metamodell für Benutzeroberflächenelemente des Android-SDK und Testdaten entwickelt werden. Auf dessen Grundlage soll eine domänenspezifische Sprache für die Testfallbeschreibung über den Modellelementen entwickelt und ggfs. durch einen ein graphischer Modellierungsansatz ergänzt werden. Darauf aufbauend soll gezeigt werden, dass es möglich ist, die beschriebenen Testfälle auf einer einfachen Dialogapplikation (z.b. ein Mock-up) auszuführen. Im Rahmen der Arbeit sind Insbesondere sind folgende Aufgaben zu bearbeiten: Recherche zu existierenden Test-Möglichkeiten für mobile Plattformen (vgl. Keyword-driven Testing, Android Instrumentation Framework), speziell für Oberflächen- und Blackboxtests Notwendige Elemente im Metamodell, um die Dialogelemente zu adressieren und auf diesen aufbauende komposite Elemente zu beschreiben Als notwendig erscheinende Eingriffe in die Anwendung (Introspektion, Monitoring, Debugging, zusätzliche UI-Layer, Betriebssystemeingriff) und Möglichkeiten zum nicht-invasiven Einsatz Notwendige Teile/Elemente in einem Modell, zur vollständigen Testfallbeschreibung Ansatz zur (teil-)automatisierten Ausführung der modellierten Testfälle Möglichkeiten zur Verifikation der durch die Elemente dargestellten Daten Optional können außerdem noch weitere Fragen betrachtet werden: Wie sind die Aspekte (UI-Struktur, Ereignisse, Daten) im Modell zu trennen? Ist dieses Vorgehen auch auf andere SDKs anwendbar? Welche modellbezogenen Gemeinsamkeiten könnten genutzt werden? Zur besseren Integration in die bereits entwickelten Entwicklungswerkzeuge wird die Arbeit mit Eclipse, dem Android-SDK und EMFText bevorzugt. Die Ausarbeitung fasst die Recherche, eigene Erkenntnisse, die Implementierung, die Evaluation mit einer Beispielanwendung und die Diskussion nachvollziehbar zusammen. Ansprechpartner Betreuer/Kontakt Prüfer : Georg Püschel; Raum INF/2033 (georg.pueschel@googl .com) : Jun.-Prof. Dr. Thomas Schlegel

10 1. Einleitung 1.3. Aufbau dieser Arbeit Im folgenden Kapitel werden zunächst die theoretischen Grundlagen der Arbeit dargelegt. Kapitel 3 beschäftigt sich mit verwandten Arbeiten, um eine Abgrenzung dieser Ausarbeitung zu ermöglichen. Darauf folgt im vierten Kapitel ein Konzept zur Lösung der Aufgabenstellung, dessen Implementierung im anschließenden Kapitel vorgestellt wird. Zur besseren Integration in bereits entwickelte Werkzeuge des Softwarelehrstuhls der TU Dresden basiert die Arbeit auf Eclipse 3, dem Android-SDK 4 und EMFText 5. In Kapitel 6 folgt die Evaluierung der Arbeit durch die Anwendung des entwickelten Testframeworks auf eine Androidapplikation. Abschließend wird die Auswertung mit einem Ausblick auf eine mögliche Weiterentwicklung vollzogen

11 2. Grundlagen Das Grundlagenkapitel gibt zunächst einen Überblick über das komplexe Themengebiet Softwarequalität. In diesem werden der Softwaretest und die Testautomatisierung eingeordnet, welche die Hauptthematik dieser Arbeit bilden. Im Abschnitt Softwaretest werden der grundlegende Testprozess und verschiedene Testarten vorgestellt. Zwei weitere Unterkapitel behandeln die Grundlagen des Testens von Benutzeroberflächen und Testdaten, auf welche in den weiteren Kapiteln aufgebaut wird Softwarequalität Computer und damit auch die darauf ausgeführte Software verbreiten sich seit ungefähr 30 Jahren in rasantem Tempo im menschlichen Alltag. Waren dies zunächst nur große Desktop Computer, ist es heute durch die Miniaturisierung der Technik leicht mehrere Geräte am Körper mitzuführen. Denn auch Handy und mp3-player enthalten einen nicht zu vernachlässigbaren Anteil an Software. Des Weiteren dringt Software in Bereiche vor, in welchen sie sicherheitskritische Aufgaben übernimmt und damit für Menschenleben verantwortlich ist. Fly- oder drive-by-wire, also das Fliegen und Fahren mithilfe von Software sind nur zwei Beispiele dafür. Neben der steigenden Verbreitung von Software wächst auch deren Komplexität stetig, sodass die Wahrscheinlichkeit von Fehlern trotz ihrer sinkender Anzahl pro 1000 Zeilen Code steigt. Diese Fehler kosten der Wirtschaft jährlich Milliarden von Euro. Nach einer Studie des National Institute of Standards and Technology aus dem Jahre 2002, kosten Softwarefehler der US-amerikanischen Wirtschaft knapp 60 Milliarden Dollar jährlich 1. Deswegen ist es für jedes Unternehmen wichtig sich mit dem Thema Softwarequalität zu befassen. Zu dem großen Gebiet Softwarequalität gehört auch die in dieser Arbeit behandelte Thematik des Softwaretest. Darum sollen in den folgenden Abschnitten die Grundlagen der Softwarequalität beschrieben werden Qualitätsmanagement Qualität im Allgemeinen wird durch die Norm DIN EN ISO 9000 wie folgt definiert: Definition 2.1. Qualität ist das Vermögen einer Gesamtheit inhärenter Merkmale eines Produkts, eines Systems oder eines Prozesses zur Erfüllung von Forderungen von Kunden und anderen interessierten Parteien. [Bal08, S.461] Die DIN ISO Norm 9126 bezieht sich konkret auf Softwarequalität:

12 2. Grundlagen Definition 2.2. Software-Qualität ist die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte Erfordernisse zu erfüllen. [Hof08, S.6] Um die Softwarequalität zu messen und unter Umständen zu verbessern bedarf es also der Analyse verschiedenster Merkmale von Software. Im FCM-Modell (factor-criteriametrics model) werden die Merkmale (factors) zu Teilmerkmalen (criteria) und schließlich zu messbaren Qualitätsindikatoren bzw. Metriken (metrics) verfeinert (siehe Abbildung 2.1). Abbildung 2.1.: Factor-Criteria-Metrics Model (nach [Bal97, S.257]) Folgende sechs Qualitätsmerkmale werden dabei von der Norm als grundlegend angesehen und sind für jede Software anwendbar [Bal97, S. 257ff.]. Das Merkmal Funktionalität beschreibt in welchem Maße eine Software die von ihm geforderten Funktionen korrekt umsetzt. Ein häufiger Fehler ist die Einschränkung des Qualitätsprozesses auf dieses Merkmal. Funktionale Fehler sind so allgegenwärtig, dass der Begriff Software-Qualität häufig auf dieses singuläre Kriterium reduziert wird [Hof08, S. 7]. Auch die weiteren Merkmale sind demnach zu beachten. Effizienz bezeichnet das Verhältnis zwischen der Leistung und dem Verbrauch von Ressourcen der Software. Zwei Kriterien dieses Merkmals sind zum Beispiel Zeitverhalten und Verbrauchsverhalten. Gerade in eingebetteten Systemen wird auf dieses Merkmal großen Wert gelegt, da zum Beispiel von Software unterstützte Bremsvorgänge im Auto zeitnah geschehen sollten. Mit dem Merkmal Zuverlässigkeit wird festgestellt inwieweit das Leistungsniveau der Software über einen festgelegten Zeitraum bewahrt wird. Hier spielen Fehlertoleranz und Wiederherstellbarkeit als Teilmerkmale eine wichtige Rolle. Für Kunden ist eine gute Benutzbarkeit der Software wichtig. Unter anderem die Kriterien Erlernbarkeit und Bedienbarkeit beschreiben, welcher Aufwand für potenzielle 12

13 2.1. Softwarequalität Nutzer erforderlich ist, um die Software anzuwenden. Wichtiger für den Hersteller der Software ist die Änderbarkeit. Spätere Änderungen und Aktualisierungen sowie Korrekturen sind nur möglich, wenn Kriterien wie Stabilität und Modifizierbarkeit bei der Entwicklung beachtet wurden. Das letzte von der Norm definierte Qualitätsmerkmal heißt Übertragbarkeit. Es beschreibt die Eignung der Software in anderen Nutzungsumgebungen eingesetzt zu werden. Als unterschiedliche Umgebungen werden verschiedene Software-, Hardwareoder Organisationsumgebungen angesehen. Das Kriterium Konformität beschreibt zum Beispiel, inwieweit sich die Software an definierte Standards hält. Da sich die verschiedenen Merkmale gegenseitig beeinflussen, ist bei jeder Softwareentwicklung abzuwägen, welche Merkmale mit welcher Qualität umgesetzt werden sollen. So ist eine hohe Effizienz oft nur zu Lasten fast aller anderen Merkmale möglich. Neben dem FCM Modell existieren noch weitere, aber weniger bedeutende Qualitätsmodelle (z.b.: FURPS von HP oder das DGQ-Modell der deutschen Gesellschaft für Qualität[Bal97, S. 263]). Sind die Qualitätsanforderungen aufgestellt, bedarf es der Umsetzung durch Qualitätsmanagement und Qualitätssicherung. Die Methoden und Werkzeuge zur Qualitätssicherung teilen sich zunächst in die Bereiche Prozess- und Produktqualität auf [Hof08, Kap. 1.4]. Durch eine hohe Prozessqualität wird sicher gestellt, dass die Software-Entwicklung in einem wohldefinierten Rahmen stattfindet und von qualitativ hochwertigen Werkzeugen unterstützt wird. Die Produktqualität hingegen beschreibt Methoden und Techniken, um die oben beschriebenen Qualitätsmerkmale umzusetzen. Eine weitere Möglichkeit der Differenzierung von Maßnahmen zur Qualitätssicherung ist die Unterscheidung in konstruktive und analytische Maßnahmen[Bal97, Kap. 2.1]. Konstruktive Maßnahmen sind demnach all die Maßnahmen, die bei der Entwicklung zur Einhaltung der Qualitätsziele führen (u.a. Standards, Checklisten). Auf der anderen Seite sollen die analytischen Maßnahmen Qualitätsmängel der Software im Nachhinein aufdecken, indem die Software vermessen wird. Die konstruktiven Maßnahmen lassen sich nochmals in technische und organisatorische Maßnahmen unterteilen. Technischen Maßnahmen definieren Werkzeuge, Sprachen und Entwicklungsmethoden, welche entsprechend des Endprodukts gewählt und angewendet werden müssen. Dazu zählen unter anderem die Entwickler-Dokumentation der Software, Änderungs- und Konfigurationsmanagement zur Unterstützung der Teamarbeit oder auch das Bereitstellen von benötigter Hardware und anderen Ressourcen. Die organisatorischen Maßnahmen stellen Richtlinien und Standards bereit, welche sich an definierten Vorgehensmodellen orientieren. Die beiden Vorgehensmodelle V-Modell und RUP werden im folgenden Kapitel näher beschrieben. Ein weiteres Kapitel beschäftigt sich mit dem analytischen Qualitätsmanagement, in dessen Bereich auch die Werkzeuge und Techniken dieser Arbeit fallen. Dennoch wird ein kurzer Einblick in die Vorgehens- und Reifegradmodelle gegeben, um eine komplette Übersicht des Themas Softwarequalitätssicherung zu bieten. 13

14 2. Grundlagen Abbildung 2.2.: Das V-Modell (nach [Bal97, S.101]) Vorgehens- und Reifegradmodelle Vorgehensmodelle haben das Ziel, die Ablauforganisation von Geschäftsprozessen festzulegen. Nach Balzert sollen dabei folgende Punkte durch das Vorgehensmodell festgelegt werden[bal08, S. 449]: ˆ Reihenfolge des Arbeitsablaufs ˆ jeweils durchzuführende Aktivitäten ˆ Definition der Teilprodukte ˆ Fertigstellungskriterien ˆ notwendige Mitarbeiterqualifikationen ˆ Verantwortlichkeiten und Kompetenzen ˆ anzuwendende Standards, Richtlinien, Methoden und Werkzeuge. Vorgehensmodelle lassen sich in Phasen- und Prozessmodelle untergliedern. Je ein Modell der beiden Gruppen und dessen Ansätze zur Sicherung der Softwarequalität werden hier vorgestellt. Das V-Modell (siehe Abbildung 2.2) ist ein Phasenmodell, das bedeutet es spezifiziert die einzelnen Phasen der Softwareentwicklung zur Erstellung eines Produkts. Wie beim Wasserfallmodell[Boe81] orientieren sich die einzelnen Phasen an einem Top-Down- Ansatz. Ausgehend von der Anforderungsanalyse wird die Software schrittweise verfeinert bis einzelne Komponenten implementiert werden können. Im Gegensatz zum Was- 14

15 2.1. Softwarequalität serfallmodell gibt es aber nicht mehr nur eine Testphase fast am Ende der Entwicklung, sondern mehrere, die parallel zu den jeweiligen Konstruktionsphasen verlaufen. So werden im Modultest die Implementierungen der Module und im Abnahmetest die Umsetzung der Anforderungen überprüft. Der rechte Ast des V ist demnach eine Erweiterung des Wasserfallmodells und weist dem Test eine wesentlich größere Bedeutung zu. Eine moderne Weiterentwicklung zu einem Prozessmodell erfuhr das V-Modell in der Definition des V-Modell-XT 2 durch die Bundesregierung. Ein weit verbreiteter Vertreter der Prozessmodelle ist RUP (Rational Unified Process). Im Gegensatz zu Phasenmodellen beschäftigen sich Prozessmodelle, wie es der Name nahe legt, nicht mit den einzelnen Phasen der Entwicklung, sondern mit den Prozessen, also wann welche Artefakte (u.a. Dokumente, Teilprodukte) von wem bearbeitet werden. RUP wurde von Mitarbeitern der Firma Rational entwickelt und wird mittlerweile von IBM weitergeführt. Der Prozess basiert auf den sechs Prinzipien Prozesse anpassen, konkurrierende Prioritäten von Projektbeteiligten ausgleichen, teamübergreifend zusammenarbeiten, Nutzen iterativ nachweisen, Abstraktionsgrad erhöhen und ständige Konzentration auf die Qualität[Bal08, Kap. 22.2]. Dafür werden vier Phasen vorgeschrieben, welche bei der Entwicklung durchlaufen werden. Die Phasen sind Konzeption (inception), Ausarbeitung (elaboration), Konstruktion (construction) und Übergabe (transition). In Anlehnung an das Spiralmodell von Boehm[Boe81] wird dabei in jeder Phase iterativ gearbeitet. Das Modell gibt des Weiteren eine Empfehlung mit welchem Aufwand neun definierte Disziplinen zu welchem Zeitpunkt an der Entwicklung beteiligt sind (siehe Abbildung 2.3). Seit einiger Zeit verbreiten sich auch Prozesse der agilen Softwareentwicklung (z.b. Scrum) in der Praxis. In sehr kurzen Iterationen soll unter Verzicht auf starre Prozesse eng mit dem Kunden zusammengearbeitet werden, um dessen Anforderungen kurzfristig umzusetzen. Wenige Prozessmodelle der agilen Entwicklung haben durch ihre allgemeine Definition eine explizite Empfehlung für den Umgang mit Softwarequalität. Prinzipien ähnlich denen des Total Quality Management, wie zum Beispiel regelmäßige Tests und lauffähige Produkte nach jeder Iteration und die Nähe zum Kunden tragen allerdings zu einer guten Qualität bei. Ist ein Vorgehensmodell für die Softwareentwicklung festgelegt, bedeutet dies noch nicht, dass es richtig umgesetzt wird. Daher vertrauen viele Kunden auf Zertifizierungen der Prozessqualität, welche mittels Reifegradmodellen wie SPICE, CMMI oder der ISO 9000 Norm nachgewiesen werden. Das Capture Maturity Model (CMM) bewertet die Prozessabläufe innerhalb eines Unternehmens zur Durchführung von Projekten mit fünf sogenannten Reifegraden. Während die erste Stufe ( initial ) eine unzureichende Prozessdefinition beschreibt, bei welcher Projekte meist ad hoc und ohne allgemeines Muster ablaufen, bescheinigt Stufe 5 ( optimizing ) einen wohldefinierten, angewandten Prozess, welcher außerdem anhand von Projekterfahrungen stets optimiert wird. Das CMMI ermöglicht auch eine kontinuierliche Bewertung, bei der nicht das komplette Modell zum Einsatz kommt, sondern nur die für das Unternehmen wichtigen Teile be

16 2. Grundlagen Abbildung 2.3.: RUP (Rational Unified Process) 3 wertet werden. Die Zertifizierung wird durch autorisierte Stellen durchgeführt, welche neben der Einordnung anhand der Reifegrade auch Verbesserungsvorschläge erteilen Softwaretest Im Gegensatz zu den konstruktiven tragen die analytischen Maßnahmen der Qualitätssicherung nicht zu Qualitätssteigerungen des Produktes bei. Sie überprüfen lediglich die Qualität des Produkts und geben Mängel an die Entwicklung zurück, wo diese ausgebessert werden. Analytische Maßnahmen verlaufen allerdings nicht unabhängig von den konstruktiven Methoden. Nur wenn bei der Konstruktion der Software bestimmte Vorgaben eingehalten werden, sind Analysen erst sinnvoll oder gar möglich. Im Falle von automatisierten Tests für Benutzeroberflächen ist es zum Beispiel sinnvoll allen GUI- Elementen feste Identifikatoren zuzuweisen. Diese können in den Testskripten referenziert werden und sollten von der Entwicklung nicht geändert werden, da dies wiederum Anpassungen der Testskripte nach sich ziehen würde. Es lassen sich zwei Arten von analytischen Verfahren unterscheiden, Software-Verifikation und Software-Validierung. Definition 2.3. Verifikation ist eine formal exakte Methode, um die Konsistenz zwischen der Programmspezifikation und der Programmimplementierung für alle in Frage kommenden Eingabedaten zu beweisen [Bal97, S. 446]. Durch den hohen Aufwand alle möglichen Eingaben eines Programms und dessen Ergebnisse zu überprüfen ist ein Einsatz bis heute nur selten über wissenschaftliche Mach- 16

17 2.1. Softwarequalität barkeitsstudien hinausgekommen. Auch in sicherheitskritischen Anwendungen werden meist nur essentielle Programmteile wie zum Beispiel das Zeitverhalten verifiziert, da das Verhältnis zwischen Aufwand und Nutzen nicht wirtschaftlich genug ist. Neben den formal vollständigen Methoden, wie zum Beispiel der Deduktion (siehe [Hof08, Kap. 6]), treten daher auch immer mehr semiformale Methoden in den Vordergrund. Die abstrakte Interpretation zum Beispiel generalisiert den Eingabedatenbereich mittels statischer Programmanalyse ähnlich einer Äquivalenzklassenanalyse, sodass nicht alle Eingaben, sondern nur die verschiedenen Bereiche verifiziert werden müssen. Auch modellbasiertes Testen gehört zu den verifizierenden Techniken. Definition 2.4. Validierung (nach DIN EN ISO 9000): Bestätigung durch Bereitstellung eines objektiven Nachweises, dass die Anforderung für einen spezifisch beabsichtigten Gebrauch oder eine spezifische beabsichtigte Anwendung erfüllt worden sind. Im Gegensatz zur Verifikation prüft die Validierung nicht das komplette Programm, sondern nur dessen Verhalten in Bezug auf ausgewählte Spezifikationen. Validierung lässt sich grob in statische und dynamische Testverfahren untergliedern. Während bei statischen bzw. analytischen Maßnahmen die verschiedenen Artefakte der Entwicklung (u.a. Dokumentation, Quellcode) manuell oder durch Werkzeuge untersucht werden, wird bei dynamischen Tests das Testobjekt (zumeist das Software-Produkt oder ein Teil davon) unter verschiedenen Bedingungen ausgeführt und dabei die Korrespondenz von Ein- und Ausgabedaten geprüft. Beide haben das Ziel Fehler zu finden. Definition 2.5. Ein Fehler ist [...] die Nichterfüllung einer festgelegten Anforderung, eine Abweichung zwischen dem Istverhalten (während der Ausführung der Tests oder des Betriebs festgestellt) und dem Sollverhalten (in der Spezifikation oder den Anforderungen festgelegt) [SL04, S.7]. Des Weiteren wird zwischen Fehlerwirkung (nach außen sichtbares Fehlverhalten), Fehlerzustand (Teil der Software, welcher die Fehlerwirkung verursacht) und Fehlermaskierung (Überdeckung eines Fehlerzustands durch die Fehlerwirkung eines anderen Fehlerzustands) unterschieden. Aufbauend auf dem Fehlerbegriff lässt sich nun der Begriff Test wie folgt definieren: Definition 2.6. Beim Software-Test wird das Testobjekt unter bestimmten Rahmenbedingungen ausgeführt, um durch einen Vergleich von Soll- und Istverhalten Fehlerwirkungen aufzudecken. Das Testen unterliegt einem fundamentalem Prozess (siehe Abbildung 2.4). Einschließlich der Planung und einer ständigen Kontrolle und Steuerung des Testprozesses besteht dieser aus fünf Phasen. Während der Planung werden Umfang und Ziel des Testens definiert und in einer Teststrategie festgehalten. Da die Tests nicht die komplette Software validieren können, müssen Schwerpunkte gesetzt werden. Für die Durchführung der Tests werden Ressourcen wie Mitarbeiter und Testinfrastruktur benötigt. Auf Grundlage von Berichten durch die Mitarbeiter muss während der verschiedenen Testphasen der 17

18 2. Grundlagen Abbildung 2.4.: Fundamentaler Testprozess (nach [SL04, S.20]) Testplan und das Testkonzept kontrolliert und aktualisiert werden. Ebenso müssen Testabläufe unter Umständen angepasst werden, sodass der Plan eingehalten werden kann. Testplanung und -steuerung laufen demnach ähnlich ab wie allgemeine Projektplanung und -steuerung. Während der Analyse- und Designphase werden zunächst das zu testende System (System Under Test, SUT) und die dazugehörigen Dokumente analysiert, um herauszufinden, ob genügend Informationen für die Testerstellung vorhanden sind. Verläuft die Überprüfung positiv, werden entsprechend der Strategie des Testkonzepts die einzelnen Testfälle spezifiziert und in der Testspezifikation festgehalten. Die Spezifikation eines Testfalls wird meist aus der Systemspezifikation abgeleitet und enthält Vor-, Nach- und Randbedingungen sowie Eingabedaten und erwartete Ergebnisse. Sind die Testfälle ausreichend spezifiziert und das SUT in einem testbaren Zustand, sind die Tests durchzuführen. Dazu muss die Testinfrastruktur im Detail vorbereitet werden (Testrahmen implementieren, Testumgebung entsprechend der Testvorbedingungen konfigurieren). Testfälle werden zur Ausführung meist zu Testsequenzen oder -szenarien kombiniert. Sind die vorbereitenden Aufgaben komplett abgeschlossen, können die Tests durchgeführt werden. Entsprechend der Testart geschieht dies manuell oder durch Werkzeuge. Während der Durchführung muss ein Testprotokoll erstellt werden, in welchem alle Ergebnisse der Tests festgehalten werden, zum Beispiel Unterschiede zwischen Sollund Istverhalten oder unerwartete Fehler. Basierend auf dem Testprotokoll wird in der dritten Phase eine Testauswertung vorgenommen. Die Auswertung entscheidet anhand von sogenannten Testendekriterien, ob 18

19 2.1. Softwarequalität das Testen erfolgreich war und somit beendet werden kann oder ob die Entwicklungsabteilung das System nachbessern muss. Fehler sollten aber auch auf Seiten der Tester gesucht werden, da zum Beispiel die Testinfrastruktur fehlerhaft sein könnte oder die bei der Ausführung von Testfällen spezifizierten Bedingungen nicht eingehalten wurden. Deshalb sind im Prozess auch Rückkopplungen zu den beiden vorherigen Phasen definiert, die solche internen Fehler beseitigen sollen. Ein Testbericht ist an die zuständigen Mitglieder des Projektteams weiterzuleiten. In der letzten Phase des Testprozesses, dem Testabschluss, sollten die vorherigen Phasen analysiert werden, um Verbesserungen im eigenen Prozess zu erkennen. Außerdem müssen alle entstandenen Artefakte archiviert und genutzte Ressourcen wieder freigegeben werden. Diese Arbeit beschäftigt sich mit dem Testfalldesign durch eine domänenspezifische Sprache, der Testrealisierung und -durchführung (automatische Testausführung auf mobilen Geräten) und zum Teil mit der Testauswertung. Die Ergebnisse der ausgeführten Testfälle werden zurückgegeben aber nicht speziell aufbereitet. Neben dem grundlegenden Testprozess und dem Ziel Fehler zu finden, haben statische und dynamische Testverfahren wenig Gemeinsamkeiten. Bei statischen Verfahren wird durch Analyse der Systemdokumente (Dokumentation, Quelltext, Architektur,...) versucht deren Qualität einzuschätzen. Die Einhaltung von Codekonventionen verbessert zum Beispiel die Wartbarkeit des Systems, die Analyse der Codekomplexität (Schleifen, verschachtelter Code) gibt Aufschluss über dessen Effizienz. Konkrete Maßnahmen des statischen Tests sind Reviews und Tests mittels Werkzeugen wie Compiler oder Datenflussanalysatoren. Da sich diese Arbeit mit dynamischen Tests beschäftigt, wird im Folgenden nicht weiter auf die statischen Methoden eingegangen. Wie bereits beschrieben wird beim dynamischen Test das Testobjekt ausgeführt und dessen Effekt auf Eingabedaten durch die Analyse der Ausgabedaten bewertet. Dazu muss sich das Testobjekt in einem ausführbarem Zustand befinden, was, wie zum Beispiel bei Modultests, nicht immer der Fall ist. In diesen Fällen muss das Testobjekt in einen Testrahmen eingebettet werden, welcher die Funktion der fehlenden Programmteile nachahmt. Aufgabe des Testrahmens ist auch die Bereitstellung der Eingabedaten und Visualisierung bzw. Dokumentation der Ausgabedaten, soweit dies nicht manuell vom Tester übernommen wird. Je nach Verfügbarkeit von Informationen wird zwischen Black- und Whitebox-Testverfahren unterschieden. Bei Blackbox-Verfahren ist das Testobjekt unbekannt und kann nur anhand der Ein- und Ausgabedaten analysiert werden. Bei Whitebox-Verfahren ist das Testobjekt bekannt. Quellcode, Dokumentation, Modell, etc. sind also les- und analysierbar. Die dahingehend zugeordneten Testarten unterscheiden sich in der Auswahl der Testfälle und Festlegung der Testendekriterien. Zu den Blackbox-Verfahren zählen u.a. die Testarten Äquivalenzklassenanalyse, Grenzwertanalyse, zustandsbezogener Test, anwendungsfallbezogener Test, Entscheidungstabellentechnik und die Ursache-Wirkungsgraph-Analyse[SL04]. Es existieren natürlich noch einige andere, aber die genannten Testverfahren zählen zu den wichtigsten. Beispielhaft wird der anwendungsfallbezogene Test näher beschrieben. Im Kapitel Testdaten werden auch Äquivalenzklassen- und Grenzwertanalyse kurz erklärt. 19

20 2. Grundlagen Abbildung 2.5.: Beispiel Anwendungsfalldiagramm Die ursprünglich in der modellgetriebenen Entwicklung eingesetzten UML-Diagramme haben sich mittlerweile in fast allen Software-Projekten etabliert. Auch wenn Sie nicht immer zur konstruktiven Entwicklung beitragen, dienen sie der anschaulichen Repräsentation verschiedener Systemkomponenten. Ein Anwendungsfalldiagramm, wie beispielhaft in Abbildung 2.5 dargestellt, wird oft bei Anforderungsanalysen eingesetzt, um die entwickelten Anwendungsfälle darzustellen und mit den Kundenwünschen zu vergleichen. Das Beispiel soll ein Anwendungsfalldiagramm für die später zur Evaluierung genutzte Beispielanwendung darstellen. Es enthält den Anwendungsfall Frage beantworten. Der Nutzer soll mit der Anwendung also Fragen beantworten. Dazu muss er zuerst eine Frage wählen, was eine Voraussetzung für Frage beantworten ist. Mit der include- Anweisung wird diese Abhängigkeit dargestellt. Wurde die Frage beantwortet, wird die Lösung angezeigt. Dies wird durch die Erweiterungsanweisung (extend) mit einer angehängten Bedingung (condition) ausgedrückt. Da die Anwendungsfälle meist komplexer sind als die im Beispiel, sind sie oft noch textuell erklärt. In diesen Beschreibungen sind auch Vor-, Nach- und Randbedingungen der Fälle zu finden, zum Beispiel, dass die Anwendung gestartet sein muss und die Antwort durch die Auswahl eines Formularfeldes gewählt wird. Anwendungsfalldiagramme werden meist bei der Erstellung von Abnahme -, System- oder Integrationstests genutzt, da durch sie gut komplette Arbeitsabläufe oder wie bei der Integration das Zusammenwirken verschiedener Komponenten dargestellt wird. Im Rahmen der Testfallspezifikation kann für jeden Anwendungsfall je ein Testfall erstellt werden, der dessen Ablauf nachvollzieht. Zusätzlich können mehrere Negativtests entwickelt werden. Deren Anzahl kann aber schnell steigen, da in Anwendungsfalldiagrammen meist keine Abgrenzungskriterien definiert sind, sondern ausschließlich die vorgesehene Funktionalität. Als Testendekriterium für anwendungsfallbezogene Tests könnte die erfolgreiche Durchführung von mindestens 80 Prozent aller Testfälle gelten. Anwendungsfallbezogene Tests sind vor allem für Abnahmetests geeignet, da sie für den Kunden leicht nachvollziehbar sind und der Kunde an der Erstellung der Anwendungsfälle meist beteiligt war. Als Whitebox-Testverfahren sind u.a. Anweisungs-, Zweig- und Pfadüberdeckung, Kontrollflussmodellierung oder der Test von Bedingungen bekannt[sl04]. Auch hier gibt es zahlreiche weitere Verfahren. Als Beispiel wird die Pfadüberdeckung näher vorgestellt. Grundlage der Whitebox-Verfahren ist die Analyse der Programmlogik des Testobjekts, welches bei den Überdeckungsverfahren meist der Quellcode ist. Bei der Pfadüber- 20

21 2.1. Softwarequalität deckung wird versucht, anhand der Programmlogik die Eingabedaten so zu wählen, dass ein bestimmter Pfad im Code durchlaufen wird. Ziel ist eine komplette Pfadüberdeckung, also das es für jeden möglichen Pfad im Quellcode einen Testfall gibt. Anhand der Systemspezifikation wird dann kontrolliert, ob die korrekten Ausgabedaten zu den Eingaben geliefert wurden. Meist ist eine komplette Pfadüberdeckung nicht möglich, da zum Beispiel bei Schleifen jede mögliche Anzahl von Schleifendurchläufen einen Pfad bildet. Ist die Anzahl direkt durch die Eingabe definiert, entstehen so unendlich viele Pfade und damit Testfälle. Wenn bestimmte Programmteile gar nicht erreicht werden können, liegt ein Fehler im Programm vor. In der Praxis hat diese Technik aufgrund ihrer Komplexität eine eher geringe Bedeutung und ist daher nur für kleine sicherheitskritische Komponenten sinnvoll. Ein Blackbox-Testverfahren, bei welchem zusätzlich Informationen aus dem Testobjekt entnommen werden, wird oft als Greybox-Test bezeichnet. Das später in dieser Arbeit beschriebene Beispiel entspricht solch einem Greybox-Testverfahren. Um Identifikatoren für Oberflächenelemente anbieten und validieren zu können, werden diese aus Dateien des SUT gelesen, in welchen sie deklariert sind. Die Testfalldefinitionen orientieren sich aber an den Anwendungsfällen. Die Testauswahlkriterien sind demnach den Blackbox-basierten Verfahren zuzuordnen, ein Teil der Testdatenbereitstellung denen der Whitebox-basierten Verfahren, was nach Definition einem Greybox-Testverfahren entspricht. Im Allgemeinen ist der Ansatz des entwickelten Testframeworks allerdings auch für Black- und Whitebox-Testverfahren einsetzbar. Neben der Black- und Whitebox Unterscheidung gibt es noch eine Reihe weiterer Klassifikationsmöglichkeiten von Software-Tests. Hoffmann unterscheidet Tests zum Beispiel nach den drei Merkmalsräumen Prüfebene, Prüfkriterium und Prüfmethodik [Hof08, Kap. 4.2]. Letzteres definiert die eben beschriebene Unterscheidung von Blackbox-, Greybox- und Whitebox-Testverfahren. Die Klassifikation nach Prüfebene unterscheidet Tests entsprechend ihres Auftretens im Entwicklungszyklus. Im Falle des V-Modells wären das konkret Modul-, Integrations-, System- und Abnahmetests. Bei der Klassifikation nach Prüfkriterium werden Tests zunächst in eine der Kategorien Funktional, Operational und Temporal eingeordnet. Danach können die Tests spezieller zu Funktions-, Trivial-, Crash-, Kompabilitäts- oder Zufallstests (Funktional), Installations -, Ergonomie- oder Sicherheitstests (Operational) sowie Komplexitäts-, Laufzeit-, Last- oder Stresstests (Temporal) spezifiziert werden. Mit den drei Merkmalen kann dann jeder Test eingeordnet werden, wobei nicht alle Kombinationen sinnvoll sind. So ist es kaum möglich einen Komplexitätstest mit einem Blackbox-Verfahren durchzuführen. Weitere Klassifikationen lassen sich nach den Kriterien Testziel, Testmethode, Testobjekt, Teststufen, Testperson oder Testumfang vornehmen. Um das in dieser Arbeit vorgestellte Testframework einzugrenzen wird es wie folgt klassifiziert. Das Testobjekt ist, wie bereits mehrfach erwähnt die Benutzeroberfläche von mobilen Geräten und damit Software. Es wird im Folgenden daher oft auch von einer Application Under Test (AUT) statt eines SUT gesprochen. Als Prüfebene sind System- und Abnahmetests am wahrscheinlichsten, da Tests der Benutzeroberfläche meist komplexe Arbeitsabläufe des kompletten Programms nachahmen. Eine anwendungsfallbezogene Testfallerstellung wäre eine geeignete Methode im Rahmen der Prüfmethodik. Der Fokus beim Prüfkriterium 21

22 2. Grundlagen liegt in dieser Arbeit bei der Funktionalität. Zwar können durch das Testen der Benutzeroberfläche auch Rückschlüsse auf die Laufzeit, Benutzbarkeit oder andere Kriterien vollzogen werden, meist steht aber das Prüfen der Korrektheit aller geforderten Funktionen im Vordergrund. Vor allem die Tatsache, dass es sich um automatisierte Tests handelt, schränkt die Möglichkeit des Testens anderer Kriterien stark ein. Beim manuellen Test sind Benutzbarkeit oder Reaktionsverhalten auch neben den eigentlichen funktionalen Testzielen einschätzbar, aber der automatische Test enthält in seinen Ergebnissen keine Hinweise darauf ob das Layout fehlerhaft ist oder ein Teil der Anwendung erst nach 20 Sekunden funktioniert. Solang das Testskript alle Oberflächenelemente findet, welche benötigt werden und die Programmlogik intakt ist, wird der Testfall auch bei einem fehlerhaften Layout erfolgreich verlaufen. Ein weiteres Ziel dieser Arbeit ist die automatisierte Ausführung der Tests. Allein der Softwaretest beansprucht bereits einen Anteil um die 50 Prozent der Entwicklungskosten [SL04, S.15]. Auch wenn der Wert nur eine grobe Schätzung und stark abhängig von Projektgröße und -domäne ist, setzt sich der Ansatz der Testautomatisierung in den letzten Jahren immer weiter durch, um die Kosten zu reduzieren. Außerdem wird die Automatisierung stark von agilen Projekten voran getrieben. Die Grundsätze Continious Integration und Continious Delivery erlauben keine lang andauernden manuellen Tests. Nach jeder, oft nur ein- oder zweiwöchigen, Implementierungsiteration, sogenannter Sprints, werden Regressionstests durchgeführt, um den Fortschritt der Entwicklung und eventuell entstandene Nebeneffekte festzustellen. Die Ausführung manueller Tests würde je nach Projektfortschritt mehrere Tage dauern, automatisierte Tests hingegen können über Nacht oder am Wochenende laufen, sodass am folgenden Arbeitstag sofort mit einer neuen Iteration begonnen werden kann. Aber auch in anderen Prozessmodellen gibt es bei großen Projekten Tests die wiederholt durchgeführt werden müssen, um zum Beispiel Rückwärtskompitabilitäten zwischen verschiedenen Produktversionen nachzuweisen. Offensichtlich sind Automatisierungen unverzichtbar, da sonst der Aufwand des Testens bei steigender Iterationsanzahl zu groß wird[hf10, S. 188 ff]. Um eine Automatisierung der Tests zu ermöglichen, sind gewisse Punkte bei Architektur und Umsetzung des in dieser Arbeit entwickelten Testframeworks zu beachten, auf welche an den jeweiligen Stellen hingewiesen wird. In den folgenden beiden Abschnitten dieses Kapitels werden die Grundlagen und Techniken zum Testen von Benutzeroberflächen und zu Testdaten behandelt, auf welchen in den weiteren Kapiteln aufgebaut wird Testen von Benutzeroberflächen In der Einleitung wurden bereits die Schwächen des in der Testautomatisierung oft eingesetzten Capture-Replay-Ansatzes beschrieben. Um eine höhere Änderungsresistenz zu erreichen, ist es wünschenswert die komplette Struktur der Benutzeroberfläche eindeutig zu beschreiben. In [MBN03] werden GUIs wie folgt definiert: Definition 2.7. A Graphical User Interface (GUI) is a hierarchical, graphical front-end to a software system that accepts as input user-generated and system-generated events, 22

23 2.2. Testen von Benutzeroberflächen from a fixed set of events and produces deterministic graphical output. A GUI contains graphical widgets; each widget has a fixed set of properties. At any time during the execution of the GUI, these properties have discrete values, the set of which constitutes the state of the GUI. Eine GUI besteht also aus einem oder mehreren Fenstern, zwischen denen mittels verschiedener Events gewechselt werden kann. Jedes Fenster befindet sich dabei in einem Zustand der durch die Widgets, deren Eigenschaften und die Werte dieser Eigenschaften bestimmt wird. Werden die Übergänge zwischen Fenstern und deren Zuständen in einem Zustandsübergangsgraph festgehalten, entstehen Bäume 4, bei welchen das Startfenster an der Wurzel steht. Existieren mehrere Fenster beim Start einer Anwendung, entsteht ein Wald von Zustandsübergangsgraphen. Ist solch ein Modell gegeben, kann die GUI durch Tests validiert werden, welche die verschiedenen Pfade des Baumes entlang gehen und die Zustände mit dem Modell vergleichen. Zur Navigation bedarf es ausschließlich der Events, die die Zustandswechsel bestimmen. Ein Event besteht im Allgemeinen aus einem Fenster oder Widget und den darauf ausführbaren Aktionen, welche mit entsprechenden Daten gefüllt werden. Ein Beispiel wäre die Texteingabe (Aktion) von Hallo (Testdaten) in ein Textfeld (Widget). Da sich der Wert der Eigenschaft Textfeldinhalt geändert hat, würde ein neuer Zustand erreicht. Da oft mehrere Instanzen eines Widgets in einem Fenster existieren, müssen diese unterschieden werden können, entweder über deren Eigenschaften (Name, Farbe, Größe,...) oder eine eindeutige Kennung. Die Lokalisierung von Oberflächenelementen durch Identifikatoren macht die Tests gegenüber Layoutänderungen resistenter. Außerdem können mögliche Aktionen anhand der Elemente begegrenzt werden. Mit dieser Art von modellbasiertem Testen ist es auch möglich Testfälle automatisch generieren zu lassen. Es ist allerdings eine Strategie zur Auswahl der Testdaten nötig, da nicht alle Eingabemöglichkeiten getestet werden können[vlh + 06]. Obwohl die Testfallgeneration kein Bestandteil dieser Arbeit ist, ist die Struktur von Arbeitsabläufen in Benutzeroberflächen dargestellt worden, da diese auch wichtig für die Modellierung von GUI-spezifischen Tests ist. Da Tests oft nicht von Programmierern entworfen werden, fällt es Testern schwer komplexe Testfälle zu schreiben, in welchen jede Aktion auf der Benutzeroberfläche durch eine Reihe von technischen Befehlen umgesetzt werden muss. Um von der technischen Ebene zu abstrahieren, kann Keyword-driven Testing eingesetzt werden[buw03, FG99, S. 88ff.]. Dabei werden komplexe, lineare Befehlsfolgen, die mehrmals verwendet werden, in Skripte ausgelagert, welche über Keywords angesprochen bzw. ausgeführt werden können. So kann zum Beispiel die Auswahl eines Listeneintrags, bei welchem zuerst zur Liste und dann weiter zu dem bestimmten Eintrag navigiert und zuletzt der Eintrag selektiert werden muss, durch ein Keyword wähleeintraginliste(eintrag, liste) abgebildet werden. So wird zum einen das Schreiben von Tests vereinfacht, aber auch die 4 Es können auch zyklische Graphen entstehen, wenn nach verschiedenen Aktionen zu einem Ausgangspunkt zurückkehrt wird. Funktionalen Tests liegt aber meist ein linearer Arbeitsablauf zugrunde, der als Ast des Baumes besser dargestellt werden kann, auch wenn wenige Zustände mehrfach vorkommen. 23

24 2. Grundlagen Wartbarkeit der Testskripte, da diese an weniger Stellen angepasst werden müssen. Die selbe Technik kann benutzt werden, um oft wiederkehrende Sequenzen von Befehlen auszulagern und über ein Keyword auszuführen. Ist es zum Beispiel bei mehreren Testfällen nötig, dass ein Nutzer sich anmeldet, um bestimmte Aktionen ausführen zu können, sollte eine Sequenz unter dem Keyword anmelden erstellt werden, welches wiederum die von der technischen Ebene abstrahierenden Keywords tragenutzerein(nutzername), tragepasswortein(passwort) und klickebutton(loginbutton) beinhaltet. Der Keyword-driven Testing Ansatz ist sehr allgemein definiert und kann noch in verschiedenen weiteren Ausprägungen angewandt werden. Ein weiteres Problem von automatisierten Tests sind stetige Änderungen am SUT. Oberflächenelemente in einer Applikation werden oft über IDs angesprochen, was bei einer Änderung dieser eine aufwendige Anpassung mehrerer Testskripte nach sich ziehen kann. Deshalb sollten Attribute, über welche ein Zugriff auf GUI Elemente erfolgt ebenfalls aus den Testskripten ausgelagert werden. In den Testskripten wird dann ein Name verwendet, welcher in sogenannten Object Repositories[GXF09, S.3] oder GUI Maps auf die tatsächlichen IDs oder andere Eigenschaften, die einen Zugriff erlauben, verwiesen wird. Bei Änderungen des SUT müssen dann ausschließlich die Werte in den Object Repositories bzw. GUI Maps angepasst werden und nicht sämtliche Testskripte. Eine Besonderheit bei mobilen Geräten ist die Masse an Eingabemöglichkeiten durch den Nutzer. Während der Nutzer an einem Desktop oder Notebook auf die Eingabe per Maus und Tastatur beschränkt ist, sind bei modernen Smartphones und Tablets unter anderem auch Eingaben über Touchscreens und Lagesensoren möglich[dv10]. Des Weiteren ändert sich das Layout einer Applikation nicht nur auf unterschiedlich großen Geräten, sondern auch bei Drehung von Hoch- zu Querformat (portrait, landscape Modus). Diese Faktoren können erheblichen Einfluss auf Aussehen und Funktionalität haben und müssen bei Tests beachtet werden. Daher ist es nötig Testschritte zu erlauben, die den sogenannten Kontext von Apps beeinflussen können, ohne das Smartphone an einen anderen Ort bringen zu müssen, um dort dessen Verhalten zu prüfen. Entsprechende Befehle müssen von den jeweiligen Plattformherstellern bereitgestellt werden, da der Kontext meist vom Betriebssystem analysiert wird, worauf im Testframework kein Einfluss genommen werden kann. Die Notwendigkeit von Tests für Benutzeroberflächen von mobilen Plattformen liegt nicht allein an der Tatsache, dass sich mit ihnen das Verhalten gegenüber dem Nutzer am Besten testen lässt. Viele Apps arbeiten in der Cloud, da mobile Geräte nicht den gewünschten Speicher oder die gewünschte Leistung erbringen, oder um Online-Dienste besser integrieren zu können. Dies hat zur Folge, dass auf den mobilen Geräten oft nur die Benutzeroberfläche und Protokolle zur Übermittlung der Informationen laufen, weswegen die Begrenzung auf GUI-Tests in dieser Arbeit seine Berechtigung hat. So werden Daten wie Karten inklusive darauf basierender Routenberechnungen auf zentralen Servern gehalten und nur die Daten an den Nutzer gesandt, die dieser benötigt (z.b. Kartenausschnitte oder Navigationsanweisungen). 24

25 2.3. Testdaten 2.3. Testdaten Unabhängig von Testobjekt und Testart werden Testdaten benötigt, die als Eingaben des Programms dienen. Da es oft nicht möglich ist jeden Testfall mit allen möglichen Testdaten zu instanziieren, werden Testdaten, welche ein ähnliches Verhalten hervorrufen, zu Äquivalenzklassen zusammengefasst und jeweils mit nur einem und wenigen Repräsentanten der Äquivalenzklasse getestet. Des Weiteren sind bei Tests die Grenzwerte von besonderer Bedeutung. Wenn eine Spezifikation besagt, dass z. B. alle Mitarbeiter, die in einem Betrieb schon mindestens 5 Jahre arbeiten, eine Prämie erhalten, sollten für Testfälle Mitarbeiter gewählt werden die knapp 5, genau 5 oder mehr als 5 Jahre in dem Betrieb arbeiten. Die Äquivalenzklassen für dieses Beispiel wären zum einen die Menge der Mitarbeiter mit einem Betriebsalter von weniger als 5 Jahren und zum anderen die Menge der Mitarbeiter mit einem Betriebsalter von 5 Jahren und mehr. Außerdem sollte stets eine Äquivalenzklasse für Negativtests existieren, welche ungültige Eingaben wie -1 oder falsche Datentypen enthält. Bei Whitebox Tests können zudem Kriterien wie Pfadoder Codeabdeckung zur Auswahl von Testdaten herangezogen werden. Zur Automatisierung der Testerstellung müssen Testdaten generiert werden. [FG99] unterscheidet dabei vier Klassen von Testdatengeneratoren. Codebasierte Testgeneratoren nutzen das Testobjekt um benötigte Daten zu generieren. Eben genannte Codeund Pfadabdeckungskriterien dienen zur Begrenzung der Anzahl der Testfälle. Da nur der existierende Quellcode genutzt wird, können allerdings keine Fehler entdeckt werden, welche durch fehlenden Code entstehen. Datenbankbasierte Testdatengeneratoren analysieren Datenbankschemata oder auch Dateien verschiedener Formate um daraus verschiedene Testdatenobjekte zu erstellen. Die Abbildung der Daten auf entsprechende Testfälle muss anderweitig erfolgen. Spezifikationsbasierte Generatoren leiten Testdaten aus formal beschriebenen Spezifikationen ab. Das können zum Beispiel annotierte UML- Sequenzdiagramme sein. Je nach Spezifikation können so Sollwerte, Wertebereiche oder Negativtests genutzt werden. Die letzte der vier von Fewster und Graham genannten Testdatengeratorenansätze sind Schnittstellenbasierte Generatoren. Sie analysieren die Schnittstellen des Testobjekts, z.b. Datentypen und Definitionsbereiche von Eingaben. Im Gegensatz zur spezifikationsbasierten Generierung können keine Sollwerte erkannt werden, aber mittels Äquivalenzklassen- und Grenzwertanalyse werden alle Eingabebereiche effizient abgedeckt und Negativtests können ebenfalls abgebildet werden. In letztere Klasse fallen auch Generatoren für GUI-Testdaten. Bei der Definition von Testdaten von Benutzeroberflächen sind demzufolge alle Änderungen von Widgeteigenschaften zu betrachten sowie allgemeinere Interaktionen wie Fensterwechsel. Im Gegensatz zu Komponententests sind bei GUI-Tests keine komplexen Domänenobjekte als Eingabe zu definieren, was die Verwaltung der Testdaten erheblich vereinfacht. Zumeist beschränken sich die Eingabemöglichkeiten bei GUIs auf die Auswahl von Widgets oder Widgetelementen (Checkbox, Button, DropDownList, etc.) und Texteingaben in entsprechende Felder. Je nach Plattform können Eingabefelder Wertebereichsbeschränkungen aufweisen (z.b. Datumsangaben, Zahlen, Text,...). Informationen über diese Beschränkungen sind abhängig von der Testart (Whitebox oder Blackbox) und entsprechend detailliert zu sammeln und für die Testdatenauswahl auszuwerten. 25

26 2. Grundlagen Um Testdaten variabel und wiederverwendbar nutzen zu können, bedarf es Techniken des datadriven-testing. Diese besagt, dass Testdaten an zentralen Punkten (z.b. Dateien oder Datenbanken) gespeichert und dann über Kennungen, ähnlich der Identifikatoren von Oberflächenelementen, in die Testskripte eingebunden werden sollen. So können die gleichen Daten in verschiedenen Tests referenziert werden und notwendige Änderungen müssen an weniger Stellen getätigt werden. 26

27 3. Verwandte Arbeiten In diesem Kapitel sollen einige Arbeiten vorgestellt werden, die sich allgemein mit der Entwicklung von Testdeklarationssprachen und Tests von grafischen Benutzeroberflächen befassen, aber auch mit spezielleren Arbeiten, welche Werkzeuge für Tests von GUIs auf mobilen Plattformen beschreiben Testsprachen Eine bekannte und vor allem in der Entwicklung von Protokollen eingesetzte Testsprache ist TTCN-3 1. Abbildung 3.1 stellt die Architektur von TTCN-3 dar. TTCN-3 (Testing and Test Control Notation) ist eine standardisierte Programmiersprache zur Deklaration von Tests. Die hohe Verbreitung beim Test von Protokollen (3G, IPv6 u.a.) stammt von der engen Kopplung an das OSI-Schichtenmodell in früheren TTCN-Versionen. Diese Kopplung wurde mit Version 3 gelockert, wodurch TTCN-3 auch in anderen Softwarebereichen eingesetzt werden kann. Tests werden in TTCN-3 durch Module beschrieben. Diese enthalten einen Moduldefinitionsteil sowie einen Modulkontrollteil[GHR + 03]. Während ersterer die Testfälle beschreibt, welche die Korrektheit des SUT nachweisen sollen, ist letzterer für die Testausführung zuständig. Das SUT wird über definierte Ports bzw. das TTCN-3 Runtime Interface angesprochen und liefert die Testergebnisse als Verdicts zurück (siehe Abb. 3.2). Module können andere Module sowie Objekte aus anderen Sprachen (IDL, Java, XML) importieren, weitere können durch Erweiterungen hinzugefügt werden. Außerdem besteht die Möglichkeit Tests graphisch mittels Message Sequence Charts (MSC) zu beschreiben (siehe Abb. 3.1). TTCN-3 ist eine mächtige Sprache, mit deren Ansätzen sich wahrscheinlich auch diese Aufgabenstellung umsetzen liese. Da die Sprache aber so komplex ist, lässt sie sich nicht ohne weitere Einarbeitung von Testern nutzen. Ziel dieser Arbeit ist aber unter anderem eine einfache Sprache anzubieten, welche sofort zum Schreiben von Tests eingesetzt werden kann. Außerdem gibt es bisher nur wenige Arbeiten, welche sich mit der Nutzung von TTCN-3 außerhalb der Domäne von Protokolltests befassen. Angetrieben vom verstärkten Einsatz der modellgetriebenen Entwicklung (MDD) von Software, entstanden zahlreiche Ideen zur Deklaration und Generierung von Tests mittels UML. Neben frühen wissenschaftlichen Ansätzen, wie zum Beispiel der Nutzung von UML-Sequenzdiagrammen als formale Testbeschreibungssprache[PJ04], befasst sich seit 2001 auch die Object Management Group (OMG) mit der Erstellung eines UML

28 3. Verwandte Arbeiten Abbildung 3.1.: TTCN-3 Überblick 2 Abbildung 3.2.: TTCN-3 Adapter 3 Testprofils (UTP). Die OMG orientierte sich dabei vorwiegend an TTCN-3, aber auch den Grundsätzen von xunit-frameworks, wie JUnit. Im UTP werden drei Hauptbegriffe unterschieden: Testarchitektur, Testdaten und Testverhalten [SDGR03]. Diese drei Komponenten dienen auch der Strukturierung (als Pakete) des Metamodells des Profils. Die Komponente Testarchitektur wird zur Spezifikation von Testkomponenten und der Kommunikation mit dem SUT genutzt, entspricht also in etwa dem Modellkontrollteil der TTCN-3. Testkomponenten bilden den Rahmen zur Überprüfung des Testverhaltens in Verbindung mit entsprechenden Testdaten. Des Weiteren enthält das Testarchitekturpaket den Arbiter, welcher für die Auswertung der Testergebnisse zuständig ist. Testarchitekturen werden hauptsächlich mittels Struktur und Komponentendiagrammen entworfen. Das Testdatenpaket bündelt alle Informationen die zur Deklaration und Nutzung von Testdaten benötigt werden. Die Daten können dabei konkret oder abstrakt definiert werden. Abstrakte Daten können zum Beispiel durch logische Regeln beschrieben werden. 28

29 3.2. GUI Modellierung Das Paket Testverhalten definiert die Testfälle. Testfälle enthalten Testziele und die Aktionen der es bedarf, um das Ziel zu erreichen. Zur Modellierung kann jede Art von Verhaltensdiagrammen der UML genutzt werden. Auch Verschachtelungen, also Testverhalten, welche andere Testverhalten beinhalten, sind möglich. Die Ergebnisse von Testfällen werden mittels Verdicts beschrieben. Sie können die in der TTCN-3 definierten Werte (pass, fail, inconclusive und error) annehmen. UML Testprofilelemente können in TTCN-3 Elemente überführt werden, sodass der Schritt zwischen Modell und Implementierung nicht zu groß ist. Das UML-Testprofil dient also der Definition von Tests durch verschiedene UML-Diagrammtypen auf Basis eines speziellen UML-Metamodells. Aufgrund der Komplexität Anwendungen komplett in UML zu modellieren und die nötigen Elemente des UTP-Metamodells in eine eigene Sprache abzubilden, ist eine Nutzung in dieser Arbeit nicht möglich. Der Fokus dieser Arbeit liegt auf der automatischen Ausführung von Tests, wobei keine Eingrenzung auf Anwendungen mit modellierten Oberflächen getroffen werden soll. Zu den Testsprachen sind auch die xunit Frameworks oder TestNg zu zählen. Sie stellen aber meist nur Rahmen zur Teststrukturierung und -ausführung bereit. Die eigentlichen, funktionalen Tests werden mit den jeweiligen Programmiersprachen umgesetzt Testdatenintegration Zur Ausführung von Tests werden zumeist auch Daten benötigt, welche zum Beispiel in Benutzeroberflächen eingegeben werden. TTCN-3 verwendet dafür den oben beschriebenen datengetriebenen Testansatz, indem Testdaten in Modulen definiert werden, die in den Testfällen genutzt werden können[ghr + 03]. Dabei wird zwischen Testdatenstruktur und den eigentlichen Testdaten unterschieden. Mithilfe der Struktur können komplexe Datentypen definiert werden. Im Falle von TTCN-3 sind dies oft Nachrichten, welche zwischen Protokollen ausgetauscht werden, aber auch Objekte wie Kunden mit Namen, Adresse und Alter oder auch object maps können so abgebildet werden. Diese Strukturen können auch aus anderen Sprachen, zum Beispiel ANS.1, IDL oder XML importiert werden[fok03], wobei Views die zu importierenden Typen einschränken oder entsprechend der Testbedürfnisse umwandeln können. Konkrete Testdaten werden für die definierten Strukturen mittels Templates deklariert. In diesen können feste Werte oder Wertebereiche festgelegt werden. Ein Import von konkreten Daten ist nicht möglich und kann maximal durch die Implementierung eigener Module erfolgen GUI Modellierung Wie in Kapitel 2.2 beschrieben, ist für eine automatische Generierung von Tests ein Zustandsübergangsmodell erforderlich. Da dies aufgrund der Anzahl von Fenstern, Widgets, Widgeteigenschaften und deren Werten aufwendig zu modellieren ist, wird in Arbeiten wie [MBN03] und [AFT11] versucht diese Modelle im Nachhinein zu generieren. Die Modelle können außer zur automatischen Testfallerstellung auch zur Validierung von Testfällen genutzt werden. D. Amalfitano et al. erstellen mithilfe eines Crawlers einen Zustandsbaum der GUI, indem Sie von der Startaktivität ausgehend zufällig Events an 29

30 3. Verwandte Arbeiten die Applikation schicken. Verschiedene Widgets bilden die Zustände des Baumes, Events definieren die Zustandsübergänge. Dabei wird nicht nur die Klasse der unterschiedlichen Widgets verglichen, sondern auch deren Inhalte und Eigenschaften. Aus den verschiedenen Pfaden des Zustandsbaumes wird durch einen Testfallgenerator je ein Testfall generiert. Die Testfälle werden mittels JUnit erstellt und können auf Basis des Robotium Frameworks auf dem Androidemulator ausgeführt werden. Nach jedem Event wird dabei auf Äquivalenz zu den vorher aufgenommenen Zuständen geprüft. Die automatische Generation von Modellen der Oberfläche ist praktisch zur Testfallgeneration und kann die Nutzung von UTP vereinfachen. Die automatische Testausführung ist nur für Android implementiert und ist aufgrund eines fehlenden Metamodells, dass die Tests beschreibt, nicht auf andere Plattformen anwendbar. Um dem Problem der Invalidierung von Testskripten durch Änderungen von GUIs zu begegenen, schlagen Grechanik et al. vor sogenannte object maps zu nutzen. Dabei werden GUI-Elemente nicht direkt durch ihre Eigenschaften wie Koordinaten oder Ähnlichem in Testskripten referenziert, sondern über eigens vergebene Namen. Diese Namen werden während der Testausführung mittels der object maps aufgelöst, in welchen die zugehörigen Eigenschaften zur Identifikation abgelegt sind. Bei Änderungen der Benutzeroberfläche müssen dann nur die entsprechenden Einträge im object repository, der Sammlung von object maps, angepasst werden. Der Name, welcher in den Testskripten genutzt wird, bleibt bestehen, sodass die Testskripte nicht bearbeitet werden müssen. Grechaniks Arbeit stellt zudem einen Ansatz vor, der die object maps automatisch aktualisiert[gxf09]. Einer der ersten Ansätze des Keyword-driven Testing beschrieb die Arbeit Action Figures von Hans Buwalda[Buw03, FG99, Kap. 22]. Sein Ziel war die Trennung von Testskripten und Programmteilen, die der Ausführung automatisierter Tests dienen. Der Tester soll ausschließlich die auszuführenden Aktionen (action words) und Überprüfungen von Eigenschaften des zu testenden Systems nutzen. Die Umsetzung der Aktionen soll von Testautomatisierern oder anderen Entwicklern umgesetzt werden, die davon entsprechend mehr Wissen besitzen, als die Tester. Die benötigten action words müssen also vom Testframework bereitgestellt werden, sodass der Tester mithilfe dieser die automatischen Tests ähnlich der manuellen Tests definieren kann. Das Testframework liest dann die Testfälle ein, wandelt die genutzten action words in ausführbaren Code um und liefert die Testergebnisse zurück. Durch diesen Ansatz wird nicht nur die beschriebene Abstraktion durch Keywords erreicht, es ermöglicht auch die Definition von Tests durch Tester, die keine spezielle Automatisierungserfahrungen haben. In dieser Arbeit wird daher eine ähnliche Interpretation des Keyword-driven Testing genutzt, da dies eine der Anforderungen ist Testwerkzeuge Robotium ist ein an Selenium angelehntes Framework für Blackbox Tests von Android Oberflächen. Es führt Nutzeraktionen aus und testet Zusicherungen über die Eigenschaften der Oberfläche auf ihre Gültigkeit. Als Abstraktion des Instrumentation 30

31 3.3. Testwerkzeuge Framework ist allerdings die Möglichkeit verloren gegangen, Widgets über ihre ID lokalisieren zu können. Selenium 4 wiederum ist ein Open Source Testwerkzeug zum Test von Webseiten. Es kombiniert Keyword-driven- und Capture-Replay-Testmethoden. Mit einem Werkzeug können Nutzeraktionen auf einer Webseite als Testfall aufgenommen und später automatisch abgespielt werden. Die einzelnen Testschritte bestehen jeweils aus Element, Aktion und Testdaten, ähnlich der Events in den bereits beschriebenen Zustandsübergangsgraphen. Ein sehr mächtiges Testframework ist TEMA 5, welches an der Technischen Universität Tampere entwickelt wurde. Es stellt eine Menge von modellbasierten Testwerkzeugen bereit, die speziell für GUI Tests auf Smartphones entworfen wurden. Ein Modell Designer ermöglicht das Erstellen von Zustandsmaschinen des SUT. Dabei wird zwischen action machines und refinement machines unterschieden. Erstere bilden abstrakte Modelle, die geräteunabhängig gültig sind. Ihre Zustandswechsel sind durch abstrakte Aktionen (z.b. awsendmms) definiert. Zustände können für Verifikationen verwendet werden. Die abstrakten Aktionen werden in den geräteabhängigen refinement machines auf Keywords abgebildet, welche konkrete GUI-Aktionen, wie das Betätigen eines Buttons, darstellen. Testdaten und Lokalisierung können von Tabellen angesprochen werden, die später vom Tester gefüllt werden. Die Testkontrolle erfolgt durch eine Weboberfläche, welche das Ausführen von Tests und deren Auswertung ermöglicht. Dabei kann zwischen Online- und Offlinetests, sowie zwischen automatisierten Smoketests und selbst definierten Tests gewählt werden. Bei selbst definierten Tests werden die in den Modellen definierten Keywords ausgewählt und zu entsprechenden Testfällen zusammengesetzt. Die Testausführung erfolgt über Adapter, welche die plattformspezifischen Keywords bereitstellen und auf dem SUT ausführen. Das Framework enthält eine Bibliothek zur Erstellung eigener Adapter, stellt aber auch bereits einige Adapter, z.b. für Android oder die Nokia S60 Platform, bereit. [PTK11] zeigt die Möglichkeit der Erweiterung des Frameworks zum Test von Swing Oberflächen mittels des Robot Frameworks 6. Das TEMA Framework unterstützt die meisten Anforderungen an diese Arbeit, so zum Beispiel die automatische Testausführung auf verschiedenen Plattformen oder eine große Änderungsresistenz aufgrund der Anwendung des Keyword-driven Testing. Dem Framework fehlt allerdings die Möglichkeit Tests zu schreiben. Automatische Stresstests sind praktisch, aber dennoch werden Testskripte benötigt, welche vorgegebene Anwendungsfälle überprüfen. Die Erstellung von Tests über die Weboberfläche ist in diesem Sinne zu umständlich. Androidspezifische Testwerkzeuge sind Monkey und MonkeyRunner. Monkey ist ein Kommandozeilenprogramm, das zufällig Events an den Androidemulator oder ein angeschlossenes Androidgerät senden kann. Es ist vor allem für Stresstests geeignet, kann aber auch zur Fehlerfindung dienen, wie die Arbeit [HN11] zeigt. C. Hu und I. Neamtiu lassen Monkey auf allen Aktivitäten einer Applikation laufen und schreiben die Ergebnis

32 3. Verwandte Arbeiten se in Logfiles. In diesen benutzen Sie Muster, um verschiedene Fehlerarten aufzudecken. In ihrer Fallstudie haben Sie in zehn bekannten Applikationen 9 neue und 90 Prozent der bekannten Fehler gefunden. Auch der Androidadapter vom TEMA Framework beruht auf Monkey. MonkeyRunner stellt eine API bereit, mit welcher Nutzeraktionen, wie Tastenanschläge oder Touchevents, an den Emulator oder ein angeschlossenes Gerät gesendet werden können. Zusätzlich erlaubt es die Aufnahme von Screenshots und deren Vergleich. So ist es möglich Funktions- und Regressionstest zu definieren, die allerdings allein auf der Auswertung von Screenshots beruhen und damit dieselben Nachteile wie Capture-Replay Tests haben. 32

33 4. Konzept In diesem Kapitel soll das Konzept zur Lösung der Aufgabenstellung beschrieben werden. Zum Erreichen der Hauptziele Plattformunabhängigkeit, Modellierung für Tests von Benutzeroberflächen mittels einer abstrakten Testsprache und deren automatische Ausführung werden zwei Ansätze miteinander verbunden. Nach der Vorstellung einer Android App, welche zur Veranschaulichung von Beispielen und später zur Evaluierung dient, wird ein Metamodell (Kapitel 4.2) vorgestellt, mit welchem Tests für Benutzeroberflächen modelliert werden können. Das Metamodell kann nicht nur für Benutzeroberflächen von mobilen Plattformen benutzt werden, es ist in gleichem Maße auf traditionelle Desktopoberflächen anwendbar. Dabei werden existierende Ansätze der Teststrukturierung und des Keyword-driven Testing im Metamodell verbunden, welches danach zur Generierung einer Testsprache genutzt wird (Kapitel 4.3). Der Gebrauch von domänenspezifischen Testsprachen ist wenig verbreitet. Keine der im vorherigen Kapitel vorgestellten Arbeiten, welche sich mit Tests von Benutzeroberflächen befassen, nutzen eine definierte Sprache. Dabei vereinfacht sich die Arbeit für die Tester, wenn ihnen eine Abstraktion von der meist technischen Ebene der Testskriptbeschreibung angeboten wird. Gültige Testskripte wiederum sind nötig, um eine Automatisierung der Tests zu ermöglichen. Die Automatisierung und Plattformunabhängigkeit wird durch die in Kapitel 4.4 dargestellte Architektur des zu entwickelnden Testframeworks erreicht. Dabei steht die Auslagerung plattformspezifischer Elemente in je nach Plattform verschiedene Adapter im Vordergrund. Im Metamodell wurden ebenfalls Vorkehrungen getroffen, um die Automatisierung und das Nutzen von Adaptern zu ermöglichen. So wird in jedem Testmodell der zu nutzende Adapter angegeben und die Lokalisierung von Oberflächenelementen erfolgt über IDs. Das Finden von Elementen über ihre Syntax ist wesentlich änderungsresistenter als die Nutzung der visuellen Repräsentation (z.b. Koordinaten). Die Erklärung dafür wurde bereits im Grundlagenkapitel gegeben Evaluierungs-App Um die konzeptionelle Lösung zu veranschaulichen und diese später zu evaluieren, wurde eine Beispielapplikation für Android entwickelt. Sie trägt den Namen Planetenquiz. Die App basiert auf der Beispiel-App Spinner aus dem Android SDK, welche aus einem Fenster besteht, das eine Dropdown Auswahl enthält, von welcher einer der Planeten unseres Sonnensystems ausgewählt werden kann. Ausgehend von dem Beispiel wurde im Fenster je nach Auswahl des Planeten die Frage Wie viele Monde hat der Planet X? hinzugefügt, sowie je eine richtige und falsche Antwort in Form von Radio Buttons angeboten. Hat der Nutzer eine Antwort ausgewählt, wird zum nächsten Planeten und 33

34 4. Konzept Abbildung 4.1.: Evaluierungs-App damit zur nächsten Frage gewechselt und angegeben ob die vorherige Antwort korrekt war. Außerdem ist es möglich durch Auswahl eines Planeten bereits getätigte Antworten anzusehen. Zusätzlich wurde die App um zwei weitere Fenster erweitert. Das erste fragt den Namen des Nutzers ab und startet das Quiz. Das zweite zeigt dem Nutzer eine Auswertung an. Abbildung 4.1 zeigt die drei Fenster der Evaluierungs-App. Um bei der Anwendung des Testframeworks Fehler zu finden, wurden folgende eingebaut: Wird ein Planet gewählt, für welchen die Frage bereits beantwortet wurde, wird nicht die Auswertung dieser Antwort angezeigt sondern die der zuletzt getätigten Antwort. Außerdem ist die Angabe der korrekten Antworten im Auswertungsfenster falsch. Es wird die Anzahl der falschen Antworten angezeigt, nicht die der korrekten. In Kapitel 6 sind die zugehörigen Tests zu finden Testmetamodell Abbildung 4.2 zeigt das entworfene Metamodell für Tests als Klassendiagramm. Die Bestandteile werden im Folgenden erläutert. Das Modell lässt sich in drei Teile gliedern, die dem horizontalen Verlauf in der Abbildung entsprechen. Auf der linken Seite befinden sich die Komponenten für die Teststrukturierung, in der Mitte die für das Testverhalten und rechts sind die Testdaten definiert. Diese Unterteilung entspricht in etwa denen von TTCN-3 und UTP. Die Klasse TestSuite ist der Ausgangspunkt eines jeden Modells. Die TestSuite hat einen Namen und beinhaltet Testfälle sowie Sequenzen. Außerdem werden in ihr definiert, mit welchem Adapter die Testfälle ausgeführt werden und welche Applikation getestet wird. Die Klassen TestCase und Sequence haben einen Namen und beinhalten einen oder mehrere Testschritte (AbstractTestStep). Im Unterschied zu Sequenzen können Testfälle ausgeführt werden und haben deshalb auch das Attribut verdict, welches das Ergebnis des Tests enthält. Verdikte können die aus TTCN-3 und UTP bekannten Werte Pass (Test erfolgreich), Fail (fehlgeschlagen), Inconclusive (nicht auswertbar) und Error (unerwarteter Fehler bei der Testausführung) enthalten. Sequenzen werden benutzt, um oft verwendete Testschritte zu bündeln, welche dann durch Angabe des Namens selbst als 34

35 4.2. Testmetamodell Abbildung 4.2.: Test Metamodell 35

36 4. Konzept Testschritt benutzt werden können. Ihr Name dient demnach als Keyword zur Abstraktion von mehreren Testschritten. Mit diesen vier Klassen lassen sich Tests strukturieren. TestSuite, TestCase und TestStep sind aus den xunit Derivaten bekannt und etabliert. Die Sequenz wurde aufgrund der Erkenntnisse des Keyword-driven Testing hinzugefügt und erlaubt eine Form von Modularität, die bei rein iterativer Angabe der Testschritte nicht möglich wäre. Das Testverhalten des Modells ist durch die verschiedenen Testschritte definiert. Um eine Sequenz in einem Testfall zu nutzen, kann eine Instanz der Klasse SequentialStep erstellt werden. Sie referenziert anhand ihres eigenen Namens auf eine definierte Sequenz und fügt die dort enthaltenen Testschritte im aktuellen Kontext aus. Weitere mögliche Testschritte sind durch die Klassen Keyword und Assertion gegeben. Ein Keyword stellt eine Aktion in der Applikation dar. Das Keyword selbst ist als Attribut Name in der Klasse eingetragen. Des Weiteren kann auf ein UIElementLocator verwiesen werden, soweit dieser vom Keyword benötigt wird. Der Locator enthält ein Attribut ID, über dessen Wert die auszuführende Aktion einem Element in der Benutzeroberfläche der AUT zugewiesen wird. Außerdem kann ein Keyword Testdaten enthalten, die an die AUT übergeben werden sollen. Keywords können sowohl für die Eingabe von Daten, als auch für die Abfrage von Eigenschaften der AUT genutzt werden. Ein kurzes Beispiel soll die Nutzung von Keywords veranschaulichen. In der Evaluierungs-App muss der Nutzer einen Namen eingeben, bevor er das Quiz starten kann. Um diese Aktion im Test nachzuahmen, kann der Tester das Keyword entertext mit einem Locator mit der ID textfield und dem Testdatum Max nutzen. Die Ausführung dieses Schrittes sollte zur Folge haben, dass in dem Textfeld der Name Max erscheint, unter der Annahme, dass das Textfeld die angegebene ID besitzt. Genauso kann im Test aber auch das Keyword gettext mit dem selben Locator genutzt werden, welcher den Namen zurückgibt, der im Textfeld eingegeben ist. Die Auslagerung der ID in eine Locator Klasse wurde vorgenommen, um später leichter weitere Identifikationsmechanismen einzufügen. Am Beispiel Android sind IDs ausreichend, falls eine Plattform aber keinen ähnlichen Mechanismus bietet könnte das Metamodell an dieser Stelle erweitert werden ohne bestehende Tests zu zerstören. Keywords werden vom Adapter bereitgestellt, was Vor- und Nachteile hat, welche im abschließenden Kapitel aufgezeigt werden. Der dritte mögliche Testschritt, die Assertion hat einen Namen (Attribut assert) und verweist zum einen auf ein Keyword und zum anderen auf ein Testdatum. Über das Keyword soll ein aktueller Wert in der AUT ausgelesen werden, welcher mit dem angegebenen Testdatum verglichen wird. Bei Zusicherungen mit einem Argument (z.b. asserttrue ) wird nur ein Keyword angegeben. Zudem kann jede Assertion mit einem Verdict versehen werden, welches die Bewertung des Tests bei einem Fehlschlagen der Assertion übernimmt. So kann eine weniger wichtige Prüfung mit PASS versehen werden, was bedeuten würde, dass der Test trotz Fehlschlagens dieser Überprüfung als erfolgreich angesehen wird. Im dritten Abschnitt der Abbildung befinden sich die Klassen zur Definition von Testdaten. Hier wurden zunächst nur die grundlegenden Datentypen Zahl, Zeichenkette und boolescher Wert abgebildet. Die Art der Datentypen ist für GUI-Tests ausreichend. Den- 36

37 4.3. Testsprache noch wäre eine Integration eines datengetriebenen Ansatzes besser, was ebenfalls im abschließenden Kapitel diskutiert wird. Das Metamodell enthält einfache Strukturen zur Deklaration der Tests. Die Evaluierung wird zeigen inwieweit die Anforderungen dadurch erfüllt werden. Die Existenz des Metamodells bildet die Grundlage zum einen für die Testsprache und zum anderen für die automatische Testausführung. Nur wenn den ausführenden Adaptern Tests nach einem festen Modell vorliegen, können sie diese in ausführbare Skripte umwandeln. Die Keywords übernehmen dabei die Aufgabe der im vorherigen Kapitel beschriebenen action words. Sie sollen die Definition von Tests auch für nicht-programmierer ermöglichen Testsprache Aufbauend auf dem Testmetamodell kann nun eine Sprache entwickelt werden, durch welche Tester möglichst einfach aber dennoch vollständig Tests deklarieren können. Im Folgenden wird die Sprache in EBNF-Notation 1 dargestellt. Dazu wird ausgehend von der Wurzel des Metamodells, der TestSuite, jede benötigte Mataklasse in Form eines Nichtterminalsymbols definiert. Zum besseren Verständnis sind Attribute von Klassen mit ihren Namen (z.b. TestSuite.name) statt eines extra Nichtterminals aufgeführt. Sie entsprechen zumeist einer beliebigen Folge von Zeichen beginnend mit einem Buchstaben. Integer.dataValue entspricht offensichtlich einer beliebigen Ganzzahl. Des Weiteren wurden Whitespace-Zeichen nicht beachtet. <TestSuite> = "TESTSUITE {", "suitename:", TestSuite.name, ",", "systemundertest:", TestSuite.systemUnderTest, ",", "adapter:", TestSuite.adapter, <Sequence>*, <TestCase>+, "}"; <TestCase> = "TESTCASE {", "casename:", TestCase.name, (<AbstractTestStep>, ";")+, "}"; <AbstractTestStep> = <Assertion> <SequentialStep> <Keyword>; <Assertion> = "ASSERT", Assertion.assert, "(", actual (",", expected)?, ")", (":", <Verdict>)?; <Verdict> = "PASS" "FAIL" "ERROR" "INCONCLUSIVE"; <Keyword> = Keyword.name, (":", <UIElementLocator>)?, ("(", <TestData> (",", <TestData>)*, ")")?; <UIElementLocator> = "id:", UIElementLocator.id; <TestData> = Integer String Boolean; <Integer> = Integer.dataValue; <Boolean> = "true" "false"; <String> = ", String.dataValue, " ; Um die Strukturen und Funktionen der einzelnen Elemente zu verdeutlichen, werden im Folgenden kleine Beispiele gegeben und erklärt. Eine komplette TestSuite ist im 1 Die erweiterte Backus-Naur-Form ist eine in der Informatik weit verbreitete Notation, um Grammatiken und Sprachen zu veranschaulichen. 37

38 4. Konzept nächsten Kapitel enthalten. Die Beschreibung eines Testmodells beginnt mit der Deklaration der TestSuite und deren benötigter Eigenschaften. TESTSUITE { suitename: PlanetenQuizTests, systemundertest: Planetenquiz, adapter: androidadapter,... } Diese Testdefinition besagt, dass die TestSuite den Namen PlanetenQuizTests trägt, die Tests auf der App Planetenquiz ausgeführt werden und als Adapter ein androidadapter genutzt wird. Über diesen Adapter läuft die Testvalidierung und -ausführung sowie die Bereitstellung der Keywords und weiterer Elemente. Im nächsten Schritt können Sequenzen definiert werden, welche innerhalb von Testfällen, aber auch anderen Sequenzen genutzt werden können. Da mehrere Testfälle existieren werden, welche im Startfenster das Namensfeld ausfüllen und auf den Los geht s Button mit der entsprechenden ID klicken, werden diese Aktionen in eine Sequenz ausgelagert. SEQUENCE startscreen { entertext : id entername : "Stefan"; clickonbutton : id start; } Durch diese Definition einer Sequenz von Befehlen kann diese über die Angabe des Namens startscreen in allen Testfällen benutzt werden. Bei der Nutzung in anderen Sequenzen ist darauf zu achten, dass keine Endlosschleifen entstehen. Wie IDs und Keywords vom Android Adapter bereitgestellt werden, wird im nächsten Kapitel beschrieben. Die Definition der TestSuite endet schließlich mit der Beschreibung von einem oder mehreren Testfällen, welche wie folgt aussehen. TESTCASE { casename:beispiel startscreen; ASSERT asserttrue(searchtext : "Merkur"); clickonbutton : id radio0; ASSERT asserttrue(searchtext : "Venus"; clickonbutton : id radio1; ASSERT asserttrue(isspinnertextselected : "Erde"); clickonbutton : id radio1; clickonbutton : id viewresult; ASSERT asserttrue(searchtext : "Stefan") : PASS; 38

39 4.4. Architektur } ASSERT asserttrue(searchtext : "3/9") : ERROR; Der Testfall trägt den Namen beispiel. Zunächst wird die Sequenz startscreen aufgerufen, die oben beschrieben wurde. Danach wird für die ersten drei Planeten mittels Assertions jeweils geprüft ob sie ausgewählt sind. Dabei hilft das Keyword searchtext, welches die Assertion bestätigt, falls der angegebene Text gefunden wurde. Nach der erfolgreichen Assertion wird jeweils eine Antwort gewählt, indem ein Auswahl Button mit der jeweiligen ID durch das Keyword clickonbutton ausgewählt wird. Durch die Auswahl einer Antwort springt die App zum nächsten Planeten. Nach drei gegebenen Antworten wird das Quiz durch einen Klick auf den Button mit der ID viewresult beendet und mit zwei weiteren Assertions geprüft, ob das Ergebnis mit dem im Startfenster eingegebenen Namen personalisiert wurde und die korrekte Anzahl von richtigen Antworten ausgewiesen wird. Beide Assertions wurden außerdem mit einem Verdikt versehen, welcher beschreibt, was das Fehlschlagen der Assertion für das Testergebnis bedeutet. So wird in diesem Fall weniger Wert auf die Existenz des Namens gelegt, die korrekte Anzahl der richtigen Antworten ist aber sehr wichtig. Wird der Name nicht angezeigt, kann der Test trotzdem als erfolgreich gewertet werden ( PASS ), die falsche Anzeige der Antworten provoziert aber einen Fehlerzustand des Tests ( ERROR ). Wird kein Verdikt angegeben, gilt der Standardwert FAIL. Die Anzahl von Testfällen und Sequenzen ist, wie im Metamodell festgelegt, unbegrenzt. Die einzige Bedingung an ein korrektes Testmodell ist die Existenz von mindestens einem Testfall, welcher wiederum zumindest einen Testschritt enthält. Die Sprache hat eine einfache Struktur, da sie nur wenige Elemente enthält. So soll es auch Testern ohne Programmiererfahrung möglich sein Tests zu erstellen. Durch die Nutzung von Keywords und IDs zur Lokalisierung von Elementen besitzt die Sprache die nötigen Techniken, um die entstehenden Testskripte gegenüber Änderungen unempfindlich zu machen Architektur Aufbauend auf Metamodell und Testsprache wird eine Architektur entwickelt, welche es erlaubt die definierten Tests auf verschiedenen Plattformen auszuführen. Da Keywords und auch Assertions nicht im Metamodell oder der Sprache festgehalten sind, sondern vom Adapter bereitgestellt werden, ist es außerdem sinnvoll diese über Vorschläge dem Tester sichtbar zu machen. Ähnliches gilt für die IDs der Elemente, welche abhängig von der zu testenden Applikation sind und durch Vorschläge direkt beim Schreiben der Tests nicht erst vom Nutzer gesucht werden müssen. Die Implementierung der Keywords erfolgt ebenfalls in den Adaptern. Dadurch wird die gwünschte Trennung von Testdefinition durch Tester und Implementierung durch Automatisierer erreicht. Im Gegensatz zu den Testsprachen TTCN-3 oder dem UML-Testprofil wird die Steuerung der Tests nicht selbst in der Sprache festgehalten, sondern durch die Adapter vollzogen. TTCN-3 nutzt auch Adapter zur Testausführung, erlaubt aber eine wesentlich 39

40 4. Konzept Abbildung 4.3.: Architekturdiagramm weitreichendere Konfiguration dieser in der Testsprache. Auch das vorgestellte TEMA- Framework nutzt Adapter zur Testausführung, wobei dieser aber erst bei der Testausführung angegeben wird und so keine plattformspezifischen Werte bei der Testfalldefinition bereitstellen kann[tmk09]. In dieser Arbeit wird der zu nutzende Adapter im Testmodell eingetragen. Um die Adapter einheitlich ansprechen zu können, bedarf es einer fest deklarierten Schnittstelle, die von den plattformspezifischen Adapterinstanzen umgesetzt werden muss. Die Schnittstelle ist in Listing C.3 festgehalten. Sie enthält ausschließlich elementare Datentypen und im Metamodell definierte Typen, um die Verbindung zwischen Adapter und Testsprache einfach zu halten. Der Adapter dient damit als Kommunikationsschicht zwischen Testmodell und SUT. Die Auslagerung der Funktionalitäten ermöglicht die Unterstützung verschiedenster Plattformen, ohne das Metamodell oder die Testsprache anpassen zu müssen. Einige Beispiele für mögliche Adapter folgen im nächsten Abschnitt. In Kapitel 5 ist festgehalten, an welchen Stellen der Adapter in den Werkzeugen der Testsprache verankert ist, um Validierung, Code-Vervollständigung und Testausführung zu ermöglichen. Abbildung 4.3 veranschaulicht die angedeutete Struktur Adapter Wie bereits beschrieben, zählen die Testausführung und die Bereitstellung von Keywords, Assertions und IDs der GUI-Elemente zu den Funktionalitäten des Adapters. Die Vervollständigungen bzw. Vorschläge sind sinnvoll, da der Tester die zu testende Applikation oft nicht gut kennt und Details wie IDs oft nicht in Dokumenten festgehalten werden. Bei Assertions und Keywords wird dies benötigt, da sie plattformspezifisch, d.h. je Adapter bereitgestellt werden und der Nutzer nicht die möglichen Keywords und Assertions aller Adapter kennen kann. Die Modellvalidierung geschieht auf Seiten der Testsprache, nutzt aber ebenfalls die Daten, welche durch den Adapter bereitgestellt wurden (Keywords, Assertions und IDs). Vor allem die Validierung der IDs ist für den Tester praktisch, da bei Änderungen seitens der App-Entwickler eine notwendige Anpassung sofort ersichtlich ist. Die Validierung von Assertions und Keywords ist notwendig, da bei falschen Angaben eine Testausführung unmöglich ist. Der zu nutzende Adapter wird in der TestSuite angegeben. Wie der Adapter die bereitzustellenden Daten ermittelt und die Tests ausführt ist nicht festgelegt und erlaubt damit verschiedene Einsatzszenarien. So können Adapter sowohl White- als auch Blackboxtests ausführen, Keywords von existierenden Frameworks verwenden oder eigene de- 40

41 4.4. Architektur finieren oder auch als Zwischenschicht für mehrere Adapter fungieren. Letzteres erlaubt die gleichzeitige Ausführung von Tests auf mehreren Plattformen. Dazu benötigt der Adapter ein Keywordmapping von Keywords, welche in den Tests genutzt werden auf Keywords die von den jeweiligen Plattformen bzw. weiteren darunter liegenden Adaptern verstanden werden. Ähnliche Mappings müssen auch für IDs und Assertions existieren. Im nächsten Kapitel wird ein einfacher Adapter für den Android Emulator gezeigt, welcher auf einem existierenden Keyword-basierten Framework aufbaut und die IDs über Whitebox Methoden aus der AUT extrahiert. 41

42

43 5. Implementierung In den folgenden Abschnitten des Kapitels wird die Umsetzung des eben beschriebenen Konzepts dargestellt. Dafür werden zunächst die genutzten Werkzeuge und Frameworks vorgestellt und danach die Implementierung der Frameworkelemente Metamodell, Testsprache und Adapter erklärt Werkzeuge Zur Generation einer Testsprache aus einem gegebenen Metamodell, wurde an der Informatikfakultät der TU Dresden das Werkzeug EMFText 1 entwickelt. Dieses wird in Verbindung mit Eclipse und EMF für die Definition des Metamodells und der Testsprache des Testframeworks eingesetzt. Obwohl das Testframework plattformunabhängig arbeiten soll, wird für die Evaluierung und zur Orientierung eine mobile Plattform benötigt. Die Wahl fiel dabei auf Android, welches ebenso wie EMFText und Robotium, einem Testwerkzeug für Android in den nächsten Kapiteln beschrieben wird EMFText Zur Erstellung des Metamodells für die Testsprache wird in dieser Arbeit ein Ecore- Metamodell definiert. Ecore ist Bestandteil des Eclipse Modelling Framework (EMF), ein von der Eclipse Foundation initiiertes Modellierungsframework. EMF startete als eine Implementierung des Meta Object Facility Standards (MOF) der OMG Gruppe, unterstützt derzeit aber nur die Kernfunktionalität der MOF API. Dieses MOF-artige Metamodell wird daher Ecore genannt. Aufbauend auf einem Ecore Metamodell, kann mittels EMFText eine domänenspezifische Sprache (DSL) erzeugt werden, welche eine syntaktisch einfachere Erzeugung von Modellen erlaubt. EMFText selbst ist als Plugin für die Eclipse IDE umgesetzt und hat sich als Werkzeug für Modellsprachen im Eclipse Ökosystem bewährt. Es zählt zusammen mit XText 2 zu den wichtigsten Vertretern seiner Art. Mit EMFText wurde bereits eine Reihe von existierenden Sprachen nachgebaut (z.b. die komplette Java 5 Syntax), aber auch einige neue DSLs erstellt. Die Breite von Anwendungen reicht dabei von Ontologien bis zu Sprachen für Formulare. Zur Erstellung einer eigenen Sprache wird zunächst das Ecore Metamodell, sowie eine darauf aufbauende konkrete Syntax benötigt. In der konkreten Syntax ist definiert,

44 5. Implementierung durch welche Textbausteine Modellelemente konstruiert werden, indem jedem Metamodellelement eine bestimmte Syntax, ähnlich der EBNF Notation, zugeordnet wird. Ein Beispiel wird im nächsten Kapitel gegeben. Wurden sowohl das Metamodell, als auch die zugehörige Syntax vollständig ausgearbeitet, generiert ein Code Generator Java Code, der es ermöglicht Modelle als Instanzen des Metamodells textuell zu erstellen. Der Code Generator geht dabei in zwei Schritten vor. Zuerst werden Interfaces und Implementierungen der im Metamodell definierten Klassen erstellt. Danach werden zwei Eclipse Plugins generiert, welche die grafisch unterstützte Erstellung und Validierung von Modellen in Eclipse realisieren. Durch Installation der Plugins in eine beliebige Eclipse IDE, erhält der Nutzer dann die Möglichkeit seine Modelle in einem Editor konform zum Metamodell zu schreiben. Dabei können alle Features des Eclipse Frameworks, wie Codevervollständigung, Syntaxhervorhebung, Modellausführung oder Fehlerbehebung nach der Codegenerierung den persönlichen Bedürfnissen angepasst werden. Auch dafür wird es im Folgenden einige Beispiele geben Android Android wurde 2005 von Google gekauft und seitdem unter dessen Führung im Rahmen der Open Handset Alliance weiterentwickelt. Aktuell liegt Version 4.0 des Betriebssystems vor. Laut Gartner ist Android das führende Betriebssystem bei Smartphoneverkäufen seit dem zweiten Quartal Es besitzt mit 46 Millionen verkauften Geräten einen Marktanteil von über 40 Prozent. Weitere Gründe für die Wahl von Android als Evaluierungsplattform sind das Open Source Lizenzmodell und die Implementierung großer Teile in Java und damit auch die Möglichkeit der Entwicklung von Apps in Java. Java als Programmiersprache des SDK erlaubt eine einfache Integration in Eclipse und EMFText. Android nutzt einen Linux Kernel als Basis für Prozess- und Speicherverwaltung. Darauf läuft die Dalvik Virtual Machine, eine Art JVM, als Laufzeitumgebung für Android. Nur einige Bibliotheken sind aus Geschwindigkeitsgründen in C/C++ geschrieben. Zur Erstellung eigener Androidapplikationen stellt Google das Android SDK sowie eine Integration für die Eclipse IDE bereit. Ein wichtiges Element des SDK, welches in dieser Arbeit zur Testausführung genutzt wird, ist das Instrumentation Framework 4. Es wird zur Ausführung von Tests genutzt, indem es den eigentlichen Anwendungsprozess zerstört und einen neuen startet, auf welchem Tests ausgeführt werden können. JUnit 3 Testfälle können damit die verschiedenen UI-Elemente der App über ihre IDs lokalisieren, manipulieren und auf ihre Eigenschaften prüfen. Activity Tests erlauben es außerdem Tastenund Touch Aktionen auszuführen html 44

45 5.2. Testframework Robotium Aufbauend auf dem Instrumentation Framework, im Speziellen den Activity Tests, arbeitet das Testframework Robotium 5, welches Keywords bereitstellt, die GUI-Tests auf Android erheblich vereinfachen. So werden Funktionen wie clickonbutton (int index) oder pressspinneritem (int index, int item) bereitgestellt, die von intern nötigen Aktionen, wie das Navigieren zu Elementen sowie Klicks oder der Auswahl eines Listenelements abstrahieren. Außerdem wird bei Ausführung jeder Aktion ein Timeout eingebaut, welcher ermöglicht, dass auf Elemente eine gewisse Zeit gewartet wird. Dies ist nötig, da bei modernen Anwendungen manche Elemente erst nach Übergangseffekten wie Einund Ausblendungen zur Verfügung stehen. Da das Testframework solche Keywords, wie die des Robotium Frameworks, zur Nutzung vorsieht und auch das Timeoutverhalten ein wichtiger Vorteil gegenüber dem androideigenen Instrumentation Testframework ist, wurde Robotium für die Ausführung von Tests in dieser Arbeit gewählt. Bei der Abstraktion zu Keywords, haben die Robotium Entwickler allerdings die Entscheidung getroffen, statt mittels IDs über einen Index auf die einzelnen Elemente zuzugreifen (siehe Beispiel oben). So wird nicht ein Button mit der ID button1 ausgewählt, sondern Button Nummer eins oder zwei in dem jeweiligen Fenster. Dies stellt zwar sicher, dass nur existierende Elemente ausgewählt werden und erleichtert die Arbeit bei Blackboxtests, wo IDs nicht immer bekannt sind, ist aber bei Änderungen der AUT äußerst fehleranfällig, zumal bei der Hierarchie von Elementen im Android SDK nicht immer offensichtlich ist, wie groß die Anzahl der Elemente im aktuellen Fenster ist. So zählen RadioButton und CheckBox ebenfalls zur Gruppe der Buttons und müssen bei Keywords wie clickonbutton bei der Angabe des Index beachtet werden. Glücklicherweise ist Robotium ein Open Source Java Framework, sodass für das in dieser Arbeit entwickelte Framework eine spezialisierte Version der betroffenen Funktionen geschrieben werden konnte. Dazu wurde eine Klasse SoloId erstellt, welche von der Robotiumklasse Solo, die alle Funktionen (Keywords) des Frameworks enthält, erbt. Die neue Klasse überschreibt alle Funktionen, die Indizes zur Lokalisierung nutzen. Den neuen Funktionen können die IDs übergeben werden, welche dann in Indizes umgewandelt werden, mit denen die überschriebenen Funktionen arbeiten können. Listing C.1 enthält das Skelett der betroffenen Funktionen und die Hilfsfunktion zur Abbildung der IDs auf Indizes Testframework Im Folgenden wird zunächst die Grobstruktur des umgesetzten Frameworks vorgestellt bevor in den weiteren Unterkapiteln dann näher auf die einzelnen Komponenten eingegangen wird. Wie bereits erwähnt, wird zur Definition des Metamodells EMF bzw. Ecore genutzt. Das Ecore-Metamodell wird ähnlich wie ein UML Klassendiagramm erstellt und enthält die Elemente, die im Konzept beschrieben wurden. Aufbauend auf dem Metamodell wird eine Syntax definiert, welche von EMFText zur Erstellung der domänenspezifischen

46 5. Implementierung Abbildung 5.1.: Struktur Implementierung Testsprache benötigt wird. Die Syntax folgt dabei einem Keyword-driven Ansatz, um die Modelle möglichst abstrakt zu halten. Da EMFText eine EBNF-ähnliche Notation unterstützt kann hier ebenfalls auf die im Konzept erstellte Syntax zurückgegriffen werden. Der von EMFText generierte Code wird an bestimmten Stellen angepasst, um erweiterte Funktionalitäten, wie Codevervollständigung, Modellvalidierung und Testausführung zu ermöglichen. Dabei wird in den generierten Plugins ein Eclipse Extension Point erstellt, der eine definierte Schnittstelle für Adapter zur Verfügung stellt. Durch Implementierung der Schnittstelle entstehen plattformspezifische Adapter, welche den Extension Point füllen. Die angepassten Funktionen können damit auf alle eingetragenen Adapter zugreifen und diese benutzen. Im als Referenz implementierten Android Adapter werden als GUI-Elemente zum Beispiel nur solche erlaubt, welche durch das SUT deklariert worden sind. Dabei werden XML-Dateien ausgelesen, in welchen alle Elemente deklariert sind. Zur Testausführung wird im Falle Androids das Testmodell auf ausführbare JUnit3 Testfälle abgebildet. Das bedeutet der Adapter wandelt das Modell in eine äquivalente JUnit Testsuite um und führt diese mittels des Robotium Frameworks auf dem Emulator aus. Abbildung 5.1 veranschaulicht die eben angedeutete Struktur. 46

47 5.2. Testframework Abbildung 5.2.: Diagramm von Ecore Metamodell Ecore Metamodell Mit Ecore lassen sich Metamodelle für verschiedenste objektorientierte Anwendungsbereiche erstellen. Dafür stellt Eclipse mit dem Eclipse Modelling Framework Werkzeuge zur grafischen Konstruktion bereit. Da Ecore Modelle ähnlich wie UML Klassendiagramme aufgebaut sind, lässt sich das Metamodell aus dem Konzept damit äquivalent umsetzen. Abbildung 5.2 zeigt das Ecore Diagramm und enthält im Gegensatz zu Abbildung 4.2 zusätzlich noch die Datentypen der Attribute EMFText Testsprache Mittels EMFText können nun die nötigen Hilfsklassen erstellt werden, um Modelle textuell zu definieren, die dem Metamodell entsprechen. Dazu benötigen alle Metaklassen des Metamodells eine syntaktische Beschreibung, welche in EMFText in einer.cs - Datei (concrete Syntax) abgelegt werden. Die zu diesem Ecore-Modell gehörige Syntaxdatei ist im Anhang (Listing C.2) zu finden. Neben Konfigurationseinstellungen zur Codegenerierung enthält sie den folgenden Abschnitt, der den Metaklassen eine Syntax zuweist: RULES { TestSuite ::= "TESTSUITE" #1 "{"!1 "suitename"":" name[bigname]","!1 "systemundertest"":" systemundertest[bigname]","!1 "adapter"":" adapter[identifier]!1 (sequences!1)* (testcases!0)+ 47

48 5. Implementierung "}"; TestCase ::= "TESTCASE" #1 "{"!2 "casename" ":" name[identifier]!2 (teststeps ";"!1)+ "}"; Assertion ::= "ASSERT" assert[identifier]"(" actual ("," expected)? ")" (":" verdict[fail : "FAIL", error : "ERROR", inconclusive : "INCONCL", pass : "PASS"])?; UIElementLocator ::= "id" id[identifier]; Keyword ::= name[identifier] (":" target)? (":" testdata ("," testdata)*)? ; Sequence ::= "SEQUENCE" #1 name[identifier] #1"{"!1 (steps ";"!1)+!0 "}"; SequentialStep ::= "seq:" sequence[identifier]; Integer ::= datavalue[integer]; Boolean ::= datavalue["true" : "false"]; String ::= datavalue[ ", " ]; Float ::= datavalue[float]; } Da die Notation ähnlich der im Konzept ist, wird auf die Erklärungen im Kapitel 4.3 verwiesen. Der Code enthält einige Formatierungsanweisungen. Dazu zählen #1,!1 und!2, welche das textuelle Äquivalent eines Modells lesbarer machen, indem Zeilenumbrüche und Einrückungen eingefügt werden, sowie die in eckigen Klammern angegebenen Wörter, welche die erlaubten Werte der Variable definieren (Zahlen, großoder klein geschriebene Wörter, etc). Diese sind ebenfalls in der Datei angegeben und können dem Anhang entnommen werden. Aus dem Metamodell und der konkreten Syntax kann der Codegenerator von EMFText alle nötigen Dateien erstellen, welche zur Nutzung der Testsprache benötigt werden. Im Ausgangsprojekt (mgt.model) 6, welches das Ecore-Metamodell und die.cs Datei enthält, werden Java-Interfaces und Implementierungen der Metaklassen erstellt. Zusätzlich werden noch drei weitere Eclipse Plugins erstellt. Eins davon ist ein Antlr 7 Projekt, dass zum Parsen der Sprache genutzt wird. Ein weiteres Plugin (mgt.lang) enthält alle Klassen und Werkzeuge, die benötigt werden, um ein Modell in der Sprache darzustellen bzw. mit der Sprache Modelle zu definieren. Das dritte Plugin (mgt.ui) wird benötigt,um Eclipse als Werkzeug zur Nutzung der Sprache verwenden zu können. Dabei greift es über Extension Points auf die weiteren Plugins zu. Mit Hilfe der vier Eclipse Plugins ist es nun bereits möglich in einem Eclipse Editor Modelle des Testframeworks zu erstellen. Allerdings müssen noch einige Anpassungen gemacht werden, um die Arbeit mit dem Editor zu vereinfachen und die Adapter ein- 6 Für die generierten Plugins werden in Klammern die Namen angegeben, um sie im weiteren Verlauf besser unterscheiden zu können. MGT steht dabei für Mobile GUI Testing

49 5.2. Testframework zubinden. So existiert im Plugin mgt.ui nur ein Gerüst zur Ausführung der Modelle, welches noch mit entsprechender Logik gefüllt werden muss Adapter Anbindung Um der Sprache einen Zugriff auf verschiedene Adapter zu ermöglichen, wurde im Plugin mgt.lang ein Extension Point erstellt, der ein Interface IAdapter (Listing C.3) bereitstellt, sodass alle Eclipse Plugins, die dieses Interface implementieren einen nutzbaren Adapter darstellen. Das Interface enthält alle Funktionen, welche laut Konzept vom Adapter abgedeckt werden sollen. Die Nutzung der Eclipse Plugin Infrastruktur ermöglicht so die Variierung des Adapters ähnlich des Bridge Entwurfsmusters[GHJ94, S.151]. Dieses erlaubt die Auswahl verschiedener zu Verfügung gestellter Implementierungen einer festgelegten Schnittstelle. Die Plugin Architektur an sich entspricht zwar dem Multi-Bridge Entwurfsmuster (dem Nutzen beliebig vieler Implementierungen), da in der Sprache des Testframeworks aber nur einen Adapter erlaubt ist, wird dies im konkreten Fall auf eine einfache Bridge reduziert. Innerhalb der Plugins mgt.lang und mgt.ui können verfügbare Plugins geladen und genutzt werden. Im folgenden werden die Anpassungen dargestellt, um Validierung, Codevervollständigung und Testausführung über einen Adapter zu nutzen. Für die Vervollständigung bzw. Vorschläge von Keywords, IDs und Assertions ist die Klasse CodeCompletionHelper anzupassen. Sie enthält verschiedene Funktionen, um die Vorschläge zu berechnen. Um eigene Vorschläge einzubringen, muss die Methode handleattribute geändert werden. Wenn es sich um ein Vervollständigungsversuch für einen der drei genannten Fälle handelt, wird aus den vorhandenen Adaptern der im Modell genannte herausgesucht und mit diesem Adapter eine der entsprechenden Funktionen (getkeywords(), getelementids(string aut) oder getassertionproposals()) ausgeführt. Bei IDs wird der Name der zu testenden Applikation übergeben, da die IDs App-spezifisch sind. Keywords und Assertions hingegen werden direkt vom Adapter bereitgestellt. Für die Validierung der Testmodelle bietet EMFText einen Extension Point an, welcher immer aktiviert wird, sobald sich das Modell im Editor ändert. Im Plugin mgt.lang wird dieser Extension Point durch die Klasse ValidateModel gefüllt. Diese bekommt das aktuelle Testmodell übergeben, sammelt alle Keywords, Assertions und IDs und überprüft ob diese vom aktuellen Adapter angeboten werden. Falls dies nicht der Fall ist, wird im Editor eine Warnung ausgegeben (siehe Abbildung 5.3). Das generierte Plugin mgt.lang bietet ebenfalls ein Skelett zur Ausführung des Testmodells an. Dieses wird vom Plugin mgt.ui automatisch aufgerufen, wenn im Eclipse Editor ein Testmodell über den Run-Dialog ausgeführt wird. In der vorgegebenen Klasse wird die launch-methode geändert. In ihr wird der deklarierte Adapter aus dem Modell ausgelesen und in diesem die Methode runtest ausgeführt, welche im IAdapter Interface definiert ist. Die konkrete Testausführung ist komplett dem entsprechenden Adapter vorbehalten. Die Testausführung liefert die Ergebnisse an das mgt.lang-plugin zurück, wo sie zum einen auf der Konsole der Eclipse Instanz ausgegeben, als auch in eine CSV-Datei geschrieben werden, welche dann von anderen Programmen ausgewertet 49

50 5. Implementierung Abbildung 5.3.: Warnung der Modellvalidierung werden kann. Dadurch werden die Testergebnisse unabhängig vom Adapter gesammelt. Ein Testergebnis besteht aus der Anzahl der Tests zugeordnet zu ihrem Verdikt, dem genutzten Adapter und dem Ausführungszeitpunkt Android Adapter Zur Evaluierung wurde das Adapter Interface beispielhaft für die Android Plattform implementiert. Dieser Abschnitt beschreibt die Umsetzung der Funktionen getassertion- Proposals(), getelementids(string aut), getkeywords() und runtest(testsuite suite). Da das Android Instrumentation Framework JUnit3 Testfälle verwendet, liegt es nahe JUnit Assertions auch für die Tests des entwickelten Testframeworks zu verwenden. Dazu werden alle Methoden der Klasse Assert aus dem JUnit Framework über Reflection ausgelesen und dem Testframework bereitgestellt. Konkret sind dies die Methoden assertequals, assertfalse, assertnotnull, assertnull, assertnotsame, assertsame und asserttrue, welche unterschiedliche Datentypen als Argumente erlauben. Um die IDs der Oberflächenelemente herauszufinden, benötigt der Adapter Zugriff auf die zu testende Anwendung. Deren Name wird daher beim Funktionsaufruf mit 50