Category

Der Systemtest einer Android App beginnt mit manuellen Tests. Wird agil entwickelt, werden die Regressionstests aber schon bald sehr zeitintensiv. Nach einigen Sprints werden die ersten ‚Ermüdungserscheinungen‘ sichtbar und die Testqualität beginnt zu sinken. Spätestens jetzt sollen einzelne Tests automatisiert werden. So kann die Qualität erhöht werden und es bleibt mehr Zeit für neue explorative oder auch automatisierte Tests.
Ranorex unterstützt die Testautomatisierung sehr gut, muss aber im aktuellen Projekt eine App testen, die auf einer proprietären Hardware mit einem kundenspezifischen Android Betriebssystem läuft. Die Kommunikation ist nur über Bluetooth vorgesehen. Wie gelingt eine Testautomatisierung trotzdem?

Vorbedingungen

• proprietäre Hardware
  • mit zusätzlichen Bedienelementen
  • ohne WLAN
• Kundenspezifisches Android Betriebssystem
  • Entwicklung auf Linux
  • App nicht in Google Play Store
  • Kein Windows USB Treiber

Lösung

Für Ranorex wird ein USB Treiber benötigt. Wie komme ich zu einem eigenen Treiber?

• Gerät über USB am Windows PC anschliessen
• Im Gerätemanager unter ‘Andere Geräte’ die Hardware-ID auslesen: USB\VID_<VendorId>&PID_…
• VendorId einfügen in C:\Users\<user name>\.android/adb_usb.ini als Hexwert: 0x<VendorId>
• GenericDriver installieren
  • Google USB Driver downloaden und unzippen
  • Im android_winusb.inf neuen Eintrag SingleAdbInterface erstellen mit entsprechender Hardware-ID
  • Geräte Treiber installieren
    Windows 8 muss wie folgt überredet werden: ‚Disable Driver Signature Enforcement‘ nach einem Restart mit Troubleshoot>Advanced Option
• Kontrolle ob das Device erkannt wird über: adb devices
  Das adb.exe findet man unterhalb des Ranorex Installationspfades.

Der Verbindungsaufbau mit dem Ranorex Studio zum Device gelingt nun gut mit der Anleitung im User Guide zum Thema Android Testing.

Für die Testautomatisierung müssen die zusätzlichen Bedienelemente der proprietären Hardware von Ranorex angesteuert werden können. Dazu wird ein Commandline-Interface (CLI) verwendet, das auch für Hardware Tests benötigt wird.

Für die Hardware Tests wird ein Python Script mit GUI verwendet. Diese Script dient als Vorlage. Mit einem adb forward tcp… wird die Verbindung zum CLI Service aufgebaut. Das weitere Login und steuern der zusätzlichen Bedienelemente ist nur noch Copy & Paste. Sobald das Python Script auf Windows läuft, ist das erste Ziel erreicht. Da Python auf Windows besondere Aufmerksamkeit beansprucht, bis alle Umgebungsvariablen korrekt gesetzt sind, ist es speziell auf einer verteilten Testumgebung besser, die Ansteuerung direkt im Ranorex UserCode zu realisieren.

Die Testfall Erstellung und die Testdurchführung mit Ranorex funktioniert nun wie gewohnt für Android Apps. Die GUI-Elemente werden im Ranorex Repository erfasst, logisch benannt und nach Activity aufgeteilt.
Die Erstellung der Recording Module ist stark abhängig von der gewählten Teststrategie. Soll ein Keyword-driven Testing implementiert werden, oder reicht ein einfacheres Automated Functional Testing. Kleinere Module sind einfacher in der Wartung, benötigen aber klar definierte Funktionsbeschreibung und oft Variablen als Schnittstellen zu anderen Modulen. Grössere Module sind einfacher zu erstellen, können dafür weniger gut in verschiedenen TestCases verwendet werden.

Damit ist Ranorex bereit fürs Testen eines proprietären Android Devices. Das Testdesign und die Testfälle sind damit allerdings noch nicht erstellt und bieten eine weitere spannende und herausfordernde Aufgabe.

Noser Engineering AG ist Ranorex Gold Partner, Open Handset Alliance – Mitglied und hat Kernfunktionalität von Android in enger Zusammenarbeit für Google entwickelt. Weitere Informationen:

http://www.noser.com/de/testing
http://www.noser.com/de/mobile-Solutions