iX 7/2017
S. 110
Praxis
App-Entwicklung
Aufmacherbild

Testautomation mobiler Applikationen mit Appium

Wie von selbst

Die Vielzahl an Plattformen, Geräten und Systemversionen macht den Test mobiler Apps sehr aufwendig. Mit Appium, einem Framework zur Testautomation, lassen sich umfangreiche Tests auf verschiedenen Geräten in eine Continuous Deliverey Pipeline einbinden.

Anbieter mobiler Applikationen müssen ihre Apps ausgiebig testen, um sicherzustellen, dass diese auf allen Geräten fehlerfrei laufen. Trotz immer kürzerer Entwicklungszyklen ist das Testen der Apps für alle Betriebssysteme und Geräteplattformen daher eine ebenso notwendige wie schwierige Aufgabe: Mittlerweile ist der Testaufwand häufig größer als der Aufwand für die eigentliche Entwicklung. Kein Unternehmen kann sich ein schlechtes Rating in den App-Stores leisten.

Der größte Teil des Testaufwands fließt dabei nicht in den funktionalen Test der App: Kritischer als die reinen Funktionstests ist das Testen von Interoperabilität, Performance, Benutzerfreundlichkeit und Sicherheit. Effektive und effiziente Tests helfen dabei den Geräteherstellern und Anwendungsentwicklern, die Produktqualität zu verbessern. Dieser Artikel zeigt am Beispiel einer mit dem Ionic-Framework entwickelten hybriden App, wie Testautomation mit Appium in einer Continuous Delivery Pipeline die Bereitstellung einer App durch das Entwicklungsteam beschleunigen und gleichzeitig das Risiko von Fehlern in der App reduzieren kann.

Testen der Interoperabilität

Screenflow durch die Test-App: Nach dem Anmelden wählt der Anwender einen beliebigen oder den aktuellen Ort aus, um Informationen dazu zu erhalten (Abb. 1).

Die Test-App, entwickelt in HTML und JavaScript mit dem Ionic-Framework, zeigt einen ausgewählten Ort auf der Landkarte an und liefert den Zeitpunkt von Sonnenauf- und -untergang sowie Wetterdaten. Die App bestimmt den aktuellen Ort per GPS, alternativ kann der Anwender den Ort auf der Karte auswählen oder er kann per Konfiguration übergeben werden. Abbildung 1 zeigt den Screenflow durch die App.

Bei Interoperabilitätstests wird geprüft, ob die mobile Anwendung auf den wichtigsten Geräten im Markt des App-Herstellers richtig funktioniert. Die zunehmende Gerätefragmentierung (Gerätetypen, Hersteller, Plattformen, Betriebssystemversionen) erzwingt einen immer höheren Testaufwand. Gegenüber manuellen Tests kann eine gute Testautomationsstrategie bis zu 70 Prozent des Zeitaufwands einsparen.

Statistiken zeigen, dass Unternehmen Zugriff auf 50 bis 70 voll funktionsfähige Geräte zu einem bestimmten Zeitpunkt benötigen, um einen aussagekräftigen Test durchführen zu können. Dazu kommt, dass in jedem Quartal etwa fünf dieser Geräte ersetzt werden müssen, um auf dem neuesten Stand zu bleiben. Die Logistik der Verwaltung dieser Anzahl von Handsets, womöglich auch noch an verschiedenen Standorten, ist eine Herausforderung.

Lokale Geräte oder Mobile Device Cloud?

Lokale Device Labs halten daher oft nur eine relativ geringe Anzahl physischer Geräte vor (meist eines pro angezielter Geräteklasse), die die Teammitglieder (Product Owner, Developer, Tester) für manuelle und automatisierte Tests nutzen können. Mobile Device Clouds, wie sie beispielsweise TestObject (mittlerweile von Sauce Labs übernommen) oder BitBar bereitstellen, machen eine Vielzahl mobiler Endgeräte über die Cloud zugänglich.

Entwickler und QA-Team haben so Zugriff auf die Geräte, wann immer sie sie benötigen, ohne dass das Unternehmen neue Devices beschaffen muss. Geräte lassen sich leicht zum eigenen Testpark hinzufügen oder je nach Marktbedürfnissen auswechseln. Darüber hinaus erleichtert die Cloud global verteilten Teams die Zusammenarbeit in diesem Bereich. Allerdings lässt sich damit nur die Funktionalität einer App testen, die Performance muss mit den physischen Geräten im Unternehmen geprüft werden.

Viele Entwicklungsteams entscheiden sich daher für eine gemischte Variante beim Testen. Innerhalb einer Continuous Delivery Pipeline wird die neueste Version der App in der Integration Stage zunächst lokal auf Emulatoren und ausgewählten physischen Devices getestet. Im Erfolgsfall wird dann in der Mobile Stage der Test auf vielen Geräten in einer Mobile Device Cloud durchgeführt.

Appium vermittelt zwischen Testskript und App

Für das automatisierte Testen von Webanwendungen ist das Open-Source-Projekt Selenium/WebDriver das Maß aller Dinge. Kein kommerzielles Tool kann ähnliche Erfolge aufweisen. Dominik Darys Selendroid und Dan Cuellars Appium haben Selenium erfolgreich in die mobile Welt überführt. Das Open-Source-Framework Appium kann sowohl auf Emulatoren als auch auf physischen Geräten testen.

Kern von Appium ist ein in Node.js entwickelter HTTP-Server mit der gleichen Architektur wie der Selenium WebDriver Server. Der Appium-Server empfängt Kommandos für die zu testende App in Form von HTTP-Requests von einer Client Library, führt diese Kommandos auf dem physischen Gerät oder Emulator aus und schickt eine HTTP-Response zurück. Die zu testende App muss dazu nicht rekompiliert, instrumentiert oder sonst wie angepasst werden, damit sie sich automatisiert testen lässt.

Die Kommunikation mit Appium erfolgt über das JSON Wire Protocol. Die WebDriver-Entwickler haben JSONWP spezifiziert, um darüber einen Browser per Software so fernzusteuern, dass sich damit Webseiten automatisiert testen lassen. Dazu definiert das JSON Wire Protocol einen Satz standardisierter Endpunkte, die über eine REST-API angesprochen werden. Appium implementiert Mobile JSONWP, eine Erweiterung des Selenium-JSONWP.

Der Appium-Server vermittelt zwischen dem Testprogramm und dem plattformspezifischen Automations-Framework (Abb. 2).

Verschiedene Client Libraries für Appium erlauben es, Tests in unterschiedlichen Sprachen zu programmieren: Java, Ruby, PHP, JavaScript, Python und C#. Die Client Library stellt den Testprogrammen die Selenium- und gerätespezifischen Befehle zur Verfügung und übernimmt die Kommunikation via JSONWP mit dem Appium-Server. Das auf die zu testende App zugeschnittene Testprogramm wird durch einen Testrunner wie jUnit oder TestNG abgearbeitet.