Testskripte
Mittels einem Testskript wird festgelegt, welche Aktionen und Prüfungen stattfinden sollen. Ein Testskript wird initial in einer XML Datei definiert, wobei zur Bearbeitung jeder beliebige XML Editor mit Schemaunterstützung verwendet werden kann. Kern eines Testskripts sind die enthaltenen Positionen, die sequentiell abgearbeitet werden.
Info
Zur Unterstützung bei der Definition wird die Verwendung einer Schemadatei dringend empfohlen. Die Schemadatei beinhaltet alle unterstützten Elemente sowie auch eine (reduzierte) Beschreibung der Bibliotheksfunktionen. Die Schemadatei kann über das Hilfsprogramm Define erstellt werden.
Philosophie
Ein Testskript besteht aus einer Aneinanderreihung von Positionen welche schrittweise abgearbeitet werden. Jede Position repräsentiert einen Aufruf einer Bibliotheksfunktion, wobei Quality Toolkit vier unterschiedliche Arten von Funktionen unterstützt. Diese Funktionen werden je nach Aufgabe im Kontext des Monitors oder des COMOS Agent ausgeführt.
| Typ | Bezeichnung |
|---|---|
| Selector | Mittels einer Funktion vom Typ Selector werden Daten selektiert, wobei der Begriff 'Daten' sehr weiträumig zu verstehen ist. Ein Selector kann beispielsweise ein COMOS Objekt, ein Dokument oder ein Recordset selektieren. Ein Selector selektiert immer ein einzelnes Datenobjekt. |
| Executor | Ein Executor verändert Daten oder führt eine Aktion aus. Der Kontext in dem die Aktion stattfindet wird in der Regel über einen vorgelagerten Selector bestimmt und über weitere Parameter festgelegt. |
| Test | Ein Test wird verwendet um Daten auf Ihre Korrektheit zu prüfen. Die zu prüfenden Daten werden in der Regel über einen vorgelagerten Selector ermittelt und je nach Szenario ggf. über einen Executor manipuliert. Die Definition des Tests erfolgt über die Parametrierung der Position. |
| Waiter | Ein Waiter wartet eine definierte Zeitspanne oder auf einen bestimmten Zustand eines Datenobjektes. |
Info
Die Verkettung der Funktionen kann als Schrittkette verstanden werden, wobei lediglich Funktionen vom Typ Selector Daten an andere Funktionen weiterreichen können. Die Typen Executor, Test und Waiter sind vom Aufbau und Verhalten her ident und unterscheiden sich nur durch die entsprechende Namensgebung.
Aufbau
Die nachfolgende Skizze gibt Ihnen einen groben Überblick über die erwartete Struktur eines Testskripts. Ein Testskript besteht aus Positionen (Bibliotheksfunktionen), die in Gruppen organisiert werden und den notwendigen externen Ressourcen (Dateien).
Bei der Definition von Elementen und Attributen in XML achten Sie bitte auf die korrekte Groß-/Kleinschreibung. Innerhalb des Quality Toolkits werden Namen von Elementen mit großem Anfangsbuchstaben geschrieben, Attribute beginnen immer mit einem Kleinbuchstaben.
Script
│
└───Resources (Container für Ressourcen)
│ │
│ └───Resource (Referenzen auf externe Ressourcen)
│ └───Resource
│
└───Positions (Container für Positionen)
│
└───Group (Gruppierung von Positionen)
│ │
│ └───Position (Funktionen)
│ └───Position
Script
In einer XML Datei muss genau ein Testskript definiert werden.
| Attribut | Beschreibung |
|---|---|
| identifer | Eindeutiger Bezeichner des Testskripts. Über diesen Bezeichner können Ergebnisse später verglichen werden. In zukünftigen Versionen wird dieses Attribut zur skript-übergreifenden Referenzierung von Positionen verwendet. |
| comment | Anwenderfreundliche Bezeichnung des Testskripts. Dieser Text wird unter anderem im Monitor angezeigt. |
Resource
Eine Ressource beschreibt eine physikalische Datei im Filesystem, welche für die Ausführung des Testskripts erforderlich ist. Diese integrierten Ressourcen können in Positionen verwendet werden.
| Attribut | Beschreibung |
|---|---|
| identifier | Eindeutiger Bezeichner der Ressource. Über diesen Bezeichner wird die Ressource später aus den Positionen referenziert. |
| location | Pfad zu der Datei, relativ zu der Ablage des Testskripts. Ist dieses Attribut nicht definiert, wird die Datei im gleichen Ordner wie das Testskript erwartet. |
| name | Name der Datei inkl. Erweiterung, aber ohne Pfadangabe. |
Positions
Gruppen werden unter einem Positions Knoten gesammelt. Dieser Knoten kann auch verwendet werden, um Defaults für die Attribute host und listener zu definieren.
| Attribut | Bezeichnung |
|---|---|
| host | Default, Beschreibung siehe Abschnitt Position. |
| listener | Default, Beschreibung siehe Abschnitt Position. |
Group
Gruppen dienen der Strukturierung eines Testskripts. Ist keine Strukturierung erforderlich, muss dennoch eine Gruppe erstellt werden. Zusätzlich kann über dieses Element ein Default für die Attribute host und listener vergeben (oder abgeändert) werden.
| Attribut | Bezeichnung |
|---|---|
| comment | Anwenderfreundliche Bezeichnung der Gruppe. Dieser Text wird unter anderem im Monitor angezeigt. |
| host | Default, Beschreibung siehe Abschnitt Position. |
| listener | Default, Beschreibung siehe Abschnitt Position. |
Position
Positionen sind der Kern eines jeden Testskripts und definieren, welche Funktionen ausgeführt werden sollen - der Name einer Position entspricht dem Namen der Bibliotheksfunktion. Nachfolgend sind jene allgemeinen Attribute aufgeführt welche für alle Funktionen zur Verfügung stehen. Darüber hinaus können je Funktion zusätzliche Attribute zur Verfügung stehen.
| Attribut | Bezeichnung |
|---|---|
| assembly | Der Name der Assembly wird per Default aus dem Namen der Positionen abgeleitet und muss normalerweise nicht definiert werden - kann aber mittels dieses Attributes übersteuert werden. Für die Position Common.XmlRecordsetSelector wird beispielsweise als Default der Wert QTK.Common ermittelt. |
| comment | Anwenderfreundliche Bezeichnung der Position. Dieser Text wird unter anderem im Monitor angezeigt. |
| expectederror | Im Regelfall wird eine erfolgreiche Ausführung einer Position erwartet. Zur Realisierung von Negativtests kann aber (je nach Funktion) auch ein bestimmter Fehlercode erwartet werden. |
| host | Definition ob die Position im Kontext des Monitors oder des Agents ausgeführt werden soll. Aktuell werden die Werte local und remote unterstützt. Während manche Position sowohl im Monitor als auch im Agent ausgeführt werden können, müssen bestimmte Positionen in einem bestimmten Kontext ausgeführt werden. Per Default wird eine Position im Agent ausgeführt. |
| identifier | Eindeutiger Bezeichner der Position. Über diesen Bezeichner kann eine Position später aus einer anderen Position referenziert werden. |
| listener | Umlenkung der Debugausgaben der zu testenden Applikation in das interne Feebback. Aktuell werden die Werte local und global unterstützt. Mittels local werden Ausgaben über Trace.WriteLine umgelenkt, global fängt alle win32 Debugausgaben ein. Bei aktivierter Option global darf kein zusätzlicher Listener (z.B. Sysinternals DebugView) gestartet werden. |
| namespace | Der Namespace einer Bibliotheksfunktion wird per Default aus dem Namen der Position abgeleitet, kann aber mittels dieses Attributes übersteuert werden. Für die Position Common.XmlRecordsetSelector wird beispielsweise als Default der Wert Stupka.QTK.Common ermittelt. |
Beispiel
Das nachfolgende Beispiel zeigt Ihnen die vollständige Definition eines sehr einfachen Testskripts mit den erforderlichen Attributen.
<?xml version="1.0" encoding="utf-8" ?>
<Script xmlns="http://www.stupka.at/qtk" identifier="SC-01" comment="Einfaches Testskript">
<Resources>
<Resource identifier="data" name="file.xml"/>
</Resources>
<Positions>
<Group comment="Init">
<Common.XmlRecordsetSelector identifier="candidate" resource="data" xpath="//Recordset[@id='identifer']/Rows/Row" comment="Kandidat aus XML einlesen"/>
<Common.RecordsetContentTest recordset="candidate" keycolumnname="col1" rowkey="value2.1" columname="col2" columntext="value2.2" comment="Kandidat prüfen"/>
</Group>
</Positions>
</Script>