Test Automation

Test Automation

Teil eines jeden Entwicklungsprozesses ist die Testphase der entwickelten Funktionalität. Dies Prinzip sollte auch im Bereich der Automation genutzt wurden und ist wie in allen Entwicklungsbereichen ein wichtiger Bestandteil um die Implementierung mit den Anforderungen zu vergleichen und zu bestätigen, dass die gewünschte Stabilität weiterhin gewährleistet ist.

Der Begriff des Testens umfasst ein weiträumiges Gebiet. Dabei gibt es Unterschiede in der Qualität, Quantität und Ausführungstechnik. Die best4Automic Module dieser Kategorie beschäftigen sich mit der Testautomation.

Cucumber

Cucumber ist ein Behavior-Driven-Development-Werkzeug zur textuellen Spezifikation von Anforderungen an Software und zur automatisierten Überprüfung dieser Beschreibung auf ihre korrekte Implementierung. Diese Form der Spezifikation wird im Kontext der Testautomatisierung dafür genutzt Testfälle für Workflows zu definieren und diese automatisiert auszuführen.

Eine Definition (ein sogenanntes Feature) kann aus mehreren Szenarien bestehen. Jedes dieser Szenarien definiert einen Test Case. Alle Szenarien in einem Feature dienen dazu die beschriebene Funktionalität zu testen. Ein Test Case besteht aus drei Phasen:

  • Given: Überprüfung, ob die Umgebung den Erwartungen entspricht

  • When: Ausführung der Testschritte

  • Then: Überprüfung der Ergebnisse der Testausführung

Cucumber ist eine generische Definition, die unabhängig von verschiedenen Testverfahren ist. Für die spezielle Verwendung im Kontext der Automic Automation Engine® wurden Schritte in best4Automic definiert um Testfälle zu spezifizieren. Diese bestehen aus der Festlegung entsprechender Sätze und der umsetzenden Implementierungen, die die Ausführungen bzw. Überprüfungen übernehmen. Für die Zuordnung der Sätze zu den Implementierungen wird ein eindeutiger Schlüssel genutzt. Die Zuordnung ist in der Konfigurationsdatei cucumber.conf definiert. Ausgeliefert wird ein Beispiel, dass für alle existierenden Implementierungen einen entsprechenden Satz definiert. Die Sätze werden als reguläre Ausdrücke definiert, die für jede Implementierung eine genau definierte Menge an Schlüsselwörtern in benannten Gruppen definieren. Beispiel:

when-execute = Execute +@OBJECT_NAME@(:? +on date @DATE@)?(?<parameters> +with parameters)?(?: +do not wait longer than @TIME@)?

Der Schlüssel when-execute definiert einen Schritt, der Objekte in der Automic Automation Engine® aktivieren kann. Dabei kann optional ein logisches Datum übergeben werden und/oder eine Liste von PromptSet-Parametern. Der angegebene reguläre Ausdruck enthält dafür benannten Gruppen object, date und parameters. Die Gruppen object und date sind versteckt in den vordefinierten Variablen @OBJECT_NAME@ und @DATE@.

Beispiele für Cucumber-Definitionen, die diese Sätze nutzen sind im Verzeichnis examples der Distribution zu finden (siehe ta.Execute).

Vordefinierte reguläre Ausdrücke

  • @OBJECT_NAME@ - regulärer Ausdruck für Objektnamen, der die Gruppe object definiert

  • @ALIAS@ - regulärer Ausdruck für Aliase, der die Gruppe alias definiert

  • @OBJECT_VARIABLE@ - regulärer Ausdruck für AE-Script-Variablen, der die Gruppe variable definiert

  • @TASK_NAME@ - regulärer Ausdruck für Aufgaben, der die Gruppe task definiert

  • @VARIABLE@ - regulärer Ausdruck für Variablen, die bei einer Test Case-Ausführung zwischengespeichert werden, der die Gruppe attribute definiert

  • @REPORTTYPE@ - regulärer Ausdruck für Reporttypen, der die Gruppe reporttype definiert

  • @DATE@ - regulärer Ausdruck, der ein Datum der Form YYYY-MM-DD erkennt und als Gruppe date definiert

  • @TIME@ - regulärer Ausdruck, der zwei verschiedene Formate von Zeitangaben versteht. Einmal Zeitstempel der Form HH:MM:SS, der als Gruppe „time“ definiert wird. Oder relative Zeitangaben der Form ([0-9]+h)?([0-9]+m)?([0-9]+s)?. Die einzelnen Teile werden als Gruppen hours, minutes und seconds definiert.

  • @CONNECTION@ - regulärer Ausdruck für eine b4A Verbindung

  • @FOLDER@ - regulärer Ausdruck für einen Ordner/Pfad in einem Mandant

Formate

Cucumber selbst spezifiziert ein Textformat für die Definitionen, die auf die Syntax von Gherkin aufsetzen. Ein Beispiel sieht wie folgt aus.

Feature: Workflow to show a Cucumber example

    Scenario: Execute Masterworkflow with logical date and check preaggregate jobs
        Given Workflow PCK.BEST4AUTOMIC_CUCUMBER.JOBP.TEST with tasks
            |Tasks                                    |
            |PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST1(2)  |
            |PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST2(3)  |
            |PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST3(4)  |

        When Set values of variable PCK.BEST4AUTOMIC_CUCUMBER.VARA.SET_VALUES to
            |Key   |Value 1                 |
            |EMAIL |test-team@example.com   |

        And Execute PCK.BEST4AUTOMIC_CUCUMBER.JOBP.TEST(TEST_RUN) on date %{DATE:-1d:} do not wait longer than 30m
            |key            |value   |
            |action#        |add     |
            |pattern#       |*       |

        And Remember &ticket_number# from PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST2(3) of TEST_RUN as incident-number

        Then Task status of TEST_RUN is
            |Task                                     |Status    |
            |PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST1(2)  |ENDED_OK  |
            |PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST2(3)  |ANY_OK    |
            |PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST3(4)  |ENDED_OK  |

        And Check if PCK.BEST4AUTOMIC_CUCUMBER.JOBP.CHECK_INCIDENT for TEST_RUN ended successfully
            |key               |value              |
            |incident_number#  |%(incident-number) |

        And Comment of task PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST1(2) of TEST_RUN contains '*test*'

Wenn mehrere Szenarien in einem Feature definiert werden kann es sein, dass die Vorbedingungen der Tests sich ähneln. Anstatt diese bei jedem Szenario zu wiederholen können die gemeinsamen Vorbedingungen auch in einer Background Definition innerhalb des Feature ausgelagert werden.

Feature: Testing b4A modules

    Background: Given b4A options
        |Option       |Value       |
        |log-variants |REPORT      |
        |log-flags    |+MONOCHROME |
        |log-levels   |+DEBUG      |

    @tag1 @tag2
    Scenario: Check if b4A info.Search works and no translation is missing
        When Start b4A module info.Search
            |Parameter  |Value      |
            |connection |AE12-0010  |
            |folder     |TESTS      |
            |name       |TEST*      |

        Then Exitcode of b4A module info.Search is 0
        And Report of b4A module info.Search does not contain "![a-zA-Z.]+!"

    Scenario: Check if no translation is missing
        When Start b4A module info.Search
            |Parameter  |Value |
            |help       |true  |
        Then Report of b4A module info.Search does not contain "![a-zA-Z.]+!"

Zusätzlich ist es möglich Szenarien und Features mit Tags zu markieren. Jedes Tag muss mit einem @ anfangen. Werden mehrere Tags angeben so sind diese durch Leerzeichen voneinander zu trennen. Werden die Tests mit dem b4A Modul ta.Execute gestartet ist es möglich eine Liste von Tags zu übergeben. In diesem Fall werden nur Tests ausgeführt, die mindestens eins der angegebenen Tags besitzen. Eine weitere Option ermöglicht es eine Liste von Tags anzugeben, die zum Ausschluss von Tests führt. Auch dabei reicht es wenn ein Test eines der angegebenen Tags besitzt. Bei der Ausführung wird zuerst die Liste der Tags geprüft, die Tests zulassen und anschließend die Liste der Tags, die zum Ausschluss führen.

Alle b4A Module, die sich mit Cucumber beschäftigen, können Cucumber-Definitionen in eine strukturierte Dokumentation an einem Objekt überführen und dort gegebenenfalls auch die Testergebnisse protokollieren. Diese Struktur wird im folgenden erläutert.

_images/cucumber-structure.png

b4A Expressions

In den Testspezifikationen können b4A Expressions genutzt werden, um die Definitionen flexibel zu halten. Beispielsweise können Zeitpunkte oder Datumsangaben als b4A Expression angegeben werden, damit diese nicht zu einem einzigen Zeitpunkt stimmen, sondern sich dynamisch anpassen. Dafür können die die Funktionen %{DATE::} und %{TIME::} genutzt werden. Des Weiteren stehen folgende Attribute zur Verfügung:

  • b4A

    • connection: Name der b4A Verbindungen

    • client: Nummer des genutzten Mandant

    • system: Name des Automic Automation Engine® Systems

    • username: Benutzername der aktuellen Verbindung

    • department: Abteilung des aktuellen Benutzers

    • timezone: Zeitzone der aktuellen Verbindung

    • language: Sprache der aktuellen Verbindung

    • version: Versionsnummer der Automic Automation Engine®

Beispiel:

Verbindung: %(b4A.connection)
  System: %(b4A.system)
  Mandant: %(b4A.client))

Logik bei der Testverarbeitung

Bei der Ausführung der Testfälle wird zuerst die gesamte Testspezifikation eingelesen. Dabei werden die b4A Expressions zur Laufzeit ersetzt. Jeder Testschritt in der Testspezifikation wird dabei auf eine der bestehenden Implementierungen abgebildet. Wird zu einem Testschritt, also einem Satz, keine bestehende Implementierung gefunden, handelt es sich um eine fehlerhafte Testspezifikation. Das Einlesen wird dabei aber nicht abgebrochen. Es gibt lediglich einen Hinweis im Report. Danach werden die Szenarien nacheinander Schritt für Schritt abgearbeitet. Enthält ein Szenario dabei eine fehlerhafte Testspezifikation, so wird die Verarbeitung des Szenarios übersprungen. Die Fortschrittsanzeige zeigt bei einem solchen Szenario die Anzahl der erfolgreich eingelesenen Testschritte plus dem fehlerhaften als gescheitert an. Ist die Testspezifikation selbst korrekt, der Test läuft aber auf einen Fehler, dann wird die weitere Testverarbeitung für dieses Szenario abgebrochen, die korrekt gelaufenen Testschritte als erfolgreich angezeigt und nur der fehlerhafte als gescheitert. Die restlichen Testschritte dieses Szenarios werden dann übersprungen und mit dem nächsten Szenario fortgefahren.

Vorhandene Implementierungen

best4Automic bringt einen Satz von Implementierung mit, die entsprechend in der cucumber.conf mit einem Satz verknüpft sind. Diese können direkt im Auslieferungszustand genutzt werden ohne das Anpassungen notwendig sind. Jede Implementierung eines Schritts benötigt eine definierte Gruppe von Parametern, damit diese funktionieren kann. Diese werden im folgenden definiert. Dabei ist zwischen zwei Arten zu unterscheiden:

  • Parameter im Satz: einige Parameter sind direkt in den Sätzen enthalten. Diese müssen im regulären Ausdruck als benannte Gruppen definiert werden.

  • Parameter in tabellarischer Form: Diese Parameter werden in den Zeilen nach einem Satz in Form einer Tabelle angegeben. Dabei hat eine Tabelle immer eine Kopfzeile, die den einzelnen Spalten einen Titel gibt. In den folgenden Zeilen werden die Werte definiert. In allen Spalten außer der ersten können b4A Expressions genutzt, welche vor der Ausführung ersetzt werden.

given-workflow

  • Phase: Given

  • Beschreibung: Dieser Schritt Überprüft ob ein Workflow mit einer angegebenen Liste von Aufgaben verfügbar ist

  • Parameter

    • Satz

      • object: Name des zu prüfenden Workflows

    • Tabelle

      • Spalte 1: Aufgabenname in der Form: <Objektname>(<laufende Nummer>)

Beispiele

Given Workflow B4A.BASE.JOBP.TEST
Given Workflow B4A.BASE.JOBP.TEST with tasks

    | Task                   |
    | B4A.BASE.JOBS.TEST(2)  |
    | B4A.BASE.JOBS.TEST2(3) |

given-variable-contains

  • Phase: Given

  • Beschreibung: Dieser Schritt überprüft, ob eine Variable angegebene Keys mit den Werten enthält

  • Parameter

    • Satz

      • object: Name der zu prüfenden Variable

    • Tabelle: Die Spalten 3 bis 6 sind optional

      • Spalte 1: Key des Eintrags

      • Spalte 2: Wert 1

      • Spalte 3: Wert 2

      • Spalte 4: Wert 3

      • Spalte 5: Wert 4

      • Spalte 6: Wert 5

Beispiele

Given Variable B4A.BASE.VARA.TEST contains

    | Key  | Value 1  | Value 2 |
    | KEY1 | Wert 1   | Wert 2  |
    | KEY2 | Wert 1   | Wert 2  |
Given Variable B4A.BASE.VARA.TEST contains in connection AE123-0090

    | Key  | Value 1  | Value 2 |
    | KEY1 | Wert 1   | Wert 2  |
    | KEY2 | Wert 1   | Wert 2  |

given-object-exists

  • Phase: Given

  • Beschreibung: Dieser Schritt Überprüft, ob ein Objekt existiert oder auch nicht. Beide Varianten sind möglich.

  • Parameter

    • Satz

      • object: des zu prüfenden Objektes

      • negative, positive: Nur einer der beide kann existieren. Existiert negative wird geprüft, ob das Objekt nicht existiert

      • connection: Wird der Parameter angegeben, dann wird das Objekt in einer anderen Verbindung gesucht (optional)

Beispiele

Given Object B4A.BASE.STORE.TEST exists
Given Object B4A.BASE.STORE.TEST does not exist
Given Object B4A.BASE.STORE.TEST does not exist in connection AE123-0091

given-folder-exists

  • Phase: Given

  • Beschreibung: Dieser Schritt überprüft, ob ein Ordner in einer ausgewählten Verbindung existiert oder auch nicht. Beide Varianten sind möglich. Zudem kann geprüft werden, ob sich bestimmte Objekte in diesem Ordner befinden.

  • Parameter

    • Satz

      • folder: der zu prüfende Ordner

      • negative, positive: Nur einer der beiden kann existieren. Existiert negative wird geprüft, ob der Ordner nicht existiert

      • connection: Wird der Parameter angegeben, dann wird das Objekt in einer anderen Verbindung gesucht (optional)

      • objects: wird dieser Satzteil angegeben, dann werden die Objekte in der Tabelle in dem Ordner gesucht (optional)

    • Tabelle:

      • Spalte 1: Objektname

Beispiele

Given Folder B4A/TEST exists
Given Folder B4A/TEST does not exist
Given Folder B4A/TEST exists in connection AE123-0092
Given Folder B4A/TEST exists with objects

    | Object name         |
    | B4A.TEST.JOBS.TEST1 |
    | B4A.TEST.JOBS.TEST3 |

given-run-object

  • Phase: Given

  • Beschreibung: Dieser Schritt führt ein Objekt aus. Dabei kann ein logisches Datum gesetzt und Parameter per PromptSet übergeben werden

  • Parameter

    • Satz

      • object: Name des auszuführenden Objektes

      • alias: Alias für die Ausführung (optional)

      • date: logisches Datum (optional)

      • success: ist die Gruppe nicht leer, dann muss das Objekt erfolgreich enden

      • failure: ist die Gruppe nicht leer, dann muss das Objekt fehlschlagen

    • Tabelle:

      • Spalte 1: Name der Variable (ohne führendes &)

      • Spalte 2: Wert

Beispiele

Given Object B4A.TEST.JOBP.TEST ends successfully
Given Object B4A.TEST.JOBP.TEST fails
Given Object B4A.TEST.JOBP.TEST on date 2022-05-31 ends successfully
Given Object B4A.TEST.JOBP.TEST ends successfully

    | Variable       | Value |
    | B4AB_FIELD1_I# | TEST1 |
    | B4AB_FIEL21_I# | TEST2 |

given-resolve-agentgroup

  • Phase: Given

  • Beschreibung: Dieser Schritt kann auf die Existenz einer Agentengruppe prüfen und diese auflösen. Der aufgelöste Agent wird als Variable für b4A Expressions zur Verfügung stellt, so dass diese als Parameter weiter gegeben werden kann. Die Variable heißt genauso wie die Agentengruppe. Wenn der Modus der Agentengruppe ‚alle‘ gesetzt ist, dann wird nur der erste Agent in die Variable geschrieben.

  • Parameter

    • Satz

      • object: Name der Agentengruppe

Beispiele

Given Agent group B4A.TEST.HOSTG.TEST exists and can be resolved

given-check-sync

  • Phase: Given

  • Beschreibung: Dieser Schritt kann den Status und den Wert eines Sync Objekts auf mitgegebene Werte prüfen

  • Parameter

    • Satz

      • object: Name des Sync-Objekts

      • state: Erwarteter Status des Sync-Objekts

      • value: Erwarteter Wert des Sync-Objekts (optional)

Beispiele

Given Sync B4A.TEST.SYNC.TEST is in state RUNNING
Given Sync B4A.TEST.SYNC.TEST is in state RUNNING with value 5

given-b4a-options

  • Phase: Given

  • Beschreibung: In diesem Schritt können globale b4A Optionen für alle Szenarien eines Features gesetzt werden. Dieser Schritt wird im Background eines Features verwendet.

  • Parameter:

    • Tabelle:

      • Spalte 1: Name der Option

      • Spalte 2: Wert

Beispiele

Given b4A options

    | Option       | Value                    |
    | log-flags    | +MONOCHROME              |
    | log-variants | REPORT                   |
    | log-variants | ERROR,INFO,WARNING,DEBUG |

when-set-variable

  • Phase: When

  • Beschreibung: Dieser Schritt setzt angegebene Werte in einer statischen Variable. Diese werden hinzugefügt oder geändert.

  • Parameter

    • Satz

      • object: Name der zu prüfenden Variable

    • Tabelle: Die Spalten 3 bis 6 sind optional

      • Spalte 1: Key des Eintrags

      • Spalte 2: Wert 1

      • Spalte 3: Wert 2

      • Spalte 4: Wert 3

      • Spalte 5: Wert 4

      • Spalte 6: Wert 5

Beispiele

When Set values of variable B4A.TEST.VARA.TEST to

    | Key  | Value 1 | Value 2 |
    | KEY1 | Wert 1  | Wert 2  |
    | KEY2 | Wert 1  | Wert 2  |
When Set values of variable B4A.TEST.VARA.TEST to

    | Key  | Value 1 | Value 2 | Value 3 |
    | KEY1 | Wert 1  | Wert 2  | Wert 3  |
    | KEY2 | Wert 1  | Wert 2  | Wert 5  |

when-reset-variable

  • Phase: When

  • Beschreibung: Dieser Schritt setzt angegebene Werte in einer statischen Variable. Diese wird zuvor geleert. Werden keine neuen Werte angegeben, dann wird die Variable ausschließlich geleert.

  • Parameter

    • Satz

      • object: Name der zu prüfenden Variable

    • Tabelle: Die Spalten 2 bis 6 sind optional

      • Spalte 1: Key des Eintrags

      • Spalte 2: Wert 1

      • Spalte 3: Wert 2

      • Spalte 4: Wert 3

      • Spalte 5: Wert 4

      • Spalte 6: Wert 5

Beispiele

When Reset variable B4A.TEST.VARA.TEST to

    | Key  | Value 1 | Value 2 |
    | KEY1 | Wert 1  | Wert 2  |
    | KEY2 | Wert 1  | Wert 2  |
When Reset variable B4A.TEST.VARA.TEST

when-save-variable

  • Phase: When

  • Beschreibung: Dieser Schritt liest Objekt-Variablen einer Aufgaben von ausgeführten Workflows aus. Die Variable kann als Attribute für b4A Expressions gespeichert werden um später als Parameter übergeben zu werden.

  • Parameter

    • Satz

      • object: Name oder Alias des ausgeführten Objektes

      • task: Aufgaben von der die Objekt-Variable gelesen werden soll

      • attribute: Name des b4A Expression-Attributs

      • variable: Name der Objekt-Variable

Beispiele

When Execute B4A.TEST.JOBP.TEST(TEST1)

And Remember B4AT_INFO_O# from B4A.TEST.JOBS.TEST of TEST1 as info

And Execute B4A.TEST.JOBP.TEST2

    | Variable     | Value   |
    | B4AT_INFO_I# | %(info) |

when-remove-variable

  • Phase: When

  • Beschreibung: Dieser Schritt entfernt eine Liste von Einträgen aus einem Variable-Objekt.

  • Parameter

    • Satz

      • object: Name des Variable-Objektes

    • Tabelle

      • Spalte 1: Wert des zu löschenden Keys

Beispiele

When Remove values from variable B4A.TEST.VARA.TEST

    | Key  |
    | KEY1 |
    | KEY2 |

when-execute

  • Phase: When

  • Beschreibung: Dieser Schritt führt ein Objekt aus. Dabei kann ein logisches Datum gesetzt und Parameter per PromptSet übergeben werden

  • Parameter

    • Satz

      • object: Name der zu prüfenden Variable

      • alias: Alias für den Lauf (optional)

      • date: logisches Datum (optional)

      • time: Maximale Laufzeit des auszuführenden Objekts. Bei Erreichen der maximalen Laufzeit wird das auszuführende Objekt rekursiv abgebrochen und der Test schlägt fehl. (optional)

    • Tabelle

      • Spalte 1: Name der Variable (ohne führendes &)

      • Spalte 2: Wert (in dem Wert können b4A Expressions genutzt werden)

Beispiele

When Execute B4A.TEST.JOBP.TEST

    | Variable     | Value   |
    | B4AT_INFO_I# | testing |
When Execute B4A.TEST.JOBP.TEST do not wait longer than 10m
When Execute B4A.TEST.JOBP.TEST on date 2022-05-21

when-create-temp-file

  • Phase: When

  • Beschreibung: Mit diesem Schritt kann eine temporäre Textdatei erzeugt und optional deren Inhalt definiert werden. Nach dem Durchlauf aller Tests wird diese Datei automatisch gelöscht. Der Name der Datei kann über b4A Expressions in anderen Schritten des Tests genutzt werden.

  • Parameter

    • Satz

      • attribute: Name des b4A Expression Attributs über den der Dateiname referenziert werden kann

    • Tabelle

      • Spalte 1: eine Zeile, die in die temporäre Datei geschrieben wird

Beispiele

When Create a file remembered as temp_file

    | Line           |
    | The first line |
    | A second line  |
When Create a temporary file remembered as temp_file

when-cancel-task

  • Phase: When

  • Beschreibung: Dieser Schritt bricht entweder eine Aufgabe oder ein gestartetes Objekt ab. Optional kann der Abbruch auch rekursiv durchgeführt werden

  • Parameter

    • Satz

      • object: Name des abzubrechenden Objektes oder der Parent der abzubrechenden Aufgabe

      • task: Name der abzubrechenden Aufgabe (optional)

      • recursive: Ist die Gruppe nicht leer, dann wird der Abbruch rekursiv duchgeführt (optional)

Beispiele

When Cancel B4A.TEST.JOBS.TEST1(3) of B4A.TET.JOBP.TEST
When Cancel B4A.TET.JOBP.TEST recursively

when-wait-for-task

  • Phase: When

  • Beschreibung: Dieser Schritt wartet auf das Ende einer Aufgabe

  • Parameter

    • Satz

      • object: Name des Objektes zum die Aufgabe gehört

      • task: Name der Aufgabe auf die gewartet werden soll

      • time, hours, minutes, seconds: Entweder mit dem Parameter time oder einer Kombination aus den anderen drei kann definiert werden wie lange maximal gewartet werden soll (optional)

Beispiele

When Wait for task B4A.TEST.JOBS.TEST1(3) of B4A.TET.JOBP.TEST for 5m
When Cancel B4A.TET.JOBP.TEST recursively

when-wait

  • Phase: When

  • Beschreibung: Dieser Schritt wartet auf einen definierten Zeitpunkt

  • Parameter

    • Satz

      • date: Datum (YYYY-MM-DD) (optional)

      • time: fest definierter Zeitpunkt (HH:MM:SS)

      • hours, minutes, seconds: Angabe von Stunden, Minuten und/oder Sekunden, die gewartet werden soll.

Beispiele

When Wait until 1h 15m
When Wait until 15:52:00
When Wait until 2022-05-31 15:52:00

when-b4a

  • Phase: When

  • Beschreibung: Dieser Schritt startet ein b4A Modul mit den angegebenen Optionen

  • Parameter

    • Satz

      • module: Name des Moduls

    • Tabelle

      • Spalte 1: Name der Option

      • Spalte 2: Wert der Option

Beispiele

When Start b4A module pm.Install

    | Option     | Value      |
    | connection | AE123-0090 |
    | zip-file   | B4A.BASE   |

when-set-sync-state

  • Phase: When

  • Beschreibung: Dieser Schritt setzt den Status und den Wert eines Sync Objekts. Soll wirklich eine Action getriggert werden, so empfehlen wir dringend den Schritt when-set-sync-action.

  • Parameter

    • Satz

      • object: Sync Objekt, dessen Status und Wert gesetzt werden soll.

      • state: Status, der gesetzt werden soll.

      • value: Wert, um den der aktuelle Wert je nach Operator erhöht, verringert oder gleich gesetzt werden soll.

      • operator: Auswahl, ob der Wert um den in value angegebenen Wert erhöht (+), verringert (-) oder gleichgesetzt (0) werden soll.

Beispiele

When Set state of sync B4A.TEST.SYNC.TEST to RUNNING
When Set state of sync B4A.TEST.SYNC.TEST to RUNNING with operator = value 3

when-set-sync-action

  • Phase: When

  • Beschreibung: Dieser Schritt führt eine Action auf ein Sync Objekt aus. Lässt sich keine passende Action für den aktuellen Status des Sync Objekts finden, schlägt der Schritt fehl.

  • Parameter

    • Satz

      • object: Sync Objekt, auf das die Action ausgeführt werden soll.

      • action: Action, die ausgeführt werden soll.

Beispiele

When Run action RUNNING on sync B4A.TEST.SYNC.TEST

then-task-status

  • Phase: Then

  • Beschreibung: Dieser Schritt prüft die angegebenen Status von Workflow-Aufgaben, die bei when-execute gestartet worden sind

  • Parameter

    • Satz

      • object: Name oder Alias des Objektes zu dem die Aufgabe gehört. Der Alias muss zuvor mit when-execeute genutzt worden sein

    • Tabelle

      • Spalte 1: Name der Aufgabe

      • Spalte 2: Status (z.B. ENDED_OK, ANY_OK, ANY_ABEND, …)

Beispiele

Then Task status of B4A.TEST.JOBP.TEST is

    | Task                   | Status   |
    | B4A.TEST.JOBS.TEST1(2) | ENDED_OK |
    | B4A.TEST.JOBS.TEST2(3) | ANY_OK   |

then-task-queue

  • Phase: Then

  • Beschreibung: Dieser Schritt prüft ob Aufgaben eines Workflow eine angegebene Queue bei der Ausführung genutzt haben

  • Parameter

    • Satz

      • object: Name oder Alias des Objektes zu dem die Aufgabe gehört. Der Alias muss zuvor mit when-execeute genutzt worden sein

    • Tabelle

      • Spalte 1: Name der Aufgabe

      • Spalte 2: Name der Queue

Beispiele

Then Task queue of B4A.TEST.JOBP.TEST is

    | Task                   | QUEUE        |
    | B4A.TEST.JOBS.TEST1(2) | CLIENT_QUEUE |
    | B4A.TEST.JOBS.TEST2(3) | B4A_QUEUE    |

then-task-deactivated

  • Phase: Then

  • Beschreibung: Dieser Schritt prüft, ob die angegebenen Aufgaben bei when-execute deaktiviert waren

  • Parameter

    • Satz

      • object: Name oder Alias des Objektes zu dem die Aufgabe gehört. Der Alias muss zuvor mit when-execeute genutzt worden sein

    • Tabelle

      • Spalte 1: Name der Aufgabe

Beispiele

Then Task of B4A.TEST.JOBP.TEST is deactivated

    | Task                   |
    | B4A.TEST.JOBS.TEST1(2) |
    | B4A.TEST.JOBS.TEST2(3) |

then-check-object

  • Phase: Then

  • Beschreibung: Dieser Schritt prüft ob ein ausgeführtes Objekt erfolgreich beendet wurde. Als PromptSet-Parameter wird dem Objekt die Variable CHECK_RUNID# übergeben, die die RunID aus when-execute enthält.

  • Parameter

    • Satz

      • object: Name des auszuführenden Objektes

      • alias: Name oder Alias des Objektes, dass mit when-execute gestartet wurde

      • success: ist die Gruppe nicht leer, dann muss das Objekt erfolgreich enden

      • failure: ist die Gruppe nicht leer, dann muss das Objekt fehlschlagen

Beispiele

Then Check if B4A.TEST.JOBP.CHECK for B4A.TEST.JOBP.TEST ended successfully
Then Check if B4A.TEST.JOBP.CHECK for B4A.TEST.JOBP.TEST has failed
Then Check if B4A.TEST.JOBP.CHECK for B4A.TEST.JOBP.TEST on date 2022-05-28 ended successfully
Then Check if B4A.TEST.JOBP.CHECK for B4A.TEST.JOBP.TEST ended successfully

    | Variable     | Value       |
    | B4AT_INFO_I# | hello world |

then-task-has-comment

  • Phase: Then

  • Beschreibung: Dieser Schritt prüft ob die angegebene Aufgabe eine Zeichenkette in den Kommentaren hat

  • Parameter

    • Satz

      • object: Name oder Alias des Objektes zu dem die Aufgabe gehört. Der Alias muss zuvor mit when-execute genutzt worden sein

      • task: Name der Aufgabe

      • text: Muster des zu suchenden Textes in den Kommentaren

Beispiele

Then Comment of task B4A.TEST.JOBS.TEST(2) of B4A.TEST.JOBP.TEST contains .*hello world.*

then-b4a-exitcode

  • Phase: Then

  • Beschreibung: Dieser Schritt wertet den Exit-Code eines b4A Moduls aus

  • Parameter

    • Satz

      • module: Name des Moduls

      • exitcode: erwarteter Exit-Code des Moduls

Beispiele

Then Exitcode of b4A module pm.Install is 0

then-b4a-report

  • Phase: Then

  • Beschreibung: Dieser Schritt sucht in dem Bericht des b4A Moduls nach einem regulären Ausdruck

  • Parameter

    • Satz

      • module: Name des Moduls

      • not: existiert dieser Satzteil, dann darf der reguläre Ausdruck im Bericht nicht existieren

      • pattern: das zu suchende Muster

Beispiele

Then Report of b4A module pm.Install contains .*credentials not found.*
Then Report of b4A module pm.Install does not contain .*credentials not found.*

then-compare-variable

  • Phase: Then

  • Beschreibung: Dieser Schritt vergleicht eine zuvor mit when-save-variable gespeicherte Variable mit einem regulären Ausdruck

  • Parameter

    • Satz

      • attribute: Name des b4A-Expression-Attributs

      • pattern: regulärer Ausdruck mit dem der Wert verglichen werden soll

Beispiele

When Execute B4A.TEST.JOBP.TEST(TEST1)

And Remember B4AT_INFO_O# from B4A.TEST.JOBS.TEST of TEST1 as info

Then Compare variable info to .*testing.*

then-check-report

  • Phase: Then

  • Beschreibung: Dieser Schritt sucht nach einem regulären Ausdruck in den Reports einer Aufgabe

  • Parameter

    • Satz

      • object: Name oder Alias des Objektes zu dem die Aufgabe gehört. Der Alias muss zuvor mit when-execeute genutzt worden sein

      • task: Name der Aufgabe (optional, wenn nicht angegeben, wird der Report des obigen Objekts durchsucht)

      • reporttype: Typ des Reports, der durchsucht werden soll. Gültige Werte: REP, ACT, LOG, PLOG, POST

      • nomatch: existiert diese Frase, dann darf der reguläre Ausdruck im Bericht nicht existieren

      • pattern: regulärer Ausdruck, der das zu suchende Textfragment beschreibt

Beispiele

Then Check report ACT from B4A.TEST.JOBP.TEST for .*a pattern.*
Then Check report REP of B4A.TEST.JOBS.TEST1 from B4A.TEST.JOBP.TEST for .*a pattern.*
Then Check report REP of B4A.TEST.JOBS.TEST1 from B4A.TEST.JOBP.TEST for no match of .*a pattern.*

then-variable-contains

  • Phase: Then

  • Beschreibung: Dieser Schritt prüft, ob eine angegebene Variable die definierten Keys und Werte enthält

  • Parameter

    • Satz

      • object: Name der zu prüfenden Variable

    • Tabelle (die Spalten 3 bis 6 sind optional)

      • Spalte 1: Key des Eintrags

      • Spalte 2: Wert 1

      • Spalte 3: Wert 2

      • Spalte 4: Wert 3

      • Spalte 5: Wert 4

      • Spalte 6: Wert 5

Beispiele

Then Check variable B4A.TEST.VARA.TEST contains

    | Key  | Value 1 | Value 2 |
    | KEY1 | VALUE1  | VALUE2  |
Then Check variable B4A.TEST.VARA.TEST contains in connection AE123-0094

    | Key  | Value 1 | Value 2 |
    | KEY1 | VALUE1  | VALUE2  |

then-object-exists

  • Phase: Then

  • Beschreibung: Dieser Schritt Überprüft, ob ein Objekt existiert oder auch nicht. Beide Varianten sind möglich.

  • Parameter

    • Satz

      • object: Name des zu prüfenden Objektes

      • negative, positive: Nur einer der beide kann existieren. Existiert negative wird geprüft, ob das Objekt nicht existiert

      • connection (optional): Wird der Parameter angegeben, dann wird das Objekt in einer anderen Verbindung gesucht

Beispiele

Then Check object B4A.TEST.JOBP.TEST exists
Then Check object B4A.TEST.JOBP.TEST does not exist
Then Check object B4A.TEST.JOBP.TEST exists in connection AE123-0097

then-folder-exists

  • Phase: Then

  • Beschreibung: Dieser Schritt überprüft, ob ein Ordner in einer ausgewählten Verbindung existiert oder auch nicht. Beide Varianten sind möglich. Zudem kann geprüft werden, ob sich bestimmte Objekte in diesem Ordner befinden.

  • Parameter

    • Satz

      • folder: Name des zu prüfenden Objektes

      • negative, positive: Nur einer der beiden kann existieren. Existiert negative wird geprüft, der reguläre Ausdruck nicht enthalten ist

      • connection: Wird der Parameter angegeben, dann wird das Objekt in einer anderen Verbindung gesucht (optional)

Beispiele

Then Check folder B4A/TEST exists
Then Check folder B4A/TEST does not exist
Then Check folder B4A/TEST exists in connection AE123-0093
Then Check folder B4A/TEST exists

    | Object              |
    | B4A.TEST.JOBS.TEST1 |
    | B4A.TEST.JOBS.TEST2 |

then-xml-export-contains

  • Phase: Then

  • Beschreibung: Dieser Schritt überprüft, ob der XML-Export eines Objektes in einer angegebenen Verbindung einen regulären Ausdruck enthält (negativ sowie positiv ist möglich). Der reguläre Ausdruck kann sich auf mehrere Zeile in dem XML-Export beziehen.

  • Parameter

    • Satz

      • object: der zu prüfende Ordner

      • negative, positive: Nur einer der beiden kann existieren. Existiert negative wird geprüft, ob der Ordner nicht existiert

      • connection: Wird der Parameter angegeben, dann wird das Objekt in einer anderen Verbindung gesucht (optional)

      • pattern: regulärer Ausdruck, der das zu suchende Textfragment beschreibt

Beispiele

Then Check if XML export of object B4A.TEST.JOBS.TEST contains .*testing.*
Then Check if XML export of object B4A.TEST.JOBS.TEST does not contain .*testing.*
Then Check if XML export of object B4A.TEST.JOBS.TEST in connection AE123-0099 contains .*testing.*

then-set-sync-state

  • Phase: Then

  • Beschreibung: Dieser Schritt setzt den Status und den Wert eines Sync Objekts. Soll wirklich eine Action getriggert werden, so empfehlen wir dringend den Schritt then-set-sync-action.

  • Parameter

    • Satz

      • object: Sync Objekt, dessen Status und Wert gesetzt werden soll.

      • state: Status, der gesetzt werden soll.

      • value: Wert, um den der aktuelle Wert je nach Operator erhöht, verringert oder gleich gesetzt werden soll.

      • operator: Auswahl, ob der Wert um den in value angegebenen Wert erhöht (+), verringert (-) oder gleichgesetzt (0) werden soll.

Beispiele

Then Set state of sync B4A.TEST.SYNC.TEST to RUNNING
Then Set state of sync B4A.TEST.SYNC.TEST to RUNNING with operator = value 3

then-set-sync-action

  • Phase: Then

  • Beschreibung: Dieser Schritt führt eine Action auf ein Sync Objekt aus. Lässt sich keine passende Action für den aktuellen Status des Sync Objekts finden, schlägt der Schritt fehl.

  • Parameter

    • Satz

      • object: Sync Objekt, auf das die Action ausgeführt werden soll.

      • action: Action, die ausgeführt werden soll.

Beispiele

Then Run action RUNNING on sync B4A.TEST.SYNC.TEST

then-check-sync

  • Phase: Then

  • Beschreibung: Dieser Schritt kann den Status und den Wert eines Sync Objekts auf mitgegebene Werte prüfen

  • Parameter

    • Satz

      • object: Name des Sync-Objekts

      • state: Erwarteter Status des Sync-Objekts

      • value: Erwarteter Wert des Sync-Objekts (optional)

Beispiele

Then Sync B4A.TEST.SYNC.TEST is in state RUNNING
Then Sync B4A.TEST.SYNC.TEST is in state RUNNING with value 5

then-workflow

  • Phase: Then

  • Beschreibung: Dieser Schritt Überprüft ob ein Workflow mit einer angegebenen Liste von Aufgaben verfügbar ist

  • Parameter

    • Satz

      • object: Name des zu prüfenden Workflows

    • Tabelle

      • Spalte 1: Aufgabenname in der Form: <Objektname>(<laufende Nummer>)

Beispiele

Then Workflow B4A.BASE.JOBP.TEST
Then Workflow B4A.BASE.JOBP.TEST with tasks

    | Task                   |
    | B4A.BASE.JOBS.TEST(2)  |
    | B4A.BASE.JOBS.TEST2(3) |

then-check-messages

  • Phase: Then

  • Beschreibung: Dieser Schritt durchsucht die Meldungen und prüft dabei auf die Nummer sowie auf einen regulären Ausdruck. Gesucht wird in Nachrichten, die seit dem Start des Tests gemeldet wurden. Des Weiteren werden nur Nachrichten des Benutzers selbst betrachtet.

  • Parameter

    • Satz

      • negative, positive: Nur einer der beiden kann existieren. Existiert negative wird geprüft, ob die Meldung nicht existiert

      • number: Nummer der Meldung. Diese kann mit dem führenden Buchstaben U oder ohne angegeben werden.

      • pattern: Definiert den regulären Ausdruck, der auf den Meldungstext angewendet wird.

Beispiele

Then Check if message exists with number U00011000 and pattern .*test.*
Then Check if message does not exist with number U00011000 and pattern .*test.*

Module