Dialog: Unittest hinzufügen
Funktion: Der Dialog fügt einen neuen Testbaustein für den IEC-Unittest ein.
Aufruf:
Tabelle 84. Implementierung
Name der POU | Der Name des zu generierenden Testfall-Funktionsbausteins. Später kann die Testfall-Ausführung bedingt anhand des Namens von Testfällen gesteuert werden. Außerdem wird der Name im Testreport angezeigt. |
Typ | Extend TM.Testcase (empfohlen) Diese Vorlage bietet ein einfach zu verwendendes Schema für einen einzelnen Testfall. Sie besteht aus einer Reihe von Methoden und Ausgängen, um testspezifische Aufgaben auszuführen. Wenn der Test ausgeführt wird, werden die Methoden der POU in der folgenden Reihenfolge aufgerufen: Setup() (optional, einmaliger Aufruf) bietet die Möglichkeit, Prüfling und Test vorzubereiten.
Execute() (obligatorisch, wird in der Schleife aufgerufen) dient dazu, den Prüfling zu stimulieren und seine Ergebnisse zu überprüfen. Die Methode wird solange aufgerufen, bis sie TRUE zurückgibt. Um Fehlschlag oder Erfolg zu melden, werden Assert-Funktionen verwendet. Der VAR_OUTPUT Info der POU kann zusätzlich verwendet werden, um textuelle Details in den Testbericht aufzunehmen, wird aber möglicherweise wechelseitig durch Assert-Funktionen überschrieben.
Teardown() (optional, einmaliger Aufruf) bietet die Möglichkeit, den Test zu bereinigen und zurückzusetzen, nachdem er beendet ist.
Abort(): Wird der Testbaustein abgebrochen indem die VAR_INPUT xAbort auf TRUE gesetzt wird, wird diese Methode solange wiederholt aufgerufen, bis sie TRUE zurückgibt. Dies bietet die Möglichkeit, einen laufenden Test auch im Falle eines Abbruchs zu bereinigen. Das Testelement IEC Unittest bricht einen Testbaustein beispielsweise dann ab, wenn der Timeout für den Testfall abgelaufen ist.
Extend TM.BaseMultiTest
Dieses Schema ist für die Implementierung einer Reihe von Testfällen geeignet. Die Schnittstelle des Schemas (siehe TM.BaseMultiTest) wird in verschiedenen kontextuellen Phasen mehrfach für jeden einzelnen Testfall aufgerufen. Die Vorlage weist den Methoden IFBCommand von CBM.ETrigA die folgenden Aufgaben zu: prvStart() (optional, einmaliger Aufruf) bietet die Möglichkeit, Prüflinge und Test vorzubereiten.
prvCyclicAction() (obligatorisch, wird in der Schleife aufgerufen) ist die Stelle, um den Prüfling zu stimulieren und seine Ergebnisse zu überprüfen. Diese Methode wird in verschiedenen kontextuellen Phasen mehrfach für jeden einzelnen Testfall aufgerufen:
Vor der eigentlichen Testausführung (Eingang xGetTestInfo := FALSE) werden Informationen über die einzelnen Testfälle der POU gesammelt. In dieser Phase hat der Eingang xGetTestInfo den Wert TRUE. Mit dem Wert -1 am Eingang diTestCaseIndex, wird die Anzahl n der Testfälle am Ausgang diTestCaseCount abgefragt. Dann gibt es eine Folge von Abfragen, die die Werte des Eingangs diTestCaseIndex von 0 bis n-1 variiert, um die Informationen der Ausgänge TestCaseName, TestCaseCategories und diTestCaseTimeout für jeden Testfall abzufragen. Jede Abfrage wird vom Test Manager in einem geschlossenen Zyklus aus xEcecute := TRUE, Warten auf xDone = TRUE oder xError = TRUE und Rücksetzen des Eingangs xExecute auf FALSE durchgeführt. Der Test wird somit als eine Folge von geschlossenen Zyklen (xExecute bis xDone oder xError) ausgeführt, die den Eingang diTestCaseIndex von 0 bis n-1 variiert. Dabei wird der Eingang xGetTestInfo immer auf dem Wert FALSE belassen. Um Fehlschlag oder Erfolg zu melden, werden hier Assert-Funktionen verwendet. Der VAR_OUTPUT Info der POU kann zusätzlich verwendet werden, um textuelle Details in den Testbericht aufzunehmen, wird aber möglicherweise wechelseitig durch Assert-Funktionen überschrieben.
prvAbort() wird wiederholt aufgerufen, wenn der Eingang xAbort der POU TRUE ist, und bis die VAR xAbortInProgress der POU auf FALSE gesetzt wird. Dies bietet die Möglichkeit, einen laufenden Test in jedem Zustand zu bereinigen.
|
Optiomnale Methoden hinzufügen | Fügt entsprechend dem Typ die oben als optional markierten Standardmethoden zum Einrichten, Abbrechen und Rücksetzen des Funktionsbausteins hinzu. |
Implementierungsvorlage hinzufügen | Füllt alle generierten Methoden mit einer Beispielimplementierung eines Testfalls, die mithilfe von "TODO"-Kommentaren ersichtlich macht, wo die eigene Testlogik eingesetzt werden sollte. Diese Option wird empfohlen, wenn ein Testfall von grundauf neu geschrieben wird |
Erklärende Kommentare hinzufügen | Fügt in den Deklarationsteil des Testfall-Funktionsbausteins und jeder seiner Methoden einen Code-Kommentar ein, der die grundlegende Funktionsweise des Bausteinmusters erklärt. Diese Option wird empfohlen, wenn das Muster noch nicht bekannt ist. |
Tabelle 85. Optionale Attribute
Testfallname | Ein Name für den Testfall, der dann statt des Namen der POU verwendet wird. Für weitere Informationen siehe: Pragmas in Testbausteinen |
Testfallkategorie | Eine kommagetrennte Liste von Kategorien, zu denen der Testfall gehört. Später kann die Testfallausführung bedingt anhand der Kategorien von Testfällen gesteuert werden. Für weitere Informationen siehe: Pragmas in Testbausteinen |
Timeout Testfall | Die Zeit, die der Testfall zur Ausführung brauchen darf. Wenn der Testfall länger braucht, wird er abgebrochen und gegebenenfalls die Abort-Methode aufgerufen. Mit Wert 0 kann das Timeout auf unendlich gesetzt werden. |
Testfallgruppe | Fügt im Deklarationsteil das Attribut testcasegroup hinzu |
Timeout Tesfallgruppe | Fügt im Deklarationsteil das Attribut testcasegrouptimeout hinzu |