“Sakuli”, das Open-Source-Framework zum automatisierten Testen von Applikationen, ist vor kurzem in Version 1.0 erschienen. Ein kleiner Blick auf die zurückliegenden Änderungen.
Der grafische Installer vereinfacht die Installation eines Sakuli-Clients deutlich. Java 8 (JRE) ist die einzige Voraussetzung, um Sakuli auf Windows oder Linux zu installieren. Mit im Gepäck sind unter anderem der Firefox Portable (um die System-Browser unangetastet zu lassen) und eine Reihe von Beispiel-Tests, die als Funktionstest und Vorlage für eigene Tests dienen. Unter Windows empfohlene Registry-Settings (z.B. zur Deaktivierung von visueller Effekte, welche die Sikuli-Bilderkennung stören könnten) nimmt der Installer ebenfalls vor.
Am Ende der Installation können alle Parameter in einem XML-File gespeichert werden; folgende Installationen lassen sich damit parametrisieren und damit headless ausführen.
Deutlich vereinfacht - und vor allem vereinheitlicht - hat sich der Aufruf von Sakuli-Tests, die bisherigen Shell- und Batchscripte für Linux und Windows sind obsolet. Der generische Starter sakuli startet einen Testlauf mit nur zwei Parametern (“run” + Suite-Pfad). Die übrigen Informationen werden aus den Property-Files gelesen, die entweder global, für den Suite-Ordner oder für die Suite speziell gelten.
-preHook und -postHook können als Startparameter angegeben werden, wenn vor und/oder nach dem Test weitere Aktionen ausgeführt werden sollen. In verteilten Umgebungen, in denen Sakuli-Tests in einem GIT-Repository vorgehalten werden, kann ein PreHook beispielsweise verwendet werden, um die Testdefinition noch vor dem Start über GIT zu aktualisieren.
Während der Implementierung von Tests erweist sich der Parameter “loop” als praktisch: mit ihm kann ein Sakuli-Test in einer Dauerschleife ausgeführt werden (im Produktiv-Betrieb hingegen empfiehlt sich nach wie vor der Start per Task Scheduler bzw. cron).
$ sakuli
Generic Sakuli test starter.
2016 - The Sakuli team <sakuli@consol.de>
http://www.sakuli.org
https://github.com/ConSol/sakuli
Usage: sakuli[.exe] COMMAND ARGUMENT [OPTIONS]
sakuli -help
sakuli -version
sakuli run <sakuli suite path> [OPTIONS]
sakuli encrypt <secret> [OPTIONS]
Commands:
run <sakuli suite path>
encrypt <secret>
Options:
-loop <seconds> Loop this suite, wait n seconds between
executions, 0 means no loops (default: 0)
-javaHome <folder> Java bin dir (overrides PATH)
-javaOption <java option> JVM option parameter, e.g. '-agentlib:...'
-preHook <programpath> A program which will be executed before a
suite run (can be added multiple times)
-postHook <programpath> A program which will be executed after a
suite run (can be added multiple times)
-D <JVM option> JVM option to set a property at runtime,
overrides file based properties
-browser <browser> Browser for the test execution
(default: Firefox)
-interface <interface> Network interface card name, used by
command 'encrypt' as salt
-sahiHome <folder> Sahi installation folder
-version Version info
-help This help textForwarder transportieren die Ergebnisse von E2E-Tests an Systeme, die diese dann weiter verarbeiten. Zu den bisher zwei Forwardern mod-Gearman (Monitoring-Systeme mit mod-gearman an Bord) und database (Ablegen der Ergebnisse in einer Datenbank, von wo andere Systeme lesen) kommt nun icinga2 als dritter im Bunde. Mit ihm ist es möglich, E2E-Ergebnisse ähnlich wie beim gearman-Forwarder in Echtzeit an die REST-Schnittstelle von Icinga2 zu übertragen (vorgestellt auf dem Icinga Camp 2016 in Berlin).
Für Sakuli-Einsteiger gibt es nun ein First-Steps-Tutorial. Es wird gezeigt, wie mit den beiden Tools Sahi und Sikuli automatisierte Benutzeraktionen sowohl auf Webseiten, als auch nicht-Web-Inhalten ausgeführt werden können.
Die Ausführung von Sakuli in Docker-Containern ist kein wirklich neues Feature; an dieser Stelle sei aber erwähnt, dass natürlich auch die Docker-Images für CentOS und Ubuntu mit der aktuellen Stable-Version aus dem master-Branch (Tag: latest) bestückt sind. Wer es noch etwas aktueller haben will, kann auch die mit “dev” getaggten Images verwenden.
Die LIDL Stiftung & Co. KG setzt Sakuli ein, um die Applikations-Performance stiftungs-/europaweit zu messen. Die Messsonden (Windows) werden mit einem auf LIDL angepassten Paket installiert und von zentraler Stelle aus mit stets aktuellen Testfällen versorgt. Ein Thruk-Dashboard visualisiert die Verfügbarkeit und Güte der Applikationen, wie Felix Winkemann (IT-Projektleiter International) auf dem ConSol-Event “Von Monitoring bis Managed Service” am 3. März 2016 in der Allianz-Arena erklärte.
Auch die pbb Deutsche Pfandbriefbank hat Sakuli im Einsatz. Die europäische Spezialbank für die Immobilienfinanzierung und die öffentliche Investitionsfinanzierung sichert mit Sakuli die Qualität und Verfügbarkeit ihrer zentralen Anwendungen und IT-Services, darunter SAP und Summit.
Sakuli ist darüber hinaus nicht nur in Monitoring-Umgebungen einsetzbar, sondern eignet sich auch zur Integration in Continuous-Integration-Systeme. Folgendes Video zeigt, wie Sakuli den Bestellprozess im Online-Portal der M-net Telekommunikations GmbH prüft:
Die nächste Stable-Version ermöglicht u.a. die Anzeige vergangener Screenshots samt Fehlermeldung in Thruk. Die Bilder können in einer Lightbox per Maus/Tastatur durchgeblättert werden:
siehe GitHub