Lade...
 

Testframework

Testframework

Beschreibung

Diese App (im folgenden auch als QM App bezeichnet) ist Teil des CyberEnterprise Qualitätsmanagements. Mittels bestimmt aufgebauter Excel Dateien können manuelle Eingaben von Benutzern simuliert und die Ergebnisse dieser Eingaben automatisiert überprüft werden.

(Im classic Evaluationssystem liegen Testframework Excel Dateien im Verzeichnis ..\Projects\TestFrameworks\Data\ zur Verfügung.)

Das Format dieser Excel Dateien sieht folgendermaßen aus:

#Flags #Kommentar #ExecuteString #KommandoString #Variable Test-Zugriffsausdrücke
           
  • Flags (auch Großschreibung zugelassen)
    Flags Beschreibung
    rem; kommentiert eine Zeile aus
    break;

    führt zum Abbruch der Verarbeitung
    sleep; folgende Zeilen werden nicht ausgeführt bis zum nächsten "wakeup;"-Flag. Dies eine einfach art um Zeilen in einem Testframework auszukommentieren.
    wakeup; folgende Zeilen werden wieder ausgeführt.
    load; es können andere Testframeworks mit einbezogen können um beispielsweise Teile anzulegen. Es ist allerdings nicht dazu gedacht mehrere Auswertungen aneinander zu hängen da beim Flag "load" keine Auswertungsdateien geschrieben werden und keine Fehler geloggt werden
    goto:Zeilennummer:Bedingung goto Anweisung:
    Die Syntax sieht wie folgt aus: goto:19:var 3 <   Der erste Teil "goto" definiert die GoTo Anweisung. Dann folgt die Zeilennummer, in welche gesprungen werden soll und der letzte Teil (z.B. var 3 <, d.h. der Wert einer vorher definierten Variablen var sollte kleiner 3 sein) definiert die Bedingung, unter der die Sprungmarke angefahren wird. Nur wenn diese Bedingung TRUE zurückgibt wird die GOTO Anweisung ausgeführt, um Endlosschleifen zu vermeiden.
    idle(Wartezeit); Die Abarbeitung des Testframeworks wird um die Wartezeit in ms angehalten. Das System ist in dieser Wartezeit idle. Damit kann das Verhalten des Systems beim Warten auf Benutzereingaben simuliert werden.
        
  • Kommentar: Hier können beschreibende Angaben zur Zeile gemacht werden.
     
  • ExecuteString (unten Spalte 1 genannt): Der hier angegebene String wird als String auf den Stack gelegt. Die hier gemachten Angaben dienen ausschließlich dazu, über die in der nächsten Spalte angegebene TEST_... oder EXEC_... Message in einem Zielmodul per Execute ausgeführt zu werden. Fehlt jedwede TEST_... oder EXEC_... Message, führen die Angaben in dieser Spalte zu keinem Ergebnis. (Hinweis: Alle AppsWarehouse Apps "verstehen" eine TEST_... bzw. EXEC_ Message, die in der jeweiligen App nur das Kommando "Execute" ausführen lässt.)
  • KommandoString (unten Spalte 2 genannt): Der hier angegebene String wird direkt in der QM App per Execute ausgeführt. Ein eventuell in der Spalte1 angegebener String wird entsprechend als String Stack Eintrag verarbeitet. (Weiter unten sind Beispiele aufgeführt)
     
  • Variable (unten Spalte 3 genannt): Mit der Message QM_ROW_EXECUTED kann mittels des ExecuteString und seiner Abarbeitung im Zielmodul ein dort vorhandener Stackeintrag an die QM App zurückgeschickt werden. Dieser Stackeintrag wird dann in der in dieser Spalte angegebene Variable gespeichert.
  • Test-Zugriffsausdrücke: Ab dieser Spalte können Zugriffsausdrücke angegeben werden. Die vorher in der QM App definierten Variablen dienen als Ausgangspunkte für die Zugriffsausdrücke. Mittels dieser Zugriffsausdrücke werden über die Variablen die Werte ermittelt, die dann mit den in der Excel Datei in den Zeilen hinterlegten Werte verglichen werden. Stimmen diese Werte nicht überein, wird eine Fehlermeldung ausgegeben. 
    Syntax:   
    Zugriffsausdruck
    Beispiel: purchaseOrder
    supplier.uniqueID

Es dürfen keine Leerzeilen in der Testdatei enthalten sein! Deshalb bitte darauf achten, in gewünschte Leerzeilen immer in der ersten Spalte (#Flags) ein REM; zu schreiben. Dann funktioniert es auch ohne, dass die letzte Zeile nicht mit ausgeführt wird.

Ein paar Hinweise zur Benutzung und Beispiele:

Nehmen wir an, wir wollen eine Bedarfsanforderung erstellen und hieraus eine Bestellung erstellen.

So geht man in folgenden groben Schritten vor:

  1. Leere Bedarfsanforderung erstellen
  2. Bedarfsanforderung über Speichern Button speichern
  3. Teilenummer in Bedarfsanforderungsposition (die sich beim Speichern des Kopfbeleges automatisch öffnet) schreiben und SELECT Message an Teilenummernfeld schicken
  4. Menge ändern und Position über Speichern Button speichern
  5. Kopfbeleg buchen
  6. Variable der Bedarfsanforderungsposition an unsere QM App zurückschicken
  7. Bestellung über übliche Message erstellen

Es stellen sich folgende zu lösende Problematiken:

  1. Wie schicke ich eine Variable an die QM App zurück?
  2. Wie schicke ich meine Bedarfsanforderungsvariable aus der QM App an eine andere App über die Testmessage, die ja nur einen Execute Parameter hat?

..und dazu die Lösungen:

  1. SendMsg(QM_ROW_EXECUTED) in Spalte 1, SendMsg(TEST_PURCHASE_REQUISITION_ITEM) in Spalte 2 und die Zielvariable, in der wir diese Position in der QM App halten wollen also purchaseRequisitionItem in Spalte 3.
    Die QM App empfängt diese Antwortmessage und speichert sie immer in der selben temporären Variable. Dann wird das Objekt aus der temporären Variable in die gewünschte Variable übertragen.
  2. Folgende Ausführungsfolge führt zum Ergebnis, wenn man zum Beispiel die Bedarfsanforderungsposition als Vorgänger in die Bestellung ziehen will:
    Spalte 1: Widget(EditWin, predecessors) SendMsg(PURCHASE_REQUISITION_ITEM_SELECTED, DIRECT)
    Spalte 2: purchaseRequisitionItem Swap SendMsg(TEST_PURCHASE_ORDER_ITEM)
    Durch das Swap wird die Variable purchaseRequisitionItem hinter den auszuführenden String gestellt, sodass sich folgende Anweisung ergibt:
    purchaseRequisitionItem "Widget(EditWin, predecessors) SendMsg(PURCHASE_REQUISITION_ITEM_SELECTED, DIRECT)" SendMsg(TEST_PURCHASE_REQUISITION_ITEM)
    Es liegen beim Auslösen der Testmessage also 2 Parameter auf dem Stack: Unsere Bedarfsanforderungsposition und auf dem TOP der in der Ziel App per Execute auszuführende String.

In jedem Branch ist mindestens eine blanko-Datei und eine vollständig funktionierende "Beispiel" Testdatei eingecheckt. Man findet diese Test Dateien im Verzeichnis: \AppsWH\\data\QS

Zur Benutzung der BREAK; und der REM; Anweisung folgender Hionweis:
Diese Anweisung bezieht sich immer genau auf den Beginn der entsprechenden Zeile: Das heißt, genauso wie man mit REM; genau die Zeile auskommentiert, bricht man mit BREAK; auch genau VOR Ausführung dieser Zeile ab!
Die Zeile, in der sich das BREAK; befindet, wird also nicht mehr ausgeführt.

Noch ein Tipp: Fenster-Testmessages

Soll eine Prozedur per EXEC Message ausgeführt werden, welches Zugriffe auf Widgets beinhaltet, die ohne führendes EditWin, also beispielsweise GetObject(, predecessors) geschrieben sind, so kann bei Bedarf eine lokale Test Message nach folgendem Schema erstellt werden: Erster Teil: Testmessage (TEST_ORDER), zweiter Teil Fenstername: (EDIT_WIN)
= TEST_ORDER_EDIT_WIN
In der App, die die Test Message empfängt, wird eine weitere Testmessage definiert:
Msg(TEST_ORDER_EDIT_WIN)
Dann wird NUR in der Actionlist des Fensters (hier EditWin) diese Message abgefangen und nur durch ein Execute ergänzt:
TEST_ORDER_EDIT_WIN: Execute

So kann man nun auch Prozeduren aus dem Fenster direkt per Execute aufrufen, ohne dass man in allen Prozeduren das EditWin (den Kontext also) hinzufügen muss, was manchmal sogar falsch wäre (falls die Prozedur von verschiedenen Fenstern aufgerufen wird!).

Allerdings muss dann der Aufruf der Message ein weing anders aussehen:
Spalte 1: "SaveObject" SendMsg(TEST_ORDER_EDIT_WIN)
Spalte 2: SendMsg(TEST_ORDER)

Der in der Fenster-Testmessage auszuführende String muss noch mal in Anführungszeichen gesetzt werden, da er sonst bereits vom ersten Execute (TEST_ORDER) ausgeführt werden würde. Mit Anführungszeichen wird er ganz normal als String behandelt und (ohne Anführungszeichen) auf den Stack geladen. Da die Anweisung SendMsg(TEST_ORDER_EDIT_WIN) nicht in selbigen steht, wird diese Anweisung ausgeführt und schickt den vorher geladenen String als nächsten Ausführungsbefehl an die Fenster-Testmessage.

Da nicht in jeder App eine solche Message nötig ist, und diese auch auf keinen Fall die App triggern sollte (sonst gäbe es wohlmöglich viele doppelte Ausführungen der Tests, weil vielleicht noch Kundenableitungen von diesen Apps erstellt sind) und es nur eine definierte Schnittstelle zu einer App geben soll,  ist diese Message bei Bedarf nach diesem Schema nachzutragen.

Häufige Fehler, die bei der Erstellung einer Testdatei passieren:

LAZY_CREATOR: Wird eine Position eines Beleges in einer Variable in der Testdatei gehalten und diese in einer Spalte zur Auswertung eines Slots o.ä. benutzt, so erscheint die Fehlermeldung "Objekt noch nicht erzeugt", obwohl diese Position bereits mit dem Kopfbeleg verbunden wurde. Da der gesamte Testprozess über die ganze Testsuite in einer Haupttransaktion geschieht, wird dieser LazyCreator nicht in ein persistentes Objekt umgewandelt. Dies muss in der Testdatei über den OBJECT Manager geschehen: position Kopfbeleg GetManager(OBJECT) Call(Instantiate) -> Variable.
Ganz wichtig ist hierbei, dass das Ergebnis des Instantiate in die Variable der Position zurück gespeichert wird. Sonst weist der alte Variablenpointer immer noch auf den LAZY_CREATOR.

Beispiel: orderItem order GetManager(OBJECT) Call(Instantiate) -> orderItem

Wird orderItem in einer Spalte benutzt, so muss diese Variable, solange sie noch den LazyCreator beinhaltet, anders benannt werden. Denn solange diese noch auf den LazyCreator zeigt, schlagen die Versuche in den Spalten wie zum Beispiel orderItem::sales.pricePer mit einer Fehlermeldung in der QM App fehl.
ALSO: Variable orderItem erst mal in orderItemTmp umbenennen und erst nach dem Instantiate in die Variable orderItem speichern. Dann kann auch die Spalte vernünftig ausgewertet werden.

Aufrufen mehrerer Testframeworks

Aufruf aus der QM App:
    - Mehrfachselektion von Dateien
    - Ordner auswählen um alle darin befindlichen Tests auszuführen

Aufruf mit einer Batch Datei:

Der genaue Pfad der gewünschten Dateien und Ordner wird in Variablen gespeichert und zu einer großen Zeichenkette zusammengesetzt.
Auszug einer Beispiel Datei:

Die Leerzeichen in den Dateinamen müssen durch "***" ersetzt werden:

SET STRING_1=%CX_QS_PATH%\Demo\Testdatei***Mustername1***-***Demo.xls (Testdatei Mustername1 - Demo.xls)
SET STRING_2=%CX_QS_PATH%\Demo\Testdatei***Mustername2***-***Demo.xls
SET STRING_3=%CX_OS_PATH%\Demo\Gueltigkeit

Die einzelnen Zeichenketten werden zu einer zusammengesetzt und sind durch "###" getrennt:

SET CX_ALL_TESTS=%STRING_1click="javascript:toggle_dynamic_var("###");" title="Click to edit dynamic variable: ###">No value assignedSTRING_2No value assignedSTRING_3%

Der Aufruf der Datei welche die Tests startet mit der Variable CX_ALL_TESTS als ÜbergabeParameter:

call %CX_ROOTDIR%\projects\Start_Testframework.bat %CX_ALL_TESTS%

Allgemeines:

Die ausgewählten Dateien und Ordner werden zu einer Zeichenkette zusammengesetzt und als Übergabeparameter für die aufrufende Batch Datei benutzt. In dieser wird die Zeichenkette als Umgebungsvariable "CX_TESTFRAMEWORKS" gespeichert. Es wird eine neue CyberEnterprise Instanz geöffnet, welche die Zeichenkette aus der Umgebungsvariable ausliest, um den ersten Test aufzurufen. Dieser Test wird aus der Zeichenkette entfernt und wenn dieser beendet ist, wird erneut die Batch Datei aufgerufen, mit der neuen Zeichenkette als Übergabeparameter. Somit laufen die Testframeworks jeweils in einer eigenen  CyberEnterprise Instanz hintereinander ab.

Falls Fehler auftreten solten, werden Error Dateien erzeugt, allerdings ohne die sonst übliche Abfrage, ob ins Testverzeichnis gewechselt werden soll.

Funktionalität

 

Eingabefenster

In diesem Fenster können Optionen für das Ausführen der Test Frameworks gesetzt, Test Frameworks ausgewählt und gestartet werden.

Menü
Menüpunkt Beschreibung

Wiederholen

Direkt vorher duchgeführte Tests können wiederholt werden.

 

Optionen Gruppe

Felder
Feld Beschreibung

: Tests nur ausführen (keine Prüfung von Ergebniswerten)

Ist diese Option gesetzt, werden die Testframeworks durchgeführt, ohne die Ergebniswerte mit den in den Excel Zellen hinterlegten Werten zu vergleichen.

: Variablen vor neuem Testbeginn löschen

Ist diese Option gesetzt, werden die von vorherigen Tests eventuell bereits gesetzten Variablen vor Ausführung des nächsten Tests gelöscht.

 

Ausführungslog

Felder
Feld Beschreibung

: Zeileninfos

Ausgabe der zuletzt ausgeführten Zeile einer Test Framework Excel Datei.

: Variablen

Liste der durch die Testframeworks erzeugten und gesetzten Variablen.

Verwandte Themen

Technische Dokumentation

 

Testframework App

Modulname

testFrameworkEdit.app

Security

Neben der Beschränkung der Zugriffsrechte über die Klasse und deren Datenfelder kann das Modul über einige der empfangenen Messages in seiner Nutzung beschränkt werden.

Empfangene Messages
Message Parameter Funktion Security
EDIT_TEST_FRAMEWORK      
RUN_TEST_FRAMEWORK Name einer Testframework Excel Datei    
LOAD_TEST_FRAMEWORK_DATA Name einer Testframework Excel Datei    

 

Operativer Betrieb