Einführung und Evaluierung einer Cross-Device

Transcription

Leopold-Franzens-Universität Innsbruck
Institut für Informatik
Quality Engineering
Einführung und Evaluierung einer
Cross-Device-Browser-Testing Plattform
Bachelor-Arbeit
David Fasching
betreut von
Dipl.-Ing. Mag. Dr. Michael Felderer
Innsbruck, 11. Oktober 2015
Zusammenfassung
Das aktuelle Ökosystem an mobilen Endgeräten ist sehr vielfältig, was
neue Herausforderungen an das Testen von Webseiten stellt. In der vorliegenden Arbeit wird eine Methodik zur Optimierung von anwenderbezogenen Tests auf Benutzerschnittstellenebene von Webseiten auf mehreren mobilen Endgeräten vorgestellt.
Die Grundidee ist ein Aufbau aus einem zentralen Steuergerät und mehreren mobilen Endgeräten. Dies ermöglicht eine zentrale Steuerung der
mobilen Geräte und dadurch die Möglichkeit den Testvorgang effizienter
zu gestalten.
Für diese Methodik wird ein Prototyp erstellt, anhand dem anschließend
der Nutzen der Methodik evaluiert wird.
Inhaltsverzeichnis
1 Einführung
1
2 Grundlagen
2.1 Kriterien der Software-Qualität . . . .
2.2 Testprozess . . . . . . . . . . . . . . .
2.2.1 Der Fundamentale Testprozess
2.2.2 Testautomatisierung . . . . . .
2.3 Related Work . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Rahmenbedingungen
3.1 Vorhandene Strukturen . .
3.1.1 Entwicklungsprozess
3.1.2 Infrastruktur . . . .
3.2 Problemstellung . . . . . . .
3.3 Anforderungen . . . . . . .
3.4 Workflow . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
. 7
. 7
. 9
. 10
. 11
. 12
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
15
16
19
24
24
26
26
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
31
32
33
35
37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Bewertung und Auswahl verfügbarer
4.1 Gerätesteuerung . . . . . . . . . . .
4.1.1 Aktionen . . . . . . . . . . .
4.1.2 Technologien . . . . . . . . .
4.1.3 Auswahl . . . . . . . . . . . .
4.2 Navigation innerhalb der Seite . . .
4.2.1 Anforderungen . . . . . . . .
4.2.2 Technologien . . . . . . . . .
4.2.3 Auswahl . . . . . . . . . . . .
.
.
.
.
.
.
Technologien
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
5 Implementierung
5.1 Übersicht Architektur . . . . . . . . . . . . .
5.1.1 Hardware Architektur . . . . . . . . .
5.1.2 Software Architektur . . . . . . . . . .
5.2 Verwendete Frameworks zur Implementierung
5.3 Controller . . . . . . . . . . . . . . . . . . . .
5.4 Devices . . . . . . . . . . . . . . . . . . . . .
III
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
4
5
5
INHALTSVERZEICHNIS
5.5
5.6
5.7
5.4.1 Device Interface . . . . . . . . . . . . . . . .
5.4.2 Implementierung für Chrome ab Android 4.1
5.4.3 Implementierung Android ohne Chromedriver
5.4.4 Implementierung iOS . . . . . . . . . . . . .
Web App . . . . . . . . . . . . . . . . . . . . . . . .
5.5.1 Web API . . . . . . . . . . . . . . . . . . . .
Client App . . . . . . . . . . . . . . . . . . . . . . .
Ghostlab Integration . . . . . . . . . . . . . . . . . .
6 Evaluierung
6.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Ergebnisse und Interpretation . . . . . . . . . . . . .
6.2.1 Polaritätsprofil . . . . . . . . . . . . . . . . .
6.2.2 Frage 1 - Testhäufigkeit . . . . . . . . . . . .
6.2.3 Frage 2 - Geräteabdeckung . . . . . . . . . .
6.2.4 Frage 3 - Leistungsfähigkeitsunterschiede . .
6.2.5 Frage 4 - Browser- und Plattformunterschiede
6.2.6 Frage 5 - Aufwand Testaufbau . . . . . . . .
6.2.7 Frage 6 - Zeitersparnis bei Testausführung . .
6.2.8 Frage 7 - Wartezeiten . . . . . . . . . . . . .
6.2.9 Frage 8 - Überforderung . . . . . . . . . . . .
7 Résumé und Ausblick
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
38
40
42
44
44
47
49
.
.
.
.
.
.
.
.
.
.
.
51
51
51
53
53
54
54
55
55
55
56
56
59
Appendix
61
A.1 Evaluierungsbogen . . . . . . . . . . . . . . . . . . . . . . 61
Abbildungsverzeichnis
63
Tabellenverzeichnis
64
Literaturverzeichnis
67
IV
David Fasching
Kapitel 1
Einführung
Der Softwaretest ist ein wichtiger Bestandteil der Softwareentwicklung,
der nötig ist, um die Qualität von Software auf einem entsprechenden
Niveau zu halten. Die Erfahrung zeigt, dass dieser Bestandteil der Softwareentwicklung oft vernachlässigt wird. Dies ist häufig auf eine schlechte Kosten-Nutzen-Relation zurückzuführen. Aus diesem Grund wurden
Werkzeuge entwickelt, die den Testprozess effizienter gestalten sollen.
Häufig wird das durch die Automatisierung von ansonsten manuellen
Testtätigkeiten durch Testautomaten erreicht.
Auf der Ebene technischer Schnittstellen, Systemkomponenten, Modulen oder Methoden sind die Testwerkzeuge schon gut ausgereift und finden auch eine immer breitere Anwendung. Fachliche, anwenderbezogene
Tests auf der Ebene der Benutzerschnittstellen sind schwieriger umzusetzen und daher mit höheren Kosten verbunden. Auf diesem Gebiet
gibt es auch noch durchaus Potential für Testwerkzeuge, die diese Testvorgänge effizienter gestalten [SBB11, Kap. 1].
In den letzten Jahren hat sich mit der Entwicklung des Internets auch
ein neues Gebiet eröffnet, in dem anwenderbezogene Tests auf Benutzerschnittstellenebene sehr wichtig erscheinen. Webseiten werden immer
aufwändiger gestaltet und sind nicht selten für den wirtschaftlichen Erfolg eines Unternehmens mitverantwortlich. Dazu kommt eine immer
größere Vielfalt an Browsern, die besagte Webseiten anzeigen. Mit der
Verbreitung von internetfähigen mobilen Endgeräten haben sich auch die
Bildschirmgrößen, Auflösungen, Rechnungsleistungen und Plattformen,
auf denen Webseiten angezeigt werden, vervielfältigt. Um sicherzustellen, dass Webseiten auf einem breiten Spektrum an Endgeräten korrekt
funktionieren und dargestellt werden, aber sich auch richtig anfühlen
(Look’n’Feel), werden neue Testprozesse erforderlich. Das vollautomatisierte Testen erscheint für diesen Anwendungsbereich nicht sinnvoll,
da Aspekte des Fühlens“ (z.B. ruckelt die Webseite bei der Bedie”
1
KAPITEL 1. EINFÜHRUNG
nung, oder ist die Webseite responsive) nicht adäquat überprüft werden
können. Sinnvoller erscheint ein teilautomatisierter Vorgang, der zwar
den Tester unterstützt, der Tester aber noch manuell eingreifen kann.
Diese Notwendigkeit wird in dieser Arbeit anhand eines Beispiels eines
Unternehmens gezeigt. Bei dem Unternehmen elements.at New Media
Solutions GmbH (elements.at) handelt es sich um eine Webagentur, die
Webauftritte für Auftraggeber erstellt. Das Spektrum reicht von sehr
einfachen Webauftritten bis hin zu sehr aufwändigen, bei denen häufig
ein gesamtes e-commerce System angeboten wird.
In dieser Arbeit wird eine Methodik vorgeschlagen, die das anwenderbezogene Testen von Webseiten auf mehreren mobilen Endgeräten (CrossDevice-Browser-Testing) vereinfachen und den Testablauf optimieren
soll. Für diese Methodik wird ein Prototyp entwickelt (Cross-DeviceBrowser-Testing Plattform) und anhand diesem evaluiert, ob die vorgeschlagene Methodik sinnvoll erscheint.
Dazu wird in Kapitel 3 die aktuelle Situation bei elements.at eruiert und
die genauen Rahmenbedingungen festgelegt. Anschließend werden in Kapitel 4 verfügbare Technologien, die für die Implementierung der CrossDevice-Browser-Testing Plattform in Frage kommen, bewertet und ausgewählt. Kapitel 5 präsentiert die Implementierung der Cross-DeviceBrowser-Testing Plattform, die dann in Kapitel 6 einer ausführlichen
Evaluierung unterzogen wird.
2
David Fasching
Kapitel 2
Grundlagen
Werfen wir zunächst einen Blick auf jene Grundlagen des Testens, die für
die dargestellte Methodik des Cross-Device-Browser-Testings relevant
sind.
2.1
Kriterien der Software-Qualität
Software-Qualität wird im ISO Modell 25010 beschrieben. Relevant für
diese Arbeit ist vor allem der Abschnitt über anwendungsbezogene Qualitätsmerkmale. Hierbei werden Qualitätskriterien aus der Sicht des Benutzers definiert. Die Definitionen wurden von [SRWL14, Kap. 2.1] entnommen.
Effektivität Wird definiert als Aufgabenerfüllung innerhalb der Genauigkeits- und Vollständigkeitsgrenzen
Effizienz Wird definiert als Aufgabenerfüllung innerhalb der Aufwandsgrenzen für Benutzer (Zeit, Kosten,...)
Risikoabwesenheit Wird definiert durch das Ausmaß der Abwesenheit von Wirtschafts-, Gesundheits-, Sicherheits-, Umgebungs- und Umweltrisiken.
Zufriedenheit Wird definiert durch den Grad an Verwendbarkeit,
Vertrautheit, Begeisterung und Bequemlichkeit im Umgang mit dem
Produkt.
Kontextabdeckung Wird definiert durch die kontextuelle Vollständigkeit und Flexibilität.
3
KAPITEL 2. GRUNDLAGEN
Abbildung 2.1: Der Fundamentale Testprozess [SBB11, Kap. 2.1]
Die beiden Merkmale der Effektivität und Zufriedenheit sind im Zusammenhang mit der beschriebenen Methodik von besonderer Bedeutung.
2.2
2.2.1
Testprozess
Der Fundamentale Testprozess
Eine Darstellung des fundamentalen Testprozesses mit den Schritten
Testplanung, Testanalyse, Testentwurf, Testrealisierung, Testdurchführung, Bewertung von Endkriterien und Bericht und Abschluss der Testaktivitäten sowie der Testüberwachung und -steuerung wurde [SBB11,
Kap. 2.1] entnommen.
Die einzelnen Schritte werden in Abbildung 2.1 gezeigt und wie folgt
beschrieben.
Testüberwachung und -steuerung Wird beschrieben durch eine
parallel zu den Testaktivitäten erfolgende Kontrolle, um gegebenenfalls
in den Prozess richtungsweisend einzugreifen.
Testplanung Wird beschrieben durch die Festlegung der Rahmenbedingungen für die folgenden Testaktivitäten.
4
David Fasching
Testanalyse und Testentwurf Wird beschrieben durch eine Überprüfung der Testbasis und die daraus folgenden Spezifikationen und Anforderungen, die für die Erstellung der Testfälle notwendig sind.
Testrealisierung und Testdurchführung Wird beschrieben durch
die Bildung ausführbarer Testfälle und deren anschließende Abarbeitung.
Bewertung von Endkriterien und Bericht Wird beschrieben durch
die Entscheidung über den Ausgang des Tests und der weiteren Vorgehensweise. Ergebnisse werden für Entscheidungsträger zusammengefasst.
Abschluss der Testaktivitäten Wird beschrieben durch die rückblickende Betrachtung der einzelnen Testaktivitäten, um Erfahrungen
für nachfolgende Projekte festzuhalten.
Der in Abschnitt 3.4 dargestellte Workflow stellt eine Spezialisierung des
fundamentalen Testprozesses dar.
2.2.2
Testautomatisierung
Die in Abschnitt 2.2.1 vorgestellten Schritte können automatisiert werden. R. Seidl definiert als Testautomatiserung
...die Durchführung von ansonsten manuellen Testtätigkeiten
durch Automaten. [SBB11, Kap. 1.4]
Die Definition zeigt eine sehr große Bandbreite an Möglichkeiten der
Testautomatisierung, aber es gibt auch Grenzen. Diese liegen darin, dass
nur manuelle Tätigkeiten eines Testers von Automaten ausgeführt werden können. Intellektuelle, kreative und intuitive Aspekte können nicht
automatisiert werden.
2.3
Related Work
In der Literatur wurde die Problematik der Kompatibilität von Webseiten auf verschiedenen Browsern anerkannt und für Desktop-Browser
wurde das Thema mit Cross-Browser-Testing schon ausführlich behandelt [MP11, HP14, EM07]. Etwas allgemeiner wird das Thema Mobile Testing in [Hal13] behandelt. Hier geht es hauptsächlich um native
mobile Apps. Einen Blick auf das verteilte Testen auf verschiedenen
Plattformen wirft [Bas12]. Methoden zum Testen von modernen Webtechnologien wie AJAX werden in [MvD09] und [MRT08] erforscht.
David Fasching
5
Das in dieser Arbeit vorgestellte Cross-Device-Browser-Testing stellt die
logische Fortsetzung des Cross-Browser-Testings dar, die durch die rapide Entwicklung und Verbreitung von mobilen Endgeräten erforderlich
wurde.
In der Industrie gibt es zur Problematik Cross-Device-Browser-Testing
schon einige Ansätze, die aber hauptsächlich auf Hilfsmittel wie Emulatoren oder die Cloud setzen. Bei diesen Ansätzen besteht nicht die
Möglichkeit lokal auf physischen Geräten und damit das Feeling“ zu te”
sten. Zu diesen Vertretern zählen unter anderem BrowserStack1 , Keynote Mobile Testing2 und Sauce Labs3 .
Eine interessante Alternative stellen Angebote wie Testbirds4 und rapidusertests5 zur Verfügung. Derartige Angebote setzen auf die Crowd.
Dabei werden Testaufträge eingereicht, welche dann von einer Vielzahl
von Testern ausgeführt werden.
1
https://www.browserstack.com
http://www.keynote.com/solutions/testing/mobile-testing
3
https://saucelabs.com
4
http://www.testbirds.de
5
http://rapidusertests.com
2
6
David Fasching
Kapitel 3
Rahmenbedingungen
In diesem Kapitel wird zuerst einmal dargelegt, unter welchen Rahmenbedingungen das Projekt realisiert wurde. Dazu werden in Abschnitt 3.1
die vorhandenen Strukturen, die bei elements.at existieren, in Erfahrung
gebracht. Anschließend wird in Abschnitt 3.2 die aktuelle Problematik
erläutert. Daraus folgen in Abschnitt 3.3 die Anforderungen. Abschließend wird in Abschnitt 3.4 noch ein Workflow vorgeschlagen, der sich
aus den Anforderungen ergibt.
3.1
Vorhandene Strukturen
Zwangsläufig wird es notwendig sein, die aktuellen Strukturen von elements.at zu beschreiben. Das heißt im Folgenden werden der Entwicklungsprozess und die Infrastruktur dargestellt. Dabei wird auch aufgezeigt, an welchen Stellen Maßnahmen zur Verbesserung angesetzt werden
können.
3.1.1
Entwicklungsprozess
Blicken wir zunächst auf den Entwicklungsprozess. Es ist zwischen Neuentwicklung und Wartung zu unterscheiden.
Neuentwicklung
Bei jeder Neuentwicklung wird zu Beginn ein Konzept gemeinsam mit
dem Kunden entwickelt. Die Erstellung des Konzepts geht dabei soweit,
dass der Kunde zunächst seine Vorstellungen zur Webseite präsentiert.
Zusammen mit den Entwicklern wird geprüft, ob diese Vorstellungen mit
einem vertretbarem Aufwand realisierbar sind.
Basierend auf dem Konzept entwerfen die Mitarbeiter von elements.at
ein User Interface. Dabei handelt es sich zuerst nur um Mockups, mit
7
KAPITEL 3. RAHMENBEDINGUNGEN
Konzept
User Interface
Frontend
Backend
Qualitätssicherung
Abbildung 3.1: Entwicklungsprozess für eine Neuentwicklung
deren Hilfe dem Kunden das Design der Webseite präsentiert werden
kann. Der Kunde hat hierbei noch die Möglichkeit, Wünsche zu äußern.
Im nächsten Schritt (Frontend) wird das User Interface implementiert. In diesem Entwicklungsschritt handelt es sich im Wesentlichen um
die clientseitige Entwicklung der Webseite. Während die im vorherigen
Schritt erstellten Mockups größtenteils statische Bilder sind, erfolgt in
diesem Schritt die Umsetzung der Mockups in Code, der die Darstellung
reproduziert. Hier kommen hauptsächlich Technologien wie HTML, CSS
und JavaScript zum Einsatz. Die Funktionalität beschränkt sich auf clientseitige Abläufe wie Animationen oder das dynamische Nachladen von
Inhalten.
Steht das Frontend, wird das Backend auf der Serverseite entwickelt.
Im Backend wird die Geschäftslogik implementiert und es dient dazu,
Informationen, die das Frontend benötigt, zur Verfügung zu stellen. Anschließend wird das Frontend mit dem Backend verknüpft. Es ergibt sich
eine voll funktionale Webseite.
Bevor die Webseite an den Kunden ausgeliefert wird, unterzieht elements.at diese noch einer ausführlichen Qualitätssicherung. Dabei
werden für jede offiziell von elements.at unterstützte Plattform verschiedene User Storys, welche die gesamte Funktionalität der Webseite abdecken, durchgespielt. Hierbei müssen die User Storys für jede Plattform einzeln nacheinander getestet werden. Diese Arbeit wird aus Ko8
David Fasching
stengründen oft an weniger qualifiziertes Personal übertragen. Werden
dabei Probleme erkannt, kehrt der Entwicklungsprozess wieder zu den
Schritten Frontend oder Backend zurück.
Wartung
Nach der Auslieferung des Produkts an den Kunden, wird bei umfangreichen Projekten eine Wartungsphase notwendig. Diese läuft im Wesentlichen in folgender Art und Weise ab:
Wünsche und Anfragen von Kunden werden von Projektleitern angenommen und in Arbeitspakete aufgeteilt. Diese stehen dann in einem
Arbeitpaket-Pool zur Verfügung. Einzelne dieser Arbeitspakete werden
von den Entwicklern nach Dringlichkeit und geplantem Fertigstellungsdatum entnommen und bearbeitet.
Änderungen und Ergänzungen an der Webseite werden direkt am LiveSystem vorgenommen. Das bedeutet, dass Modifikationen sofort für die
Öffentlichkeit sichtbar sind. Nur bei umfangreicheren Projekten kommt
ein eigener Testserver zum Einsatz, bei dem diese Modifikationen intern
entwickelt werden.
Üblicherweise werden Änderungen und Ergänzungen nur mehr am Gerät
des Entwicklers nach eigenem Ermessen getestet. Dadurch werden momentan Probleme oft erst durch den Kunden entdeckt.
3.1.2
Infrastruktur
Die Infrastruktur, die aktuell zum Testen zur Verfügung steht, besteht
aus einer Auswahl von mobilen Endgeräten und einem Webserver, auf
dem die Webseite gehostet wird.
Die mobilen Endgeräte decken ein Spektrum von am Markt befindlichen
Geräten ab, die offiziell von elements.at für ihre Webseiten unterstützt
werden. Die Auswahl an Geräten von schwächeren Leistungsklassen ist
noch ausbaufähig.
Aktuell sind die mobilen Endgeräte nur sehr lose an einem Aufbewahrungsort untergebracht, wie in Abbildung 3.2 zu sehen ist. Häufig werden einzelne Geräte von Entwicklern zu ihrem Arbeitsplatz mitgenommen und dadurch ist oft unklar, wo sich ein Gerät befindet, wenn es
gebraucht wird.
David Fasching
9
Platzhalter
Abbildung 3.2: Arbeitsplatz vor Einführung der Cross-Device-BrowserTesting Plattform
3.2
Problemstellung
Die eben beschriebenen Strukturen und Vorgehensweisen enthalten Schwachstellen, die die Qualität des Produkts stark beeinflussen können.
So ist es derzeit sehr aufwändig, eine hohe Testabdeckung zu erreichen,
da mit der aktuellen Infrastruktur mit jedem Gerät nacheinander getestet werden muss. Das führt zu einem erheblichen Zeitaufwand.
Bedingt durch diesen Zeitaufwand wird ein Test mit kompletter Testabdeckung nur am Ende einer Neuentwicklung durchgeführt. Mit kompletter Testabdeckung ist gemeint, dass hier die Webseite mit jedem von
elements.at offiziell unterstützen Gerät abgenommen wird. Selbst diese
einmalige Komlpettabnahme wird häufig an weniger qualifiziertes Personal übertragen. Diesem Personal fehlt oft das nötige Wissen um kritische
Stellen zu isolieren und diese zu testen.
Besonders Projekte in der Wartungsphase leiden bedingt durch Zeitaufwand unter mangelnder Qualitätssicherung. Da in dieser Phase nur
mehr an den einzelnen Geräten der Entwickler getestet wird, kann nicht
von einer systematischen Qualitätssicherung gesprochen werden. Diese
Geräte sind meistens von der aktuellsten Generation und der oberen Lei10
David Fasching
stungsklasse. Kompatibilitäts- und Performance-Probleme werden durch
diese sporadischen Tests kaum oder erst durch den Kunden entdeckt.
Zusammenfassend lässt sich festhalten, dass wegen des großen Zeitaufwands viel zu selten eine umfangreiche Testabdeckung erreicht wird.
3.3
Anforderungen
Es soll eine Plattform entwickelt werden, mit der das Testen von Webseiten auf mehreren Geräten vereinfacht wird. Mit der Einführung dieser
Cross-Device-Browser-Testing Plattform sollen die in Abschnitt 3.2 angeführten Probleme in Angriff genommen werden. Insbesondere soll der
benötigte Zeitaufwand zum Testen von Webseiten auf mehreren mobilen
Endgeräten reduziert werden.
Die Idee ist es, eine Plattform einzuführen, mit der die mobilen Endgeräte gleichzeitig von einem zentralen Steuergerät aus zu dem Zustand gesteuert werden können, an dem dann die Person, die den Test
durchführt, individuell die Funktionalität auf den einzelnen Geräten testen kann.
Folgende Anforderungen werden an die Cross-Device-Browser-Testing
Plattform gestellt:
1. Die Plattform soll aus einem zentralen Steuergerät (PC) und mehreren mobilen Endgeräten bestehen.
2. Auf dem zentralen Steuergerät soll eine Webseite zu einem Zustand navigiert werden können, der dann auf die anderen Geräte
synchronisiert wird.
3. Alle Geräte sollen parallel auf Knopfdruck aktiviert werden können
und automatisch den Browser mit der entsprechenden Webseite
öffnen. Der Browser soll auf den Geräten so gestartet werden, wie
es ein Benutzer machen würde. Spezielle Apps, die einen Browser
simulieren, sind nicht erwünscht, weil diese die User Experience
verfälschen können.
4. Der Aufbau eines Tests und die Durchführung soll einfach sein und
möglichst wenig Aufwand erfordern.
5. Zu Beginn soll der Arbeitsplatz alle Geräte und Browser abdecken,
die offiziell von elements.at unterstützt werden. Im Rahmen dieses Projektes werden vorerst nur die mobilen Plattformen iOS und
Android unterstützt. Eine Erweiterung auf Windows Phone/Windows 10 Mobile soll aber möglich sein.
David Fasching
11
gewünschte Geräte
aktivieren
zu gewünschter URL
navigieren
[Navigationen innerhalb der
Seite notwendig]
Seitennavigationen
durchführen
[else]
[manuel von Testperson]
Funktionalitäten testen
gefundene Fehler
dokumentieren
[weitere Testitems vorhanden]
[alle Testitems abgearbeitet]
Geräte deaktivieren
Abbildung 3.3: Workflow
6. Der Umfang der mobilen Geräte soll beliebig erweitert werden
können. Beispielsweise soll die Plattform im Nachhinein mit neuen
Gerätegenerationen, aber auch ältere Geräte oder Geräte schwächerer Leistungsklassen ausgestattet werden können.
3.4
Workflow
Basierend auf den Anforderungen wurde ein Workflow entwickelt, der
beschreibt, wie eine typische Testsession an der Cross-Device-BrowserTesting Plattform ablaufen soll.
Ausgangssituation
Als Ausgangssituation wird angenommen, dass folgende Informationen
vorliegen: Ein Satz an Testitems und eine Auswahl an Geräten, die getestet werden sollen.
12
David Fasching
Testitem Ein Testitem besteht aus einer Beschreibung der erwünschten
Funktionalität und einer Information an welcher Stelle die zu testende
Funktionalität vorzufinden ist. Diese Information liegt meist in Form einer Url vor und wenn notwendig einer Beschreibung, wie der gewünschte
Zustand erreicht wird.
Auswahl an Geräten Hier wird definiert an welchen Geräten die
Testsession durchgeführt werden soll. Typische Optionen sind gewisse
Gerätetypen wie Tablets oder Smartphones, Geräte bestimmter Leistungsklassen oder Plattformen, wie Android oder iOS.
Ablauf
Aus der erläuterten Ausgangssituation erscheint dann ein Workflow wie
in Abbildung 3.3 gezeigt sinnvoll.
Gewünschte Geräte aktivieren Bei diesem Schritt werden alle Geräte
aktiviert, die für die Testsession ausgewählt wurden. Die Aktivierung der
Geräte erfolgt vom zentralen Steuerungsgerät.
Zu gewünschter Url navigieren Sind die Geräte aktiviert, wird auf
allen Geräten gleichzeitig die gewünschte Url im Browser geöffnet. Auch
diese Aktion wird vom zentralen Steuerungsgerät aus in Gang gesetzt.
Seitennavigationen durchführen Ist es notwendig Navigationen innerhalb der Seite durchzuführen um den gewünschten Zustand zu erreichen, wird dies in diesem Schritt gemacht. Dazu gehören einfache Aktionen wie das Scrollen der Webseite zu einer bestimmten Position, aber
auch komplexere Aktionen wie Eingaben in Formularfelder oder Klicks
auf Buttons. Diese Navigationen erfolgen ebenfalls am zentralen Steuerungsgerät und werden an alle Geräte synchronisiert.
[manuel von Testperson] Funktionalität testen Jetzt sind alle
Geräte am gewünschten Zustand, an dem die erwünschte Funktionalität
getestet werden kann. Nun kann die Person, die den Test durchführt,
jedes einzelne Gerät in die Hand nehmen und die Funktionalität testen.
Dokumentation Die Ergebnisse des Tests der gewünschten Funktionalität werden anschließend dokumentiert.
Mit der Dokumentation ist der Vorgang für ein Testitem abgeschlossen
und es wird für das nächste Testitem mit der Navigation zum gewünschten
Zustand fortgesetzt. Sind alle Testitems abgearbeitet, wird zum Schritt
Geräte deaktiveren übergegangen.
David Fasching
13
Geräte deaktivieren Alle für die Testsession aktivierten Geräte werden wieder zentral vom Steuerungsgerät aus deaktivert.
14
David Fasching
Kapitel 4
Bewertung und Auswahl
verfügbarer Technologien
In diesem Kapitel wird der Auswahlprozess beschrieben, der die Technologien auswählte, die schlussendlich für die Entwicklung der CrossDevice-Browser-Testing Plattform verwendet wurden. In Abschnitt 4.1
wird der Auswahlprozess für die Gerätesteuerung behandelt. Die Gerätesteuerung umfasst alle Aktionen, die notwendig sind, das Gerät für Webseitennavigationen vorzubereiten und nach Abschluss einer Testsession
die Geräte wieder zu deaktivieren. Abschnitt 4.2 behandelt konkret die
Navigation innerhalb einer Webseite.
4.1
Gerätesteuerung
Durch die Gerätesteuerung soll es ermöglicht werden, die mobilen Endgeräte zu aktivieren, mit einem Browser eine Webseite zu öffnen und die
Geräte wieder zu deaktivieren. Die Auswahl der Technologien, die diese
Aktionen ermöglichen, wird in diesem Abschnitt beschrieben.
4.1.1
Aktionen
Im Folgenden werden die Aktionen beschrieben, die notwendig sind, um
die Geräte so zu steuern, wie es der Workflow erfordert. Alle Aktionen
müssen vom zentralen Steuerungsgerät angestoßen werden können.
A1 - Aufwecken Bevor mit den Geräten interagiert werden kann,
müssen diese zuerst aus ihrem Sleep-Zustand geweckt werden.
A2 - Entsperren Die meisten Geräte haben beim Aktivieren einen
Sperrbildschirm, der eine Benutzereingabe erfordert. Um die Geräte in
15
KAPITEL 4. BEWERTUNG UND AUSWAHL VERFÜGBARER
TECHNOLOGIEN
einem automatisierten Umfeld zu steuern, muss es möglich sein, diese
Sperre zentral zu umgehen.
A3 - Browser starten Nachdem das Gerät entsperrt wurde, ist es
erforderlich, dass der gewünschte Browser gestartet wird. Bei Geräten,
denen mehrere Browser zur Verfügung stehen, soll es möglich sein zwischen allen möglichen Browsern zu wählen. Der Browser soll so gestartet
werden, wie ihn ein Benutzer verwenden würde.
A4 - Url navigieren Sobald das Gerät den Browser gestartet hat, ist
es notwendig zu der Webseite zu navigieren, die getestet werden soll. Hier
ist es auch wichtig, dass nicht nur Basis-Urls (www.example.com), sondern auch erweiterte Urls (www.example.com/sub/page?user=muster)
angesteuert werden können. Weitere Navigationsanforderungen auf der
entsprechenden Webseite werden im separaten Abschnitt 4.2 behandelt.
A5 - Tabs schließen Die meisten Browser unterstützen das Öffnen
von Webseiten in mehreren Tabs. Wenn diese Tabs nach einem Testvorgang nicht geschlossen werden, häufen sich diese. Viele offene Tabs
führen zu Leistungseinbußen. Die Möglichkeit Tabs zu schließen oder
alternative Möglichkeiten, die Tab-Anzahl gering zu halten, sind daher
notwendig.
A6 - Browser schließen Nach dem Testvorgang soll der Browser
wieder geschlossen werden.
A7 - Gerät deaktivieren Abschließend soll das Gerät wieder in seinen Sleep-Zustand versetzt werden.
4.1.2
Technologien
Als nächstes wird einen Blick auf die verfügbaren Technologien geworfen,
welche die in Abschnitt 4.1.1 beschriebenen Aktionen bewerkstelligen
können.
Selenium [Sel15] Das Selenium Projekt ist einer der ersten Anlaufpunkte für automatisierte Tests von Webseiten. Dieses Projekt stellt
eine Reihe von Werkzeugen für das automatisierte Steuern von Browsern zur Verfügung. Mit sogenannten Webdrivern können alle verbreiteten Desktopbrowser gesteuert werden. Diese Webdriver werden entweder von Selenium oder zum Teil auch von den Browserherstellern selbst
16
David Fasching
TECHNOLOGIEN
entwickelt. Alle Webdriver implementieren das sogenannte JsonWireProtocol 1 . Zusätzlich werden vom Selenium Projekt noch Bibliotheken
für gängige Programmiersprachen (Java, C#, Ruby, Python, Javascript
(Node)) zur Verfügung gestellt, welche die Ansteuerung der verschiedenen Webdriver vereinfachen. Mit Hilfe dieser Werkzeuge lassen sich
Abläufe programmieren, die ein Browser automatisch für einen Testfall
durchführen soll.
Das Selenium Projekt unterstützt offiziell keine mobilen Webbrowser.
Es sind allerdings weitere Projekte entstanden, die von Selenium gelegte Standards und Protokolle verwenden und eine Automatisierung von
mobilen Apps ermöglichen. Diese Projekte werden im Folgenden vorgestellt.
ios-driver [Ios15] Selenium empfiehlt ios-driver für die Automatisierung von Apps auf der iOS Plattform von Apple. Mit ios-driver ist es
möglich, Testfälle auf die selbe Art und Weise, wie für Browser mit Selenium zu erstellen. Ios-driver konzentriert sich hierbei hauptsächlich auf
die automatisierte Steuerung von nativen Apps. Apps können sowohl im
Emulator, als auch auf physischen Geräten automatisiert werden.
Selendroid [Sel12] Für die Android-Plattform von Google wird von
Selenium Selendroid empfohlen. Mit Selendroid lassen sich Testfälle gleich
wie für ios-driver erstellen. Auch Selendroid konzentriert sich hauptsächlich
auf die automatisierte Steuerung von nativen Apps.
Appium [App15a] Das Appium-Projekt versucht die automatisierte
Steuerung von mobilen Apps der Plattformen iOS und Android in ein
Projekt zu vereinen. Appium setzt auf andere Projekte, die sich auf
Teilbereiche spezialisiert haben (z.B. Selendroid), sowie auf Frameworks,
die von den Plattformherstellern zur Verfügung gestellt werden. Appium
stellt deren Dienste über eine einheitliche Schnittstelle zur Verfügung,
die plattformunabhängig ist.
Auch bei diesem Projekt kommen wieder die von Selenium definierten
Protokolle zum Einsatz. Die Erstellung von Testfällen läuft daher wieder
nach dem gleichen Schema ab.
Chromedriver [Goo15b] Chromedriver ist ein Webdriver, der von
Google für deren Webbrowser Chrome erstellt wurde. Das besondere an
diesem Webdriver ist, dass sich damit auch der mobile Chrome Browser
auf einem Android-Gerät steuern lässt.
1
https://code.google.com/p/selenium/wiki/JsonWireProtocol
David Fasching
17
TECHNOLOGIEN
ADB (Android Debugging Bridge) [Goo15a] ADB ist ein von
Google zur Verfügung gestelltes Kommandozeilenprogramm, mit dem es
möglich ist, mit verbundenen Android-Geräten zu kommunizieren und
diese zu steuern. Die Android-Geräte müssen über die USB-Schnittstelle
mit dem Entwicklerrechner verbunden sein. Mit Hilfe von ADB lassen
sich unter anderem Apps auf dem Android-Gerät installieren und deinstallieren, Apps starten und stoppen und physische Knopfdrücke simulieren (z.B. die Betätigung der Standby-Knopfes).
Xcode [App15b] Sind die von Apple zur Verfügung gestellten Entwicklungstools. Neben der IDE zum Erstellen von iOS-Apps, stehen hier auch
Tools zum Installieren, Starten und Debuggen von Apps auf den mobilen Geräten zur Verfügung. Es ist nur möglich selbst entwickelte Apps
mit Xcode zu starten. Apps anderer Hersteller (z.B. der native Browser
Safari) können allerdings nicht über die Ferne gestartet werden. Xcode
steht nur dem Apple Betriebsystem OS X zur Verfügung. Es kann daher
nur in Verbindung mit einem Mac verwendet werden.
ios-deploy [Pho15] Ist ein kleines Tool, das es vereinfacht, Apps auf
iOS-Geräten zu installieren und starten. Dieses Tool verwendet die von
Xcode zur Verfügung gestellten Werkzeuge und benötigt daher die Installation von Xcode.
libimobiledevice [Lib07] Eine Sammlung von Tools, um mit iOSGeräten zu kommunizieren. Diese Tools stehen für OS X, Windows und
Linux zur Verfügung. Aus dieser Sammlung wird nur das Tool idevicedate verwendet, mit dem es möglich ist, die Einstellungen für Zeit und
Datum von einem iOS-Gerät abzufragen und zu ändern.
Webkit remote debuggung protocol [Goo12b] Mit diesem Protokoll ist es möglich, geöffnete Browserseiten vom Browser Google Chrome zu steuern. Dieses Protokoll wird hauptsächlich von den Chrome
Developer Tools verwendet, mit denen Browserseiten inspiziert werden
können. Durch dieses Protokoll ist es aber auch für andere Entwickler möglich, Informationen über Browserseiten zu erhalten und diese zu
steuern. In Zusammenarbeit mit ADB ist es sogar möglich Browserseiten des mobilen Chrome Browser zu steuern. Diese Methode wurde
allerdings für neuere Versionen von mobile Chrome durch den Einsatz
von Chromedriver ersetzt.
iOS WebKit Debug Proxy [Goo12a] Browserseiten, die auf einem
iOS-Gerät im Safari Browser geöffnet sind, lassen sich über die Ferne mit
Safari auf OS X inspizieren. Dieser Proxy übersetzt die Steuersignale in
18
David Fasching
TECHNOLOGIEN
das Webkit remote debugging protocol und ermöglicht es dadurch auch
anderen Entwicklern, Browserseiten von mobile Safari über die Ferne zu
steuern.
iOS Jailbreak Es ist sehr schwierig abseits von den von Apple zur
Verfügung gestellten Hilfsmitteln auf iOS-Geräte zuzugreifen und diese
zu Steuern. Dazu kommt, dass die offiziellen Hilfmittel sehr beschränkt
sind und aus Sicherheitsgründen der Zugriff auf nicht eigens entwickelte
Apps und das Betriebsystem selbst nahezu unmöglich ist. Aus diesem
Grund gibt es einige Projekte, welche viele dieser Beschränkungen aufheben und den Zugriff auf das Betriebsystem ermöglichen. Dieses Vorgehen
ist unter dem Namen Jailbreak bekannt.
4.1.3
Auswahl
Nachdem die Technologien besprochen wurden, gilt es nun die verwendeten Technologien zu bewerten und eine Auswahl zu treffen.
Zuerst werden die Lösungspakete untersucht, die alle erforderlichen Aktionen auf einmal abdecken können.
ios-driver (iOS) ios-driver hat einige Einschränkungen, mit denen es
schwierig ist, die in Abschnitt 3.3 gestellten Anforderungen zu erfüllen.
Das größte Problem ist, dass bei physischen Geräten Webseiten nicht
mit dem mobilen Safari gestartet werden, sondern dafür eine App mit
Webview verwendet wird. Da aber gefordert ist, dass der Browser so gestartet werden soll, wie ihn ein Benutzer starten würde, ist diese Methodik
unzureichend. Ein weiterer Schwachpunkt ist, dass sich von einem Steuergerät aus nur ein einziges physisches iOS-Gerät gleichzeitig ansteuern
lässt. Es lassen sich daher nicht mehrere Geräte parallel steuern, was
ebenfalls eine wichtige Anforderung ist, die nicht erfüllt werden kann.
Selendroid (Android) Auch Selendroid hat Probleme, die Anforderungen dieser Arbeit zu erfüllen. Das größte Problem ist auch bei diesem
Paket, dass Webseiten nicht in einem mobilen Browser gestartet werden, sondern auch hier mit einer App mit Webview gearbeitet wird. Für
die Android-Plattform ist diese Einschränkungen noch schwerwiegender, weil dadurch nicht mit Browsern von unterschiedlichen Herstellern
(Chrome, Firefox) getestet werden kann. Es ist daher nicht möglich, Verhaltensunterschiede zwischen verschiedenen mobilen Browsern zu analysieren.
David Fasching
19
TECHNOLOGIEN
Appium (Android + iOS) Anders als die zwei plattformabhängigen
Projekte, bietet Appium die Möglichkeit Webseiten direkt in den jeweiligen mobilen Browsern zu starten. Dieses Lösungspaket hat allerdings
auch Einschränkungen, die es nur bedingt brauchbar für diese Arbeit
machen.
Für ältere Android-Plattformen wird bei Appium das Selendoid Projekt
verwendet und hat somit für diese Plattformen die gleichen Nachteile wie
Selendroid selbst. Da das Anwendungsgebiet dieser Arbeit auch ältere
Geräte und Plattformen betrifft, kommt es auch hier zu Komplikationen mit den Anforderungen. Für iOS-Geräte hat auch Appium keine
Unterstützung zur gleichzeitigen Ansteuerung von mehreren physischen
Geräten.
Abseits der Probleme der einzelnen Lösungspakete gibt es auch noch
Generelles zu diesen Lösungspaketen zu sagen. Diese Lösungspakete
wurden für andere Anwendungsszenarios entwickelt. Diese Szenarien sehen alle die vollständige Automatisierung von Testfällen in einem Emulator vor. Szenarien in denen eine Person, die den Test ausführt, während
des Ablaufs auf einem physischen Gerät eingreift, etwa um die Haptik
zu evaluieren, sind bei diesen Lösungen nicht vorgesehen. Dazu kommt,
dass die vorgesehenen Szenarien derartiger Lösungen um einiges komplexer sind, als für die Cross-Device-Browser-Testing Plattform notwendig. Damit diese komplexeren Szenarien unterstützt werden können, ist
mehr Overhead erforderlich. Dieser zieht vor allem die Testinitialisierungszeiten in die Länge. Ein derartiger Overhead ist aber unnötig. Daher wurde auch nicht versucht, eines dieser vorhandenen Lösungpakte,
bei denen der Quellcode offen wäre, für die Anforderungen der CrossDevice-Browser-Testing Plattform anzupassen.
Aus den aufgezeigten Gründen wurde für beide mobilen Plattformen
kein fertiges Lösungspaket ausgewählt, sondern aus einer Ansammlung
von einzelnen Tools eine eigene Lösung entwickelt. Im Folgenden werden
die Tools untersucht, die für die einzelnen Aktionen anwendbar sind.
Dazu werden für jede erforderliche Aktion aus Abschnitt 4.1.1 geeignete
Tools auf ihre Verwendbarkeit überprüft. Zusätzlich werden die zwei
mobilen Plattformen iOS und Android separat behandelt.
Plattform iOS
Anmerkung zu iOS Jailbreaks: Bei der Entwicklung der Cross-DeviceBrowser-Testing Plattform wurde die Verwendung von Jailbreaks vermieden. Der Hauptgrund dafür ist, dass Jailbreaks nicht offiziell von
Apple unterstützt werden und Apple daher versucht diese mit Betriebsystemupdates zu unterbinden. Es kann daher nicht garantiert werden,
20
David Fasching
TECHNOLOGIEN
dass für akuelle iOS-Versionen immer ein Jailbreak zu Verfügung steht.
Eine Lösung, die auf einen Jailbreak basiert, kann daher sehr schnell
nutzlos werden.
A1 & A2 Aktionen Aufwecken und Entsperren
Xcode Zum Aufwecken und Entsperren eines iOS-Gerätes über die
Ferne, wurde nur eine Lösung gefunden. Dazu muss eine eigens kompilierte App über Xcode zum Debuggen auf dem Gerät ausgeführt werden.
Die Ausführung einer solchen App führt dazu, dass ein iOS-Gerät, das
sich im Sleep-Modus befindet, automatisch geweckt und entsperrt wird.
A3 Aktion Browser starten
Xcode Einer der wenigen Wege, um andere Apps zu starten, sind URL
Schemes 2 . Es ist möglich von einer eigenen App eine spezielle URL aufzurufen, die bewirkt, dass das Betriebsystem die zuständige App öffnet.
Mit einer Laucher-App, die beim Start eine angegebene URL aufruft,
ist es daher möglich den mobilen Safari zu öffnen.
A4 Aktion Url navigieren
Xcode URLs zum Öffnen des mobilen Safari können entsprechende Informationen enthalten, damit Safari auch gleich die gewünschte Webseite
aufruft. Es ist daher möglich mit der Launcher-App, die auch zum Starten des Browsers verwendet wird, gewünschte Webseiten zu öffnen. Der
Nachteil mit dieser Methode ist, dass für jede erneute Seitennavigation
erneut zuerst die Lauchner-App geöffnet werden muss, die dann wiederum in den mobilen Safari mit entsprechender Url startet. Zusätzlich
wird für jede erneute Seitennavigation ein neuer Tab erstellt, der nicht
mehr geschlossen werden kann (siehe Aktion Tabs schließen).
iOS WebKit Debug Proxy Ist der mobile Safari geöffnet, besteht
die Möglichkeit mit Hilfe des iOS WebKit Debug Proxy den aktuellen
Tab zu steuern und Seitennavigationen durchzuführen. Mit dieser Methode sind Seitennavigationen möglich, die nicht das Öffnen neuer Tabs
mit sich ziehen.
A5 Aktion Tabs schließen
2
https://developer.apple.com/library/ios/featuredarticles/
iPhoneURLScheme Reference/Introduction/Introduction.html
David Fasching
21
TECHNOLOGIEN
Es wurde keine Möglichkeit gefunden, geöffnete Tabs wieder über die
Ferne zu schließen. Um die Tab-Anzahl dennoch gering zu halten, empfiehlt sich daher die Seitennavigation mit Hilfe des iOS WebKit Debug
Proxys durchzuführen.
A6 & A7 Aktionen Browser schließen und Gerät deaktivieren
Es wurden keine Möglichkeiten gefunden, fremde Programme zu schließen und ein iOS-Gerät wieder in den Ruhezustand zu versetzen.
Die schlussendlich für die Plattform iOS ausgewählten Technologien sind
in der Tabelle 4.1 zusammengefasst.
Aktion
A1 Aufwecken
A2 Entsperren
A3 Browser starten
A4 Url navigieren
A5 Tab schließen
A6 Browser schließen
A7 Gerät deaktivieren
Technologie
Xcode debug / ios-deploy
Xcode debug / ios-deploy
Xcode: eigene Launcher-App
iOS WebKit Debug Proxy
iOS WebKit Debug Proxy
keine gefundene Lösung
keine gefundene Lösung
Tabelle 4.1: verwendete Technologien iOS
Plattform Android
A1 Aktion Aufwecken
ADB Mit Hilfe von simulierten Knopfdrücken lässt sich ein AndroidGerät aufwecken, indem die Betätigung des Standby-Knopfes simuliert
wird.
A2 Aktion Entsperren
ADB Der Sperrbildschirm (Lock-Screen) lässt sich mit Hilfe eines simulierten Knopfdruckes entsperren. Diese Methode funktionierte allerdings nicht an jedem Android-Gerät.
Sperrbildschirm deaktivieren Bei allen Android-Geräten ist es möglich,
den Sperrbildschirm in den Geräteeinstellungen zu deaktivieren. Dies ist
die einfachste Methode die erforderliche Benutzerinteraktion zu umgehen.
22
David Fasching
TECHNOLOGIEN
A3 Aktion Browser starten
ADB Wie schon bei der Einführung von ADB im Abschnitt Technologien erwähnt, ist es möglich, mit ADB jede beliebige installierte App auf
dem Gerät zu starten. Dadurch kann jeder gewünschte Browser gestartet
werden.
Chromedriver Bei der Verwendung von Chromedriver wird automatisch der mobile Chrome Browser gestartet. Mit dieser Methode kann
nur mobile Chrome gestartet werden.
A4 Aktion Url navigieren
Chromedriver Die Verwendung von Chromedriver ermöglicht eine
umfangreiche Steuerung des mobile Chrome Browsers, inklusive Seitennavigation. Mit dieser Methode lässt sich nur der mobile Chrome Browser steuern. Andere Browser werden nicht unterstützt.
ADB Beim Starten von Apps über ADB können Startparameter übergeben
werden. Durch die Angabe von Url-Parametern kann daher ein Browser aufgefordert werden, beim Starten eine entsprechende Url zu öffnen.
Die meisten Browser erstellen bei jedem Start einen neuen Tab, was die
geöffnete Tab-Anzahl wiederum in die Höhe treibt.
A5 Aktion Tabs schließen
Chromedriver Mit Chromedriver können zwar nicht direkt Tabs geschlossen werden, aber für Seitennavigationen werden keine neuen Tabs
geöffnet. Die Tab-Anzahl bleibt daher gering. Des Weiteren werden beim
Beenden einer Chromedriver-Session alle geöffneten Tabs geschlossen.
ADB Der einzige Weg mit ADB Tabs zu schließen, ist einen Browser komplett zurückzusetzen. Dadurch werden alle Einstellungen und
Zustände des Browsers gelöscht. Manche Browser erfordern allerdings
beim ersten Öffnen nach einer Zurücksetzung eine Benutzereingabe (z.B.
AGB akzeptieren).
A6 Aktion Browser schließen
ADB Mit ADB kann jede beliebige App über die Ferne geschlossen
werden. Browser schließen ist daher kein Problem.
David Fasching
23
TECHNOLOGIEN
Chromedriver Beim Schließen einer Chromedriver-Session wird der
geöffnete Browser automatisch wieder geschlossen.
A7 Aktion Gerät deaktivieren
ADB Wie schon das Aufwecken eines Android-Gerätes, lässt sich auch
das Deaktivieren mit Hilfe der Simulation des Standby-Knopfdruckes bewerkstelligen.
Die schlussendlich für die Plattform Android ausgewählten Technologien
sind in der Tabelle 4.2 zusammengefasst.
Aktion
A1 Aufwecken
A2 Entsperren
A3 Browser starten
A4 Url navigieren
A5 Tab schließen
A6 Browser schließen
A7 Gerät deaktivieren
Technologie
ADB keyevent
Lockscreen deaktivieren
für Chrome: Chromedriver
für andere Browser: ADB start
für Chrome: A5 Chromedriver
für andere Browser: ADB start mit Startargumenten
für andere Browser: ADB clear
für andere Browser: ADB force stop
ADB keyevent
Tabelle 4.2: verwendete Technologien Android
4.2
Navigation innerhalb der Seite
Das Ziel für die Navigation innerhalb der Seite ist, Benutzereingaben
an eine Webseite von dem Steuergerät auf alle zu testenden Geräte zu
synchronisieren. Hierfür wurden verfügbare Lösungen bewertet und die
am besten geeignete Lösung ausgewählt.
4.2.1
Anforderungen
Im Folgenden werden die Anforderungen erläutert, nach denen die verfügbaren Technologien bewertet wurden.
R1 - Events Events sind Aktionen, die der Benutzer auslöst und
von einer Webseite behandelt werden können. Am grundlegendsten sind
24
David Fasching
TECHNOLOGIEN
Klick-Events, die ausgelöst werden, wenn ein Benutzer z.B. auf einen
Link klickt. Es gibt aber noch viele weitere Events wie Hover-Events
und Tastendrücke. Je mehr dieser Events synchronisiert werden können,
desto besser lässt sich die korrekte Funktionalität testen.
R2 - Back Button Das Klicken des Zurück-Buttons des Browsers
kann oft zu unvorhergesehenen Nebenwirkungen führen, wenn es nicht
korrekt von einer Webseite behandelt wird.
R3 - Integration Es ist erstrebenswert, dass sich die Lösung gut in
die Cross-Device-Browser-Testing Plattform integrieren lässt. Lösungen
mit schlechten Schnittstellen können hier problematisch werden.
R4 - Scrolling Wenn eine Seite auf dem Steuergerät zu einer bestimmten Position gescrollt wird, soll die Position auf alle Geräte synchronisiert werden.
R5 - Formulare Das Ausfüllen von Formularfeldern soll synchronisiert werden. Dazu zählt auch das Aktivieren von Checkboxen und
Auswählen von Auswahlfeldern.
R6 - Manuelle Url-Änderungen Manuelle Änderungen der Url in
der Adressleiste sollen synchronisiert werden.
R7 - Klicks auf versteckte Elemente Klicks auf Elemente, die
versteckt sind, sollen trotzdem synchronisiert werden. Das ist wichtig
bei Webseiten, die ein speziell für mobile Geräte angepasstes Layout
haben. So kann es passieren, dass z.B. Menüpunkte, die am Steuergerät angezeigt werden, bei einem mobilen Gerät ausgeblendet sind. Die
Synchronisation eines Klicks auf einen solchen Menüpunkt ist trotzdem
wünschenswert.
R8 - Kosten Eine kostenlose Lösung wäre natürlich ideal, wenn allerdings eine viel umfangreichere Funktionalität die Mehrkosten rechtfertigt, werden diese in Kauf genommen.
R9 - Proxy zu existierendem Webserver Die Lösung soll auch auf
Webseiten anwendbar sein, die bereits von einem externen Webserver
angeboten werden. Hier soll auch das verschlüsselte Protokoll HTTPS
unterstützt werden.
David Fasching
25
TECHNOLOGIEN
4.2.2
Technologien
Nach einer strukturierten Recherche bezüglich ihrer Funktionalität haben es nur zwei Lösungen in die engere Auswahl geschafft. Diese Lösungen
bieten mit Abstand die meiste Funktionalität und können am ehesten
die Anforderungen erfüllen.
Ghostlab [Van11] Ist eine kommerzielle Lösung des Unternehmens
Vanamco AG.
Browsersync [JH15] Ist eine freie open source Lösung unter der Apache 2.0 Lizenz.
4.2.3
Auswahl
Es wird nun eruiert, wie gut die einzelnen Technologien jede der gestellten Anforderungen erfüllen können.
R1 Anforderung Events
Ghostlab Von Ghostlab werden sehr viele der am meisten gebrauchten Events unterstützt. Neben grundlegenden Klick-Events, werden sogar Hover-Events korrekt synchronisiert.
Browsersync Browsersync unterstützt nur Klick-Events auf Links.
Selbst Klick-Events, deren Behandlung dynamisch nachgeladen wurde,
werden nicht unterstützt.
R2 Anforderung Back Button
Ghostlab Wurde von einer älteren Version (1.*) unterstützt, bei der
aktuellen Version (2.0.8) wird es allerdings zur Zeit nicht unterstützt.
Browsersync
Wird nicht unterstützt.
R3 Anforderung Integration
Ghostlab Da es sich um ein kommerzielles Produkt handelt, steht kein
offener Sourcecode zur Verfügung. Ghostlab bietet auch keine Schnittstellen nach außen, mit denen das Programm gesteuert werden könnte.
Eine Integration in ein anderes System ist daher nur schwer möglich.
26
David Fasching
TECHNOLOGIEN
Browsersync Browsersync ist ein Node.js-Projekt mit offenem Quellcode. Es besitzt eine umfangreiche Schnittstelle, die eine Steuerung von
außen ermöglicht. Es ist daher sehr einfach, Browsersync in ein anderes Projekt zu integrieren, insbesondere, wenn es sich um ein Node.jsProjekt handelt.
R4 Anforderung Scrolling
Ghostlab Synchronisiertes Scrolling wird von Ghostlab sehr gut unterstützt. Es stehen mehrere Möglichkeiten zur Auswahl, wie Scrolls synchronisiert werden. So kann sichergestellt werden, dass auch bei verschiedenen Browserauflösungen die Webseite zur richtigen Stelle gescrollt
wird.
Browsersync Browsersync hat zwar keine Konfigurationsmöglichkeiten
bezüglich des Scroll-Sync-Verhaltens. Die Synchronisation von ScrollEvents funktioniert aber einwandfrei.
R5 Anforderung Formulare
Ghostlab Das Ausfüllen von Formular-Elementen wird ohne Einschränkungen unterstützt. Ghostlab bietet sogar die Möglichkeit, dass Formularfelder automatisch ausgefüllt werden. So können z.B. Eingabefelder
für E-Mail-Adressen automatisch mit einer Zeichenkette befüllt werden,
welche die Richtlinien einer E-Mail-Adresse erfüllt.
Browsersync Es wird die Synchronisation für alle gängigen Formularfeldern unterstützt. Eingabeelemente mit erweiterter Funktionalität,
erzielt durch JavaScript, können Probleme verursachen. Dazu zählen
z.B. auch Elemente, die mit Hilfsbibliotheken wie jQuery [The15] generiert wurden.
R6 Anforderung Manuelle Url-Änderungen
Ghostlab Wurde von einer älteren Version (1.*) unterstützt, bei der
aktuellen Version (2.0.8) wird es allerdings zur Zeit nicht unterstützt.
Browsersync
Wird nicht unterstützt.
R7 Anforderung Klicks auf versteckte Elemente
Wird sowohl von Ghostlab, als auch Browsersync unterstützt.
David Fasching
27
TECHNOLOGIEN
R8 Anforderung Kosten
Ghostlab Für eine Lizenz für zwei Arbeitsplätze werden einmalig 50
Euro veranschlagt.
Browsersync Für die Verwendung von Browsersync fallen keine zusätzlichen Kosten an.
R9 Anforderung Proxy zu existierendem Webserver
Ghostlab Ghostlab kann sowohl selbst einen Webserver, der lokale
Dateien zur Verfügung stellt, als auch Seiten von externen Webservern
anbieten. Webseiten, die das HTTPS-Protokoll verwenden, sind dabei
kein Problem.
Browsersync Auch Browsersync kann als Webserver lokale Dateien
zur Verfügung stellen. Bei externen Webseiten werden allerdings nur
Webseiten mit einer unverschlüsselten Verbindung unterstützt. Webseiten, die das HTTPS-Protokol verwenden, werden daher nicht unterstützt.
Finale Entscheidung
Browsersync ließe sich zwar sehr gut in das Projekt integrieren, die
Funktionalität ist aber im Gegensatz zu Ghostlab doch um einiges eingeschränkter. Das schwerwiegendste Problem ist die fehlende Unterstützung
des HTTPS-Protokolls. Da dieser Standard immer mehr eingesetzt wird,
ist Browsersync für einen Großteil der zu testenden Webseiten unbrauchbar. Es wurde daher Ghostlab als Lösung zur Navigation innerhalb einer
Webseite ausgewählt und zudem wurde versucht, Ghostlab so weit wie
möglich in das System zu integrieren. Tabelle 4.3 fässt den Auswahlprozess noch einmal zusammen.
28
David Fasching
TECHNOLOGIEN
R1
R2
R3
R4
R5
R6
R7
R8
R9
Events
Back Button
Integration
Scrolling
Formulare
manuelle Url-Änderungen
Klicks auf versteckte Elemente
Kosten
Proxy zu existierendem Webserver
Ghostlab
++
+
–
++
++
+
+
–
++
Browersync
+
–
++
+
+
–
+
+
––
Tabelle 4.3: Zusammenfassung Seitennavigation
David Fasching
29
Kapitel 5
Implementierung
In diesem Kapitel wird die Implementierung der Cross-Device-BrowserTesting Plattform vorgestellt. Dazu wird in Abschnitt 5.1 ein Überblick
über den Aufbau der Hard- und Softwarearchitektur gegeben. Abschnitt
5.2 stellt die Frameworks vor, auf denen die Cross-Device-Browser-Testing
Plattform aufgesetzt wurde. In den restlichen Abschnitten 5.3 - 5.7 werden dann die konkreten Implementierungen der in Abschnitt 5.1 vorgestellten Softwarekomponenten behandelt.
5.1
5.1.1
Übersicht Architektur
Hardware Architektur
Der hardwareseitige Aufbau besteht aus dem Kontroll-PC, einem Mac,
mobilen Android Geräten und mobilen iOS Geräten. In Abbildung 5.1
wird gezeigt, wie diese Geräte miteinander verbunden sind.
Kontroll-PC Der Kontroll-PC ist ein Windows-Rechner, auf dem die
Web App und der Browser für die Client App laufen. Von diesem Rechner aus werden alle anderen Geräte gesteuert.
Mac Der Mac ist notwendig, um iOS-Geräte zu steuern. Der Mac wird
mittels einer SSH-Verbindung vom Kontroll-PC aus gesteuert.
Mobile Android-Geräte Diese Geräte sind direkt an dem KontrollPC über USB angeschlossen und werden von diesem gesteuert. Die
Geräte wurden so gewählt, dass sie ein möglichst großes Spektrum an
Bildschirmgrößen und Leistungsklassen abdecken. Derzeit sind folgende Geräte verfügbar: Samsung Galaxy S3, Samsung Galaxy Tab 10.1,
Samsung Galaxy Tab 4 10.1, Google Nexus 5, Motorola Moto E.
31
KAPITEL 5. IMPLEMENTIERUNG
KontrollPC
Mac
Abbildung 5.1: Hardware Architektur
Mobile iOS-Geräte Diese Geräte sind über USB an dem Mac angeschlossen und werden von diesem indirekt über den Kontroll-PC gesteuert. Auch diese Geräte wurden so gewählt, dass sie ein möglichst großes
Spektrum an Bildschirmgrößen und Leistungsklassen abdecken. Derzeit
sind folgende Geräte verfügbar: Apple iPhone 4S, Apple iPad 3, Apple
iPod Touch 4te Generation.
5.1.2
Software Architektur
Abbildung 5.2 zeigt einen Überblick zum Aufbau der Software Architektur. Die Client App [5.6] kommuniziert mit der Web App [5.5] über eine
auf HTTP-basierende Schnittstelle. Die Web App verwendet den Controller [5.3], um die einzelnen Devices zu steuern, die alle das DeviceInterface [5.4] implementieren. Der Controller betreibt einen Proxy-Server,
der zur Integration von Ghostlab [5.7] verwendet wird.
In Abbildung 5.3 werden in einem Sequenzdiagramm typische Abläufe
der Cross-Device-Browser-Testing Plattform gezeigt.
32
David Fasching
<<Interface>>
DeviceInterface
Device A
Proxy
Device B
Device C
Controller
Web App
HTTP-Interface
Client App
Abbildung 5.2: Software Architektur
5.2
Verwendete Frameworks zur Implementierung
Für die Implementierung der Cross-Device-Browser-Testing Plattform
wurde die serverseitige Plattform node.js [Nod15b] ausgewählt. Node.js
forciert eine ereignisgesteuerte Architektur und bietet eine nicht-blockierende I/O API an. Da der Großteil der Cross-Device-Browser-Testing
Plattform aus Ansteuerungen von mobilen Endgeräten und dem Warten
von Bestätigungen (entspricht I/O Operationen) besteht, eignen sich
Eigenschaften von node.js hervorragend. Programme für node.js werden
in der Programmiersprache JavaScript geschrieben.
Die nicht-blockierende I/O API wird mit dem Einsatz von Callbacks umgesetzt. Ein Callback ist eine Funktion, die zum Abschluss einer Operation aufgerufen wird. Jeder I/O Operation wird ein Callback übergeben,
der mit Abschluss der Operation aufgerufen werden soll. Durch diese
Architektur lassen sich Operationen starten, ohne die Ausführung zu
blockieren. Während auf eine I/O Operation gewartet wird, können andere Aktionen durchgeführt werden. All dies wird ohne dem Einsatz von
Threading-Konzepten ermöglicht.
Neben einer umfangreichen Bibliothek, die mit node.js mitgeliefert wird,
David Fasching
33
Client
Web App
POST /activate A
activate(A)
POST /activate B
activate(B)
Controller
Device A
Device B
POST /navigate
navigate()
navigate()
navigate()
DELETE /activate B
deactivate(B)
POST /navigate
navigate()
navigate()
Abbildung 5.3: Sequenzdiagramm typischer Abläufe
34
David Fasching
gibt es auch noch einen Paketmanager, der npm [Npm09] genannt wird.
Durch npm wird es Entwicklern möglich, zusätzliche Module für node.js
zu entwickeln und diese für andere Entwickler zur Verfügung zu stellen.
Mit Hilfe von npm ist dadurch ein sehr umfangreiches Ökosystem um
node.js entstanden, das es Entwicklern ermöglicht, mit wenig Aufwand
Programme zu erstellen.
Auch in der Cross-Device-Browser-Testing Plattform kommen einige
dieser npm-Module zum Einsatz. Diese werden im Folgenden genauer
erläutert.
async [McM15] Dieses Utility-Modul erleichtert die Umsetzung asynchroner Abläufe. Mit dem Einsatz von async ist es daher sehr einfach,
mehrere I/O-Operationen parallel oder in einer Serie ablaufen zu lassen.
Da ein Großteil der Cross-Device-Browser-Testing Plattform darin besteht, eine Abfolge von Operationen gleichzeitig auf mehreren Geräten
auszuführen, kommt dieses Modul sehr stark zum Einsatz.
express [Str15] Ist ein schnelles, minimalistisches Web-Framework,
mit dem sich sehr einfach Applikationen erstellen lassen, die eine auf
HTTP-basierende Schnittstelle zur Verfügung stellen.
http-proxy [Nod15a] Ein Modul, mit dem ein einfacher Proxy-Server
erstellt werden kann. Dieses Modul findet seinen Einsatz bei der Integration von Ghostlab, welche in Abschnitt 5.7 beschrieben wird.
ssh2 [Whi15] Eine Bibliothek, die es ermöglicht, Verbindungen zu anderen Rechnern mittels SSH 1 aufzubauen.
request [Pro15] Ein Utility-Modul mit dem sich einfach HTTP-Requests
absenden lassen.
ws [Ein15] Ein Modul, das die Kommunikation mittels dem WebSocket
Standard ermöglicht.
5.3
Controller
Der Controller ist das Herzstück der Cross-Device-Browser-Testing Plattform. Er nimmt Steuerkommandos entgegen und leitet diese an die verbundenen Geräte weiter.
Der Controller verwaltet eine Liste von Device-Instanzen, die das Device Interface implementieren. Devices werden im Abschnitt 5.4 genauer
1
Secure Shell - ein verschlüsseltes Netzwerkprotokol
David Fasching
35
erläutert. Des Weiteren verwaltet der Controller eine Liste von aktiven Devices. Devices können beliebig aktiviert und deaktiviert werden.
Steuerkommandos (initialize, shutdown, navigate, reload) werden nur an
aktive Devices weitergeleitet.
Der Controller ist ein Node.js-Modul und kann einfach über das ModulLadesystem in eine Node.js-Anwendung eingebunden werden. Er stellt
eine Anzahl von Funktionen zur Verfügung, die im Folgenden genauer
erläutert werden.
activateDevice(deviceName)
Überprüft zuerst, ob das angegebene Device erreichbar ist. Wenn das
Device erreichbar ist, wird es zu den aktiven Devices hinzugefügt. Zukünftige Steuerkommandos werden an dieses Device weitergeleitet, bis
es wieder deaktiviert wird.
deactivateDevice(deviceName)
Entfernt das angegebene Device von der Liste der aktiven Devices. Zukünftige Steuerkommandos werden nicht mehr an dieses Device weitergeleitet.
getState()
Gibt Informationen über den aktuellen Status aller vom Controller verwalteten Devices zurück. Die Informationen geben Auskunft darüber,
ob ein Device aktiviert und/oder initialisiert ist.
Steuerkommandos
Funktionen: initialize, shutdown, navigate, reload
Diese Funktionen führen bei allen aktiven Devices die entsprechende
Funktion aus. Die Funktion wartet, bis alle Devices die entsprechende
Funktion ausgeführt und ein Ergebnis zurückgegeben haben. Die Ergebnisse werden gesammelt und als kombiniertes Ergebnis zurückgegeben.
Bei allen Steuerkommandos wird versucht, die betroffenen Geräte parallel anzusteuern. Dadurch werden die Wartezeiten erheblich verkürzt. Es
ist allerdings nicht mit allen Geräteimplementierungen möglich mehrere
Geräte gleichzeitig zu steuern (z.B. iOS Implementierung [5.4.4]). Der
Funktion navigate muss zusätzlich eine URL übergeben werden, zu der
die Devices navigieren sollen.
36
David Fasching
shutdown()
disabled
initialize()
initialized
isConnected()
navigate()
reload()
isConnected()
Abbildung 5.4: Device Zustände
navigate ghostlab()
Konfiguriert den lokalen Proxy zur übergebenen URL und navigiert
alle aktiven Devices zur Adresse, an der Ghostlab seine Dienste zur
Verfügung stellt. Nähere Informationen zur Integration von Ghostlab
sind in Kapitel 5.7 zu finden.
5.4
Devices
Jeder Gerätetyp von mobilem Endgerät muss mit unterschiedlichen Methoden angesteuert werden. Aus diesem Grund gibt es verschiedene
Device-Klassen, die jeweils einen Gerätetyp (z.B. Android-Gerät mit Android 4.1) repräsentieren. Jede Instanz einer Device-Klasse repräsentiert
dann ein konkretes Gerät.
Jede Device-Klasse führt die gerätespezifischen Aktionen aus, die nötig
sind, um die Funktionalität zu erfüllen, die durch ein Interface spezifiziert ist. Dieses Interface wird vom Controller verwendet, um die verschiedenen Geräte zu steuern.
Ein Device hat zwei Zustände, die in Abbildung 5.4 dargestellt sind. Implementierte Funktionen des Interfaces sollen, je nach Zustand in welchem sich das Device befindet, zur Verfügung stehen.
5.4.1
Device Interface
Im Folgenden werden die Funktionen erläutert, die vom Device Interface
gefordert werden.
isConnected
Soll überprüfen, ob das Gerät erreichbar ist und diese Information zurückgeben.
David Fasching
37
initialize
Das Gerät soll aus seinem Sleep-Zustand geweckt werden, der Sperrbildschirm (falls vorhanden) soll entsperrt werden und der entsprechende Browser soll gestartet werden. Nach der Initialisierung soll ein Gerät
bereit sein, URL-Navigationen im Browser durchzuführen, die durch navigate und reload angestoßen werden.
shutdown
Alle Tabs sollen geschlossen, der Browser soll geschlossen und das Gerät
in seinen Sleep-Zustand versetzt werden.
navigate
Nur möglich, wenn das Gerät initialisiert ist. Das Gerät soll den Browser
zu der angegebenen URL steuern.
reload
Nur möglich, wenn das Gerät initialisiert ist. Das Gerät soll die aktuell
geladene Webseite erneut laden.
Im Folgenden werden für die mobilen Plattformen Android und iOS
konkrete Implementierung vorgestellt, die zeigen mit welchen Methoden
die erforderlichen Funktionalitäten umgesetzt wurden.
5.4.2
Implementierung für Chrome ab Android 4.1
Zur Steuerung von Android-Geräten mit Chrome kommen hauptsächlich
ADB und chromedriver zum Einsatz. Diese Implementierung wurde erfolgreich für Geräte mit den Andoid-Versionen 4.1 bis 5.0 getestet.
Für ADB-Kommandos kommt öfters eine udid zum Einsatz. Dies ist
eine Zeichenkette, die ein bestimmtest Gerät eindeutig identifiziert. Mit
dem ADB-Kommando
adb devices
werden alle verbundenen Geräte mit ihrer udid aufgelistet.
isConnected
Um zu überprüfen, ob das Gerät erreichbar ist, wird das ADB-Kommando
adb -s < udid > get - state
verwendet. Aus dem Standard Output (stdout) lässt sich dann die Erreichbarkeit des Gerätes schließen.
38
David Fasching
initialize
Zuerst muss überprüft werden, ob sich das Gerät im Sleep-Modus befindet. Dazu wird das ADB-Kommando
adb -s < udid > shell dumpsys power
verwendet. Neben vielen anderen Informationen kann hier der aktuelle
PowerState ausgelesen werden.
Befindet sich das Gerät im Sleep-Modus, wird es mit einem simulierten
Tastendruck des Standby-Buttons geweckt. Folgendes ADB-Kommando
wird dazu verwendet:
adb -s < udid > shell input keyevent 26
Bei keyevent 26 handelt es sich um den Standby-Button.
Bei Android-Geräten lässt sich der Sperrbildschirm in den Einstellungen
deaktivieren. Bei deaktiviertem Sperrbildschirm muss daher der Sperrbildschirm nicht extra behandelt werden.
Sobald das Gerät aus seinem Sleep-Modus geweckt wurde, kann der
Browser (in diesem Fall Chrome) gestartet werden. Dies erfolgt mit chromedriver. Chromedriver ist ein Programm, das an einer konfigurierten
chromedriverurl eine REST-Schnittstelle zur Verfügung stellt. Chromedriver arbeitet mit Sessions. Wird eine Session gestartet, wird automatisch Chrome gestartet. Eine Session wird mit dem HTTP-Request
POST < chromedriverurl >/ session
gestartet. Als body muss folgendes JSON-Objekt mitgeschickt werden:
{
’ sessionId ’: null ,
’ desiredCapabilities ’: {
’ chromeOptions ’: {
’ androidDeviceSerial ’: < udid > ,
’ androidPackage ’: ’ com . android . chrome ’
}
}
}
Im Response wird eine SessionId mitgegeben, die für weitere Steuerungskommandos verwendet werden muss.
Wurde die Session erfolgreich erstellt, ist das Gerät bereit und kann die
Steuerkommandos navigate und reload ausführen.
shutdown
Chrome wird automatisch geschlossen, wenn eine chromedriver-session
beendet wird. Zum Beenden einer Session wird folgender HTTP-Request
verwendet:
David Fasching
39
DELETE < chromedriverurl >/ session / < sessionId >
Die <sessionId> ist diejenige, die beim Erstellen der Session erhalten
wurde.
Wurde Chrome beendet, wird das Gerät wieder in seinen Sleep-Zustand
versetzt. Dazu wird wieder ein Tastendruck des Standby-Buttons simuliert:
adb -s < udid > shell input keyevent 26
navigate
Navigationen werden mit Hilfe der chromedriver-Session durchgeführt.
Folgender HTTP-Request wird dazu verwendet:
POST < chromedriverurl >/ session / < sessionId >/ url
Als body muss folgendes JSON-Objekt mitgeschickt werden:
{ ’url ’: < destination > }
<destination> ist die Adresse, zu der navigiert werden soll. Die
<sessionId> ist wieder diejenige, die beim Erstellen der Session erhalten
wurde.
reload
Auch das erneute Landen einer Webseite wir mit der chromedriverSession durchgeführt. Folgender HTTP-Request ist dazu nötig:
POST < chromedriverurl >/ session / < sessionId >/ refresh
5.4.3
Implementierung Android ohne Chromedriver
Browser abseits von Chrome oder ältere Chrome-Versionen (Version
<33) können nicht mit chromedriver gesteuert werden. Für diese Anwendungsfälle wurde eine Implementierung entwickelt, die rein auf die Verwendung von ADB setzt. Der große Nachteil dieser Implementierung ist,
dass die Browser nicht direkt gesteuert, sondern nur auf BetriebsystemEbene gestartet und gestoppt werden können.
isConnected
Erfolgt identisch zur chromedriver-Implementierung. Siehe Abschnitt
5.4.2.
40
David Fasching
Browser
Chrome
package
com.android.chrome
Android Browser
für Andoid 4.1
Android Browser
für Android 4.4
com.sec.android.app
.sbrowser
com.android.chrome
component
com.android.chrome/
com.google.android.apps
.chrome.Main
com.android.browser/
.BrowserActivity
com.sec.android.app
.sbrowser/
.SBrowserMainActivity
Tabelle 5.1: Komponentennamen und Paketnamen
initialize
Das Aufwecken des Gerätes läuft gleich zur chromedriver-Implementierung
(siehe Abschnitt 5.4.2) ab. Zum Starten des Browsers wird aber dann
folgendes ADB-Kommando verwendet:
adb -s < udid > shell am start
-a " android . intent . action . VIEW "
-n < component > -d < destination >
Bei <destination> handelt es sich um die Adresse, zu der navigiert
werden soll. Im Zuge der Initialisierung wird hier immer die Adresse
http://about:blank angesteuert. Dies entspricht einer leeren Seite. Für
<component> muss der genaue Komponentenname des Browsers angegeben werden, der gestartet werden soll. Tabelle 5.1 listet einige Komponentennamen für verschiedene Browser auf.
Nachdem der Browser gestartet wurde, ist das Gerät bereit, Steuerkommandos entgegenzunehmen.
shutdown
Um den Browser zu schließen, wird folgendes ADB-Kommando verwendet.
adb -s < udid > shell am force - stop < package >
<package> ist der Paketname des jeweiligen Browsers. In Tabelle 5.1
sind diese aufgelistet.
Da beim navigate-Kommando für jede Navigation ein neuer Tab geöffnet
wird, ist es wünschenswert diese beim shutdown wieder alle zu schließen.
Dies ist mit dem folgenden Kommando möglich.
adb -s < udid > shell pm clear < package >
Mit diesem Kommando wird die Browser-App komplett zurückgesetzt
und alle Einstellungen werden gelöscht. Viele Browser benötigen allerDavid Fasching
41
dings beim ersten Start nach einer Zurücksetzung eine Benutzereingabe,
was zu Problemen führen kann.
Das Gerät wird mit der selben Methode, wie bei der chromedriverImplementierung, in den Sleep-Zustand versetzt (siehe Abschnitt 5.4.2).
navigate
Zu einer anderen Webseite navigieren ist mit dieser Implementierung nur
durch erneutes Aufrufen der Browser-App möglich. Dazu wird das selbe
Kommando wie bei initialize verwendet. Nur wird für <destination>
diesmal die gewünschte Adresse angegeben, zu der navigiert werden soll.
Mit dieser Vorgehensweise wird für jede erneute Navigation ein neuer
Tab geöffnet.
reload
Für reload wird einfach nochmals mit navigate zur aktuellen Adresse
navigiert.
5.4.4
Implementierung iOS
Einige der Tools zum Steuern von iOS-Geräten werden nur für das Betriebsystem OSX angeboten. Die zu steuernden iOS-Geräte müssen daher mit einem Mac verbunden sein. Dieser Mac wird wiederum mit Kommandos gesteuert, die über eine SSH-Verbindung übertragen werden.
Diese Implementierung baut eine SSH-Verbindung zu dem Mac auf und
führt dann die gewünschten Programme und Skripten auf dem Mac aus.
Auch bei den Tools für iOS-Geräte kommt öfters eine udid zum Einsatz, die einzelne iOS-Geräte eindeutig identifiziert. Mit dem Programm
idevice_id lassen sich alle angschlossenen iOS-Geräte mit ihren udids
auflisten.
Mit dem Programm ios_webkit_debug_proxy kann der aktuell geöffnete
Tab auf dem iOS-Gerät gesteuert werden. ios_webkit_debug_proxy
selbst ist ein Programm, das sich über eine WebSocket-Schnittstelle steuern lässt. Der WebSocket steht an der folgenden Adresse zur Verfügung:
http :// localhost : < port >/ devtools / page /1
Der <port> kann beim Starten von ios_webkit_debug_proxy definiert
werden. Sobald eine Verbindung mit dem WebSocket hergestellt wurde, können an ihn Nachrichten in Form von JSON-Objekten gesendet
werden. Das JSON-Objekt muss wie folgt aufgebaut sein:
{
42
David Fasching
’id ’: <id > ,
’ method ’: < method > ,
’ params ’: < parameter >
}
Bei <id> handelt es sich um eine Nummer, die das Kommando eindeutig identifizieren soll. <method> und <parameter> variieren, je nachdem
welches Kommando an den mobilen Safari geschickt werden soll.
isConnected
Um zu überprüfen, ob ein bestimmtes iOS-Gerät mit dem Mac verbunden ist, wird folgendes Kommando verwendet:
idevicedate -- udid < udid >
Ist das gewünschte Gerät nicht erreichbar, wird im stdout ’device not
found’ ausgegeben.
initialize
Zum Öffnen des mobilen Browsers Safari wird eine eigens kompilierte
App namens SafariLauncher verwendet, die beim Start eine spezielle
Url aufruft. Dieser Aufruf bewirkt, dass Safari gestartet wird und eine
gewünschte Webseite öffnet. Der Source-Code der SafariLauncher App
wurde dem Appium Projekt entnommen und steht in einem öffentlichen
Repository2 zur Verfügung.
Mit Hilfe des Tools ios-deploy, kann diese App vom Mac aus gestartet
werden:
ios - deploy -i < udid > -d -L -b <app >
-a < destination >
Bei <app> handelt es sich dabei um den Pfad zur selbst-kompilierten
SafariLauncher-App. <destination> ist die gewünschte Url, die Safari
aufrufen soll. Im Zuge der Initialisierung wird hier immer
http://about:blank aufgerufen. Die Parameter -d und -L bewirken, das
die App auf dem Gerät gestartet wird.
shutdown
Das abschließende Deaktivieren des Gerätes wird in dieser Implementierung nicht unterstützt. Grund dafür ist, dass keine Methode gefunden
wurde, die dies ermöglicht. Siehe dazu auch Kapitel 4.1.3.
2
https://github.com/budhash/SafariLauncher
David Fasching
43
navigate
Für Url-Navigationen wird ios_webkit_debug_proxy verwendet. Dazu
muss folgendes JSON-Objekt an den WebSocket gesendet werden:
{
’id ’: <id > ,
’ method ’: ’ Page . navigate ’ ,
’ params ’: { ’url ’: < destination > }
}
<destination> ist die gewünschte Url, zu der navigiert werden soll.
reload
Auch das erneute Laden einer Webseite lässt sich mit
ios_webkit_debug_proxy bewerkstelligen. An den WebSocket muss dazu folgendes JSON-Objekt gesendet werden:
{
’id ’: <id > ,
’ method ’: ’ Page . reload ’ ,
’ params ’: { ’ ignoreCache ’: true }
}
5.5
Web App
Die Web App verwendet den Controller und stellt seine Funktionalität
über eine auf HTTP-basierende API zur Verfügung. Zusätzlich wird von
ihr auch noch die Client App zur Verfügung gestellt, die in Abschnitt
5.6 beschrieben wird.
5.5.1
Web API
Die API basiert auf dem HTTP-Protokol. Sie bietet verschiedene Kommandos an, die zur Steuerung des Controllers dienen.
Die Kommandos sind HTTP-Requests, deren Parameter mit dem
application/x-www-form-urlencoded content type übertragen werden müssen. Die Antworten der HTTP-Requests haben den content type
application/json und das übertragene JSON-Objekt hat die in Tabelle 5.2 gezeigte Struktur.
Im Folgenden werden die verfügbaren Kommandos angeführt. Als ReturnWerte werden die Daten beschrieben, die im data-Objekt zurückgegeben
werden.
44
David Fasching
Schlüssel
status
Beschreibung
Kann folgende Werte enthalten:
’ok’: Das Kommando wurde erfolgreich ausgeführt.
’error’: Bei der Ausführung des Kommandos
gab es ein Problem.
Eine beschreibende Nachricht über das Ergebnis
des Kommandos.
(optional) Ein Objekt, das Daten enthält, die
bei der Ausführung des Kommandos entstanden
sind.
message
data
Tabelle 5.2: Struktur JSON-Antwortobjekt
GET /state
Gibt Auskunft über alle verwalteten Geräte.
Return Eine Liste von allen vom Controller verwalteten Geräten sowie
Informationen über deren aktuellem Zustand wird zurückgegeben. Das
Ergebnis hat folgende Form:
{
’ Beispielgeraet ’:
{ ’ initialized ’: true , ’ active ’: true } ,
’ Anderesgeraet ’:
{ ’ initialized ’: false , ’ active ’: true }
}
active: Steuerkommandos werden an dieses Gerät weitergeleitet
initialized: Das Gerät ist initialisiert und kann Navigationen (navigate, reload) durchführen
POST /activate
Aktiviert das übergebene Gerät, damit zukünftige Steuerkommandos an
dieses Gerät weitergeleitet werden.
Das Kommando gibt einen error-status zurück, wenn der Controller das
Gerät nicht erreichen kann.
Parameter
deviceName – Name, der das Gerät identifiziert
David Fasching
45
DELETE /activate
Deaktiviert das übergebene Gerät, damit zukünftige Steuerkommandos
nicht mehr an dieses Gerät weitergeleitet werden.
Parameter
deviceName – Name, der das Gerät identifiziert
POST /initialize
Alle aktivierten Geräte werden initialisiert.
Return Für jedes Gerät wird ein Status zurückgegeben, der anzeigt
ob das Gerät erfolgreich initialisiert wurde.
POST /shutdown
Alle aktivierten Geräte werden in ihren sleep-Zustand versetzt.
Return Für jedes Gerät wird ein Status zurückgegeben, der anzeigt,
ob das Gerät erfolgreich in seinen sleep-Zustand versetzt wurde.
POST /navigate
Navigiert alle aktivierten und initialisierten Geräte zu der angegeben
URL.
Parameter
destination – URL, zu der navigiert werden soll
ob die Navigation erfolgreich war.
POST /reload
Lädt die Webseite aller aktivierten und initialisierten Geräte erneut.
ob, die Navigation erfolgreich war.
46
David Fasching
Eingabefeld
Button-Gruppe
für Navigationskommandos
Button-Gruppe
für Steuerkommandos
Bereich zur
Auswahl der Geräte
Log-Bereich
Abbildung 5.5: View der Client App
POST /navigate ghostlab
Ghostlab wird für die übergebene URL konfiguriert. Alle aktivierten und
initialisierten Geräte werden zu der URL navigiert, an der Ghostlab seine
Dienste bereit stellt.
ob die Navigation erfolgreich war.
5.6
Client App
Die Client App wurde sehr einfach gehalten und hat nur die Aufgabe,
die von der Web App angebotene Funktionalität für den Endbenutzer
zur Verfügung zu stellen.
Bei der Client App handelt es sich um eine Webseite, die in einem Browser aufgerufen wird. Sie baut auf das Frontend-Framework Bootstrap
[Ott15] auf und verwendet die Javascript-Library jQuery [The15].
Die gesamte App besteht aus einer View, die in Abbildung 5.5 abgebildet ist. Die View besteht aus einem Eingabefeld für Url-Navigationen,
einer Button-Gruppe für Navigationskommandos, einer ButtonGruppe für Steuerkommandos, einem Bereich zur Auswahl der
Geräte, die angesteuert werden sollen, und einem Log-Bereich.
Eingabefeld und Button-Gruppe für Navigationskommandos
In das Eingabefeld kann die gewünschte Url eingeben werden, zu der die
mobilen Endgeräte navigieren sollen. Mit einem Klick auf go! wird an
David Fasching
47
alle aktivierten Geräte das Kommando geschickt zu der entsprechenden
Url zu navigieren.
Bei einem Klick auf reload wird bei allen aktiven Geräten die aktuelle
Webseite erneut geladen.
Ist die Benutzung von Ghostlab erwünscht, muss anstelle des go!-Buttons
der use Ghostlab“-Button verwendet werden.
”
Nur initialisierte Geräte können Navigationskommandos entgegennehmen und ausführen.
Button-Gruppe für Steuerkommandos Mit einem Klick auf init werden alle aktivierten Geräte initialisiert (Gerät wird geweckt und
der Browser wird gestartet). Mit einem Klick auf shutdown werden alle
aktivierten Geräte in ihren Sleep-Zustand versetzt.
Bereich zur Auswahl der Geräte Mit einem Klick auf ein gewünschtes Gerät wird dieses aktiviert. Sobald ein Gerät aktiviert ist,
werden zukünftige Kommandos an dieses Gerät geschickt. Mit einem
erneuten Klick lässt sich ein Gerät wieder abwählen und somit für den
Empfang von Kommandos deaktivieren. Wurde ein Gerät erfolgreich initialisiert, wird der entsprechende Button grün. Für nicht initialisierte
Geräte ist der Button blau.
Log-Bereich Hier werden die Nachrichten ausgegeben, die als Ergebnis für abgeschickte Kommandos zurückgegeben wurden.
Under the hood
Folgendes geschieht im Hintergrund: Bei Klicks auf Buttons wird JavaScriptCode ausgeführt, der das entsprechende Kommando als ein HTTP-Request
an die Web App schickt und das zurückkommende Ergebnis verarbeitet.
Das senden von HTTP-Requests läuft immer nach dem selben Schema
ab. Beispielsweise zum Aktivieren eines Gerätes:
$ . ajax ({
url : ’/ activate ’ ,
type : ’ POST ’ ,
data : { ’ deviceName ’: deviceName } ,
success : handleSuccessFn ,
error : handleErrorFn
});
Hier wird ein HTTP-Request an die Web App geschickt und bei einer
erfolgreichen Antwort die handleSuccessFn Funktion ausgeführt. Bei
einem Fehler wird die Funktion handleErrorFn ausgeführt.
48
David Fasching
5.7
Ghostlab Integration
Ghostlab agiert im Grunde als ein Proxy-Server. In Ghostlab wird eine
Url zu einer Webseite konfiguriert. Wenn nun mit einem Browser die Url
aufgerufen wird, an der Ghostlab seine Dienste anbietet (Ghostlab-Url),
werden die Inhalte der konfigurierten Webseite geladen. Zusätzlich werden aber von Ghostlab noch einige Skripte injiziert, die dann die von
Ghostlab angebotenen Funktionalitäten wie etwa synchronisertes Scrollen oder synchronisierte Klick-Events ermöglichen. Wenn nun mehrere
Geräte die Ghostlab-Url in einem Browser aufrufen, können die verschiedenen Events an alle beteiligten Browser synchronisiert werden. In
Ghostlab kann dann noch eingestellt werden, von welchen zu welchen
Geräten die Events synchronisiert werden sollen. Dadurch lässt sich eine
zentrale Steuerung bewerkstelligen.
Ghostlab ist ein kommerzielles Produkt mit geschlossenem Quellcode.
Des Weiteren wird von Ghostlab keine Schnittstelle angeboten, mit der
von außerhalb eine Steuerung der Anwendung ermöglicht wird. Es ist
daher nur sehr schwer möglich, Ghostlab in die Cross-Device-BrowserTesting Plattform zu integrieren. Es wurde dennoch versucht, zumindest die Konfiguration der Url zu einer Webseite zentral über die CrossDevice-Browser-Testing Plattform zu ermöglichen.
Um diese Funktionalität zu erreichen, kommt ein zusätzlicher ProxyServer zum Einsatz, der sich leicht über eine Schnittstelle konfigurieren
lässt. Ghostlab wird permanent auf die Adresse des zusätzlichen ProxyServers konfiguriert. Durch die Möglichkeit, dass der Proxy-Server konfiguriert werden kann, wird es möglich, Ghostlab indirekt auf eine andere
Webseite zu konfigurieren. In Abbildung 5.6 wird der gesamte Aufbau
noch einmal anschaulich dargestellt.
Bei der Implementierung des in Kapitel 5.3 vorgestellten Controllers
kommt das Node-Modul http-proxy zum Einsatz. Mit diesem Modul
kann ein sehr einfacher Proxy-Server erstellt werden, der sich im Weiteren von dem Controller direkt konfigurieren lässt. Beim Aufruf der
Funktion navigate_ghostlab des Controllers wird folgender Ablauf in
Gang gesetzt:
Zuerst wird der Proxy-Server auf die gewünschte Url konfiguriert. Wenn
jetzt die Url des Proxy-Servers aufgerufen wird, stellt dieser die Inhalte
der gewünschten Webseite zur Verfügung. Da Ghostlab auf die Url des
Proxy-Servers konfiguriert ist, stellt somit auch Ghostlab diese Inhalte
zur Verfügung. Anschließend müssen nur mehr alle betroffenen Geräte
zur Ghostlab-Url gesteuert werden.
David Fasching
49
www.example.com
In Proxy konfigurierte
Url zu gewünschter
Webseite
www.example.com
konfigurierbarer
Proxy-Server
In Ghostlab
konfigurierte Url zu
gewünschter Webseite
Ghostlab
Fix konfigurierte
Url zu Proxy-Server
Ghostlab
Ghostlab-Url
Ghostlab-Url
Normaler Ghostlab-Aufbau
Ghostlab-Aufbau mit
zwischengeschaltetem Proxy-Server
Abbildung 5.6: Ghostlab Aufbau
50
David Fasching
Kapitel 6
Evaluierung
Im abschließenden Kapitel wird die Cross-Device-Testing-Plattform einer Evaluierung unterzogen. Dazu wird in Abschnitt 6.1 das Design und
die Vorgehensweise beschrieben. In Abschnitt 6.2 werden die Ergebnisse
präsentiert.
6.1
Design
Klassische Evaluierungsmethoden haben meist Metriken (z.B. gefundene Fehler pro LOC) als Grundlage [DBCG14]. Zur Evaluierung der
Cross-Device-Browser-Testing Plattform war es allerdings schwer geeignete Metriken zu finden, weil es sich bei dieser Methode nur um eine
Teilautomatisierung handelt und der menschliche Aspekt weiterhin eine
tragende Rolle spielt. Aus diesem Grund kam bei der Evaluierung ein
Polaritätsprofil (vergleiche [Hof90, S. 75][Fri90, S. 184ff.][Fuc12]) zum
Einsatz.
Die Cross-Device-Browser-Testing Plattform wurde von sechs Personen,
die normalerweise die anwenderbezogenen Tests manuell ausführen, verwendet. Nach einer dreimonatigen Probephase mussten diese Personen
einen Evaluierungbogen ausfüllen, mit dem Veränderungen des Testverhaltens und der Testergebnisse in Erfahrung gebracht wurden. Der
Evaluierungsbogen ist in Appendix A.1 zu finden. Die gestellten Fragen
sind in Tabelle 6.1 aufgelistet.
6.2
Ergebnisse und Interpretation
Die Interpretation der Daten aus der Evaluierung ist die Meinung des
Autors. Die einzelnen Sichtweisen wurden durch zusätzliche Gespräche
mit den Testpersonen gestärkt und unterstützt.
51
KAPITEL 6. EVALUIERUNG
Seit Einführung der Cross-Device-Browser-Testing Plattform...
Frage 1 ...teste ich öfter.
Frage 2 ...decke ich beim Testen einen größeren Geräteumfang ab.
Frage 3 ...fallen mir mehr Fehler bedingt durch Leistungsfähigkeitsunterschiede einzelner Geräte auf
(z.B. unflüssiges Scrollen).
Frage 4 ...fallen mir mehr Fehler bedingt durch unterschiedliche
Browser und Plattformen einzelner Geräte auf (z.B. Darstellungsfehler in Safari).
Durch den Einsatz der Cross-Device-Browser-Testing Plattform...
Frage 5 ...hat sich der Testaufbau (das Setup) vereinfacht (Aufwand, bis die einzelnen Geräte und deren Browser gestartet sind).
Frage 6 ...spare ich Zeit bei der Testausführung auf mehreren
Geräten (z.B. Url-Navigationen, Formular-Eingaben,...).
Frage 7 ...habe ich aufgrund der Möglichkeit, Aktionen parallel
auszuführen, weniger Wartezeiten (z.B. kann ich zum
nächsten Gerät übergehen, während beim Aktuellen eine
Aktion durchgeführt wird).
Frage 8 Gleichzeitiges Testen mehrerer Geräte überfordert mich.
Tabelle 6.1: Evaluierungsfragen
52
David Fasching
stimme ich
gar nicht zu
stimme ich
vollkommen zu
Seit der Einführung der Cross-DeviceTesting Plattform...
[1] ...teste ich öfter
[2] ...decke ich einen größeren
Geräteumfang ab
[3] ...fallen mir mehr Fehler bedingt
durch Leistungsfähigkeitsunterschiede
einzelner Geräte auf
[4] ...fallen mir mehr Fehler bedingt
durch unterschiedliche Browser und
Plattformen einzelner Geräte auf
Durch den Einsatz der Cross-DeviceTesting Plattform...
[5] ...hat sich der Testaufbau (das Setup)
vereinfacht
[6] ...spare ich Zeit bei der
Testausführung auf mehreren Geräten
[7] ...habe ich aufgrund der Möglichkeit,
Aktionen parallel auszuführen, weniger
Wartezeiten
[8] Gleichzeitiges Testen mehrerer
Geräte überfordert mich
Abbildung 6.1: Polaritätsprofil der Evaluierung
6.2.1
Polaritätsprofil
Bei der Auswertung der Evaluierungsbögen wurden für jede Frage die
Antworten gemittelt und in einem Polaritätsprofil zusammengefasst.
In Abbildung 6.1 ist das resultierende Polaritätsprofil abgebildet.
6.2.2
Frage 1 - Testhäufigkeit
Mit ein Hintergedanke zur Einführung der Cross-Device-Browser-Testing
Plattform war es, durch ein attraktives Werkzeug die Testbereitschaft
der Entwickler zu erhöhen. Ein derartiges Verhalten konnte kaum beobachtet werden und es zeigt sich, dass ein Werkzeug alleine nicht ausreicht.
David Fasching
53
5
4
3
2
1
0
stimme ich gar nicht zu
stimme ich vollkommen zu
Abbildung 6.2: Frage 1 - Testhäufigkeit
Es müssen zusätzlich die Entwicklungsprozesse angepasst und die CrossDevice-Browser-Testing Plattform in diese Prozesse integriert werden.
6.2.3
Frage 2 - Geräteabdeckung
5
4
3
2
1
0
Abbildung 6.3: Frage 2 - Geräteabdeckung
Die Möglichkeit mehrere Geräte gleichzeitig zu steuern führte dazu,
dass automatisch auf mehr Geräten getestet wird. So werden häufig
zusätzliche Geräte dazugeschaltet, die dann nebenbei mitlaufen und gegenfalls auf weitere Fehler aufmerksam machen.
6.2.4
Frage 3 - Leistungsfähigkeitsunterschiede
5
4
3
2
1
0
Abbildung 6.4: Frage 3 - Leistungsfähigkeitsunterschiede
Das Verhalten von Webseiten auf leistungsschwächeren Geräten zu testen war immer ein wichtiges Argument zur Einführung der Cross-DeviceBrowser-Testing Plattform. Das etwas schwächere Ergebnis bezüglich
54
David Fasching
dieser Anforderung ist auf die mangelnde Ausstattung von leistungsschwächeren Geräten zurückzuführen. Hier wird es nötig sein noch mit
entsprechenden Geräten nachzurüsten.
6.2.5
Frage 4 - Browser- und Plattformunterschiede
5
4
3
2
1
0
Abbildung 6.5: Frage 4 - Browser- und Plattformunterschiede
Was hingegen sehr gut funktioniert, ist die Aufspürung von Problemen
bedingt durch Plattformunterschiede. Hier ist die gleichzeitige Ansteuerung von mehreren Geräten sehr hilfreich.
6.2.6
Frage 5 - Aufwand Testaufbau
5
4
3
2
1
0
Abbildung 6.6: Frage 5 - Aufwand Testaufbau
In der Theorie sollte der Testaufbau um einiges vereinfacht werden: Es
wird auf einen Button geklickt und alle Geräte sind einsatzbereit. In der
Praxis läuft dieser Prozess nicht immer so reibungslos ab. Das ist darauf
zurückzuführen, dass sich vorallem Geräte der iOS-Plattform nur recht
umständlich so steuern lassen, wie es nötig wäre. Dadurch entstehen
unnötige Wartezeiten bis zur Einsatzbereitschaft der Geräte. Hier sind
die Hersteller der Plattformen gefordert, derartige Gerätesteuerungen zu
vereinfachen oder gar zu ermöglichen.
6.2.7
Frage 6 - Zeitersparnis bei Testausführung
Eine der Hauptanforderungen an die Cross-Device-Browser-Testing Plattform, die Zeit der Testausführung zu verkürzen, wird dank der parallelen
David Fasching
55
5
4
3
2
1
0
Abbildung 6.7: Frage 6 - Zeitersparnis bei Testausführung
Ansteuerung der Geräte anstandslos erfüllt.
6.2.8
Frage 7 - Wartezeiten
5
4
3
2
1
0
Abbildung 6.8: Frage 7 - Wartezeiten
Diese Frage schlägt eine Arbeitsweise vor, die Testausführung mit Hilfe paralleler Abläufe effizienter zu gestalten. Das schwächere Ergebnis
lässt sich damit erklären, dass diese Arbeitsweise noch sehr neu und ungewohnt ist und sich die Tester erst daran gewöhnen müssen, um das
volle Potential des parallelen Arbeitens auszuschöpfen.
6.2.9
Frage 8 - Überforderung
5
4
3
2
1
0
Abbildung 6.9: Frage 8 - Überforderung
Die letzte Frage behandelt einen möglichen negativen Nebeneffekt, der
das parallele Arbeiten an mehreren Geräten haben könnte. Es zeigt sich
56
David Fasching
allerdings sehr eindeutig, dass diese Arbeitsweise zu keiner Überforderung
der Tester führt.
David Fasching
57
Kapitel 7
Résumé und Ausblick
Im Zuge dieser Arbeit wurde überprüft, ob mit der Methodik des CrossDevice-Browser-Testings anwenderbezogene Tests auf Benutzerschnittstellenebene effizienter gestaltet werden können. Anhand des entwickelten Prototyps kann bestätigt werden, dass diese Methodik derartige
Tests vereinfachen kann und dadurch der Testprozess optimiert werden
kann.
Bei der Entwicklung des Prototyps, der Cross-Device-Browser-Testing
Plattform, zeigten sich aber auch einige Schwierigkeiten. Diese laufen
hauptsächlich darauf hinaus, dass die Gerätesteuerung, aber auch die
Browsersteuerung teilweise nur sehr umständlich zu bewerkstelligen ist.
Vor allem Geräte der iOS-Plattform lassen sich nur sehr beschränkt für
die Methodik des Cross-Device-Browser-Testings steuern. Hier mussten
teilweise sehr unkonventionelle Methoden eingesetzt werden, die oft zu
Stabilitätsproblemen geführt haben. Auf der anderen Seite zeigt hingegen Google mit den zur Verfügung gestellten Werkzeugen chromedriver und ADB für die Android-Plattform, wie es gemacht werden sollte. Mit diesen Werkzeugen lassen sich die betroffenen Geräte einwandfrei und zuverlässig steuern. Es zeigt sich, dass die Kooperation der
Plattform-Hersteller eine sehr wichtige Rolle spielt, um Cross-DeviceBrowser-Testing erfolgreich umzusetzen.
Aus der Sicht der Personen, welche die Cross-Device-Browser-Testing
Plattform ausprobierten, kommt der sehr eindeutige Konsens, dass CrossDevice-Browser-Testing durchaus Potential hat die Testprozesse zu optimieren. Was sich allerdings zeigte ist, dass die Existenz einer CrossDevice-Browser-Testing Plattform alleine nicht ausreicht, zum öfteren
Testen zu motivieren. Die Plattform muss fix in die Entwicklungsprozesse integriert werden. Dank der Zeitersparnis durch Cross-Device-BrowserTesting und der daraus resultierenden besseren Kosten-Nutzen-Relation
kann aber besser für eine dementsprechende Integration argumentiert
59
KAPITEL 7. RÉSUMÉ UND AUSBLICK
Abbildung 7.1: Arbeitsplatz nach Einführung der Cross-Device-BrowserTesting Plattform
werden.
Für die zukünftige Weiterentwicklung der Cross-Device-Browser-Testing
Plattform kamen einige sehr einstimmige Ideen zum Vorschein. Zum
einen wurde sehr häufig eine bessere Möglichkeit gewünscht, gefundene
Fehler zu dokumentieren. Beispielsweise wäre die Möglichkeit Screenshots für alle Geräte zentral vom Steuerungs-PC aus zu machen eine sehr
hilfreiche Funktionalität. Auch diese Screenshots und weitere Informationen über die Cross-Device-Browser-Testing Plattform direkt in ein
bestehendes Ticket-System einzupflegen erscheint als sehr sinnvoll.
Die in Kapitel 5 vorgestellte Implementierung hat auch eine nur sehr
rudimentäre Benutzeroberfläche, die sicherlich noch um einiges intuitiver
gestaltet werden kann. Dies sollte dank der soliden Software-Architektur
sehr einfach umzusetzen sein.
Eine weitere Idee, die großes Interesse stiftete, ist die Erweiterung der
Devices neben mobilen Endgeräten auch um Desktop-Browser unterschiedlicher Versionen (z.B. IE9, IE10, IE11). Dies sollte mit der bestehenden Software-Architektur und möglicherweise dem Einsatz von
virtuellen Maschinen ebenfalls kein Problem sein.
60
David Fasching
Appendix
A.1
Evaluierungsbogen
61
APPENDIX A.1. EVALUIERUNGSBOGEN
Evaluierungsbogen - Cross-Device-Testing Plattform
Seit Einführung der Cross-Device-Testing Plattform…
Ich stimme gar
nicht zu
Ich stimme
vollkommen zu
Ich stimme gar
nicht zu
Ich stimme
vollkommen zu
...teste ich öfter
...decke ich beim Testen einen größeren Geräteumfang ab
...fallen mir mehr Fehler bedingt durch
Leistungsfähigkeitsunterschiede einzelner Geräte auf
(z.B. unflüssiges Scrollen)
...fallen mir mehr Fehler bedingt durch unterschiedliche
Browser und Plattformen einzelner Geräte auf
(z.B. Darstellungsfehler in Safari)
Durch den Einsatz der Cross-Device-Testing Plattform...
...hat sich der Testaufbau (das Setup) vereinfacht
(Aufwand, bis die einzelnen Geräte und deren Browser
gestartet sind)
...spare ich Zeit bei der Testausführung auf mehreren
Geräten
(z.B. Url-Navigationen, Formular-Eingaben,...)
...habe ich aufgrund der Möglichkeit, Aktionen parallel
auszuführen, weniger Wartezeiten
(z.B. kann ich zum nächsten Gerät übergehen, während
beim Aktuellen eine Aktion durchgeführt wird)
Gleichzeitiges Testen mehrerer Geräte überfordert mich
Folgende Erweiterungsvorschläge der Cross-Device-Testing Plattform erscheinen mir sinnvoll
Ich stimme gar
nicht zu
Ich stimme
vollkommen zu
Die Möglichkeit gefundene Probleme direkt über die
Cross-Device-Testing Plattform zu dokumentieren
(z.B. Screenshots von Geräten, sowie direkte Integration in
ein Ticketsystem)
Die Möglichkeit zum Testen an älteren Desktop-Browser
Versionen (z.B. IE9)
Bitte wenden!
62
David Fasching
Abbildungsverzeichnis
2.1
Der Fundamentale Testprozess [SBB11, Kap. 2.1] . . . . .
3.1
3.2
3.3
Entwicklungsprozess für eine Neuentwicklung . . . . . . . 8
Arbeitsplatz vor Einführung der Cross-Device-BrowserTesting Plattform . . . . . . . . . . . . . . . . . . . . . . . 10
Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1
5.2
5.3
5.4
5.5
5.6
Hardware Architektur . . . . . . . .
Software Architektur . . . . . . . . .
Sequenzdiagramm typischer Abläufe
Device Zustände . . . . . . . . . . .
View der Client App . . . . . . . . .
Ghostlab Aufbau . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
33
34
37
47
50
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
Polaritätsprofil der Evaluierung . . . . . . . .
Frage 1 - Testhäufigkeit . . . . . . . . . . . .
Frage 2 - Geräteabdeckung . . . . . . . . . .
Frage 3 - Leistungsfähigkeitsunterschiede . . .
Frage 4 - Browser- und Plattformunterschiede
Frage 5 - Aufwand Testaufbau . . . . . . . .
Frage 6 - Zeitersparnis bei Testausführung . .
Frage 7 - Wartezeiten . . . . . . . . . . . . .
Frage 8 - Überforderung . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
54
54
54
55
55
56
56
56
7.1
Arbeitsplatz nach Einführung der Cross-Device-BrowserTesting Plattform . . . . . . . . . . . . . . . . . . . . . . . 60
63
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
Tabellenverzeichnis
4.1
4.2
4.3
verwendete Technologien iOS . . . . . . . . . . . . . . . . 22
verwendete Technologien Android . . . . . . . . . . . . . . 24
Zusammenfassung Seitennavigation . . . . . . . . . . . . . 29
5.1
5.2
Komponentennamen und Paketnamen . . . . . . . . . . . 41
Struktur JSON-Antwortobjekt . . . . . . . . . . . . . . . 45
6.1
Evaluierungsfragen . . . . . . . . . . . . . . . . . . . . . . 52
64
Literaturverzeichnis
[App15a] Appium Projekt: appium Homepage, 2015, URL http://
appium.io, [Zugriff: 27.08.2015].
[App15b] Apple Inc.: Xcode Developer Tools Homepage, 2015, URL
https://developer.apple.com/xcode, [Zugriff: 27.08.2015].
[Bas12]
Y. Bassil: Distributed, Cross-Platform, and Regression Testing
Architecture for Service-Oriented Architecture, Advances in
Computer Science and its Applications (ACSA), volume 1(1),
(2012), pages 9–15.
[DBCG14] S. Doğan, A. Betin-Can and V. Garousi: Web application
testing: A systematic literature review, Journal of Systems and
Software, volume 91, (2014), pages 174 – 201.
[Ein15]
O. S. Einar: ws Github-Repository, 2015, URL https://
github.com/websockets/ws, [Zugriff: 27.08.2015].
[EM07]
C. Eaton and A. M. Memon: An Empirical Approach to Evaluating Web Application Compliance Across Diverse Client
Platform Configurations, Int. J. Web Eng. Technol., volume 3(3), (2007), pages 227–253.
[Fri90]
J. Friedrichs: Methoden empirischer Sozialforschung, VS Verlag für Sozialwissenschaften, Wiesbaden, 1990.
[Fuc12]
K. Fuchs: Fachspezifische Software – Die Qual der Wahl, Zeitschrift für neue Lernkulturen, volume 4(1), (2012), pages 56–
60.
[Goo12a] Google Inc.: iOS WebKit Debug Proxy GithubRepository, 2012, URL https://github.com/google/
ios-webkit-debug-proxy, [Zugriff: 27.08.2015].
[Goo12b] Google Inc.: Remote debugging protocol, 2012,
https://developer.chrome.com/devtools/docs/
debugger-protocol, [Zugriff: 27.08.2015].
65
URL
APPENDIX LITERATURVERZEICHNIS
[Goo15a] Google Inc.: Android Debug Bridge Homepage, 2015, URL
http://developer.android.com/tools/help/adb.html,
[Zugriff: 27.08.2015].
[Goo15b] Google Inc.: ChromeDriver Homepage, 2015, URL https:
//sites.google.com/a/chromium.org/chromedriver, [Zugriff: 27.08.2015].
[Hal13]
K. Haller: Mobile Testing, SIGSOFT Softw. Eng. Notes, volume 38(6), (2013), pages 1–8.
[Hof90]
P. R. Hofstätter: Gruppendynamik Kritik der Massenpsychologie, Rowohlt, 1990.
[HP14]
HP: Cross-browser functional testing best practices, Technical
report, HP; United States, 2014.
[Ios15]
Ios-driver Projekt: ios-driver Homepage, 2015, URL https://
ios-driver.github.io/ios-driver, [Zugriff: 27.08.2015].
[JH15]
JH: Browsersync Homepage, 2015, URL http://www.
browsersync.io, [Zugriff: 27.08.2015].
[Lib07]
Libimobiledevice Projekt: libimobiledevice Homepage,
2007, URL http://www.libimobiledevice.org, [Zugriff:
27.08.2015].
[McM15] C. McMahon: async Github-Repository, 2015, URL https:
//github.com/caolan/async, [Zugriff: 27.08.2015].
[MP11]
A. Mesbah and M. Prasad: Automated cross-browser compatibility testing, Software Engineering (ICSE), 2011 33rd International Conference on, pages 561–570.
[MRT08] A. Marchetto, F. Ricca and P. Tonella: A Case Study-based
Comparison of Web Testing Techniques Applied to AJAX
Web Applications, Int. J. Softw. Tools Technol. Transf., volume 10(6), (2008), pages 477–492.
[MvD09] A. Mesbah and A. van Deursen: Invariant-based Automatic
Testing of AJAX User Interfaces, Proceedings of the 31st International Conference on Software Engineering, ICSE ’09,
IEEE Computer Society, Washington, DC, USA, pages 210–
220.
[Nod15a] Nodejitsu: node-http-proxy Github-Repository, 2015, URL
https://github.com/nodejitsu/node-http-proxy, [Zugriff: 27.08.2015].
66
David Fasching
APPENDIX LITERATURVERZEICHNIS
[Nod15b] Node.js Foundation: node.js Homepage, 2015, URL https:
//nodejs.org, [Zugriff: 27.08.2015].
[Npm09] Npm, Inc.: npm Homepage, 2009, URL https://www.npmjs.
com, [Zugriff: 27.08.2015].
[Ott15]
M. Otto: Bootstrap Homepage, 2015,
getbootstrap.com, [Zugriff: 27.08.2015].
URL
[Pho15]
Phonegap: ios-deploy Github-Repository, 2015, URL https:
//github.com/phonegap/ios-deploy, [Zugriff: 27.08.2015].
[Pro15]
R. Projekt: request Github-Repository, 2015, URL https://
github.com/request/request, [Zugriff: 27.08.2015].
http://
[SBB11] R. Seidl, M. Baumgartner and T. Bucsics: Basiswissen Testautomatisierung, dpunkt.verlag GmbH, Heidelberg, 2011.
[Sel12]
Selendroid Projekt: selendroid Homepage, 2012, URL http:
//selendroid.io, [Zugriff: 27.08.2015].
[Sel15]
Selenium Projekt: Selenium Homepage, 2015, URL http://
www.seleniumhq.org, [Zugriff: 27.08.2015].
[SRWL14] A. Spillner, T. Roßner, M. Winter and T. Linz: Praxiswissen
Softwaretest – Testmanagement, dpunkt.verlag GmbH, Heidelberg, 2014.
[Str15]
StrongLoop: express Homepage, 2015,
//expressjs.com, [Zugriff: 27.08.2015].
[The15]
The jQuery Foundation: jQuery Homepage, 2015, URL
https://jquery.com, [Zugriff: 27.08.2015].
[Van11]
Vanamco AG: Ghostlab Homepage, 2011, URL http://www.
vanamco.com/ghostlab, [Zugriff: 27.08.2015].
[Whi15]
B. White: ssh2 Github-Repository, 2015, URL https://
github.com/mscdex/ssh2, [Zugriff: 27.08.2015].
David Fasching
URL
http:
67

Einführung und Evaluierung einer Cross-Device

Transcription

Similar documents

Sprachgesteuerte Navigation in komplexen

Methoden der Software–Testung

NetBSD - AT HTML Editor 32

Ausarbeitung - AG Softwaretechnik

Inspiring Funding Agencies to Make a Difference

Time Partition Testing — Systematischer Test

rev. 1.11 - Informatik - FB3