Archiv der Kategorie: mobile Testautomatisierung

Tools zur UI-Testautomation von Android Apps

Appium, welches in der Selenium-Welt berühmt ist, scheint mir nicht geeignet zu sein, langfristig angelegtes mobile testing zu betreiben.
Auch weitere Open-Source Projekte, die zu diesem Zweck ins Leben gerufen wurden, scheinen so langsam einzuschlafen, wie die Commit-Aktivitäten auf github nahelegen:
Robotium
robotium
Selendroid
Selendroid
So fallen diese drei Tools für diese Aufgabe aus. Die Frage, welches Tool Google eigentlich für die UI-Testautomatisierung von Android Apps nutzt, ist hier aus zweierlei Aspekten relevant. Erstens ist Google der Hersteller vom Android-Betriebssystem und hat daher genügend Insiderwissen, die richtigen Tools auszuwählen. Zweitens entwickelt Google selbst eine nicht unerhebliche Anzahl von geschäftskritischen Android Apps und muss diese natürlich auch zuverlässig testen.
Googles UI-Testautomatisierungslösung für Android Apps ist ohne Zweifel Espresso:
Artikel auf Googleblog
Talk auf Android Dev Summit
Talk auf Google I/O (inkl. tieferer Einblicke in Espresso-Codebase)

  • Reine Oberflächentests – simulieren Benutzerinteraktionen
  • Stark integriert in Android Development
    • Teil der Android Testing Support Library
    • Tests werden zusammen mit apk instrumentiert
    • Gestartet aus Android Studio
    • Im App-Code kann/muss man idle-Zustand setzen, damit Esspresso darauf reagiert.
    • Zum Programmieren in Java
  • It is intended to test a single application but can also be used to test across applications. If used for testing outside your application, you can only perform black box testing, as you cannot access the classes outside of your application. (Quelle)
  • Gutes Tutorial: http://www.vogella.com/tutorials/AndroidTestingEspresso/article.html#espresso_introduction

Bewertung von Appium in UI-Testautomatisierung für mobile Apps

Das Appium-Projekt scheint von MacOS-nutzenden Entwicklern getragen zu werden und Windows generell stiefmütterlich zu behandeln.
Einzelne Hinweise dazu finden sich im Internet.
Auch das zentrale Tool ‘Appium Inspector’ (mit dem man die Oberflächen-Elemente identifizieren kann) wird auf Windows nicht unterstützt. Und dies, obwohl in der Appium-GUI der Button dafür voll aktiv ist und nicht einmal ausgegraut wird.
Obwohl in der Appium-Version 1.5.2 der Fix für einen vitalen Bug enthalten ist, wurde bis heute (14.11.2016) die downloadbare Windows-Version nicht auf 1.5.2. geupdated – die Apple-Version jedoch bereits am 3.5.2016:
2016-11-14 14_23_24-appium
Oben aufgeführten Bug konnte ich erst durch aufwändige Recherche identifizieren, weil die Fehlermeldung nicht sehr aussagekräftig ist:

 info: [debug] Emulator Nexus_4_API_21 not running

Schaut man sich die Commit-Historie zum Appium-Projekt an, so stellt man fest, dass die Arbeit daran kontinuierlich stark rückläufig ist. Bei einem Framework für Testautomatisierung kann ich mir nur schwerlich vorstellen, dass es nicht genügend Anpassungsarbeit gibt – beispielsweise an neue Android-Versionen. Also unabhängig von der Frage, ob ein Einsatz für Windows sinnvol ist, keine guten Signale aus dem Projekt:
2016-11-14 14_39_02-Contributors to appium_appiumGitHub
Einen Einsatz von Appium für die mobile Testautomatisierung kann ich daher aktuell nicht empfehlen.

Refreshing Appium Inspector: Failed to connect to server. Please check that it is running.

Sobald ich den Refresh-Button im Appium Inspector klicke, versucht sich der Appium Server alle paar Sekunden erfolglos mit dem von ihm gestarteten Android emulators zu verbinden (“Emulator Nexus_4_API_21 not running”):
2016-11-07 17_03_22-appium inspector refresh error - Google-Suche
Nach etlichen Schleifen und ca. 2 Minuten erfolglosem Verbindungsversuchen erscheint schließlich die Fehlermeldung:
2016-11-07 17_13_09-Appium
Scrolle ich in den Meldungen hoch, entdecke ich eine ‘initiale’ Fehlermeldung, die die Ursache des Problems stärker eingrenzen könnte:

error: Unable to start Emulator: [272]:WARNING:./android/base/files/IniFile.cpp:158:Failed to process .ini file

Ein solches IniFile.cpp habe ich jedoch auf dem ganzen Rechner nicht gefunden.
Zwischendurch, wenn zu viele andere laufende Programme den RAM verstopfen, kommt es zu solchen Fehlermeldungen, die aber mit dem Schließen überflüssiger Programme behoben werden können:

> error: Unable to start Emulator: Warning: requested ram_size 1536M too big, reduced to 512M
>
> error: Unable to start Emulator: qemu-system-i386.exe: -drive if=none,index=0,id=system,file=C:\Users\mlwowr\AppData\Local\Android\Sdk/system-images\android-21\default\x86\/system.img: could not open disk image C:\Users\mlwowr\AppData\Local\Android\Sdk/system-images\android-21\default\x86\/system.img: Could not open 'C:\Users\mlwowr\AppData\Local\Android\Sdk/system-images\android-21\default\x86\/system.img': Invalid argument

Inzwischen kommt die zur Fehlermeldung ganz oben leicht abgewandelte Fehlermeldung:

> error: Unable to start Emulator: [5400]:WARNING:./androi
> error: Unable to start Emulator: d/base/files/IniFile.cpp:158:Failed to process .ini file C:\Users\mlwowr\.android\emu-update-last-check.ini for reading.

Diese Fehlermeldung scheint nicht das Problem zu sein, sondern ein Artefakt: https://code.google.com/p/android/issues/detail?id=223994
Ein spezifischer Hinweis hingegen ist:

> info: [debug] Trying to find Nexus_4_API_21 emulator
> info: [debug] Getting connected emulators
> info: [debug] Getting connected devices...
> info: [debug] executing cmd: C:\Users\mlwowr\AppData\Local\Android\Sdk\platform-tools\adb.exe devices
> info: [debug] 1 device(s) connected
> info: [debug] 1 emulator(s) connected
> info: [debug] Sending telnet command to device: avd name
> info: [debug] Getting running emulator port
> info: [debug] Socket connection to device created
> info: [debug] Socket connection to device ready
> info: [debug] Telnet command got response: aavavdavd avd navd naavd namavd name
> Nexus_4_API_21
> info: [debug] Emulator Nexus_4_API_21 not running

Wenn ich in den General Settings ‘prelaunch application’ anhake, zeigt sich, dass das genannte Problem vom Inspector unabhängig ist.
Lösungsansatz
Vermutlich ist der Bug in höheren Appium-Versionen behoben: https://github.com/appium/appium-adb/issues/150. Für Windows wurde (Stand:heute) diese Version noch nicht geupdated (seit ca. 1 Jahr). Diesen Lösungsansatz habe ich nicht weiters verfolgt, da ich Appium für die mobile UI- Testautomatisierung aktuell nicht empfehlen kann.
Archiv: Keine Lösungsansätze

    • Firewall abschalten
    • Device name genauso bezeichnen, wie es bei Launch AVD steht.
    • Device ready timeout hat keinerlei Auswirkungen gezeigt
    • Pre-Launch Application
    • Entferne alle überflüssigen Punkte im Dateinamen und alle Leerstellen im Dateipfad.
    • Ich hab ne ANDROID_SDK_HOME angelegt: http://stackoverflow.com/a/35443843/1777526 und eine neue AVD, aber nun wird bei Launch AVD nix mehr angezeigt.