Robotererstellung (RPA) mit AutoTest-Tools

Autoren: Lebedev A., Nazarova E. Die

Notwendigkeit, Robotik einzusetzen, ergibt sich aus verschiedenen Gründen: Die Notwendigkeit neuer Anwendungen zum Datenaustausch mit Anwendungen ohne API, die schnelle Integration heterogener Anwendungen, die Automatisierung von Routineprozessen mit minimalen Kosten usw.

Traditionell werden Roboter oder RPA (Robotic Process Automation) auf der Basis von vorgefertigten Frameworks erstellt. Hier sind die Marktführer unserer Meinung nach Produkte von UiPath, Automation Anywhere, Blue Prism, NICE. Dies sind bewährte Plattformen, mit denen Sie Qualitätsentscheidungen treffen können. Allerdings nicht billig. Sie müssen für Lizenzen in der Anzahl zukünftiger Jobs bezahlen, für die Anpassung an Ihre spezifische Aufgabe und die Inbetriebnahme bezahlen. In einigen Fällen können Sie billiger werden. Wir haben es geschafft und sind bereit, Erfahrungen auszutauschen.

Vor einiger Zeit begann in einer der Banken die agile Transformation. Neue Ansätze zur Entwicklung von Anwendungen für die Bedürfnisse der Bank. Um anderen den Weg zu zeigen, bildeten sie Pilotenteams, um neue Produkte zu entwickeln.

Die Bank verfügt über traditionelle Schlüsselsysteme für die Durchführung von Buchhaltungs- und operativen Aktivitäten. Die Arbeit mit den Produkten der neuen Teams wurde in Form von Microservices implementiert, die Daten mit Schlüsselsystemen austauschen sollen. Und die Entwicklung in Teams begann ziemlich schnell. Das Problem ist jedoch, dass traditionelle Ansätze zur Freigabepolitik von Schlüsselsystemen nicht in dieses Tempo passten. Und die API für die neuen Microservices war im Plan für die Zukunft.

Wie bei Pechkin stellt sich heraus: "Ich habe dir ein Paket gebracht, aber ich werde es dir nicht geben." Unter diesen Bedingungen wandten sich Vertreter der Pilotenteams an unser Auto-Test-Team mit der Idee, UI-Auto-Tests ähnlicher Prozesse zur Erstellung von Robotern zu verwenden.

Natürlich haben wir zuerst die Risiken besprochen. Die Tatsache, dass bei der Verwendung von Autotest-Tools die Zuverlässigkeit von Softwarelösungen für Testanforderungen geringer ist als für Zahlungssystemanwendungen, wurde sofort bekannt gegeben. Aufgrund der agilen Welle gingen die Teams jedoch Risiken ein.

Das Toolkit wurde traditionell und kostenlos verwendet: Java für die Entwicklung, Montage über Maven. Für die Arbeit mit dem Browser wurde Selenium verwendet (die Anwendung, in der Daten eingegeben werden mussten, verfügt über eine Weboberfläche).

Die Hauptunterscheidungsmerkmale des Roboters im Vergleich zum UI-Autotest desselben Prozesses sind die Notwendigkeit der korrekten Behandlung von Fehlersituationen und Ausnahmen sowie die Integration als Subsystem über den Dateiaustausch.

Damit der Roboter funktioniert, wurde ein virtueller Server zugewiesen, ein technisches Domänenkonto und ein separater Benutzer in dem System erstellt, in dem die Daten eingegeben wurden. Mit Autorität, wie ein lebender Angestellter, der ähnliche Handlungen ausführt.

Auf diesem Server wurde ein Jenkins-Agent installiert, mit dem Sie den Roboter ausführen können. Der Bericht über die Arbeit des Roboters wurde sowohl in Form eines Ausführungsprotokolls als auch in Form eines Allure-Berichts erstellt. Beide sind in Jenkins verfügbar und erfordern keine spezielle Berechtigung für den Zugriff auf Netzwerkressourcen.

Die Arbeit des Roboters war wie folgt strukturiert: Eine Datei mit Daten zur Eingabe in das System wird im Eingabeordner einer Netzwerkressource abgelegt und der Roboter wird über Jenkins gestartet. Es vergleicht die Datensätze der Eingabedatei anhand des Schlüsselfelds mit der Servicedatei, in der alle bereits verarbeiteten Datensätze gespeichert sind, und wählt nur diejenigen aus, die noch nicht verarbeitet wurden. Als nächstes wird das Datensatzarray in einer Schleife verarbeitet. Darüber hinaus werden bei jedem Verarbeitungsschritt jedes Datensatzes Ausnahmen und Fehler verarbeitet (try ... catch) und Prozess-Drops in der resultierenden Datei vermerkt. Gleichzeitig stoppt die Verarbeitung des Eingabearrays nicht, wir gehen einfach zum nächsten Datensatz. Wenn die Verarbeitung des gesamten Arrays abgeschlossen ist, wird die Eingabedatei gelöscht. In der Ausgabe befinden sich alle verarbeiteten Datensätze mit dem Ergebnis und der Laufzeit. Allure Report wird als Information zur Verarbeitung für jeden Datensatz angezeigt.und eine allgemeine Liste mit den Verarbeitungsergebnissen jedes Datensatzes. Dies macht es einfach, das Ergebnis auszuwerten und etwaige Probleme zu lokalisieren.



Darüber hinaus stellte sich bei der Verwendung des Roboters heraus, dass der Anwendungsfluss an Spitzentagen ziemlich groß ist und eine größere Anzahl gleichzeitiger Benutzer erforderlich ist, um die akzeptable Verarbeitungszeit einzuhalten.

Das System hat mehrere weitere Benutzer erstellt. Die parallele Ausführung wurde mithilfe von Threads (Thread) implementiert. Das gesamte Array von Eingabedatensätzen wird gleichmäßig auf die Streams verteilt, in denen die Verarbeitung jeweils unter einem eigenen Benutzer ausgeführt wird. Die Ergebnisse werden in eine Datei geschrieben und der Bericht ist auch einzeln. Das ist bequem. Gleichzeitig wurde ein einzelner Selenium-Server gestartet, der den parallelen Start mehrerer Browser (je nach Anzahl der arbeitenden Benutzer) bewältigen kann. Wir haben mit dem Chrome-Browser gearbeitet, jeweils wurde Chromedriver verwendet.

Dies ist überraschend, aber während der neun Monate des Betriebs waren die Probleme nur auf falsche Eingabedaten zurückzuführen. Technische Probleme traten erst in der Inbetriebnahmephase auf und waren mit der Koordination der Codierungen im Protokoll und der Erweiterung des Speichers verbunden, der beim Starten von Selenium Server (geliefert 1G) verwendet wurde.

Nach einiger Zeit wurde für dasselbe Agile-Team ein weiterer Roboter entwickelt. Seine Funktion ist, dass es nicht bei Bedarf gestartet wird, sondern kontinuierlich durch Scannen des Eingabeordners arbeitet. Wenn eine eingehende Datei angezeigt wird, wird sie verarbeitet. Dementsprechend wird der Jenkins-Agent nicht verwendet. Wenn der Vorgang erfolgreich ist, wird die Eingabedatei in den Ordner mit den erfolgreich verarbeiteten Dateien verschoben, andernfalls in den Ordner mit den fehlerhaften Dateien. Im Gegensatz zum vorherigen Roboter fehlt der Allure-Bericht, aber die Ausführungsprotokolle werden zur Analyse in eine separate Datei geschrieben, falls Probleme auftreten. Und noch eine Funktion: Der Browser wird am Ende der Verarbeitung zwangsweise geschlossen und startet, wenn sich der Benutzer anmelden muss.

In einigen Fällen können Sie beim Erstellen eines RPA mit den Autotest-Tools spürbar günstiger auskommen.