Ein Überblick über UI Test Automatisierungs Suiten

(Last Updated On: 22. Mai 2018)

Die Thematik der Automatisierung von User Acceptance Tests ist vor allen Dingen im Rahmen der SecDevOps-Philosophie in aller Munde und soll es Unternehmen ermöglichen, eine konsistente und umfassende Abdeckung von bestehenden Testszenarien und eine kontinuierliche Weiterentwicklung neuer Testszenarien zu implementieren, ohne sich all zu lange mit der eigentlichen Ausführung der Tests beschäftigen zu müssen.

In diesem Beitrag liefere ich einen kurzen Überblick zur Automatisierung von Software-Tests. Hierbei beleuchte ich einmal die Welt der SAP-UI-Technologien (Fiori & SAPUI5, SAPGui & Dynpro, BSP, Webdynpro u. v. m.) und einmal die von SAP unabhängige Welt der Web- und Desktop-Anwendungen.

Testautomatisierung im SAP-Umfeld

SAPGui Scripting

Die erste Automatisierungstechnologie für die Bedienung von SAPGUI-Transaktionen ist SAPGui Scripting. Auch schon beim SAPGui Scripting war es Anwendern möglich, Aktivitäten innerhalb von SAP Gui in einem Makro aufzuzeichnen und dieses dann später wieder abzuspielen. Man konnte also einen Testfall im System aufzeichnen und dann immer wieder neu abspielen. Das Problem bei SAPGui-Skripting liegt an drei Stellen:

  • zum Login auf dem System müssen die Login-Informationen des Users entweder vorher manuell eingegeben, oder die Eingabe der Login-Informationen im Skript mit aufgezeichnet werden.
  • das Skript liegt lokal auf dem Rechner des Anwenders in Form eines VBScripts. Durch diesen Umstand ist SAPGui davon abhängig, dass auf dem Arbeitsplatz des Anwenders der Windows Scripting Host (WHS) installiert und aktiviert ist. Dieser stellt jedoch häufig ein Risiko für die IT-Sicherheit dar, da Skripte über den WHS typischerweise eine beliebte Angriffsfläche für Malware-Angriffe sowohl auf Browser- als auch auf Desktop-Ebene darstellen.
  • Das Skript wird immer im Vordergrund ausgeführt. Das bedeutet, so lange das System ausgeführt wird, darf der Anwender nicht mit eigenen Tastenanschlägen und Mausbewegungen intervenieren, weil er dadurch die Ausführung des Skriptes behindern könnte.

Alle drei Probleme löste die SAP mit der Einführung von eCATT, welches wir weiter unten kennen lernen werden.

Der Vorteil von SAPGui Scripting im Vergleich zu den weiter unten stehenden Technologien ist, dass das Skript sich tatäschlich innerhabb der Desktop-Umgebung des Anwenders als VBScript bewegt und dadurch grundsätzlich mächtiger ist als die anderen Technologien, die „innerhalb von SAP gekapselt“ sind, also aus der SAP-Umgebung nicht ausbrechen können. Auch wenn dies ein Sicherheitsfeature ist, schränkt dies natürlich die Mächtigkeit dieser Skripte ein. Bei SAPGui Scripting wäre dies kein Problem. Aufgrund der oben genannten Nachteile spielt SAPGui Scripting jedoch heutzutage eine eher nachgelagerte Rolle und hat wesentlich an Bedeutung verloren – nicht nur im Testmanagement, sondern auch zur Automatisierung in der Systemadministration, da auch hier bessere Alternativen vorhanden sind.

eCATT

SAP-Kunden haben vor allem in Zusammenhang mit Release-Wechseln häufig einen gehörigen Aufwand im Entwurf ihrer Tests. Darauf hat der Hersteller reagiert und irgendwann das Computer Aided Test Tool (CATT) eingeführt und später in der Erweiterung als enhanced CATT (eCATT) betrieben. eCATT ermöglichte die Automatisierung von Transaktionen zu Testzwecken, bedarf jedoch hohem Fachwissen im Skripting, insbesondere im Hinblick auf VBScript. Zwar gibt es eine Record&Play-Funktion, die Transaktionen aufzeichnet, jedoch ist die Pflege und Anpassung dieser Aufzeichnungen sehr kryptisch. eCATT ist also ein Automatisierungstool von Experten für Experten, mit hohem ABAP-Entwickler Know-How. Dies führte häufig dazu, dass die Testfälle häufig nicht von Fachanwendern erstellt wurden, sondern von Entwicklern. Dadurch gab es einen hohen Abstimmungsbedarf zwischen dem Fachbereich, welcher häufig mit den eigentlichen Tests betraut war, und den Entwicklern, welche die Testfälle passend zu den Anforderungen der QA-Abteilung erstellen musste. Im Endeffekt mussten also die Testfälle ihren eigenen umschweifenden Abnahmeprozess durchlaufen.

Anders als beim klassischen SAPGui-Scripting muss man sich bei der Ausführung von eCATT nicht vorher im System einloggen oder die Eingabe seiner Anmeldedaten mit eingeben. Stattdessen erstellt eCATT eine RFC-Verbindung zu dem System, auf welchem das Skript ausgeführt werden soll. Das heißt, wie jeder anderen RFC-Verbindung auch, sind die entsprechenden Anmeldedaten im SSFS des SAP-Systems hinterlegt und daher wesentlich besser geschützt als in einem VBScript in der Desktop-Umgebung des Anwenders. Außerdem nutzt eCATT eine integrierte Skripting-Engine, die im Herzen allerdings, so viel muss gesagt werden, auf VBScript aufbaut. Jedoch müssen zur Ausführung von eCATT-Skripten weder auf dem Arbeitsplatz des Anwenders noch auf Server-Ebene der WHS installiert sein.

Zu guter letzt lassen sich eCATT-Skripte im Hintergrund ausführen, so dass durch das SAP-System ein Job erstellt wird, welcher das eCATT-Skript im Hintergrund ausführt. Das heißt der Anwender, welcher das Skript ausführt, kann im Gegensatz zum SAPGui-Skripting weiter im Vordergrund mit dem System arbeiten.

eCATT wird jedoch aktuell immer mehr von CBTA verdrängt, welches wir im Folgenden behandeln werden. Grund hierfür ist eben die technische Komplexität von eCATT. eCATT wird im SAP Test Management heutzutage jedoch immer noch verwendet, um technische Komponenten wie Funktionsbausteine und Exits (BAPIs, Enhancements) auf Funktionalität zu testen. Auf Ebene der UI-Automatisierung wird eCATT jedoch mehr und mehr von den moderneren Technologien zurückgedrängt.

SAP TAO

Das SAP Test Automation and Optimization Framework ist eine Engine für die Automatisierung von SAP-Testfällen bei gleichzeitiger Integration in das SAP Quality Center by HP, also einem Drittanbieter-Testmanagementtool. HP QC bzw. HP ALM verwenden eigene technsiche Workflows zur Testfallautomatisierung. SAP TAO ist ein Workcenter des SAP Solution Manager. Trotzdem müssen sie ihr klassisches Testmanagement nicht im SolMan selbst erledigen, sondern können hierzu die HP-Lösung verwenden. Das macht beispieslweise Sinn, wenn Sie HP QC bzw. HP ALM nicht nur für SAP, sondern auch für andere Anwendungen nutzen, die Sie wiederum mit anderen Adaptern automatisieren. Im Gegensatz zu CBTA des SAP Soltuion Managers müssen Sie in SAP TAO selber Skripte schreiben. Es gibt keine einfache Möglichkeit, über eine Record&Play Funktion einfach SAP Gui Schritte als Makro aufzuzeichnen.

Wenn Sie HP QC bzw. HP ALM noch nicht einsetzen, sollten Sie Ihr Test Management im Solution Manager erledigen und die Vorteile von CBTA, welches wir weiter unten vorstellen, nutzen.

SAP Solution Manager CBTA

Das neueste Baby der SAP in diesem Bereich nennt sich Component-Based Test Automation (CBTA) und ist eine technische Funktionalität des SAP Solution Manager. Die Testfälle werden also zentralisiert im Solution Manager definiert. Der Entwurf der Testfälle hingegen kann nun von Fachnutzern erfolgen, da diese nun einfach nur den Verlauf einer Transaktion als Makro aufzeichnen können.

Die Pflege der aufgezeichneten Makros ist im Vergleich zu eCATT wesentlich fachlicher gestaltet, das heißt der Anwender kann in der Übersicht ganz genau sehen, in welches Dynpro-Feld beispielsweise welcher Wert eingetragen wird.

Der Ersteller des Makros kann hierbei beispielsweise auch sogenannte Checkpoints festlegen, an welchen automatisch Screenshots vom aktuellen Ausführungsstatus des Testfalls erstellt und dokumentiert werden sollen, so dass auch die Dokumentation sehr einfach automatisiert werden kann. Selbstverständlich gibt es jedoch, für komplexere Szenarien, weiterhin die Möglichkeit, die Skripte entsprechend durch manuelle Entwicklertätigkeiten zu erweitern.

CBTA unterstützt ab Solman 7.2 SP03 von Natur aus alle wichtigen SAP UI Technologien: SAP GUI, WebDynpro ABAP, SAP CRM Web Client, SAP Portal, SAPGui for HTML, Netweaver Business Client (NWBC), Business Server Pages (BSPs), Webdynpro for Java und zu guter letzt natürlich SAPUI5 und damit Fiori. Des Weiteren unterstützt CBTA die Integration von Drittanbieter-Automatisierungstools, darunter etwa MicroFocus Unified Functional Testing (UFT, ehemals HP QuickTest Professional), Tricentis Tosca und Worksoft Certify.

Dabei wird UFT vorwiegend für das Testen mobiler Oberflächen auf den Browser-Apps verschiedener Smartphone-Betriebssysteme verwendet.

Tricentis Tosca ist ein System, welches den Zweck hat, die Testautomatisierung über CBTA komplett zu ersetzen. Neben SAP-Lösungen untersützt es auch andere Lösungen wie Salesforce. Das Tool liefert eine nochmal einfachere Sicht auf die aufgezeichneten Transaktionen und ist in den Solution Manager integrierbar.

Fernab von der UI-Welt

In diesem Blogpost spezialisieren wir uns natürlich auf der UI-Welt. An dieser Stelle sei angemerkt, dass die SAP noch andere Technologien zum automatisierten Testen anbietet, die jedoch nicht in der UI-Ebene anzuwenden sind. ABAP Unit ist beispielsweise für den Entwurf und die Ausführung von ABAP Unit Tests zuständig.

Automatisierung in der Web- und Desktop-Welt

 

Selenium

Selenium ist ein Open-Source-Framework zur Web-Automatisierung. Es gibt sowohl eine Umsetzung auf Basis von Python als auch für Java. Selenium ist für beide Programmiersprachen als Bibliothek realisiert und kann daher in Kombination mit anderen Bibliotheken kombiniert werden. Selenium liefert Klassen aus, die es ermöglichen, Web-Elemente anhand von Eigenschaften (wie etwa deren CSS-Klasse, ID, innerHTML oder anderen HTML-Attributen) auszuwählen und mit diesen zu interagieren (zu klicken, Eingaben zu tätigen usw.).

Dadurch, dass es sich bei Selenium um eine Programm-Bibliothek handelt, können ander Bibliotheken, beispielsweise zum Webcrawling o. Ä., mit geladen werden. Dadurch ist Selenium sehr mächtig. Nachteil: Sie müssen das Skript von Anfang an selbst entwickeln. Eine Record&Replay-Funktion zur einfachen Aufzeichnung von Makros gibt es nicht.

Sahi

Sahi ist sozusagen die Record&Play-Alternative zu Selenium zum autoamtischen Testen von Webanwendungenn. Das ganze funktioniert so. Sahi funktioniert zunächst einmal als eine Art WebProxy. Das heißt der Tester verbindet sich auf die Sahi-Instanz. Dort kann er einen  Browser seiner Wahl (Chrome, Edge, IE, Firefox, Safari usw.) starten und die eigentliche zu testende Webanwendung aufrufen. Innerhalb des von Sahi gestarteten Browser kann man nun mit der Maus über die einzelnen Web-Elemente fahren. Dort wird einem angezeigt, welche Aktionen (z. b. Klicken, Eingaben machen, Dropdown-Listenauswahlen tätigen usw.) man machen kann. Diese Aktioenen führt man dann durch und beendet am Schluss die Aufzeichnung. Das so aufgezeichnete Makro kann nun später abgespielt werden.

Sahi ist also eine sehr einfache Variante für Tester, die keine Programmierkenntnisse haben. Da es sich jedoch um keine Code-Implementierung wie Selenium handelt, ist die Mächtigkeit dieser Lösung eingeschränkt.

Watir

Watir ist wie Selenium eine Bibliothek zur Automatisierung von Web-UI-Interaktionen. Während Selenium auf Java oder Python basiert, ist die Grundlage für Watir die Programmiersprache Ruby. Watir bietet sich also an, wenn Sie beispielsweise in Ruby eigene Programmfunktionalitäten geschrieben haben und diese mit Automatisierungsfunktionen a la Selenium kombinieren wollen.

Robot

Das Robot Framework ist ein sehr mächtiges Python-Framework, unter Anderem, weil es sich mit Selenium, AutoIt, Sikuli und Appium integrieren lässt und mit diesen also zusammen arbeiten kann. Sie können also die Automatisierungs-Funktionalitäten von Robot mit den Vorteilen der anderen Automatisierungs-Tools kombinieren. Robot bringt noch andere diverse Vorteile mit sich, wie etwa Funktionen zur Generierung von Testdaten.

Robot hat außerdem interne Funktionalitäten, um beispielsweise Betriebssystemkommandos per SSH an Unix/Linux-Maschinen zu senden. Dazu ist das Framework auch dazu in der Lage, beispielsweise Schlüssel zu speichern, um sich auf den entsprechenden Systemen authentifizieren zu können. Auch FTP und TFTP-Datentransfers können über das Framework angeworfen werden.

Robot verfügt auch über Bibliotheken, um sich auf Datenbanken und MQTT-Broker zu verbinden und somit Testfälle auf diese Systeme anzuwenden. Ich persönlich liebe Robot, da ich unter einem Dach viele Tools zur Verfügung habe, ohne auf die Vorteile von Selenium, AutoIt, Sikuli und Appium verzichten zu müssen.

Galen

Galen ist ein auf Selenium (Java-Version) basierendes Test-Framework, welches vor allen Dingen gerne dazu genutzt wird, um die Responsivität von Web-UIs zu testen. Im Galen Framework definieren Sie eingangs einen Satz an Referenz-Devices. Sie können beispielsweise ein Mobile Device mit einer Auflösung 350×500 Pixel simulieren, und daneben beispielsweise ein Desktop Device mit 1920×1080 Pixel. Sie sind hier in Ihrer Auswahl nicht beschränkt. So wäre es beispielsweise auch möglich, eine unkonventionelle Auflösung zu wählen, um zu simulieren was passiert, wenn ein Benutzer das Browserfenster verkleinert, beispieslweise um zwei Fenster nebeneinander im selben Bidlschirm zu halten.

Der Sinn hinter Galen ist nicht, dass Sie nun die Devices und die simulierte Desktop-Auflösung wechseln  – das können Sie schließlich beispieslweise auch mit den Entwicklertools des Webbrowsers machen. In Galen können Sie definieren, welches Element (beispielsweise ein div mit einer bestimmten ID) sich bei Geräte X an welcher Stelle befinden sollte.

So können Sie beispielsweise definieren, dass die Navigation in einem Design bei Desktop Devices ganz rechts angedockt werden soll (Abstand zum rechten Bildschirmrand: 0px), bei Mobile Devices hingegen soll die Navigation die ganze Bildschirmbreite einnehmen und dafür ganz oben sein (Abstand zum rechten, linken und oberen Bildschirmrand jeweils: 0px). Sie können auch prüfen, dass die Breite etwa ein bestimmter Prozentsatz im Verhältnis zur Bildschirmbreite oder die Schriftgröße eine bestimmte Dimension annehmen soll.

Dies ermöglicht Ihnen, automatisiert zu sehen, ob Sie noch Bugs im responsiven Design Ihrer Webanwendung haben, ohne dass ein Designer selber die ganze Zeit gucken muss.

soapUI

soapUI ist ein Werkzeug zum automatisierten Testen von SOAP, Restful und GraphQL Web-APIs. Sie pflegen in SOAP die URL zu einer Web-API ein und erstellen nun Testfälle, in welcher Sie der API anhand von GET-bzw. POST-Requests unterschiedliche Parameter zuspielen. soapUI nimmt dann die Rückantwort der API und interpretiert diese. Der Vorteil bei der Nutzung von soapUI ist also, dass Sie unter Umständen keine UI-basierten Testfälle mehr definieren müssen, wo ein Tester tatsächlich noch Sachen in einen Webbrowser eingeben muss, um eine Web-API durchzutesten. An bestimmten Stellen macht dies natürlich noch weiterhin Sinn, da Sie ja wissen wollen, ob die UI an sich richtig funktioniert. Für die Web-API jedoch können Sie die relevanten Testfälle vollständig mit Hilfe von soapUI abbilden.

Cucumber

Cucumber ist ein Behaviour Driven Development (BDD) Test-Framework und unterscheidet sich in diesem Sinne von den anderen vorgestellten Test-Frameworks. Cucumber kann nicht nur mit Selenium, sondern auch mit vileen anderen Programmiersprachen und Bibliotheken kombiniert werden. Der Kern-Vorteil von Cucumber ist, dass es Testfälle anhand der Markup-Sprache Gherkin definiert. Gherkin ist eine Sprache, die darauf ausgelegt wurde, einfach zu verstehende Testfälle zu definieren, die sich am Verhalten des Nutzers orientieren. Klassische Testfälle werden von Entwicklern geschrieben und orientieren sich an den Anforderungen, die vom Entwickler bzw. BEtreiber der Software-Lösung gestellt werden. Gherkin werden häufig von Line of Business Nutzern geschrieben und orientieren sich am Endkunden, welcher die Anwendungen nutzen soll.

Ein Testfall, der in Gherkin geschrieben ist, kann beispielsweise so aussehen

Given I am on the site „Home“
When I click on „Sign in“ Link on the „Home“ Page
And I click on „Register“ on the „Sign in“ Page
And I enter „test@gmail.com“ in the „E-mail“ field on the „Register Form“ Page
And I enter „test12345“ in the „Password“ field on the „Register Form“ Page

Then XYZ

Eine interne Logik übersetzt diesen in Gherkin geschriebenen Testfall im Anschluss in Code, der beispielsweise mit Selenium ausgeführt werden kann.

Es gibt noch andere Frameworks im Bereich des BDD-Testings, die auch oft mit Cucumber kombiniert werden, beispielsweise Serenity BDD.

Sikuli

Sikuli ist ein sehr beliebtes Automatisierungstool, nicht nur im Testumfeld, sondern beispielsweise auch in der Systemadministration. Sikuli ist dazu in der Lage, sowohl Web-Objekte als auch Window-Objekte anzusteuern. Das bedeutet, Sikuli erkennt die Objekte, mit denen es interagieren soll, sowohl auf Web-Ebene als auch auf Windows-Ebene. Jedoch erkennt Sikuli dies nicht auf Basis von Objekt-Eigenschaften (beispielsweise also anhand des HTML-Tags, der HTML-ID, -Klasse oder dem innerHTML eines Containers, sondern durch Bilderkennung. Wenn Sie wollen, dass Sikuli beispielsweise einen bestimmten Button automatisch klicken soll, speichern Sie einen Screenshot vom Dialog, der diesen Button zeigt. Im Coding sagen Sie dann, Sikuli soll auf einen Dialog warten, der zum Großteil diesem Bild entspricht, und dann an eine bestimmte Stelle klicken. Sie müssen dabei wirklich nur das Element speichern, welches wirklich angewählt werden soll. Wenn Sie also beispielsweise einen Dialog haben, der zwei Auswahloptionen bietet (OK und Abbrechen), dann müssen Sie nur den OK-Button screenshoten, wenn Sikuli diesen später auswählen soll. Je weniger überflüssige Bereiche Sie screenshoten, desto wahrscheinlicher ist es, dass Sikuli das richtige Element erkennt.

Sie können übrigens nicht nur Schaltflächen, sondern beispielsweise auch Eingabefelder und Dropdown-Listen auswählen und dort Werte eintragen oder Tastaturschläge simulieren. Machen Sie einfach vom Eingabefeld, der Dropdown-Liste oder einem anderen Fromular-Element einen Screenshot und Sikuli kümmert sich um den Rest.

Der Vorteil von Sikuli ist, dass es sich damit wunderbar eignet, gemischte Automatisierungsszenarien anzugehen. Beispielsweise ist Selenium exzellent bei der Ansteueurng von Webobjekten, kann jedoch keine Window-Objekte ansteuern. Das wird beispielsweise dann zum Problem, wenn Sie eine Webanwendung bedienen müssen und diese ein Popup-Fenster bringt, in welchem beispielsweise eine Datei zum Upload oder ein Ordner zum Speichern eines Downloads ausgewählt werden muss. Selenium wäre nicht dazu in der Lage, dieses Window-Objekt anzusprechen, da es nicht von der Webanwendung, sondern direkt vom Browser (und somit vom Betriebssystem) kommt. Auch hat Selenium ein Problem bei der Automatisierung von Flash-Objekten, also beispielsweise von Media Playern, deren Bedienelemente (Play-/Pause-Button usw.) angesteuert werden sollen.

Wenn also Sikuli im Endeffekt „mehr kann“ als Selenium, warum nutzt dann jeder zunächst einmal Selenium? Nun, der Nachteil bei Sikuli ist, dass es auf die Speicherung von Bildern angewiesen ist. Das heißt beispielsweise, Sikuli erkennt einen Button, auf den es klicken soll, anhand des Bildes, nicht anhand der Eigenschaften. Sie können sich sicher vorstellen, dass das von Nachteil ist, wenn Sie beispielsweise eine Website haben, wo sich die Buttons beispielsweise nur anhand einer laufenden Nummerieren unterscheiden. Sie müssten dann von jeder einzelnen Zahl ein Bild machen. Mit Selenium hingegen können Sie eine Schleife basteln und die Buttons dynamisch anhand der Zahl einen nach dem anderen auswählen.

In der Praxis geht man nun her und kombiniert Selenium und Sikuli miteinander. Beide basieren auf Java und können als Bibliothek in Java-Code importiert werden. Das heißt aber auch, dass Sikuli derzeit nur mit der Java-Implementierung von Selenium kombiniert werden kann, nicht mit der Python-Variante.

AutoIT

AutoIt wird zur Automatisierung von Windows-Objekten genutzt. Im Gegensatz zu Sikuli wählt AutoIt die Elemente nicht anhand von Bilderkennungs-Algorithmen, sondern anhand von Window-Eigenschaften aus. Hierzu bedient es sich der .NET-Objekteigenschaften. Dies bedeutet wiederum, dass sich AutoIt, im Gegensatz zu Sikuli, nur für Automatisierung unter Microsoft Windows eignet. Bei Mac OSx und Linux beispielsweise ist AutoIt nicht das richtige Tool. Sie können mit AutoIt dann auf ein Fenster, welches mit einer .NET-Oberfläche ausgestattet ist, dessen Eigenschaften ansehen und in ihren Makros dieses Element später beispielsweise anhand des Fenster-Titels oder des Button-Textes auswählen. Dies bringt jedoch auch das Problem mit sich, dass AutoIt beispielsweise auch nicht dazu in der Lage ist, z. B. Flash-Programme oder andere UIs, deren Oberfläche nicht auf .NET basiert, auszuwählen. Dies sind zwar im Windows-Bereich entsprechend wenige, sie sind jedoch trotzdem da.

AutoIt ist außerdem nicht so gut in der Auswahl von Webobjekten wie beispielsweise Selenium. Zwar gibt es ein Addon, welches rudimentär diese Fähigkeit mit sich bringt (siehe meinen damaligen Blogpost dazu), jedoch sind die Möglichkeiten im Vergleich zu Selenium stark begrenzt.

Zwar besitzt AutoIt eine Möglichkeit, Mausklicks direkt anhand von Bildschirmkoordinaten auszuführen und dadurch auch auf Elemente zu klicken, welche nicht über .NET bzw. WindowsForms erstellt wurden, jedoch hat dies in meinem Praxistest eher schlecht als Recht funktioniert. Vor allen Dingen ist das Skript immer nur auf dem System lauffähig, auf dem es erstellt wurde. Sobald sich die Bildschirmauflösung oder die Positionierung des Fensters verändert, war das Skripting über Mauskoordinaten wieder fehlerbehaftet.

UIPath

UIPath ist eine weitere Lösung zur Automatisierung. Die Funktionalität ist ähnlich wie bei Sikuli. Sie wählen bei der Aufzeichnung eines Makros einen Bildschirmbereich aus, beispieslweise einen Button oder den Beschreibungstext eines Eingabefeld.  Von dort kann man beispielsweise (wie auch bei den anderen Vorgängerlösungen) Tastaturanschläge simulieren. Dadurch ist es wiederum etwa möglich, mit Hilfe der Tab-, Pfeil- und Enter-Tasten ein komplettes Formular auszufüllen. Jedoch konnte ich keine Möglichkeit zur koordinaten-unabhängigen Ansprache von UI-Elementen erkennen. UIPath unterstützt, so weit ich das sehen konnte, keine Erkennung von Bildschirmelementen anhand von HTML-Tags, -IDs, -Klassen oder -innerHTML, ist also kein Ersatz für Selenium. Des Weiteren erkennt es keine WindowsForms-Eigenschaften und ist daher kein Ersatz für AutoIt.

Was mich jedoch dazu veranlasst hat, UIPath zu erwähnen, ist die on-the-fly Funktionalität zum Screen Scraping. Demnach ist etwa ein UIPAth-Skript dazu in der Lage, ein Fenster zu öffnen, dort einen Wert aus einem bestimmten Bereich des Bildschirms durch OCR-Funktionalität zu entnehmen, und diesen Wert in einem neuen Fenster an einer bestimmten Stelle einzufügen. Traditionell würde man in so einem Szenario einen Screenshot vom ersten Fenster anfertigen, dann ein kommandozeilen-OCR-Tool auf diesen Screenshot ausführen, müsste dann den überflüssigen Text (von beispielsweise Schaltflächen u. Ä.) entfernen und könnte dann erst mit dem Text weiter arbeiten.

Mit UIPath hingegen wählen Sie zuerst einen Bildschirmbereich aus, in dessen Nähe der zu entnehmende Wert steht.Beispielsweise könnten Sie eine Summe entnehmen wollen. Wählen Sie als erstes das Wort „Summe“ (1) im Bildschirmfenster aus. Im zweiten Schritt markieren Sie bei der Aufzeichnung des Makros die eigentliche Summe (2). Bei der erneuten Ausführung des Makros passiert nun folgendes. Wie bei Sikuli sucht UIPath nach einer Stelle im neuen Fenster, die sich weitgehend mit dem Screenshot des Wortes „Summe“ deckt. Abhängig davon, wie weit bei der Makro-Aufzeichnung die eigentliche Summe (2) vom Wort „Summe“ (1) entfernt war, sucht nun UIPath in diesem Abstand nach der Summe des aktuellen Fensters und entnimmt diese durch seine eigene OCR-Logik. Mit diesem Wert können Sie nun im weiteren Verlauf des Skriptes weiter arbeiten.

Um jetzt wieder zurück auf unser Test-Szenario zu kommen, könnten Sie nun beispielsweise versuchen auszuwerten, ob der Wert, der angezeigt wird, auch dem Wert entspricht, den Sie im Rahmen Ihrer Testausführung erwartet haben. Bei den anderen Lösungen weiter oben ist es in der Regel etwas schwieriger, Textinhalte zu extrahieren und auszuwerten. Bei Selenium und Sikuli ist es noch leicht möglich, da diese auf Java-Code basieren und die Automatisierung für Web-Technologien vorgesehen ist. Sie können also einfach die entsprechenden HTML-Elemente auswählen und die Inhalte der Werte auslesen. Bei AutoIt können Sie Glück haben, weil Sie evtl. den Text über die AutoIt-Funktion WinGetText() heraus bekommen. Dem muss aber nicht der Fall sein. Bei SAPGuiScripting und eCATT können Sie ebenfalls über die Funktion findById das entsprechende Dynpro-Feld innerhalb von SAP Gui auswählen und den Inhalt über die Text-Property auslesen. Sie sehen jedoch, dass der Aufwand hier viel höher ist, als diesen Wert einfach on-the-fly vom Bildschirm auszulesen. Bei TAO und CBAT kommen Sie um die Anfertigung eines Screenshots und anschließende OCR-Analyse mitunter nicht herum.

Appium

Appium ist ein Automatisierungs-Framework für Mobile Apps. Hierbei spielt es keine Rolle, ob die App-UI Native, also rein auf Swift- oder Android-Funktionalitäten, oder auch auf HTML5-Funktionalitäten beruht und daher eine klassische „Web-App“ ist. Im Bereich Testing von Native Apps habe ich leider im Moment noch relativ wenig Erfahrung, da die meisten Referenzprojekte bisher auf Web- oder Desktop-Technologien aufsetzten. Daher kann ich aus Praxissicht derzeit noch nicht viel über Appium sagen.

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.