.st0{fill:#FFFFFF;}

RobotFramework, checkMK

Tutorial: RobotMK Schnellstart – Teil 2

 Oktober 12, 2020

By  Simon Meggle

(Teil 2) Mit diesem Tutorial erhältst Du in ca. 1h eine Windows-VM, in der End2End-Tests mit Robot Framework ausführt werden. Mit Hilfe des Moduls "RobotMK" werden die Test-Ergebnisse von Checkmk überwacht. 

More...

(Direktlink zu Teil 1 des Tutorials)

Selenium-Test

Bisher macht unser Test nichts besonderes, außer ein paar Sleeps aufzurufen. In dem Repository, das wir in Teil 1 gecloned haben, habe ich noch eine weitere Robot-Datei, welche die Selenium-Library verwendet und unser erster richtiger Webtest sein wird. Öffne bitte in VSC die Datei selenium_test/selenium_test.robot.

Dieser simple Web-Test prüft, ob auf einer Webseite eine Tabelle mit Buchpreisen enthalten ist.

Starte bitte jetzt auch diesen Test mit dem grünen Pfeil links oben und prüfe, ob das Ergebnis so aussieht wie bei mir: 

Jetzt komme ich auf die besondere Rolle der Python-Bittigkeit zurück.

Solltest Du statt des obigen Ergebnisses die Fehlermeldung

SessionNotCreatedException: Message: Unable to find a matching set of capabilities

sehen, dann hat das ziemlich sicher den Grund, dass die Bittigkeit des heruntergeladenen Webdrivers nicht zu der des Browsers passt. Prüfe bitte zunächst, ob Dein Browser, z.B. Firefox 64 Bit ist: gehe dazu in "Hilfe" -> "Über Firefox". Dort sollte so etwas stehen wie "79.0 (64-Bit)".

lange Erklärung: Wenn Du statt Python-64Bit die 32-Bit-Version installiert hast, dann hat webdrivermanager vermutlich einen 32-Bit-Treiber heruntergeladen, weil er zu Beginn des Downloads über eine interne Python-Funktion prüft, wie groß der mit diesem Python-Interpreter darstellbare Integer-Zahlenraum ist. Das ist bei einem 32-Bit-Python die Zahl 2147483647. Folglich landet ein 32-Bit-Webdriver auf Deinem System. Wird er nun gestartet, sucht er den Installationsort von Firefox in Registry-Pfaden, die es aber nur auf 32-Bit-Windows gibt.

kurze Lösung: Entweder Du installierst gleich die 64-Bit-Variante von Python (wie empfohlen) und rufst webdrivermanager exakt so auf wie schon einmal. Diesmal wird die interne Prüfung des Zahlenraums auf ein 64-Bit-System kommen und auch den entsprechenden Treiber installieren.

Oder aber Du sagst webdrivermanager mit der speziellen Option --bitness, dass er die 64-Bit-Version holen soll: C:\webdrivermanager --linkpath c:\webdriver --bitness 64 firefox :::

Spätestens jetzt sollte der Start des Selenium-Tests klappen!

Installieren des Selenium-Tests

Erzeuge bitte unterhalb von C:\ProgramData\checkmk\agent\ ein neues Verzeichnis robot (Achtung: nicht "robotmk", denn hier liegen Tests von "Robot Framework", die mit RobotMK - primär zumindest - überhaupt nichts zu tun haben).

Robot-Dir: Diese Verzeichnis ist per default die Stelle, an der das RobotMK-Agenten-Plugin nach Robot-Testdefinitionen suchen wird.

Schnellzugriff: Ich empfehle Dir, den agent-Pfad im Windows-Explorer nach links in die Liste der Schnellzugriffe zu ziehen. Du wirst sehen, dass das sehr praktisch ist, weil Du hier immer wieder mal arbeiten wirst.

Kopiere jetzt den Ordner selenium_test aus dem Repository in das Robot-Dir:

Konfiguration von Checkmk

Installation des RobotMK MKP

.mkp (MK Package) sind Paket-Dateien, mit denen ein Set an Dateien, die zu einem Projekt/einer Erweiterung gehören, zusammengefasst werden. Auch RobotMK wird über dieses bewährte Konzept installiert.

Lade Dir das RobotMK-Package von und installiere es in Checkmk über WATO -> Extension Packages -> Upload Package.

Wenn alles geklappt hat, taucht RobotMK in der Liste der installierten Packages auf:

Die rechte Spalte "CONTENTS" im obigen Screenshot gibt einen Vorgeschmack auf das, was wir gleich verwenden werden:

  • 2 Agents:
    • Agent Plugin: führt Robot-Tests auf den Hosts aus
    • Bakery Plugin: erzeugt in der Bakery Agenten-Packages mit dynamisch konfigurierten RobotMK-Steuerdateien für das Agent-Plugin
  • 1 Check Plugin: das Plugin untersucht auf Checkmk-Seite den XML-Output, den Robot als Ergebnis erzeugt hat.
  • 1 GUI Extension: Python-Definitionen für folgende WATO-Seiten:
    • RobotMK Discovery Level
    • RobotMK Service Configuration
    • RobotMK Bakery

Checkmk Bakery

Bakery-Rule: Zuweisen der Testausführung

Wir sind so weit: wir können uns nun an die Konfiguration der Testausführung machen. Die Checkmk Bakery leistet uns hier einen großen Dienst: per WATO-Regel legen wir einfach fest, welche Tests auf welchem Host laufen sollen und die Bakery erstellt hieraus fertige Installationspakete.

Der Reihe nach:

  • Öffne WATO -> Monitoring Agents -> Rules
  • Erzeuge eine neue Bakery Rule RobotMK (Linux, Windows):
  • Diese Rule soll nur auf den Testhost matchen, d.h. sorge dafür über eine entsprechende Folder- bzw. Hostzuweisung:

Wenn wir in dieser Rule nichts weiter einstellen, so gelten die RobotMK-Defaults: das RobotMK-Plugin würde auf wind10wp deployed werden und alle 15 Minuten alle Suites im Robot-Ordner ausführen. Das ist sicher nicht so gewünscht, weshalb wir weitere Einstellungen vornehmen: :::

  • Die Ausführung soll alle 5 Minuten erfolgen
  • Im Robot-Dir soll nur die Suite selenium_test ausgeführt werden (weitere Suites kannst Du über den Button "Add test suite" angeben).

Bakery-Rule: erlaubte Dateitypen

Die zweite wichtige Regel, die Du einrichten musst, heißt Limit script types to execute. Wende sie auf alle Hosts an, auf denen Robot-Tests ausgeführt werden sollen, denn ohne sie wird das Python-basierte RobotMK-Plugin nie funktionieren!

"Backen" neuer Installationsdateien

Jetzt ist auch der Button "Agents" in der Menüzeile oben orange gefärbt: er zeigt uns an, dass neue Agenten gebacken werden müssen.

Im folgenden startet der Button "Bake Agents" die Erzeugung aller Agenten-Installer. Wobei das nicht ganz korrekt ist: die Bakery ist so clever und erkennt Änderungen am Regelwerk. Es werden nur die Agenten neu gebaut, für die auch Änderungen anstehen.

Installation des neuen Agenten

Installiere nun die frisch gebackene Version des Agenten auf dem Windows-Host.

Stelle sicher, dass die Datei C:\ProgramData\checkmk\agent\bakery\check_mk.bakery.yml in etwa so aussieht:

global:
  enabled: true
  execute: exe bat vbs ps1 py
  port: 6556
plugins:
  enabled: true
  execution:
    - pattern: $CUSTOM_PLUGINS_PATH$\robotmk.py
      cache_age: 900
      async: yes
      timeout: 840

Außerdem solltest Du sehen, dass das Verzeichnis C:\ProgramData\checkmk\agent\plugins jetzt auch das robotmk.py-Plugin enthält.

Checkmk Inventarisierung

Es kann etwas dauern, bis der CMK Agent den Robot-Test ausführt. Ein manueller Inventarisierungslauf zeigt den neu erkannten Service:

Der Button "Fix all missing/vanished" fügt den neuen Service zum Set der überwachten Items hinzu.

Detail-Ansicht eines Robot-Tests

Öffne jetzt die Detail-Ansicht des neuen Robot-Services:

Hier fällt auf, dass der Service-Output nicht nur aus einer Zeile besteht, sondern aus einer hierarchischen Repräsentation des XML-Ergebnisses, das der Robot-Test im Filesystem des Windows-Hosts abgelegt hat.

Anhand der Kürzel am Zeilenbeginn siehst Du, um welchen Typ des Teilergebnisses es sich handelt. Das können sein:

  • Suites: [S]
  • Tests: [T]
  • Keywords [K]

Suite-Benennung: Du wunderst Dich vielleicht, warum unterhalb der Suite "Selenium Test" eine zweite Suite mit gleichem Namen existiert.

Der erste Suite-Name wird aus dem Namen des Verzeichnisses generiert, welches im Robot-Dir auf dem Windows-Client liegt.

Der zweite Suite-Name resultiert aus dem Robot-File selenium_test.robot, welches ebenfalls als Suite interpretiert wird. Eine Suite ist für Robot laut Definition eine Sammlung von einzelnen Tests (wie im Falle der Robot-Datei) und/oder weiteren Verzeichnissen (wie dem Verzeichnis selenium_test). 

Schwellwerte und Performancedaten

Checkmk wäre kein Monitoringsystem, wenn es nicht auch alarmieren könnte!

Im Falle von Robot Framework werden nicht nur Fehlschläge alarmiert (=wenn der komplette Service WARNING oder CRITICAL wird), sondern mit Hilfe meiner Entwicklung RobotMK auch Überschreitungen von vorher festgelegten Schwellwerten.

Für den Testfall "Tabelle Fachliteratur" soll nun exemplarisch eine maximale Laufzeit von 9 Sekunden gelten:

  • Dauert der Test länger als 12 Sekunden, so soll dies als CRITICAL gelten
  • Laufzeiten zwischen 9 und 12 Sekunden als WARNING

Wechsle hierfür in WATO und öffne die Ansicht "Host and service parameters":

Suche nach "robot" und erstelle eine neue RobotMK-Regel für "discovered services":

Innerhalb der Regel gibt es die Checkbox "Runtime thresholds". Hier lassen sich für Suites, Tests und Keywords Regex-Suchmuster einstellen, welche die jeweiligen WARN/CRIT-Thresholds sehr effizient auf alle passenden Unterknoten des Robot-Ergebnisses anwenden.

Info: Hier zeigt sich ein großer Vorteil von RobotMK: das Testergebnis kommt "neutral" am Checkmk-Server an und wird dort ausgewertet.

Da keinerlei Anpassung am Robot-Code erforderlich ist, können mit RobotMK theoretisch auch Ergebnisse von Robot-Tests überwacht werden, die z.B. Bestandteil von CI/CD-Pipelines sind.

Aktiviere nun die Checkbox für "Test thresholds" und gib Pattern und Schwellwerte ein, wie im nachfolgenden Screenshot gezeigt:

Performancedaten: Den gleichen Pattern kannst Du auch gleich im Punkt "Perfdata creation > Test perfdata" anwenden. Mit diesem Regex sorgst Du dafür, dass alle Tests, die mit "Tabelle" beginnen, einen Checkmk-Performance-Graphen erhalten:

Zusammenfassung

Du kannst diesen Moment feiern!

Denn mit Hilfe dieses Tutorials hast Du quasi die "Überholspur" genommen, um in professionelles End2End-Monitoring mit Checkmk einzusteigen.

Natürlich ist das erst der Anfang - alleine die Robot-Selenium-Bibliothek wäre ein eigenes Buch wert.

Und das Robot-Ökosystem hält für jeden Anwendungsfall die richtige Library bereit:

  • Webbasierte Tests
  • REST-API-Calls (sehr interessant z.B. um während eines Tests Drittsysteme zu prüfen)
  • Zugriff auf E-Mail-Postfächer
  • Bildpattern-basiertes Testen (Sikuli, ImageHorizon-Library)
  • Verwenden von AutoIT-Keywords
  • SSH-Zugriff
  • DataDriver: dynamische Parametrisierung mit Testdaten
  • Datenbank-Zugriff
  • und viele mehr.

Diese Vielfalt macht Robot zu einem Schweizer Taschenmesser für das Testen unternehmenskritischer Applikationen.

Viel Spaß beim Schreiben Deiner Robot-Tests!

Simon

P.S.: Sollten Dir für RobotMK nützliche Features einfallen, dann erstelle auf GitHub gerne ein Issue.

P.P.S.: Kennst Du mein Angebot für ein kostenloses Beratungsgespräch?


Enter your text here...

Simon Meggle


Selbständiger und unabhängiger Spezialist für die Themen IT-Monitoring (CheckMK), End2End-Testing/Testautomatisierung (RobotFramework) und Datacenter-Automatision/Ansible. Maintainer des RobotMK-Projekts (robotmk.org).

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
>