Best Practices für die Entwicklung mobiler Unternehmens-Apps

Seite 3: Testen & Teamarbeit

Inhaltsverzeichnis

Das intensive und fortlaufende Testen einer App ist das tägliche Brot des mobilen Entwicklers. Das iOS SDK enthält einen leistungsfähigen Simulator, der relativ präzise das iOS-Betriebssystem für iPhone und iPad zu simulieren vermag. Der Simulator startet samt der App innerhalb weniger Sekunden und ermöglicht so ein zügiges Debugging.

Der aus Xcode heraus gestartete iOS-Simulator (hier wird ein iPad simuliert) mit einer gestarteten App (Abb. 6)


Auch Googles Android Development Tools unterstützen das Testen vor allem durch

  • den Dalvik Debug Monitor Server (DDMS) zum Debuggen von Apps auf angeschlossenen Android-Geräten und zum Auslesen von Log-Daten und Gerätedaten sowie
  • das Android Virtual Device (AVD), einen Emulator, mit dem sich nahezu jedes Android-Gerät samt wesentlicher Hardwareeigenschaften (z. B. Speichergröße, Bildschirmauflösung und Betriebssystemversion) emulieren lässt.

Der Android Emulator von ADT mit einer gestarteten App (Abb. 7)


Leider ist die Performance des Emulators trotz der Snapshot-Funktion noch nicht optimal, da zum einen zunächst das Betriebssystem für die Emulation eines spezifischen AVDs zu laden ist, zum anderen der Emulator (noch) über keine Grafikbeschleunigung verfügt und somit für das Debugging komplexer Bildschirminhalte unter hohen Bildschirmauflösungen nur unzureichend geeignet ist.

Unabhängig vom Zielsystem, für das entwickelt wird, empfiehlt sich dringend das frühe und regelmäßige Testen auf einem angeschlossenen Endgerät, da sich die Geräte unter realen Bedingungen anders verhalten können als in einer Simulation beziehungsweise Emulation. Das trifft vor allem auf die Speicherverfügbarkeit, Nebenläufigkeit und Internetkonnektivität zu. Darüber hinaus steht bestimmte gerätespezifische Hardware innerhalb der Simulation beziehungsweise Emulation nicht zur Verfügung. Will man solche Funktionen testen, führt kein Weg am realen Endgerät vorbei.

Aufgrund ihrer Plattformunabhängigkeit und der damit verbundenen Heterogenität der Laufzeitumgebungen gestaltet sich der Test für Webapps diffiziler und zeitaufwendiger als bei den nativen Apps. Angesichts der Tatsache, dass Android-Nutzer zwischen einer ganzen Reihe von Browsern wählen können, reicht es zudem keinesfalls aus, nur unter Androids systemeigenen Webbrowser zu testen, sondern man muss alle seine Tests auch unter allen anderen populären ausführen, gegebenenfalls sogar unter Berücksichtigung der Browserversionen.

Aus der Kombination der Parameter Hardware, Browserhersteller und Browserversion ergibt sich ein ausgesprochen komplexer Testplan, der manuell nur mit größtem Aufwand zu realisieren ist. Zwar lassen sich einige Funktionen mit Unit-Tests und entsprechenden guten Test-Frameworks wie sinon.js oder Googles JsTestDriver automatisiert testen. Aber gerade das Testen des grafischen Frontends fällt schwer. Hier können Entwickler teilweise ebenfalls automatisierte Frontend-Testwerkzeuge wie Selenium einsetzen, die aber in der Praxis einen nicht unerheblichen Aufwand zur Aufbereitung der Testfälle nach sich ziehen. Hier ist daher unbedingt das Aufwand-Nutzen-Verhältnis im Auge zu behalten. Die visuelle Integrität der Webapp unter verschiedenen Browsern, Browserversionen und Betriebssystemen lässt sich mit Dienstleistungen wie browsershots.org oder Adobes BrowserLab etwas einfacher sicherstellen. Auch hier muss der Abgleich zwischen Soll und Ist größtenteils manuell erfolgen.

Side-by-Side-Vergleich einer Webpage unter zwei verschiedenen Browsern und Betriebssystemen mit Adobe BrowserLab (Abb. 8)


Mit Adobe BrowserLab lassen sich die Ansichten einer Webpage unter verschiedenen Browsern und Betriebssystemen zum besseren Ad-hoc-Vergleich auch optisch überlagern (Abb. 9)


Hat die Entwicklung erst einmal Fahrt aufgenommen und soll das Ergebnis der eigenen Bemühungen nun auf dem Gerät getestet oder gar an den Testanwender ausgeliefert werden, ist die nächste Hürde zu nehmen: Denn das Deployment nativer und hybrider Apps zu Testzwecken kann auch für erfahrene Entwickler eine Herausforderung sein. Alle Apps sind nämlich digital zu signieren, bevor sie sich auf dem jeweiligen Endgerät installieren und ausführen lassen, selbst wenn es sich dabei nur um einen Entwicklungsprototypen handelt. iOS-Einsteiger dürften angesichts des komplex anmutenden Prozesses rund um "Unique Device Identifiers", "App Identifiers", "Provisioning Profiles", "Developer Certificates" und "Distribution Certificates" und den damit durch Apple auferlegten Beschränkungen einige graue Haare bekommen.

Gerade während einer ohnehin anstrengenden Testphase sorgt dieser Code-Signing-Prozess in Kombination mit der in der Praxis oft anzutreffenden Volatilität der Testgeräte für einige Schweißperlen auf der Stirn, denn die Fehleranfälligkeit ist ausgesprochen hoch. Teils wenig aussagekräftige Fehlermeldungen, die Xcode oder das Gerät ausspucken, wenn etwas nicht exakt nach Apples Plan gelaufen ist, helfen nämlich nur wenig beim Auffinden und Beheben der Ursache.

Auch Android-Apps sind zu signieren, damit sich diese auf Android-Geräten oder auf dem Emulator installieren und testen lassen. Hierfür gibt es einen speziellen Debug-Key, den die Android SDK Build Tools erzeugen. Erst bei Veröffentlichung der Android-App ist sie mit einem passenden, privaten Schlüssel zu signieren. Er lässt sich mit verbreiteten Werkzeugen wie Keytool und Jarsigner erzeugen und zum Signieren der Apps-Datei (.apk) einsetzen. Dieses Modell und seine liberale Natur ist für den Entwickler etwas leichter anzuwenden als das von Apple: Es gibt nur zwei Schlüssel, einen zum Debugging, einen anderen zur Veröffentlichung in Google Play (vormals Android Market) und keine manuell zu verlängernden Zertifikate.

Mit den steigenden Erwartungen der Kunden an Apps gewinnt auch die enge Zusammenarbeit mit diesen an strategischer Bedeutung. Hierfür haben sich agile Entwicklungsmethoden als geeignet für das Meistern der Anforderungen an die Projekt-Teams erwiesen. Der Aspekt Continuous Integration mit seinen Grundsätzen "Check-in early and often" und "Build often" hilft dabei, die Entwickler frühzeitig auf technische und fachliche Probleme und Unzulänglichkeiten aufmerksam zu machen, um hierdurch ressourcenraubende "Sackgassen"-Entwicklungen zu vermeiden und eine auf die Zielgruppen ausgerichtete (Stichwort "User-Brille"), robuste Software hervorzubringen.

Der Exkurs im Anschluss an den Artikel beschreibt, wie die compeople AG erfolgreich Continuous Integration im Rahmen ihrer iOS-Projekte realisiert hat.

Mit dem kostenfreien Webdienst TestFlight lassen sich Builds auf die Testgeräte ausliefern und Testergebnisse vollautomatisch sammeln und übersichtlich darstellen (Abb. 10)