Nachdem ich verschiedene Mobile App Testing Automatisierungen mit den Werkzeugen Ranorex und Appium vorgenommen hatte, möchte ich in diesem Artikel meine Erfahrungen darstellen. Dabei werde ich meine Herangehensweise in der Tool- und Geräteauswahl präsentieren und dann auf die ersten Schritte in der Skriptentwicklung eingehen.
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 Automatisierung von Browsern 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 zahlreiche gehostete Angebote, 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 an Anbietern hier weder ein Marktüberblick gegeben werden kann noch alle Anbieter im Detail verglichen wurden, kann ich hier nur eine Auswahl von Tools aufzeigen, mit denen ich mich selbst beschäftigt habe.
Aus vorherigen Projekten mit Ranorex konnte ich schon die ersten Erfahrungen sammeln. Darüber hinaus gibt es für Appium eine große und präsente Community, so dass ich hier gute Chancen erkannte, eine erfolgreiche Umsetzung zu erzielen. Deshalb werde ich mich in den späteren Ausführungen auf Beispiele mit Ranorex und Appium beschränken.
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 so weit konfiguriert werden, dass es einen Zugriff von “außen” zulässt. Hier ist insbesondere die Freischaltung des Entwicklermodus und die Aktivierung des USB-Zugriffs gemeint. Schließt man eines dieser konfigurierten Geräte an, sollte dann mit den Automatisierungstools ein Zugriff möglich sein.
Bild: Ranorex Service und Instrumentalisierungs-Assistent. (Klicken zum Vergrößern) [Quelle: Ranorex]
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, es 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 Anwendungen nur für ARM geeignet sind.
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 der 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-Objekte unterstützt.
Bild: Appium Element-ID Verwendung. (Klicken zum Vergrößern) [Quelle: Appium]
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 RanoreXPaths für das Repository genauso wie bei einem Desktopprogramm oder einer Webseite auf und in den Actions lassen sich die spezifischen Mobilgerät-Aktionen wie Tippen, Wischen oder die Gerätetasten spezifizieren.
Bild: Ranorex Spy. (Klicken zum Vergrößern) [Quelle: Ranorex]
Bild: Ranorex Mobile Recording Actions. (Klicken zum Vergrößern) [Quelle: Ranorex]
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 mithilfe 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 zwischen 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.
Wer nicht mit diesen beiden Tools warm werden kann, hat auch eine alternative Auswahl bei den folgenden Testwerkzeugen:
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 die meisten 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ßen 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:
Auch wenn ich mich hier auf zwei Werkzeuge konzentriert habe, werden sich viele der hier angesprochenen Aspekte auf andere Automatisierungstools übertragen lassen.
A: Zu den besten Tools für die Testautomatisierung von mobilen Anwendungen gehören Ranorex, Appium, und Tricentis Tosca. Diese Tools bieten eine umfassende Unterstützung für verschiedene Plattformen und ermöglichen die Automatisierung von Tests für Android und iOS.
A: Ranorex ist ein kommerzielles Testwerkzeug, das eine grafische Benutzeroberfläche bietet, um Testfälle für mobile Anwendungen einfach zu erstellen und zu verwalten. Tester können Tests schreiben und die Benutzeroberfläche der Anwendung effizient automatisieren.
A: Regressionstests können automatisiert werden, indem Testfälle, die die Funktionalität der Anwendung abdecken, in Tools wie Appium oder Ranorex erstellt werden. Diese Tools helfen dabei, sicherzustellen, dass Änderungen an der Anwendung keine bestehenden Funktionen beeinträchtigen.
A: Bei der Wahl des richtigen Testwerkzeugs sollten Unternehmen Faktoren wie die unterstützten Plattformen, die Benutzerfreundlichkeit, die Integration mit bestehenden Tools wie Jira und welche Art von Testfällen überhaupt automatisiert werden sollen.
A: Die Automatisierung von Tests bietet zahlreiche Vorteile, darunter die Reduzierung der Testzeit, die Erhöhung der Testabdeckung, die Möglichkeit zur Durchführung von Regressionstests und die Verbesserung der Softwarequalität durch frühzeitige Fehlererkennung.
Veröffentlicht am 01.Dezember 2021
Aktualisiert am 22.Februar 2025
Senior Testmanager und Test Automation Engineer
