Mobile App Testautomatisierung mit Ranorex und Appium

Nachdem ich verschiedene Mobile App Testing Automatisierungen mit den Werkzeugen Ranorex und Appium vorgenommen hatte, möchte ich hiermit meine Erfahrungen darstellen. Dabei möchte ich meine Herangehensweise in der Tool- und Geräteauswahl darstellen und dann auf die ersten Schritte in der Skriptentwicklung eingehen.

Herangehensweise

Auswahl Automatisierungstool

Zuerst muss ein Automatisierungstool gefunden werden, welches die Anbindung und Automatisierung von mobilen Geräten, wie Smartphones und Tablets, unterstützt. Hierbei ist darauf zu achten, dass diese auch Mobile Apps und nicht nur eine Browser Automatisierung unterstützen.

Neben kommerziellen Tools, wie TestComplete, SilkTest, eggPlant oder Ranorex haben sich auch OpenSource bzw. andere lizenzkostenfreie Produkte, wie iOS UI Automation, UI Automator oder auch Appium am Markt etabliert. Darüber hinaus gibt es eine zahlreiche Zahl von gehosteten Angeboten, die Gerätesimulationen zum Mieten anbieten. Hierunter fallen 21Labs, Test IO, Kobiton und Blazemeter. Dabei bieten viele dieser Cloud-Anbieter für den Einstieg auch eine kostenfreie, eingeschränkte Version an.

Da Aufgrund der Vielzahl der Anbieter hier kein Marktüberblick gegeben werden kann und alle Anbieter im Detail verglichen wurden, kann ich hier nur eine Auswahl von Tools zeigen, mit denen ich mich selbst beschäftigt habe.

Ich selbst habe aus vorherigen Projekten schon mit Ranorex Erfahrungen sammeln können und es war für mich naheliegend, mich mit dem Tool zu beschäftigen. Darüber hinaus gibt es für Appium eine große und präsente Community, so dass ich hier gute Chancen sah, eine erfolgreiche Umsetzung zu erzielen. Deshalb werde ich mich in den späteren Ausführungen auf Beispiele in Ranorex und Appium beschränken.

Physikalische Geräte

Nachdem sich für ein Automatisierungstool entschieden wurde, sollten die ersten Versuche mit einem physikalischen Gerät erfolgen. Egal ob iOS oder Android, das Gerät muss soweit umkonfiguriert werden, um einen Zugriff von “außen” zuzulassen. Hier ist die Freischaltung des Entwicklermodus und die Aktivierung des USB-Zugriff gemeint. Schließt man eines dieser umkonfigurierten Geräte an, sollte mit den Automatisierungstools ein Zugriff möglich sein.

Gerätesimulation

Standardmäßig erhält man mit den Entwicklungsumgebungen für Android (Android Studio) oder iOS (XCode) eingebaute Simulatoren von Mobilgeräten. Hier lassen sich vorab unterschiedliche Geräte definieren (z.B. Auflösung, Speicher). Egal ob man sich für Appium oder Ranorex entscheidet, können diese Gerätesimulatoren eingesetzt und genauso angesprochen werden, als wären es physikalische Geräte. Zwei für mich große Einschränkungen musste ich aber feststellen. Es ließ sich bei mir kein Bluetooth verwenden und bei iOS muss die Ipk explizit gegen ein x86-System kompiliert werden, da die App Store Apps nur für ARM geeignet sind.

Erste Schritte

Appium

Da Appium keine GUI zur Testfallerstellung enthält, findet eine Umsetzung in zwei unterschiedlichen Werkzeugen statt. Appium Inspector erfasst die Oberflächenelemente und man erhält die Zugriffsmöglichkeiten mit xPath oder Id. Diese Informationen übernimmt man manuell in sein Appium-Projekt für den Webdriver Zugriff. So kann man die Elemente als Page-Objekte definieren und in seinem Automatisierungsskript verwenden. Hier kann auch die Verwendung eines Frameworks hilfreich werden, das bei der Erstellung und Verwaltung der Page-Objekten unterstützt.

Ranorex

Konnte die Verbindung über die instrumentalisierte App aufgebaut werden, lässt sich mit Ranorex eine Automatisierung leicht aufzeichnen und entwickeln. Dies funktioniert wie mit einem nativen Desktopprogramm oder einer Webseite. Ranorex Spy zeichnet die RanoreXPathes für das Repository genauso wie bei einem Desktopprogramm oder Webseite auf und in den Actions lassen sich die spezifischen Mobilgeräte-Aktionen spezifizieren, wie Tippen, Wischen oder die Gerätetasten.

Zusammenfassung

Bei dem Vergleich der beiden Tools konnte ich feststellen, dass ich in Appium anfangs einen relativ großen Aufwand mit der Installation der benötigten Werkzeuge verbracht hatte, um die ersten Schritte beginnen zu können. Vielfach war die Dokumentation oder das Hilfeforum nicht eindeutig auf mein gewähltes Setup anzuwenden, so dass ich mich sehr stark mit technischen Details des Tools auseinandersetzen musste.

Bei Ranorex fiel mir der Einstieg durch seine gute Dokumentation und mit Hilfe der eingebauten Assistenten viel leichter und ich konnte in kürzerer Zeit mit dem Scripting beginnen. Beim Scripting half Ranorex über die Actions anfänglich auch einen leichten Einstieg zu bekommen.

Es war kaum ein Unterschied zu Tests von Webapplikationen oder nativen Desktopprogrammen festzustellen. Dennoch fand ich mich mit Appium sehr schnell zurecht, konnte viele Analogien zu Web-Testing mit Selenium ziehen und erreichte in einer akzeptablen Zeit Erfolge, auch wenn ich kein spezialisierter Entwickler bin.

Letztendlich bezahlt man den Komfort eines leichteren Einstiegs in Ranorex durch die Lizenzgebühren. Diesen Vorteil sehe ich aber im weiteren Projektverlauf als immer unbedeutender an, so dass ich auch Appium weiterempfehlen kann.

Ausblick

Weiterführend zu dem oben gezeigten Einstieg sehe ich einen relativ großen Aufwand in der Definition und Einrichtung der ganzen Infrastruktur und bei der Einrichtung der Vielzahl an Geräten. Eine ausreichend ausgebaute Geräte-Matrix zu entwerfen, und diese in die Infrastruktur einzubinden, wird einige Zeit kosten. Da aber die Automatisierungsskripte weitestgehend über die verschiedenen Geräte wiederverwendet werden können, wird sich die Geräte-Matrix nicht wesentlich auf die Entwicklungsdauer der Automatisierungsskripte auswirken. Gerade bei einer große Anzahl von zu testenden Geräten lohnt sich eine Automatisierung. Dennoch rechnet sich auch hier der Aufwand erst durch die häufige Wiederholung der Testdurchführung im Produkt-Life-Cycle.

Es existieren eine Vielzahl an weiteren Herausforderungen auf die ich hier in der Kürze nicht eingehen konnte. Ich möchte Sie aber der Vollständigkeit halber nennen:

• Infrastruktur (Netzwerk, Server, Anbindung Testgeräte per USB/Wifi, etc.)
• IoT, App-Server Kommunikation, Anbindung von Zubehör
• iOS und Android Gerätevielfalt und Betriebssystem-Versionsvielfalt
• Skalierung / Parallelisierung

Auch wenn ich mich hier auf zwei Werkzeuge konzentriert habe, werden sich viele der hier angesprochenen Aspekte auf andere Automatisierungstools übertragen lassen.

Image