Emulator to the Rescue

Android-Fragmentierung – Testen per Emulator
Kommentare

Ein überzeugendes User Interface (UI) ist maßgeblich für den Erfolg einer jeden App. Ein ausgiebiges Testen des UI in Hinblick auf funktionale Korrektheit und User Experience (UX) ist unabdingbar. Android bringt diesbezüglich besondere Herausforderungen mit sich. Das Stichwort „Fragmentierung“ charakterisiert die größte Hürde im umfassenden Testing von mobilen Apps. Insbesondere Android-Geräte erscheinen laufend in zahllosen Formen, Größen und Ausstattungen auf dem Markt. Wir zeigen, wie sich nahezu alle Gerätetypen mithilfe des Android-Emulators und einigen Tricks aus der täglichen Praxis reibungslos testen lassen.

Eine der größten Herausforderungen, vor der Android-Entwickler im täglichen Alltag stehen, ist die breite Fragmentierung von mobilen Endgeräten und Android-Versionen. Im Juli 2013 waren laut der OpenSignal-Studie bereits mehr als 11 828 unterschiedliche Android-Endgeräte in allen denkbaren Formen und Größen, mit vielfältigen Bildschirmgrößen und Leistungsmerkmalen auf dem Markt vertreten (Abb. 1). Im Vergleich hierzu wurden lediglich 3 997 Gerätetypen in der Studie des Vorjahres erfasst.

Abb. 1: Verbreitung von 11 828 Android-Gerätetypen (OpenSignal-Studie 07/2013)

Aus Sicht der Mobile-App-Entwicklung lassen sich diese Gerätetypen grundlegend mit vier Eigenschaften charakterisieren:

1. OS: Die Version (1.1 bis 4.3) des Android-Betriebssystems wird technisch mit dem so genannten API-Level (1 bis 18) und dessen Revision festgelegt.
2. Display: Der Bildschirm wird vorwiegend über die Bildschirmauflösung (gemessen in Pixeln), Bildschirmdichte (gemessen in DPI) und/oder Bildschirmgröße (Diagonale gemessen in Inch) beschrieben.
3. CPU: Das „Application Binary Interface“ (ABI) definiert u. a. den Befehlssatz der CPU, vorrangig wird hier zwischen ARM- und Intel-basierten CPUs unterschieden.
4. Memory: Ein Gerät verfügt über Arbeitsspeicher (RAM) und dem vordefinierten Heap-Speicher für die Dalvik-VM (VM-Heap).

Insbesondere die ersten beiden Merkmale, sprich OS und Display, sind für den Endanwender direkt erkennbar und sollten zwingend durch intensives Testing abgedeckt werden. Hinsichtlich der Android-Versionen waren im Juli 2013 acht Versionen zeitgleich auf dem Markt vertreten und trugen so maßgeblich zur Fragmentierung bei. Im Juli bildeten die Version Gingerbread (2.3.3–2.3.7) mit 34,1 Prozent, Jelly Bean (4.1.x) mit 32,3 Prozent und Ice Cream Sandwich (4.0.3–4.0.4) mit 23,3 Prozent den signifikanten Anteil von rund 90 Prozent (Abb. 2).

Abb. 2: Verbreitung der 16 Android-Versionen (OpenSignal-Studie 07/2013)

In Bezug auf die Displays der Endgeräte zeigt eine Studie von TechCrunch durchgeführt im April 2013 deutlich, dass der Löwenanteil (79,9 Prozent) der aktivierten Endgeräte die „normale“ Bildschirmgröße verwenden – diese reicht von 3 Inch bis ungefähr 4,5 Inch. Zudem sind vorwiegend die Bildschirmdichten „mdpi“ (~160 dpi), „hdpi“ (~240 dpi) und „xhdpi“ (~320 dpi) vertreten. Eine Ausnahme findet sich in den Geräten mit einer niedrigen „ldpi“ (~120 dpi) und der Bildschirmgröße „Small“ mit 9,5 Prozent (Abb. 3).

Abb. 3: Verteilung der normalisierten Bildschirmgrößen und -dichten („buckets“) (Google-Studie 04/2013) [2]

Wird diese Vielfalt in der Qualitätssicherung vernachlässigt, schleichen sich unmittelbar Mängel in die App ein. Es folgt ein Sturm von Bugreports und letztendlich ein negatives Rating im Google Play Store. Es stellt sich die Frage, wie diese Aspekte in der Praxis mit vertretbarem Testaufwand abgedeckt werden können. Eine pragmatische Lösung bietet der Android-Emulator – die charakteristischen Merkmale eines Android-Geräts lassen sich mit diesem Werkzeug auf einem herkömmlichen PC mithilfe eines virtualisierten Endgeräts nachstellen. Zuvor sollte jedoch definiert werden, wie ein sinnvolles Testing-Konzept für die vorliegende App aussehen kann.

[ header = Seite 2: Konzept: „wo“, „was“ und „wie“ testen? ]

Konzept: „wo“, „was“ und „wie“ testen?

Das „Wo“: Um sich den zeitlichen Aufwand eines sukzessiven Tests auf den 32 prägnanten Android-Versionen und Bildschirmkombinationen zu ersparen, empfehlen wir eine Einschränkung auf die Top 5 bis 10 der vertretenen Endgeräte. Hierbei sollte berücksichtigt werden, dass diese Auswahl an Referenzgeräten möglichst eine breite Diversität in Hinblick auf Android-Versionen und Bildschirmmerkmale repräsentiert.
Beispielsweise lassen sich die populären Geräte anhand der OpenSignal-Studie 2013 oder der Infographics von Handset Detection ermitteln. Für Neugierige: Wie sich zudem die Spezifikation eines Gerätebildschirms (sprich Auflösung und Größe) auf die Bildschirmdichte- („ldpi“, „mdpi“ usw.) und Bildschirmgrößeintervalle bzw. -Buckets („Small“, „Normal“ usw.) aus den obigen Statistiken abbilden lassen, kann der Android-Dokumentation entnommen werden.

Gerätekennung Displayspez. (Breite x Höhe, Größe) Display-Buckets (Größe, Dichte) Niedrigste Android-Version RAM
Samsung I9300 Galaxy S III 720 x 1280, 4,8′ normal, xhdpi 4.0.4 1024 MB
Samsung I9100 Galaxy S II 480 x 800, 4,3′ normal, hdpi 2.3.4 1024 MB
Samsung Galaxy Y S5360 240 x 320, 3,0′ small, ldpi 2.3.5 290 MB
LG Nexus 4 E960 768 x 1280, 4,7′ norma, xhdpi 4.2 2048 MB
Asus Google Nexus 7 800 x 1280, 7,0′ large, tvdpi 4.1 1024 MB
HTC Wildfire S 320 x 480, 3,2′ small, ldpi 2.3 512 MB

Tabelle 1: Sechs exemplarische Android-Endgeräte mit hoher Diversität und Verbreitung (Handset-Detection-Studie 02/2013)

Für eine repräsentative Wahl dieser Referenzgeräte ist die Handset-Detection-Studie 2013 hilfreich. Interessanterweise verwenden 30 Prozent der Android-User in Indien ein Gerät mit einer Auflösung von lediglich 240 x 320 Pixeln (in obiger Liste durch das Samsung Galaxy Y S5360 vertreten). Oder: Die Auflösung von 480 x 800 Pixeln ist derzeit die meistverwendete Auflösung (Samsung Galaxy S II).
Neben diesen unmittelbar aus der zuvor charakterisierten Fragmentierung (sprich Android-Versionen und Bildschirmmerkmale) ableitbaren funktionalen Tests, spielt zudem die „kontextuelle“ Fragmentierung eine entscheidende Rolle. Diese umfasst die Vielfalt an unterschiedlichen Kontexten oder Situationen, in denen ein Endgerät in der Umwelt genutzt wird. Beispielsweise eine variierende Netzgeschwindigkeit und -zuverlässigkeit, Verhalten bei Unterbrechungen wie eingehende Anrufe, Sperrung des Bildschirms sollten beim Testen berücksichtigt werden (Exploratives und Stress Testing).

Hardware Software Umwelt Nutzer
● GPS
● Kamera
● Kompass
● Lagesensor
● SD-Card
● Batterie
● Speicher
● CPU
● Display
● API-Level
● Vendor-Modifikationen
● Installierte Apps
● Systemeinstellungen

● Genauigkeit der Position
● Langsame Datenverbindung
● Verbindungsabbrüche
● Leere Batterie
● Offlinefähigkeit

● Rotation
● Anruf
● Lautstärke ändern
● Geräteknöpfe
● Screen-(Un)Lock

Tabelle 2: Verschiedene Aspekte für das Testen auf Android-Geräten

Es ist sinnvoll, vorab eine Liste an spezifischen Testszenarien zu erstellen, die möglichst viel Funktionalität der vorliegenden App abdeckt. Durch kontinuierliches Testen können so Fehler (bzw. Regressionen) frühzeitig erkannt und mit den letzten Änderungen am Quellcode in Verbindung gebracht werden.
Das „Wie“: Kurz, der Android-Emulator ist im QA-Prozess ideal geeignet für kontinuierliches Regressions-Testing (UI-, Unit und Integration-Tests) auf möglichst diversen Gerätekonfigurationen (Compability Testing). Zudem können im explorativen Testing unkomplizierte vielfältige Szenarien nachgestellt werden (z. B. Wechsel der Netzgeschwindigkeit oder -qualität).
Dennoch ist die Qualitätssicherung auf realen Geräten unabdingbar. In der Praxis unterscheiden sich die virtualisierten Referenzgeräte oftmals in kleineren (jedoch für manche Apps signifikanten) Aspekten: keine herstellerspezifischen Änderungen am Android-Betriebssystem oder keine Unterstützung für Headphones und Bluetooth. Beispielsweise sollte Usability Testing möglichst auf verschiedenartigen Endgeräten durchgeführt werden, da hier Faktoren wie die Bedienung per Touchhardware, der physikalische Formfaktor des Geräts, die Performance auf realer Hardware eine entscheidende Rolle bei der Evaluation spielen. Aus diesen Gründen empfehlen wir ein zweistufiges Vorgehen:

Regressions Testing per emuliertem Referenzgerät: Kontinuierliches (idealerweise automatisiertes) Regression Testing auf Referenzgeräten zur frühzeitigen Identifizierung von essenziellen Fehlern.
Preflight Testing per realem Endgerät: Intensives (vorwiegend manuelles) Testen auf realen Endgeräten vor der Veröffentlichung im Google Play Store in einem „Staged Rollout“ z. B. Alpha- und Beta-Tests.

Vorbereitung: Lässt sich der Android-Emulator beschleunigen?

In der Android-Entwicklercommunity genießt der Emulator oft einen schlechten Ruf aufgrund seiner hohen Startzeit (oftmals mehr als fünf Minuten) und der langsamen Geschwindigkeit. Jedoch gibt es einfache Kniffe, dieser Kritik entgegenzuwirken und den Emulator auf (oder über) das Performanceniveau eines realen Geräts zu beschleunigen:

Intel-CPU-Hardwarebeschleunigung: Android wird in der Regel auf Endgeräten mit ARM-Architekturen ausgeführt, die sich sehr von typischen Intel-PCs unterscheidet. Der Emulator simuliert die ARM-CPU auf einer Intel-CPU, indem er die Instruktionen der Applikationen aufwändig übersetzt. Diese Übersetzung kann mit einem Android Intel System Image und Intels-HAXM- (oder KVM-)Beschleunigern vermieden werden. Sollte die App allerdings nativen C-Code enthalten, so muss dieser zuvor ebenfalls für Intel kompiliert werden.
OpenGL-ES-Hardwarebeschleunigung: In der Standardkonfiguration verwendet der Emulator softwarebasiertes OpenGL Rendering, wodurch die Bedienoberfläche wesentlich langsamer reagiert. Für eine signifikante Beschleunigung können ab Android 4.0.3 die OpenGL-Befehle unmittelbar an die Hardware-GPU weitergereicht werden.
Snapshots: Sollte die App nicht kompatibel mit Intel-Geräten sein und keine OpenGL-Beschleunigung benötigen, kann bei der ARM-basierten Variante zumindest die lange Startzeit mittels „Snapshots“ vermieden werden. Ein Snapshot sichert beim Beenden des Emulators den aktuellen Zustand, welcher beim nächsten Startvorgang des virtuellen Geräts in wenigen Sekunden wiederhergestellt werden kann.

Im Folgenden konzentrieren wir uns auf die Hardwarebeschleunigung der CPU und GPU, weitere Details sind hier zu finden. Auf Microsoft Windows oder Apple OS X ist die Installation des Intel-HAXM-Beschleunigers notwendig, wohingegen Linux-Nutzer KVM benötigen (Anleitung zu finden hier). Vorausgesetzt wird hier eine Intel-CPU und die im BIOS aktivierte „VT-x“-Option. Für Windows-Nutzer kann Intel HAXM über den Android-SDK-Manager unter EXTRAS | INTEL HARDWARE ACCELERATION EXECUTION MANAGER heruntergeladen werden. Nach Abschluss des Downloads im Android-SDK-Verzeichnis unter EXTRAS | INTEL | HARDWARE_ACCELERATED_EXECUTION_MANAGER die Datei IntelHAXM.exe ausführen und den Installationsanweisungen folgen (Abb. 4).

Abb. 4: Installation des Intel-HAXM-Beschleunigers

Zum Prüfen der korrekten Konfiguration kann das Tool Quick Benchmark Lite verwendet werden. Die Werte sollten sich signifikant gegenüber einem Gerät mit ARM-CPU und ohne OpenGL-Beschleunigung unterscheiden.

Aufmacherbild: Investigator checking test tubes. Man wears protective goggles von Shutterstock / Urheberrecht: YanLev

[ header = Seite 3: Beispiel: Testen auf einem emulierten Samsung Galaxy SIII ]

Beispiel: Testen auf einem emulierten Samsung Galaxy SIII

Wir richten nun einen Emulator ein, der in seiner Konfiguration dem Endgerät Samsung Galaxy S III entspricht. Hierfür verwenden wir Eclipse mit dem Android-Developer-Tools-(ADT-)Plug-in, das im Android-SDK enthalten ist.
1. Gerätedefinition anlegen: Im Android Virtual Device Manager lassen sich die virtuellen Geräte verwalten. Die Spezifikationen der Geräte finden sich unter „Device Definitions“. Eine Auswahl an Vorlagen ist bereits vorhanden. Falls das Wunschgerät nicht dabei ist, kann eine eigene Definition erstellt werden. Ein Gerät mit einem der größten Marktanteile ist beispielsweise das Samsung Galaxy S III. Dieses hat folgende Eigenschaften: Screen Size: 4,8 Inch, Resolution: 720 x 1280 px, RAM: 1 024 MB (Abb. 5).

Abb. 5: Erstellung einer Gerätedefinition Galaxy SIII

2. Virtuelles Gerät erstellen: Die Gerätedefinition kann nun für das Erstellen eines virtuellen Geräts verwendet werden. Folgende Eigenschaften sind dabei zu ergänzen: Das Galaxy S III wird standardmäßig mit Android 4.0.4 ausgeliefert. Wir wählen daher als ähnlichste SDK-Version Android 4.0.3 im Feld „Target“ des Konfigurationsassistenten. Wie zuvor beschrieben, wollen wir Hardwarebeschleunigung nutzen und verwenden daher den CPU-Typ Intel. Die Größe des VM-Heap setzen wir auf 256 MB. Zusätzlich aktivieren wir für die hardwarebasierte OpenGL-Beschleunigung die Option „Use Host GPU“ (Abb. 6).

Abb. 6: Erstellung des virtuellen Geräts „meinS3“

3. Starten des virtuellen Geräts: Nun lässt sich das neu angelegte virtuelle Gerät „meinS3“ über den AVD-Manager starten (Abb. 7).

Hinweis für Windows-Nutzer
Bei einigen Windows-Versionen muss zunächst die Konfigurationsdatei config.ini des AVD angepasst werden. Die Datei befindet sich unter C:Users\.androidavdmeinS3.avd. Der Eigenschaft hw.ramSize=1024 müssen die Buchstaben MB angehängt werden.

Abb. 7: Hardwarebeschleunigtes virtuelles Gerät „meinS3“

4. App installieren und starten: Eine App lässt sich starten, indem wir in der Eclipse-IDE auf das entsprechende Android-Projekt rechtsklicken und RUN AS | ANDROID APPLICATION wählen. Anstelle des Startens eines Projekts über Eclipse kann alternativ eine APK-Datei über die Kommandozeile ausgeführt werden. Dazu im Android-SDK-Verzeichnis unter „platform-tools“ folgenden Befehl aufrufen:

adb install <Pfad zur APK-Datei>

5. Testen der App: Wie lassen sich nun die zuvor angesprochenen Testszenarien (z. B. eingehende Anrufe) simulieren und aufgetretene Fehler analysieren? Hierfür bietet das Android-SDK verschiedene Werkzeuge:
ADB Shell: Mit diesem Tool können über die Kommandozeile wichtige Befehle an ein Gerät geschickt werden, um beispielsweise eine Activity zu starten. Dies ist mittels des adb-Befehls möglich. Alternativ kann das im SDK enthaltene grafische Tool Android Debug Monitor verwendet werden. Eine entsprechende grafische Oberfläche bietet auch das ADT-Eclipse-Plug-in in der DDMS-Perspektive (Abb. 8).

Abb. 8: Das Werkzeug „DDMS“ bietet Kontrolle über den Emulator

Exerciser Monkey: Mit diesem Tool lassen sich zufällige Touch- und Tastatureingaben über die ADB-Shell auf dem Gerät ausführen. Beispielsweise lässt sich ein einfacher Stresstest durch 500 pseudozufällige Events mit folgendem Befehl realisieren:

adb shell monkey -p <Dein.Package.Name> -v 500

Logcat: Diese Anwendung sammelt Lognachrichten des Geräts. Über ADB-Shell können diese über den logcat-Befehl angezeigt werden. Android Debug Monitor und DDMS beinhalten ebenfalls eine Ansicht für Logs.

Fazit: Der Emulator als mächtiges Werkzeug

Richtig eingesetzt, ist der Android-Emulator ein mächtiges Werkzeug im Kampf gegen die fragmentierte Android-Landschaft. Er wird zu Unrecht meist aufgrund der schwachen Performance kategorisch ausgeschlossen. Dieser Kritik kann jedoch mit wenigen Kniffen begegnet werden. In Verbindung mit einer Testautomatisierung (Stichwort: Continuous Integration) lassen sich schon während der Entwicklung ohne viel Aufwand Regressionen frühzeitig erkennen. Auf das Thema der Testautomatisierung mittels Emulator und Jenkins werden wir in naher Zukunft näher eingehen.
In eigener Sache: Wer einen schnellen Android-Emulator mit weiteren Features (z. B. Google-APIs oder Google-Maps-v2-Unterstützung) Out of the Box nutzen möchte, kann zur webbasierten Lösung von TestObject greifen. TestObject betreibt beschleunigte Emulatoren auf leistungsstarker Hardware und liefert das Videobild im Browser. Ergänzend erlaubt TestObject die einfache Automatisierung von Testfällen mithilfe von intuitiven UI-Tests.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -