Glossar
Aus ExpeccoWiki
Testsuite
Eine Testsuite bezeichnet in expecco die Gesamtheit eines Testprojektes. Sie enthält sämtliche für das Projekt notwendigen Artefakte und Definitionen wie beispielsweise Bausteine, Testpläne, Bibliotheken, Parameter, Ressourcen, Anhänge, Dokumentationen und dient zu ihrer Organisation.
Testplan
In expecco wird eine Sammlung mehrerer Testfälle als Testplan bezeichnet. Zur Durchführung eines Testplans werden alle Einzeltestfälle sequentiell ausgeführt. Dabei kann definiert werden welche dieser Einzeltests im Falle eines Fehlschlags den ganzen Testplan abbrechen sollen. Da es häufig sinnvoll ist, eine Testsuite in mehrere Untertests zu unterteilen, und diese gegebenenfalls nur teilweise auszuführen, können Testpläne ihrerseit auch wieder als Bestandteil eines anderen Testplans hierarchisch angeordnet werden. Das Ergebnis eines Testplans ist ein Testresultat. Bei Nutzung des Quality-Center Plugins, entspricht ein Testplan einem TestSet.
Testfall
Ein Testfall stellt einen Unterpunkt in einem Testplan dar. Typischerweise wird in einem Testfall ein Usecase durchgeführt und validiert. Jedem Testfall wird seinerseits eine Aktion zugeordnet, welche das tatsächliche Szenario definiert. Bei Nutzung des Quality-Center Plugins, entspricht ein Testcase einer Test-Instanz.
Testszenario
Ein Testszenario definiert den konkreten Ablauf (die Aktivitäten) eines Testfalls. In Expecco wird ein Testszenario durch einen Aktivitätsbaustein realisiert.
Aktionsbaustein (Block)
Unter Aktionsbaustein wird die Definition eines Vorgangs bezeichnet. Man unterscheidet zwischen Elementarbausteinen und zusammengesetzten Bausteinen. Ein Baustein kann als Schritt in anderen zusammengesetzten Bausteinen (auch mehrfach) platziert werden. In der Literatur über UML wird hier auch der Begriff "Aktion" verwendet. In der Geschäftsprozessmodellierung (Business-Process Modelling) auch von "Prozess".
Elementarbaustein (Elementary Block)
Ein Elementarbaustein definiert einen grundlegenden, atomaren Vorgang, der nicht durch weitere,feiner granulare Schritte beschrieben werden kann. Konkrete Beispiele sind Protokollaufrufe, Datenbank- oder Dateioperationen oder auch Zeichenketten- und arithmetische Grundoperationen. Elementare Aktionen können entweder als Programmtext (standardmäßig Javascript) (über einen integrierten Skriptinterpreter), oder durch einen Funktionsaufruf in eine DLL (Dynamic Link Library) oder durch einen RPC-Aufruf (Remote Procedure Call) in ein anderes Programm, oder durch den Aufruf eines externen Programms oder Sripts definiert werden.
Die Schnittstelle für Entwickler von neuen Elementarbausteinen ist die expecco API (Application Programmer's Interface). Diese besteht aus einer Menge von Funktionen, welche von elementarem Code aus aufgerufen werden kann. Siehe expecco API.
Zusammengesetzter Baustein (Compound Block)
Das Verhalten eines zusammengesetzten Bausteins wird durch ein Aktivitätsdiagramm beschrieben. Die Elemente eines Aktivitätsdiagramms sind Schritte welche über Daten- oder Kontrollflüsse verbunden sind. Das Verhalten eines Schrittes wird seinerseits durch einen Elementarbaustein oder zusammengesetzten Baustein beschrieben.
Virtueller Baustein
Ein virtueller Baustein definiert lediglich die Schnittstelle (also Anzahl der Ein- und Ausgänge, sowie deren Datentypen). Nicht spezifiziert wird hingegen, wie die Aktion konkret realisiert wird. In einem Aktivitätsdiagramm können solche virtuelle Bausteine wie jeder andere als Schritt platziert werden. Zur Laufzeit hingegen, wird eine echte Realisierung der Aktion benötigt. Dazu erhalten virtuelle Schritte die ID eines konkreten Bausteins zur Ausführungszeit. Dies kann entweder über einen zusätzlichen Eingangspin, oder über eine globale Bibliotheksdefinition geschehen. Bei der Eingangspinmethode kommt die ID typischerweise von einer Umgebungsvariable - es ist aber auch möglich, eine solche ID dynamisch von einem anderen Baustein zu erzeugen und an den virtuellen Schritt weiter zu geben (zum Beispiel um zur Ausführungszeit zu entscheiden, über welche physikalische Schnittstelle mit dem zu testenden System kommuniziert werden soll, und diese Kommunikation über verschiedene Bausteine abzuwickeln). Bei der Binliotheksmethode wird ein kompletter Satz virtueller Bausteine durch Angabe einer konkreten Bibliothek festgelegt.
GUI-Bausteine (expecco PRO Version)
Ein GUI-Baustein (Graphical User Interface) schaltet zur Laufzeit ein Fenster wie zum Beispiel eine Passworteingabe, Messdateneingabe, Benutzerbestätigung oder auch einen Dateibrowser auf.
GUI-Bausteine zeigen bei Aktivierung ein Fenster, dessen Komponenten (Widgets wie z.B. Eingabefelder, Schaltflächen oder Auswahlboxen) vom Testentwickler selbst arrangiert und konfiguriert werden. Dazu wird als integrierter Teil von expecco-PRO ein leistungsfähiges GUI-Painter Tool mitgeliefert, in dem Benutzerobeflächen mittels "drag & drop" erstellt werden.
GUI-Bausteine können auf zwei Arten definiert werden: als "elementare GUI-Bausteine" oder als "zusammengesetzte GUI Bausteine".
Elementare GUI-Bausteine
Diese zeigen bei Aktivierung ein Dialogfenster, welches vom Testentwickler mittels GUI-Painter definiert wurde. Die UI-Komponenten erhalten die Eingangswerte als Vorgabewerte. Damit ist es z.B. möglich, ein Eingabefeld mit einem Wert von aussen vorzubelegen. Das angezeigte Fenster wartet bis der Operator dieses wieder schliesst, wobei die unterliegende GUI-Aktion solange aktiv bleibt. nach dem schliessen (mit "OK") werden die Ausgangspins mit den GUI-Eingabewerten beschrieben, und können wie bei normalen Bausteinen weitere Aktivitäten auslösen (-> Beispiel).
Zusammengesetzte GUI-Bausteine
Bei Aktivierung wird das vom Testentwickler definierte GUI im Kontroll- & Monitorfenster aufgeschaltet, und das unterliegende Aktivitätsdiagramm ausgeführt. Dieses findet die in den GUI-Komponenten dargestellten Werte in seiner Variablenumgebung und kann diese sowohl lesen, als auch schreiben. Das Beschreiben dieser Variablen führt zur sofortigen Darstellung des Wertes im GUI. Mehrfaches Beschreiben (in einer Schleife oder mit Zeitverzögerung, oder wann immer neue Messwerte geliefert werden) dient zur Echtzeitvisualisierung (-> Beispiel).
Schritt (Step)
Ein Schritt ist ein "platzierter Aktionsbaustein" innerhalb eines Aktivitätsdiagramms. Erhält ein Schritt die von ihm benötigten Daten, so wird eine Aktivität ausgelöst, welche den zugehörigen Baustein ausführt. Zu beachten ist, dass eventuell mehrere Aktivitäten gleichzeitig den selben Schritt ausführen; dies geschieht dann, wenn während der Ausführung eines Schrittes (durch eine Aktivität) bereits wieder neue Daten eintreffen. Falls die Parallelität des Schrittes nicht begrenzt wurde, wird von expecco eine neue Aktivität erzeugt, welche den zugehörigen Baustein ausführt.
In der Workflow-Literatur wird der Begriff "Schritt" oft im selben Sinn verwendet (d.h. sowohl für die Semantik einer Aktion, als auch für eine konkrete Ausführung). In Literatur zu UML werden die Begriffe Aktion, Aktivität und Schritt leider oft inkonsistent verwendet. In der expecco Dokumentation wird streng zwischen Aktionsbaustein (=Aktionsdefinition), Schritt (=platzierter Baustein) und Aktivität (=ausgeführter Schritt) getrennt. Insbesondere ist zu beachten, dass ein Baustein in Form mehrerer Schritte, und Schritte wiederum in Form mehrerer Aktivitäten instanziiert werden können.
Aktivität (Activity)
Als Aktivität wird die Ausführung eines Schritts bezeichnet. Hierzu wird der dem Schritt zugeordnete Baustein mit den gegebenen Eingangsdaten ausgeführt. Abhängig von den Einstellungen können mehrere Aktivitäten gleichzeitig ausgeführt werden (auch für einen einzigen Schritt).
Bibliothek
Eine Bibliothek ist die Zusammenfassung von Bausteinen. Bibliotheken werden, wie die umfangreiche Standardbibliothek, von eXept oder Drittanbietern zur Verfügung gestellt. Es können auch projektspezifische Bibliotheken mit eigenen Bausteinen erstellt werden (expecco-lite und webEdition allerdings keine Elementarbausteine).
expecco bietet in seiner Grundausstattung bereits folgende Bibliotheken:
- Standardbibliothek - häufig benötigte Standartfunktionen
- Seleniumbibliothek - Funktionen zum Fernsteuern von WEB-Applicaktionen
Auf Anfrage sind weitere Bibliotheken erhältlich; zum Beispiel in den Bereichen
- Spezielle Rich-Client GUIs
- Spezielle Anwendungen wie SAP, Siebel, etc.
- Datenbanken
- Webservices
- CAN/MOST
- GPIB
- FAT-Client Tests (JavaSwing, DotNET sowie QT-Widgets)
- Business Funktionen (SWIFT, CopyBook etc.)
- RPC (Remote Procedure Call) Interfaces für (SunRPC, XMLRPC, SOAP, Visa, JSON, COM/DCOM u.a.m.)
Pin
Pins (Anschlüsse) stellen die Datenschnittstelle zwischen Schritten dar. Über sie werden Parameter, Messwerte, Datensätze oder einfache Steuerinformation eingelesen und ausgegeben. Man unterscheidet dabei zwischen Eingangs- und Ausgangspins. Je nach Typ des Eingangspins können anstehende Daten eine Warteschlange bilden. Zusätzlich zu den Pins zum Datenfluss gibt es noch eine kleine Anzahl vordefinierter Pins zu Steuerung/Überwachung des Kontrollflusses (Kontrollpins).
Eingangspins
Eingangspins können folgende Eigenschaften haben (auch Kombinationen davon):
- TRIGGER / non-TRIGGER (auslösend / nicht-auslösend)
Triggernde Pins lösen bei ankommenden Daten die Aktivität des Schrittes aus (sobald alle triggernden Pins eines Schrittes Daten erhalten haben). - CONSUMING / non-CONSUMING (konsumierend / nicht-konsumierend)
Nicht-Konsumierende Pins halten Daten in ihren Eingängen, die entweder vorbelegt sind oder zur Laufzeit gelesen werden. Konsumierende Pins dagegen besitzen eine Warteschlange in der ankommende Daten aufgenommen werden. Diese lösen in der Reihenfolge ihrer Ankunft Aktivitäten aus, welche die Daten aus der Warteschlage nehmen (konsumieren) und verarbeiten. Da mehrere Aktivitäten gleichzeitig ausgeführt werden können, entsteht Parallelverarbeitung der Daten. - MAILBOX / non-MAILBOX (Telegramm / Normal)
Normale (Non-Mailbox-) Pins werden nur einmal, zu Beginn der Aktivitätsausführung ausgelesen. Neu eintreffende Werte werden in der Warteschlange gehalten, und dienen zur Erzeugung weiterer Aktivitäten. Telegramm-Pins werden auch während der Ausführung durchgereicht und können damit zu jedem Zeitpunkt der Ausführung dessen Verhalten steuern. Ein typischer Einsatz eines Ereignis-Pins ist der Abbruch einer lang laufenden Aktivität, oder die Reaktion auf externe Ereignisse, wie z.B. Benutzereingaben, Sensormeldungen oder Unterbrechungen.
Normaler Eingangspin
Dies ist der Normalfall. Ankommende Daten werden in einer Warteschlange gehalten, und von jeweils einer einzelnen Aktivität bearbeitet. Je nach Einstellung der Schrittattribute werden diese Aktivitäten sequentiell, parallel oder begrenzt parallel ausgeführt.
Parameter-Pin
Über solche Pins können Parameter eingelesen werden. Diese können entweder statisch vordefiniert werden, aus einer Variable ausgelesen oder dynamisch von anderen Schritten geliefert werden. In einem solchen Pin wird jeweils nur der zuletzt angekommene Wert gehalten; neu ankommende Daten ersetzen ältere Werte. Bei der Ausführung gilt der zum Zeitpunkt des Aktivitätsstarts aktuelle Wert (auch wenn während der Ausführung ein neuer Wert erscheint).
Kontrolleingangspins
Trigger-Eingangspin
Über diesen Pin kann eine Aktivität ausgelöst werden. Dieser Pin wird benötigt, wenn eine Aktion über keinen oder lediglich über nicht-triggernde Parameterpins verfügt. Durch verbinden des Triggereingangs mit einem beliebigen anderen Ausgangspin kann die Aktion des Schrittes dann ebenfalls ausgelöst werden.
Bei einem Diagramm ohne Datenflüsse (also mit ausschließlichen Kontrollflüssen) werden Triggerein- mit Triggerausgängen verbunden, wodurch ein reines Flussdiagramm entsteht.
Ausnahme-Pin (Exeption-Pin)
Im Falle eines Fehlers erhält dieser Pin detaillierte Informationen über die stattgefundene Ausnahme. Diese können dann weitergereicht, ausgewertet oder zur Fehlerbereinigung bzw. Benachrichtigung verwendet werden. Meist wird die darin übergebene Detailinformation aber nicht benötigt, stattdessen das Vorhandensein eines Wertes zur Steuerung des Kontrollflusses verwendet. Eine unbehandelte Ausnahme (d.h. bei einem nicht vorhandenen oder nicht angeschlossenen Ausnahmepin) wird hierarisch nach oben weitergereicht, und könnte dort seinerseits durch einen Ausnahmepin behandelt werden. Erreicht eine unbehandelte Ausnahme die Testfallebene, dann gilt der gesamte Testfall als defekt.
Abbruch-Pin (Cancel-Pin)
Über diesen Pin wird eine bereits laufende Aktivität abgebrochen.
Zeitüberwachungs-Pin (Timelimit-Pin)
Über diesen Pin kann ein statisch definiertes oder dynamisch berechnetes Zeitintervall übergeben werden. Falls die Aktivität nach dieser Zeit nicht beendet ist, wird sie (mit einer Fehlerbenachrichtigung) abgebrochen. Diese Funktionalität könnte auch durch eine Kombination eines Zeitverzögerungsbausteins und dem Abbruch-Pin realisiert werden.
Wiederholungs-Pin (RepeatCounter-Pin)
Über diesen Pin lässt sich ein Schritt wiederholt ausführen. Dem Pin wird dabei die Anzahl der durchzuführenden Wiederholungen übergeben.
Ausgangspins
Über Ausgangspins werden in einem Schritt erzeugte Daten an andere Schritte weiter gegeben.
Ausgangspins können folgende Eigenschaften haben:
- BUFFERED / UNBUFFERED (gepuffert/ nicht-gepuffert)
Da während der Ausführung eines Schrittes eventuell mehrere Ausgangspins zu unterschiedlichen Zeiten beschrieben werden, und ein einzelner Pin auch mehrfach beschrieben werden kann, ergibt sich die Frage, was mit bereits beschriebenen Werten passieren soll, wenn während der Ausführung ein Ausnahmezustand, Fehler oder Abbruch erfolgt. Dazu dient diese Eigenschaft: gepufferte Ausgänge merken sich alle Ausgabewerte die während der Ausführung anfallen und geben diese am Ende, nach erfolgreicher Ausführung, weiter. Im Falle einer nicht erfolgreichen Ausführung werden keine Daten weitergegeben. Im Gegensatz dazu geben ungepufferte Ausgänge ihre Daten sofort weiter (was auch sofort zur Erzeugung neuer Aktivitäten führen kann).
Bitte beachten Sie, dass gepufferte Ausgänge im allgemeinen die richtige Wahl darstellen. Ein Ausnahme stellen allerdings Bausteine dar, welche große Datenmengen in kleinen Paketen weiter reichen (also ihre Pins mehrfach beschreiben). Insbesondere sind dies Datei- und Datenbanklesende Bausteine, sowie solche, welche in einer Schleife Messwerte oder andere Daten lesen, aufbereiten und weitergeben.
Normale Ausgangspins
Als solche werden die Datenpins bezeichnet, welche im Schema-Editor definiert werden. Sie werden typischerweise rechts im Step angeordnet. Ihr Datentyp kann vom Benutzer vorgegeben werden, und der Editor verlangt typekonforme Verbindungen zwischen Eingangs- und Ausgangspins (d.h. ein Eingangspin muss immer ein kompatibler (Ober-)Type des Ausgangspin-Typs sein. Diese strenge Typprüfung kann für einzelne Verbindungen auch ausgeschaltet werden (um dennoch mit falsch definierten Bausteinen arbeiten zu können). In einem Elementarbaustein mit Skriptcode werden normale Ausgangspins durch einen "pin.value(arg)"-Aufruf beschrieben. Dies kann auch mehrfach während der Ausführung eines Schrittes erfolgen (siehe auch Beschreibung zu gepuffert/ungepuffert oben). In zusammengesetzten Bausteinen werden Ausgangspins intern mit einem oder mehreren internen Schritten verbunden, so dass deren Ausgangswerte weiter geleitet werden.
Kontrollausgangspins
Trigger-Ausgangspin
Dieser Pin kann jedem Schritt einzeln hinzugefügt werden (über eine PopUp-Menu Funktion im Editor). Er wird aktiviert, sobald die dem Schritt zugeordnete Aktion beendet ist (ohne dass ein Fehler auftrat). Dieser Pin wird benötigt, wenn eine Aktion durch die Beendigung einer anderen Aktion synchronisiert werden soll.
Bei einem Diagramm ohne Datenflüsse (also mit ausschließlichen Kontrollflüssen) werden Triggerein- mit Triggerausgängen verbunden, wodurch ein reines Flußdiagramm entsteht.
Exception-Ausgangspin
Auch dieser Pin ist nicht im Schema sichtbar, sondern wird einzelnen Schritten über eine PopUp-Menu Funktion zugefügt. Falls vorhanden, werden Ausnahmen (Exceptions) während der Ausführung an diesen Pin als Exception-Informationspaket geleitet. Damit kann der Kontrollfluss im Fehlerfall an andere Bausteine geleitet werden. Mögliche Ausnahmen sind "Division durch 0", "E/A-Fehler in Dateioperationen" aber auch synthetisch erzeugte Ausnahmen.
Zeitmessung-Ausgangspin
Nach der Ausführung erscheint an diesem Pin die Ausführungszeit des Schrittes.
Triggerbedingung
Die Triggerbedingung eines Bausteins gibt an, welche Eingangspins Werte erhalten haben müssen, um eine Aktivität zu starten. Parametereingänge sind nicht triggerfähig - es muss also mindestens ein nicht-Parameterpin vorhanden sein, oder der Schritt mit der Autostart-Eigenschaft versehen werden.
Zur Triggerbedingung gibt es 3 mögliche Einstellungen:
- UND (AND)
Alle Eingangspins müssen Werte erhalten haben. - UND-Verbunden (AND-Connected)
Wie oben, offene Eingänge werden aber ignoriert. - ODER (OR)
Mindestens ein Eingangspin muss einen Wert erhalten haben.
Zu beachten ist, dass in den beiden letzten Fällen ein elementarer Baustein selbst festzustellen hat, welche Pins über gültige Eingabewerte verfügen. Das expecco API bietet dazu entsprechende Funktionsaufrufe an.
Vorbedingung (Precondition)
Eine Vorbedingung kann einem Testplan, Testfall oder einem Baustein zugeordnet werden. Vorbedingungen sind ihrerseits als Bausteine realisiert (elementar- oder zusammengesetzt). Falls einem Element eine Vorbedingung zugeordnet wurde, so wird die Vorbedingung zuerst ausgeführt, und nur falls diese keinen Fehler oder Defekt meldet, wird anschließend das Element selbst ausgeführt.
Nachbedingung (Postcondition)
Analog zur Vorbedingung gibt es auch die Möglichkeit, einem Testplan, Testfall oder Baustein eine Nachbedingung zuzuordnen. Diese wird immer nach dem Element ausgeführt unabhängig vom Ergebnis der Ausführung - außer, wenn eine vorhandene Vorbedingung bereits einen Fehler oder Defekt meldete. Vor- und Nachbedingungen eignen sich besonders zur Anforderung und Freigabe von zusätzlich benötigten Ressourcen - insbesondere zum Erstellen von Kommunikationsverbindungen, welche anschließend wieder freigegeben werden müssen.
Variablenumgebung (Variable-Environment)
In der Variablenumgebung können Variablen definiert werden um diese in den Diagrammen zu verwenden. Dabei kann ihnen ein Datentyp sowie ein Initialisierungswert zugewiesen werden. Variablenumgebungen sind geschachtelt. Jeder zusammengesetzte Baustein kann neue Variablen definieren, oder überladen. So definierte Variable sind dann in den von ihm ausgeführten Schritten sichtbar. Auch Testpläne können eigene Umgebungen definieren. Die Verschachtelung der Variablenumgebungen endet auf oberster bei der Testsuite. Hier werden typischerweise Parameterwerte (Hostnamen, Portnummern und andere Konfigurationsparameter) abgelegt. Beim Zusammenspiel mit einer Automatisierungslösung wie z.B. expeccoNET können die Parameterwerte der obersten Ebene von aussen vorgegeben werden, so dass die selbe Testsuite in mehreren Konfiguration ausgeführt werden kann.
Datentypen
Vordefinierte (Standard-) Datentypen
Primary Types (Primärtypen)
Primärtype sind solche, welche das unterliegende Laufzeitsystem bereits unterstürtzt. Technisch sind dies die Klassen des ST/X Basissystems [Klassendokumentation].
Bei der folgenden Liste handelt es sich lediglich um einen kleinen Auszug der wichtigsten Datentypen. Tatsächlich unterstützt das unterliegende Laufzeitsystem eine weit grössere Anzahl bereits eingebauter und nützlicher Datentypen (in der aktuellen Version ca. 7000).
Numerische Typen
- Number - allgemeiner Obertyp aller Zahlentypen
- Integer - ganze Zahlen; sowohl kleine (32bit) als auch grosse (beliebig gross)
- Float - Gleitkommazahlen; Wissenschaftliche Darstellung, Mantisse+Exponent
- Fraction - Brüche, bestehend aus Nenner und Zähler
- FixedPoint Decimal - Dezimalzahlen
Texttypen
- String - Zeichenketten; Unicode 8bit, 16bit oder 32bit.
- Filename - OS-unabhängige Dateinamen
- URL
Container
- Collection - allgemeiner Obertype aller Containertypen
- Array - fixe Größe, Zugriff über ganzzahligen Index (Vektor, Tupel)
- OrderedCollection - variable Größe, Zugriff über ganzzahligen Index
- StringCollection - ditto, mit speziellen Stringfunktionen
- SortedCollection - intern immer sortiert
- BTree - ditto, aber als Baum organisiert
- Dictionary - variable Größe, Zugriff über beliebigen Index (Hashtable)
- Set - variable Größe, gleiche Elemente werden nur einmal gehalten
Zeit
- Date - Datum
- Time - Uhrzeit
- DateTime - Zeitstempel; Datum+Uhrzeit (mit Millisekunden)
- TimeDuration - Zeitdifferenz (auf Millisekunde)
Weitere Typen
- Any - Obertyp aller anderen Typen
- Boolean
- UUID - auch GUID ("globally unique ID"); weltweit einmalige Kennzeichner
- Stream - Streaming über interne Collections oder über Dateiinhalte
- Socket - TCP/IP Verbindung
Expecco-Spezialtypen
- ActivityLog
- Datatype
- Exception
- Handle
- Performer
Instanzen dieses Typs repräsentieren eine Bausteindefinition. Diese werden primär als Eingabewert eines virtuellen Schrittes benötigt, damit dieser festlegen kann, welchen konkreten Baustein dieser ausführen soll. Konstanten von diesem Typ (Vorgabewerte) werden als GUID (Globally Unique Identifier) des Bausteins dargestellt. Diese ID eines Bausteins erhält man entweder über eine Menüfunktion im Projektbaum, oder in der Dokumentationsseite des Bausteineditors. - Resource
- Verdict
Benutzerdefinierte Datentypen
Neben der Möglichkeit, neue Klassen und damit Primäre Datentypen dynamisch nachzuladen oder in einem Plugin zur Verfügung zu stellen, können strukturierte Datentypen auch explizit definiert werden.
Compound Types (Zusammengesetzter Datentypen)
Dieser entspricht den Record- oder Struct-Typen von Pascal, C oder ähnlichen Programmiersprachen. Der Typ wird beschrieben durch eine Menge von Feldern, welche ihrerseits aus einem Namen sowie Datentype bestehen. Zum Beispiel könnte ein Personenrecord durch den Compoundtyp "{ vorName:String; nachName:String }" definiert werden.
Union Types (Vereinigungstypen)
Tuple Types (Tupeltypen)
Tupels bestehen aus einer vorgegebenen Anzahl von Elementen, welche per numerischem Index zugreifbar sind. Zum Beispiel könnten 3D Koordinaten durch Tupel wie "[ Integer, Integer, Integer ]" reprasentiert werden.
Array Types (Vektortypen)
Arrays (Vektoren) bestehen aus einer statisch Anzahl von Elementen, welche per numerischem Index zugreifbar sind. Sie entsprechen dabei Tupels, deren Grösse zur Laufzeit festgelegt wird.
Enumeration Types (Aufzählungstypen)
Subrange Types (Unterbereichstypen)
Inventar (Inventory)
Ein Inventar ist ein Liste von zur Verfügung stehenden Betriebsmittel, die typischerweise technische Ausrüstung wie beispielsweise Mess- und Prüfgeräte oder menschliches Bedienpersonal darstellen. Solche Betriebsmittel können von Testplänen, Testfällen oder einzelnen Bausteinen benötigt werden. Sobald Betriebsmittel benötigt werden, dann werden diese vor der Ausführung von einem Inventar bereitgestellt und danach wieder zurückgegeben. Sollte ein Betriebsmittel nicht verfügbar sein, so wird die Ausführung der Aktivität unterbrochen bis das benötigte Betriebsmittel verfügbar ist. Auf diese Weise können mehrere Aktivitäten ihren Zugriff und ihre Verwendung von gemeinsam genutzten Betriebsmittel synchronisieren.
Testdurchführung
Testresultat (Testresult)
Das Ergebnis eines Tests. Testresultate werden als Ergebnis sowohl eines einzelnen Testfalls, der Ausführung eines Schrittes, als auch eines Testplans geliefert. Eine Ausführung kann (ungeachtet weiterer Detailinformationen sowie Trace- und Loggingdaten) grundsätzlich einen von 4 Werten als Testresultat liefern:
- Bestanden (PASSED) [
]
Der Test wurde durchgeführt, und das getestete System hat diesen bestanden.
Als Resultat einer Testplan-Ausführung bedeutet dies, das alle Einzeltests bestanden wurden. Aus Sicht des Qualitätsmanagers gelten sowohl das getestete System als auch der Test selbst als korrekt.
- Fehlgeschlagen (FAILED) [
]
Der Test wurde durchgeführt, und das getestete System hat diesen nicht bestanden. Der für die entsprechende Komponente zuständige Entwickler ist zu benachrichtigen.
Als Resultat einer Testplan-Ausführung bedeutet dies, das mindestens ein Einzeltest fehlgeschlagen ist, und keiner ergebnislos oder defekt war. Aus Sicht des Qualitätsmanagers gilt das getestete System als defekt, der Test selbst als korrekt.
- Ergebnislos (INCONCLUSIVE) [
]
Der Test konnte nicht durchgeführt werden weil benötigte Ressourcen (z.B. Messgeräte, Verbindungen etc.) nicht vorhanden waren. Der Testmanager ist zu benachrichtigen.
Als Resultat einer Testplan-Ausführung bedeutet dies, das mindestens ein Einzeltest ergebnislos war. Aus Sicht des Qualitätsmanagers kann weder über das getestete System noch über den Test eine Aussage gemacht werden.
- Test Defekt (ERROR) [
]
Der Test konnte nicht korrekt durchgeführt werden da während der Ausführung des Tests im Testsystem selbst ein Fehler aufgetreten ist. Der Testentwickler ist zu benachrichtigen.
Als Resultat einer Testplan-Ausführung bedeutet dies, das mindestens ein Einzeltest defekt, und keiner ergebnislos war, da ein ergebnisloser Test zu einem Fehler führen kann. Aus Sicht des Qualitätsmanagers gilt der Test selbst als fehlerhaft; über die Qualität des getesteten Systems kann keine Aussage gemacht werden.
Log Aufbereitung
Ein Log Aufbereiter kann zu einem Testfall hinzugefügt werden. Er verarbeitet den Aktivitätslog, welcher von Testfällen erzeugt wird und generiert eine gekürzte oder anders bearbeitete Variante der Daten. Die verarbeiteten Daten werden auf einer separaten Seite der Ausführungsprotokollierung.
Log Aufbereiter sind Bausteine - elementare oder zusammengesetzte. Die zugehörige Bausteinbeschreibung muss einen einzelnen input pin vom Typ ActivityLog besitzen.
Die gebräuchlichste Verwendung von Log Aufbereitern ist die Zusammenfassung von Logdaten - zum Beispiel um zusammengefasste Ausführungszeit- oder performancedaten zu generieren, ohne dass die aktuelle Testfalldefinition verändert werden muss.
Risikobasiertes Testen (Risk Based Testing)
Oft ist die Durchführung einer gesamten Testsuite zu zeit- oder ressourcenaufwändig, um z.B. bei Regressionstests immer durchgeführt zu werden. Auch kann es vorkommen, dass bestimmte Mess- oder Prüfgeräte nicht zu jedem Test bereitstehen. In solchen Fällen kann eine Auswahl der durchzuführenden Testfälle durch ein Risikofilter automatisch erfolgen. Hierzu wird zu jedem Testfall eine Risikobewertung durchgeführt (i.e. "wie gross ist der Schaden für das Produkt, wenn dieser Testfall einen Fehler erkennt"), und dies in Form eines Risikoattributes im Testfall vermerkt. Zur Durchführung kann dann ein Filter (i.e. "nur Testfälle für Mittleres und Hohes Risiko durchführen") angegeben werden.
Untermengen Testen
Werden umfangreiche Testpläne als Hierarchie von Testplänen organisiert, so können diese ihrerseits auch einzeln ausgeführt werden. Insbesondere Entwickler, welche eine Fehlersituation reproduzieren wollen, werden typischerweise nicht die gesamte Testsuite während der Debugsitzung erneut ausführen.
Gruppentests
Zusätzlich zur oben erwähnten hierarchischen Gruppierung ist es auch möglich, einzelne Testfälle mit einem oder mehreren Schlüsselwörtern - so genannte Tags - zu versehen, und bei der Ausführung ein oder mehrere Tags als Filterkriterium anzugeben. Es werden dann nur solche Tests durchgeführt, welche mit dem entsprechenden Tag versehen wurden.
Tags (Etiketten)
Treeelemente (Aktionen, Typen, Testpläne etc.) sowie Schritte in einem Diagramm können mit einem oder mehreren Tags (Etiketten) versehen werden. Diese Tags dienen an verschiedenen Stellen zur Suche, Auswahl, Filterung oder Unterdrückung dieser Elemente. Im einzelnen haben Tags auswirkung auf:
- Suchfunktion im ProjektBaum (explizite Angabe zur Suche)
- Auswahlliste bei "Neuer Schritt" bzw. "Schritt Ersetzen" (Aktionen welche mit "invisible" oder "obsolete" etikettiert sind, werden nicht angezeigt)
- Reportgernerierung und Druck (Filter zum Ausschluss oder Einschluss bestimmter Etiketten)
