Schema für Mehrfachtestbausteine
Testbaustein definieren
Wenn ihr Test aus mehreren gleichförmigen Testfällen besteht, können Sie statt vieler Einzeltestbausteinen einen Mehrfachtestbaustein implementieren. Mehrfachtestbausteine folgen ähnlich, wie Testbausteine für einzelne Testfälle, einem Schema und sind mit dem Attribut {attribute 'test' := 'multitest'} gekennzeichnet. Weitere Merkmale des Schemas sind in der Schnittstellenkonvention zu finden. Sie können das Schema leicht einhalten, indem Sie den Assistenten zum Erstellen eines Testbausteins nutzen.
Für weitere Informationen siehe Beispiel Examples.IecUnitTest
Unterstützung bei der Implementierung
Wenn Sie mit dem Assistenten einen Unittest hinzufügen, wird Ihnen eine Beispielimplementierung vorgeben. Der Assistent erstellt ein funktionierendes Beispiel, sofern Sie die Option Implementierungsvorlage hinzufügen aktivieren.
Grundlegende Testfall-Funktion
Vor der eigentlichen Testausführung (xGetTestInfo := FALSE) werden Informationen über die einzelnen Testfälle des Bausteins eingesammelt. 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 erfolgt eine Sequenz von Abfragen, die die Werte des Eingangs diTestCaseIndex von 0 bis zur Zahl n-1 variiert, um die Informationen sTestCaseName, sTestCaseCategories und diTestCaseTimeout für jeden Testfall anzufordern. Jede Abfrage erfolgt durch den Test Manager in einem in sich geschlossen Zyklus aus xExecute := TRUE, dem Warten auf xDone oder xError und dem Rücksetzen des Eingangs xExecute auf FALSE.
Die Testausführung erfolgt dann über eine Sequenz von geschlossenen Zyklen (xExecute zu xDone oder xError), die den Eingang diTestCaseIndex von 0 bis zur Zahl n-1 variieren und dabei aber den Eingang xGetTestInfo immer auf dem Wert FALSE belassen. Über den Ausgang sInfo kann eine Beschreibung für den Testreport ausgeben werden. Im Fehlerfall (xError := TRUE) kann über eError der Fehlercode und über sError eine Beschreibung der Fehlersituation in den Testreport übernommen werden. Dabei wird, wenn möglich, der symbolischen Namen des Fehlercodes in das Protokoll übernommen.
Ein mit dem Assistenten erstellter Testbaustein kapselt dieses Verhalten in das Schema des Basis-Bausteins TM.BaseMultiTest (definiert in der Bibliothek IEC Unit Test). Für die Ausführung der Testlogik steht die Methode prvCyclicAction als Rahmen zur Verfügung, in der der Prüfling stimuliert werden soll. Für das Prüfen des Ergebnisses und das Melden von Fehlern stehen des Weiteren einfach zu verwendende Assert-Funktionen zur Verfügung.
Für weitere Informationen siehe: Einzeltestbaustein implementieren
Timeouts in Testbausteinen
Mit Timeouts definieren Sie maximale Zeitspannen für die Ausführung des Tests. Bei einer Überschreitung wird mit einem Fehler abgebrochen. Die verbleibenden Testfälle werden übersprungen. Die Timeouts definieren Sie im Assistenten im Dialog Unittest hinzufügen.
Testfallname
Mit der optionalen Angabe eines Testfallnamens können Sie dem im Testbaustein implementierten Testfall einen alternativen Namen (Standard: POU-Name des Testbausteins) geben. Diesen Namen können Sie im Testelement IEC-Unittest zur Auswahl/Ausnahme des Testfalls wie den POU-Namen verwenden. Im Testreport wird der Testfallname gegebenenfalls angezeigt.
Für weitere Informationen siehe: Pragmas in Testbausteinen
Testfallkategorie
Testfälle können in Kategorien organisiert werden, mit denen sie gesammelt im Testelelement IEC-Unittest ausgewählt/ausgenommen werden können. Ein Testfall kann mehreren Kategorien angehören.
Für weitere Informationen siehe: Pragmas in Testbausteinen
Schnittstellenkonvention
Die Schnittstellenkonvention wird von einem Testbaustein, der mit dem Assistenten erzeugt wurde und das Schema des TM.BaseMultiTest einhält, automatisch befolgt und vom Testelement IEC Unittest automatisch ausgewertet. Die Schnittstellenkonvention ist daher dann interessant, wenn ein Testbaustein manuell getriggert werden muss, beispielsweise zur Fehlersuche. Zusätzlich gelten die Pragmas in Testbausteinen.
Name | Typ | Gültigkeitsbereich | Optional | Beschreibung |
|---|---|---|---|---|
|
|
| Startet und kontrolliert die Ausführung des Bausteins | |
|
|
| Abbruch des Tests gemäß | |
|
|
|
Auch für Aktionen mit gesetztem | |
| Ganzzahliger Datentyp |
| X | Anzahl der Testfälle, die dieser Testbaustein anbietet Wenn die Direktive |
| Ganzzahliger Datentyp |
| Testfall, der bearbeitet wird | |
|
|
| X | Testfallname, der über Wenn der Name über eine Direkive angegeben wurde und kein leerer String ist, wird er in den Testreport übernommen. |
|
|
| X | Zusätzliche Testkategorien, die dem angegebenen einzelnen Testfall zugewiesen sind |
| Ganzzahliger Datentyp |
| X | Timeout des Testfalles in Millisekunden Wenn der Wert größer als 0 ist, gilt er als Timeout für diesen Testfall (und überschreibt gegebenenfalls per Direktive angegebene Testfälle). Negative Werte sind für zukünftige Verwendung reserviert und führen zum Abbruch. |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
| X | Zusätzliche textuelle Information für den Testreport |
| Enumeration |
| X | Enumerationswert der Fehlerbeschreibung Voraussetzung: Ein Fehler ist aufgetreten. |
|
|
| X | Genauere textuelle Fehlerbeschreibung Ist auch bei nicht-multitest-fähigen Funktionsbausteinen implementiert Voraussetzung: Ein Fehler ist aufgetreten. |
|
|
| X | Warnmeldung für den Testreport Ist auch bei nicht-multitest-fähigen Funktionsbausteinen implementiert |
|
|
| X | Fehlermodus (Fehlerbehandlung) des Testfalls Ist auch bei nicht-multitest-fähigen Funktionsbausteinen implementiert |