Die vorliegende Masterthesis beschäftigt sich mit dem Einsatz von Continuous Integration in der Android-Entwicklung. Dabei liegt das Hauptaugenmerk auf automatisierten Tests. Ziel der Arbeit ist zum einen, die Besonderheiten und Möglichkeiten beim Testen von mobilen, insbesondere Android-Anwendungen aufzuzeigen.
Zum anderen wird eine Ende-zu-Ende-Buildkette beschrieben, mit welcher der Integrationsprozess von Android-Anwendungen unter Einsatz des Werkzeugs Jenkins vollständig automatisiert werden kann. Zusätzlich wird ein Konzept für einen skalierbaren Gerätepool vorgestellt, mit dem es möglich ist, Android-Anwendungen parallel auf beliebig vielen Endgeräten zu testen.
CD nicht im Lieferumfang enthalten!
Inhaltsverzeichnis
1. Einleitung
1.1. Kontext der Arbeit
1.2. Ziel der Arbeit
1.3. Aufbau der Arbeit
2. Continuous Integration als Konzept
2.1. Definition
2.2. Die zehn CI-Praktiken
2.3. Vorteile von Continuous Integration
3. Testen von Android-Anwendungen
3.1. Besonderheiten
3.1.1. Konfigurationsvielfalt
3.1.2. Ein- und Ausgabe
3.2. Testumgebungen
3.3. Test-Arten
3.4. Werkzeuge
3.4.1. Android Testing Framework
3.4.2. Monkeyrunner
3.4.3. Robotium
3.4.4. Robolectric
3.5. Beispiele
3.5.1. Beispielanwendung: PixBox-App
3.5.2. Testen mit dem ATF
3.5.3. Testen mit Monkeyrunner
4. Entwicklung einer CI-Kette für Android-Projekte
4.1. Die CI-Kette im Überblick
4.2. Jenkins CI-Server
4.2.1. Jenkins – Ein historischer Überblick
4.2.2. Die Architektur von Jenkins
4.2.3. Jenkins-Server für diese Arbeit
4.3. Versionsmanagement mit Git
4.4. Automatisierte Builds
4.4.1. Werkzeuge
4.4.2. Jenkins-Integration
4.5. Statische Codeanalyse
4.5.1. Werkzeuge
4.5.2. Jenkins-Integration
4.6. Automatisiertes Deployment
4.7. Automatisierte Tests
4.8. Automatisierte Berichte
4.8.1. Aktive Benachrichtigungen
4.8.2. Informationen auf Abruf
5. Konzept für einen skalierbaren Testpool
5.1. Benötigte Vorkenntnisse
5.1.1. Android Debug Bridge
5.1.2. Verteilte Builds mit Jenkins
5.2. Architektur-Konzept
5.3. Ablauf
5.4. Slave-Knoten
5.5. Jobs
5.5.1. Build-Job
5.5.2. Test-Job
5.6. Test-Skript
6. Fazit
Zielsetzung & Themen
Ziel dieser Arbeit ist die Entwicklung einer vollständig automatisierten Ende-zu-Ende-Buildkette für die Android-Entwicklung unter Verwendung des CI-Systems Jenkins. Ein besonderer Fokus liegt dabei auf der Evaluation und Implementierung automatisierter Testverfahren sowie der Konzeption eines skalierbaren Testpools, der parallele Tests auf einer Vielzahl von Geräten ermöglicht.
- Einsatz von Continuous Integration in der mobilen Softwareentwicklung.
- Untersuchung und Vergleich verschiedener Test-Frameworks für Android.
- Aufbau einer automatisierten Build-Kette mit Jenkins, Git und Ant.
- Integration statischer Codeanalyse-Werkzeuge in den Build-Prozess.
- Konzeption und Realisierung eines skalierbaren Testpools für Paralleltests.
Auszug aus dem Buch
3.1.1. Konfigurationsvielfalt
Die größte Herausforderung beim Testen von Android-Anwendungen ist die Konfigurationsvielfalt. Die Menge der zur Verfügung stehenden Android-Geräte ist immens groß, fast unüberschaubar. Die Entwickler der beliebten Android-App OpenSignal führen seit 2012 eine Studie durch, bei der für jeden Download der App Informationen über das herunterladende Gerät sowie das darauf installierte Betriebssystem gesammelt werden. Bei insgesamt 682.000 Downloads lag die Anzahl der unterschiedlichen verwendeten Geräte im Jahr 2012 bei knapp 4000 und im Juli 2013 bereits bei annähernd 12000. Der Trend zur sog. Device Fragmentation scheint sich also weiterhin stark fortzusetzen. Abbildung 3.1 zeigt eine von OpenSignal erstellte Visualisierung unterschiedlicher Android-Geräte, mit denen die App in den letzten Monaten heruntergeladen wurde.
Während die Verfügbarkeit so vieler verschiedener Geräte für den Endbenutzer eher vorteilhaft ist (in jeder Preisklasse ist ein entsprechendes Android-Gerät zu finden), stellt sie eine große Herausforderung an das Testen von Applikationen dar. Es existieren Geräte unterschiedlichster Größen, welche verschiedene Bildschirmauflösungen nutzen. Hinzu kommt die große Anzahl verschiedener Android-Versionen. Jedes Jahr erscheint mindestens eine neue Version des Betriebssystems, wobei viele ältere Geräte nicht in der Lage sind, diese auszuführen. Dies führt dazu, dass zur selben Zeit viele verschiedene Android-Versionen im Umlauf sind.
Wollte man sicherstellen, dass eine Anwendung auf allen verfügbaren Geräten und OS-Versionen korrekt läuft, müsste man eine unmöglich zu bewältigende Anzahl an Kombinationen aus Geräten und Betriebssystemen testen. Natürlich ist nicht jedes Gerät komplett unterschiedlich und eine Anwendung muss nicht zwingend für die Ausführung auf allen OS-Versionen konzipiert sein. Jedoch ergibt sich, selbst wenn man nur einen ausgewählten Teil der verfügbaren Kombinationen abdecken möchte, schnell eine sehr komplexe Konfigurationsmatrix.
Zusammenfassung der Kapitel
1. Einleitung: Vorstellung des Kontexts der Arbeit, der Relevanz von Continuous Integration für die Android-Entwicklung sowie der Zielsetzung und des Aufbaus der Thesis.
2. Continuous Integration als Konzept: Erläuterung der Grundlagen von Continuous Integration, inklusive der zehn Kernpraktiken und der daraus resultierenden Vorteile für die Softwareentwicklung.
3. Testen von Android-Anwendungen: Detaillierte Betrachtung der Besonderheiten beim Testen von Android-Apps, gefolgt von einer Vorstellung gängiger Test-Frameworks und Praxisbeispielen.
4. Entwicklung einer CI-Kette für Android-Projekte: Dokumentation des Aufbaus der CI-Kette, der Integration von Jenkins, Git, Build-Werkzeugen sowie der Implementierung statischer Codeanalyse und automatisierter Berichterstattung.
5. Konzept für einen skalierbaren Testpool: Vorstellung eines Architektur-Konzepts zur Realisierung eines skalierbaren Pools für parallele automatisierte Tests auf verschiedenen Android-Geräten.
6. Fazit: Zusammenfassende Bewertung der Ergebnisse sowie Ausblick auf das Potenzial und die Anforderungen für den professionellen Einsatz von CI in der Android-Entwicklung.
Schlüsselwörter
Continuous Integration, Android, Jenkins, Automatisierte Tests, Softwarequalität, Build-Kette, Device Fragmentation, Test-Framework, Statische Codeanalyse, Testpool, Jenkins Plugins, Build-Automatisierung, Android Testing Framework, Robotium, Monkeyrunner.
Häufig gestellte Fragen
Worum geht es in dieser Arbeit grundsätzlich?
Die Masterthesis behandelt den Einsatz von Continuous Integration (CI) in der Android-Entwicklung, wobei der Fokus primär auf der Automatisierung des Testprozesses liegt.
Was sind die zentralen Themenfelder?
Die zentralen Themen sind der Aufbau einer CI-Kette, der Vergleich von Android-Test-Frameworks und die Entwicklung eines skalierbaren Konzepts für parallele Gerätetests.
Was ist das primäre Ziel der Arbeit?
Das Ziel ist die Beschreibung einer Ende-zu-Ende-Buildkette für Android, die den gesamten Prozess vom Einchecken des Codes bis zur automatisierten Testausführung vollständig automatisiert.
Welche wissenschaftliche Methode wurde verwendet?
Es wurde eine praxisorientierte, explorative Methode angewandt: Eine Beispielanwendung (PixBox-App) wurde entwickelt, um die Integration verschiedener Werkzeuge (Jenkins, Git, Ant, Test-Frameworks) in eine CI-Kette unter realen Bedingungen zu evaluieren.
Was wird im Hauptteil der Arbeit behandelt?
Der Hauptteil gliedert sich in die theoretischen CI-Grundlagen, eine detaillierte Analyse der Android-Test-Frameworks, die Implementierung der CI-Kette mit Jenkins sowie die Ausarbeitung eines Konzepts für einen skalierbaren Testpool.
Welche Schlüsselwörter charakterisieren die Arbeit?
Die Arbeit lässt sich am besten durch Begriffe wie Continuous Integration, Android, Jenkins, automatisierte Tests, Device Fragmentation und Build-Automatisierung beschreiben.
Welches Problem der Gerätevielfalt wird thematisiert?
Die Arbeit adressiert die massive "Device Fragmentation" im Android-Ökosystem, die es nahezu unmöglich macht, Anwendungen manuell auf allen verfügbaren Hardware-Konfigurationen und OS-Versionen zu testen.
Wie lässt sich das Problem der beschränkten adb-Verbindungen lösen?
Das entwickelte Konzept nutzt eine verteilte Architektur mit Jenkins-Slave-Knoten, bei der jeder Knoten exklusiv mit einem Gerät kommuniziert, um so die Limitierungen des adb-Clients bei parallelen Tests zu umgehen.
- Arbeit zitieren
- Max Batt (Autor:in), 2013, Continuous Integration und automatisierte Tests für Android, München, GRIN Verlag, https://www.grin.com/document/314757
