Testing AI Anwendungssoftware

Industrieroboter testet Apps

Der Artikel stellt ein automatisiertes Testsystem für mobile Applikationen vor. Das Testsystem ist Black-Box-Test fähig und kann Android-Applikationen mithilfe eines flexiblen Industrieroboterarms physisch testen. Dadurch ist es in der Lage, Systeme und Abläufe zu testen, die mit rein digitalen Testverfahren nicht realisierbar sind.

Demian Frister

Author

Aleksandar Goranov

Author

Andreas Oberweis

Author

23.04.2021
Lesezeit: 10 Minuten
75 Views

Im Jahr 2018 hat der Anteil mobiler Endgeräte im weltweiten Vergleich klassische Desktopsysteme bei der Internetnutzung überholt [StatC20]. Die Gewährleistung einer fehlerfreien Nutzung der auf mobilen Endgeräten laufenden Software ist essenziell für deren weiteren Erfolg. Um dies zu erreichen, müssen softwarequalitätssteigernde Methoden an die abweichenden Gegebenheiten angepasst und für mobile Endgeräte erweitert werden.

Das Testen der Benutzeroberfläche mobiler Applikationen (Apps) erfordert aufgrund der größeren Gerätevielfalt eine hohe Flexibilität. Mobile Geräte besitzen sehr unterschiedliche Displaygrößen, Displayarten, Formfaktoren und Reaktionszeiten, wodurch eine Vereinheitlichung der Tests für diese variablen Benutzeroberflächen kaum möglich ist. So unterscheidet sich die Bedienung von Apps mittels Finger deutlich gegenüber der von Desktop-Applikationen, die meist mit Maus und Tastatur bedient werden. Außerdem haben auch Umwelteinflüsse (Feuchtigkeit oder Temperatur) Auswirkungen auf die Benutzung und damit das Testen.

Bisher basiert das Testen von Apps auf einem hohen Anteil an manuellen Tests, welche im Vergleich zu automatisierten Testverfahren ineffizient und kostspielig sind [Mao17]. Daher wird in diesem Artikel ein Verfahren beschrieben, das mithilfe eines Roboterarms automatisierte Tests der Benutzeroberfläche mit hoher Testtreue ermöglicht. Der Roboter benötigt weder zusätzliche Informationen über die zu testende App, wie beispielsweise einen möglichen Testablauf oder deren Quellcode (Black-Box-Tests), noch eine Beaufsichtigung.

Werkzeuge

Industrielle Roboterarme bieten eine höhere Flexibilität als speziell auf eine konkrete Aufgabe hin erstellte Robotersysteme. Daher wird im Folgenden als Testausführer der Roboterarm Panda verwendet. Dieser Roboter weist eine ausreichend hohe Präzision bei der Ansteuerung einzelner Elemente auf einem mobilen Endgerät auf [FrankaEmika] und ermöglicht eine flexible Testbarkeit unterschiedlicher Geräte mit variabler Displaygröße. Der Endeffektor bedient dazu mithilfe eines kapazitiven Stifts das Device under Test (DUT). Angebunden ist der Roboter mit dem Open-Source-Framework Robotic Operating System (ROS), das die Entwicklung von Robotersystemen vereinheitlicht und vereinfacht.

Einer der Leitgedanken von ROS ist es, die im Roboter verwendeten Standardfunktionen hinsichtlich der Steigerung der Effizienz gemeinschaftlich zu verbessern und wiederzuverwenden [Qui09].

Die Oberfläche des zu testenden Geräts wird in der aktuellen Ausprägung des Systems über das UI-Test-Framework UIAutomator von Google über die ADB-Schnittstelle eingelesen [Google]. UIAutomator kann Nutzerinteraktionen simulieren und Veränderungen der Oberfläche registrieren. Dazu erstellt es eine hierarchische Abbildung aller auf der Oberfläche vorhandenen Elemente und deren Eigenschaften in einer XML-Datei. Mit UIAutomator ist es möglich, Black-Box-Tests auszuführen, solange eine Verbindung zum DUT besteht. Dementsprechend bietet es sich für den beschriebenen Anwendungsfall besonders an. Die umfangreichen Informationen über die Elementzustände der Oberfläche durch Appium ermöglichen zukünftigen Versionen des Systems, selbstständig Informationen über die Oberfläche zu erlernen und darauf zu reagieren.

Um das entwickelte Testverfahren mit bisherigen Verfahren zu vergleichen, wurde eine App mit grundlegenden Android-Funktionen erstellt. Aufgrund der Vielzahl an möglichen Testelementen konzentriert sich der implementierte Ansatz vorerst auf die Erkundung von Aktivitäten, die durch Buttons aufgerufen werden.

Verfahren

Um das Verfahren auf Android-Geräten mit nahezu beliebiger Größe auszuführen, sind mehrere Schritte erforderlich:

Zunächst muss in der Einlern-Phase das Koordinatensystem des Roboters an das Koordinatensystem des DUT angeglichen werden.
Anschließend wird in der Test-Phase der Displayinhalt eingelesen und weiterverarbeitet. Dabei werden alle relevanten testbaren Elemente auf der eingelesenen Oberfläche identifiziert und eine effiziente Test-Sequenz ermittelt.
In der Ausführungs-Phase fährt der Roboter die identifizierten Elemente an, um sie durch die Bedienung zu testen.

Für die in der Einlern-Phase vorzunehmende Angleichung der Koordinatensysteme existieren unterschiedliche Herangehensweisen. Einige Systeme erfordern die Ausführung einer zuvor installierten Software auf dem DUT.

Statt einer Softwareinstallation werden dem Roboter in dem in diesem Beitrag beschriebenen Verfahren, wie links in Abbildung 1 zu sehen, drei Punkte vorgegeben, aus denen die Lage und Größe des Gerätedisplays errechnet wird. Zudem erlernt der Roboter die Position der Zurück-Taste des Gerätes, da diese bei jedem Endgerät anders positioniert sein kann. Dazu wird der Roboter mit seinem Endeffektor mit einem kapazitiven Stift zunächst zum linken oberen Displayrand (p1), dann zum rechten oberen Displayrand (p2), danach zum rechten unteren Displayrand (p3 ) und anschließend zum Zurück-Button geführt. Jede dieser Positionen wird mit einem Tastendruck bestätigt. Mit diesem Verfahren können die beiden Koordinatensysteme in der Einlern-Phase aneinander angeglichen werden. Das System ist sowohl unabhängig von einer auf dem DUT installierten Software als auch von unterschiedlichen Displaygrößen. Die Angleichung muss zudem nur einmalig für ein neues DUT durchgeführt werden.

Abb. 1: Links: DUT, auf dem die initialen Punkte eingezeichnet sind, die der Roboter erlernt. Rechts: Panda-Roboterarm von Franka Emika mit DUT

Folgende Schritte werden in der darauffolgenden Test-Phase bis zur vollständigen Testung iterativ durchgeführt. Zunächst wird die Displayoberfläche, wie bereits beschrieben, eingelesen. Das entwickelte Verfahren geht dabei von zwei Grundsätzen aus, welche auf die Bedienung der meisten Android-Apps zutreffen:

Vorhandene Schaltflächen vom Typ Button führen zu bisher noch nicht aufgerufenen, neuen Activities.
Um zu zuvor besuchten Activities zu springen, wird die Zurück-Schaltfläche benutzt.

Andere Oberflächenelemente führen hauptsächlich zu einem neuen Oberflächenzustand in der gleichen Activity. Aufgrund dieser Annahmen kann ein nominaler Ablauf einer App in einem Baum dargestellt werden. Im Vergleich zu anderen Graphen ist bei einem Baum jedes Blatt von der Wurzel aus erreichbar und es existieren keine geschlossenen Pfade (Zyklen). Diese Eigenschaften stellen sicher, dass alle in der App enthaltenen Activities aufgerufen werden. Erst dadurch sind aussagekräftige Tests möglich.

Jeder (neu) gefundene Button wird dem (Ablauf-)Baum als neuer Knoten hinzugefügt. Die Wurzel eines Baumes bildet die erste Activity der App ab. Nach dem Hinzufügen aller Buttons einer Activity zu ihrem jeweiligen Activity-Knoten können diese vom Roboter angefahren werden.

Um alle Elemente zu finden, kommen die beiden Suchstrategien Breiten- und Tiefensuche in Frage [Cor17]:

Bei der Breitensuche wird der Baum sequenziell Ebene für Ebene durchsucht, bis es keinen unberührten Knoten auf einer Ebene gibt. Erst dann wird zur nächsten Ebene übergegangen.
Bei der Tiefensuche wird der Baum von der Wurzel aus, Knoten für Knoten, bis zu einem Endknoten (Blatt) durchlaufen. Der nächste (von der Wurzel aus betrachtet) unbesuchte Knoten in einer der höheren Ebenen dient anschließend als neuer Startknoten.

Da zu Beginn der Suche noch nicht alle Knoten bekannt sind, wird im verwendeten Verfahren eine Mischung aus beiden Suchstrategien angewendet. Die Breitensuche ist bei endlichen Graphen vollständig: Eine Activity, die von der Wurzel aus erreichbar ist, wird sicher gefunden. Um nicht nach jeder neu gefundenen Activity wieder zurück zu einer anderen Activity derselben Ebene springen zu müssen, werden erst alle Buttons einer Activity zu einer Ebene (Breitensuche) hinzugefügt. Daraufhin wird die erste zur Ebene hinzugefügte Activity getestet und ausgehend von dieser tiefer gegangen (Tiefensuche).

Dieser Suchalgorithmus geht die erstellte App beispielhaft in Abbildung 2 durch.

Abb. 2: Suchalgorithmus anhand der Beispiel-App mit entdeckten und angefahrenen Knoten in der entdeckten und getesteten Reihenfolge

Das Verfahren wird solange durchgeführt, bis alle Knoten beziehungsweise Buttons gefunden und vom Roboterarm getestet wurden. Dieser Gesamtablauf des Testverfahrens ist in Abbildung 3 dargestellt.

Abb. 3: Testablauf nach dem entwickelten Verfahren

Passiert in der App etwas Unvorhergesehenes, das zu deutlich detektierbaren Fehlern (bspw. Abstürzen) führt, werden mehrere Dokumentationsvorgänge gestartet. Dadurch kann das Verhalten der App bis zu diesem Zeitpunkt nachvollzogen werden und der Fehler ist reproduzierbar. Optional können während des Testablaufs regelmäßig Screenshots erstellt werden. Zusätzlich wird der bis dahin erstellte Ablauf-Baum gespeichert, mit dem der Fehlerzustand nachvollzogen werden kann. Durch das Verfahren wird insbesondere die Stabilität einer App getestet. Für einen automatischen funktionalen Vergleich des Ist- mit dem Sollzustand müsste dem Roboter zunächst ein musterhafter Idealablauf der zu testenden App beigebracht werden. Alternativ kann der Tester durch Überprüfung des Ablauf-Baums fehlende oder nicht erreichte Zustände der App finden.

Zusammenfassung und Ausblick

In diesem Artikel wurde ein Verfahren vorgestellt, das eine Möglichkeit darstellt, mit einem generalisierten Roboterarmsystem Apps mit einer hohen Testtreue zu testen. Es ermöglicht Black-Box-Tests für native Android-Apps. Dabei benötigt es nur minimale manuelle Eingriffe und kann nach dem Einlernen des DUTs sowohl autonom als auch automatisiert durchgeführt werden.

Die Verwendung offener modularer Standards ermöglicht die Anpassung des Verfahrens an andere Robotersysteme. Bisherige Verfahren zum automatisierten Testen benötigen entweder besondere Fähigkeiten der Tester oder spezifische Anpassungen an die Testaufgabe. Der dadurch benötigte Zusatzaufwand erschwert das Testen von Apps unnötig und mindert die Akzeptanz von Tests.

Die in dem vorgestellten Verfahren zusätzliche Verwendung eines Roboterarmsystems führt zu einer höheren Testtreue und ermöglicht außer dem Test der App auch ein Testen des Endgeräts unter spezifischen Umwelteinflüssen. Eine Beaufsichtigung des Roboters ist nicht notwendig, da dieser die Tests nach dem Starten selbstständig durchführt und das Programm anschließend ausführliche Ergebnisse liefert.

Mit der Weiterentwicklung des Ansatzes auf weitere interaktive UI-Elemente von Android wird das Testen von deutlich mehr Applikationsarten und Interaktionsmöglichkeiten unterstützt. An einer Ausweitung des Testalgorithmus durch maschinelle Lernverfahren wird bereits mit vielversprechenden Teilergebnissen gearbeitet.