55.6 Automatische Erzeugung von Prozeduraufruf-Definitionen

Um Knotenabfolgen in Prozeduraufrufe umwandeln zu können, benötigt QF-Test entsprechende Prozeduraufruf-Definitionen. Diese können Sie automatisiert erstellen lassen. Selektieren Sie hierzu ein oder mehrere Prozeduren oder Packages, öffnen per Rechtsklick das Popup-Menü und wählen den Eintrag »Weitere Knotenoperationen«-»Prozeduraufruf-Definition erzeugen«.

Nach Aktivierung der Funktion wird der Dateiname, in dem die erstellten Definitionen abgelegt werden sollen, in einem Eingabedialog abgefragt, sofern er nicht im Doctag @prec/definitions im Prozeduren-Wurzelknoten angegeben ist.

Die Definitionen werden in der gleichen Package-Struktur angelegt wie die der zugehörigen Prozeduren.

Der erzeugte Definitionsknoten enthält den Namen der Prozedur. Enthält die Prozedur überhaupt keine aufnehmbaren Knoten, kann keine gültige Definition erzeugt werden. In diesem Fall wird der Definitionsknoten deaktiviert und ein entsprechender Hinweis in seinen Code geschrieben. Etwaige Probleme, die beim Analysieren der Prozedur auftreten, werden im Definitionsknoten berichtet.

Zum Erstellen einer Definition analysiert QF-Test die Schritte der Prozedur der Reihe nach und steigt rekursiv in alle relevanten Kindknoten ab. Dabei wird geprüft, ob ein bestimmter Knoten für die Definition relevant ist. Falls ja, werden die Angaben, die den Knoten ausreichend spezifizieren, in die Definition übertragen. Außerdem wird geprüft, ob der Knoten Variablen enthält, die bei der späteren Umwandlung von Knoten als Prozeduraufrufparameter relevant sind. Auch diese werden in die Definition eingetragen. Ablaufstrukturen wie If, Try und Schleife werden analysiert und als entsprechende Gruppen in der Definition abgebildet. Der Automatismus lässt sich mit den in "Doctags zum Steuern der automatischen Definitionserstellung" beschriebenen Doctags genauer steuern.

Hinweis Die automatisierte Erstellung von Definitionsknoten ist für die Knotenumwandlung direkt im Anschluss an eine Aufnahme konzipiert. Das heißt zum Beispiel, dass Knoten, die nicht aufgenommen werden können oder bei denen es unwahrscheinlich ist, dass sie der Anwender aufnimmt, nicht in die Definition geschrieben oder als optional gekennzeicht werden.

55.6.1 Definitionsrelevante Knoten

Da die automatisierte Erstellung von Definitionsknoten für die Knotenumwandlung direkt im Anschluss an eine Aufnahme konzipiert ist, werden nur Knoten in die Definition eingetragen, die aufgenommen werden können. Dazu gehören die Event-Knoten, zum Beispiel Mausevent, Texteingabe und Tastaturevent, sowie Check-Knoten. Knoten, die nicht aufgenommen werden können oder deaktivierte Knoten, werden übersprungen.

Darüber hinaus können Knoten explizit über das Doctag @prec/ignore, Knotenfolgen über die Doctags @prec/ignore/start / @prec/ignore/end, mitsamt ihrer Kindknoten ausgeschlossen werden.

Eine Prozedur kann mit @prec/duplicate davon ausgeschlossen werden, eine eigene Definition zu erzeugen, wird aber dennoch expandiert, wenn sie von einer anderen Prozedur aufgerufen wird. Bei @prec/ignore wird die Prozedur in jedem Fall übergangen.

55.6.2 Verpflichtende und optionale Knoten

Bei der Entscheidung, ob ein Knoten in der Definition als verpflichtend oder optional gekennzeichnet wird, wird bewertet, ob ein Benutzer auch manuell die Aktion ausführen würde, für die ein Knoten in einer Prozedur steht. Dabei wird davon ausgegangen, dass dies bei Mausklicks der Fall ist, soweit sie sich nicht in "Bedingte Strukturen" befinden. Bei einem Texteingabe-Knoten wird geprüft, ob er in aufnahmerelevanten Attributen Variablen enthält. In diesem Fall wird der Knoten als verpflichtend gekennzeichnet. Die Variable wird als Parameter für den Prozeduraufruf eingetragen. Falls er keine Variable enthält, wird er als optional gekennzeichnet. Der Text wird dann als erwarteter Wert in die Definition eingetragen. Check-Knoten werden nur dann als relevant eingestuft, wenn aufnahmerelevante Attribute Variablen enthalten.

Dieser Automatismus kann mit "Doctags zum Steuern der automatischen Definitionserstellung" übersteuert werden: Check-Knoten und Warten auf Komponente-Knoten können mit dem Doctag @prec/addNode auf jeden Fall als relevant für die Definition markiert werden. Um einen einzelne Knoten samt seiner Kindknoten als optional zu kennzeichnen, verwenden Sie @prec/optional, für ganze Knotenbereiche @prec/optional/start und @prec/optional/end. Das Ende einer Prozedur beendet einen offenen optionalen Bereich implizit.

55.6.3 Auflösen von Prozeduraufrufen

Enthält die Prozedur Aufrufe weiterer Prozeduren, steigt QF-Test in die aufgerufene Prozedur ab und fügt deren aufnehmbare Knoten zur Definition hinzu. Rekursive Aufrufe werden erkannt und übersprungen, um Endlosschleifen zu vermeiden. In einem Prozeduraufruf übergebene Variablen werden entlang der Aufrufhierarchie weitergereicht, sodass der in der Definition letztlich verwendete Variablenname derjenige ist, der auf der Ebene des zu definierenden Prozeduraufnahmes sichtbar ist.

55.6.4 Bedingte Strukturen

Die Zweige von If und Try Strukturen werden zusammen mit ihren Else, Elseif und Catch Blöcken in eine Auswahlgruppe übersetzt, d.h. in eine Menge alternativer Blöcke, von denen einer passen muss. Identische Blöcke werden zusammengefasst, sodass Zweige, die sich nur in ihrem Optional-Flag unterscheiden, nur einmal erhalten bleiben. Enthält nur ein einziger Block für die Definition relevante Inhalte, so wird dieser Block optional, statt eine Auswahl zu bilden. Der Inhalt eines Finally Blocks wird immer als verpflichtend behandelt und nach der Auswahlgruppe angefügt.

55.6.5 Priorität

Jeder Definition wird eine Priorität (priority) hinsichtlich der späteren Reihenfolge der Definitionsauswertung zugewiesen, die sich aus der Anzahl ihrer verpflichtenden und optionalen Knoten ableitet (siehe Abbildung von Prozedurstrukturen). So erhalten spezifischere Definitionen Vorrang vor allgemeineren. Jeder verpflichtende Knoten erhöht die Priorität um 10, jeder optionale Knoten um 1. Der berechnete Wert kann mit dem Doctag @prec/priority überschrieben oder angepasst werden, wobei ein vorangestelltes "+" oder "-" zum berechneten Wert addiert bzw. von ihm subtrahiert und eine reine Zahl ihn ersetzt, siehe Flag für die Priorität.

55.6.6 Ersatzprozeduren für die Generierung von Definitionen verwenden

Manche Prozeduren führen eine einfache Aktion aus, müssen diese aber aus technischen Gründen auf komplizierte Weise implementieren. In solchen Fällen können Sie dem automatischen Generator mitteilen, nicht die komplexe Prozedur zu analysieren, sondern eine Ersatzprozedur zu verwenden, aus der die Prozeduraufruf-Definition abgeleitet wird.

Die Ersatzprozeduren müssen in einer eigenen Testsuite in einem Package mit dem Namen "known procedures" abgelegt werden. Die Package-Struktur innerhalb dieses Packages muss der Package-Struktur der Originalprozedur entsprechen. Die Ersatzprozeduren werden sowohl bei der Erstellung einer Prozeduraufruf-Definition für die Prozedur selbst verwendet als auch dann, wenn die Prozedur aus anderen Prozeduren heraus aufgerufen wird. Wenn eine Ersatzprozedur bei der Definitions-Erstellung verwendet wird, wird dies im Kommentar des Definitionsknotens vermerkt. Der Dateiname wird im Doctag @prec/substituteProcedures im Prozeduren-Wurzelknoten angegeben.

55.6.7 Doctags zum Steuern der automatischen Definitionserstellung

Die folgenden Doctags steuern die automatische Erstellung von Definitionen für die Prozeduraufnahme. Sie können damit bestimmte Werte für die erstellte Definition setzen oder übersteuern.

55.6.7.1 Flags für optionale Knoten

Wenn Sie einen oder mehrere Knoten für die Umwandlung als optional kennzeichnen möchten, können Sie eines der folgenden Doctags verwenden.

Bei komplexeren Prozeduren wird ein Anwender bei der Aufnahme der entsprchenden Aktionen vermutlich nicht alle aufnehmbaren Ereignisse auch tatsächlich aufnehmen. In diesem Fall können Sie die Schritte, die voraussichtlich nicht aufgenommen werden, als optional kennzeichnen können. @prec/optional/start kennzeichnet den ersten einer Reihe optionaler Schritte, @prec/optional/end in derselben Prozedur den letzten davon. Der letzte Knoten einer Prozedur besitzt ein implizites @prec/optional/end.

Wenn Sie nur einen bestimmten Schritt als optional kennzeichnen möchten, verwenden Sie @prec/optional. Falls dieser Kindknoten besitzt, werden auch diese optional.

@prec/optional/start und @prec/optional/end

Alle Knoten zwischen den gekennzeichneten Knoten - einschließlich dieser - werden der Gruppe der optionalen Knoten der Prozeduraufruf-Definition hinzugefügt. Wenn Sie nur @prec/optional/start angeben, werden der aktuelle Knoten und alle nachfolgenden Geschwisterknoten bis zum Ende der Prozedur der optionalen Gruppe hinzugefügt.

@prec/optional

Der Knoten wird mit allen seinen Kindknoten der optionalen Gruppe hinzugefügt.

55.6.7.2 Flags für Attribute

@prec/component/id/ignore

Die im Knoten angegebene Komponente muss für die Definition ignoriert werden, z.B. wenn Strg-Enter oder ESC nicht auf eine bestimmte Komponente beschränkt sind. Werte, die in den Doctags @prec/condition oder @prec/scope angegeben sind, werden in die Prozeduraufruf-Definition übertragen.

@prec/attributes/id/ignore

Die im Knoten angegebene QF-Test ID der Komponente muss für die Definition ignoriert werden. Andere Kriterien zur Komponentenerkennung werden in die Prozeduraufruf-Definition geschrieben. Nützlich, wenn in verschiedenen (Prozedur-)Testsuiten doppelte Komponenten (aber mit unterschiedlichen QF-Test ID der Komponente) vorhanden sind.

@prec/component/id meineQF-TestIdDerKomponente

Die QF-Test ID der Komponente ist als Variable angegeben, z.B. $(node), und der Automatismus kann nicht erkennen, für welche Komponente sie steht. Tatsächlich wird die Prozedur aber immer für eine bestimmte Komponente, typischerweise mit unterschiedlichen Indizes, ausgeführt. Über das Doctag kann die Komponente - ohne Index - spezifiziert werden. Das Doctag wird ignoriert, wenn in einem Prozeduraufruf die Variable definiert ist.

Der Automatismus erstellt in der Rubrik set procedure call parameters einen Eintrag Name der Variablen: >componentid<, so dass im Prozeduraufruf, der später erzeugt wird, die volle QF-Test ID der Komponente einschließlich Indizes in der Parameterliste hinzugefügt wird. Die im Doctag angegebene QF-Test ID der Komponente oder SmartID wird in der Rubrik component eingetragen.

@prec/scope

Die QF-Test ID der Komponente oder die SmartID einer Container-Komponente. Wenn für die Komponente selbst eine QF-Test ID der Komponente oder die SmartID angegeben ist, wird der Scope nur dann zum YAML-Code hinzugefügt, wenn die Option OPT_RECORD_COMPONENT_NAME_OVERRIDE auf VAL_NAME_OVERRIDE_EVERYTHING gesetzt ist.

@prec/attributes/xxx

Attribute, die über eine Aufnahme gesetzt werden, können für die Definition genutzt werden. Der Automatismus geht beim Hinzufügen von Attributwerten wiefolgt vor:

1. Prüfung, ob es sich um eine Variable handelt. Wenn ja und wenn der Wert nicht der Standardwert ist, wird in der Rubrik set procedure call parameters ein Eintrag erstellt: Name der Variablen: >Platzhalter für das entsprechende Attribut<.
2. Falls ein entsprechendes Doctag vorhanden ist, wird in der Rubrik attributes ein Eintrag für das Attribut mit dem Wert des Doctags erstellt.
3. Wenn weder 1 noch 2 zutreffen, wird in der Rubrik attributes ein Eintrag für das Attribut mit dem Attributwert aus dem entsprchenden Knoten erstellt. Es sei denn, es handelt sich um eines der Attribute, bei denen es nicht sinnvoll ist, den Wert hinzuzufügen, wie X oder Y bei Mausevents.

Die Attribute können nicht vererbt werden, sofern dies nicht für bestimmte Attribute anders angegeben ist.

@prec/attributes/client

Das Doctag wird von Knoten aus Prozeduren oder Packages vererbt. Innere Doctags überschreiben äußere Werte.

@prec/VariableIsNoIndex

Enthält die QF-Test ID der Komponente eine eingebettete Variable wie z.B. MeineKomponente$(suffix), versucht QF-Test diese normalerweise als Subindex-Variablenpaar (Separator und Index) zu extrahieren. Wenn die Variable jedoch Teil der QF-Test ID der Komponente selbst ist und kein Subindex, kennzeichnen Sie den Knoten mit diesem Doctag.

@prec/component/name meinKomponentenname

Der angegebene Name wird in der Rubrik component der Definition hinzugefügt. Nützlich bei Knoten, deren QF-Test ID der Komponente nur eine Variable ist. Ansonsten wird der im Knoten angegebene Wert überschrieben.

Das Doctag wird vererbt. Doctags von Kindknoten überschreiben die Werte derer von Elternknoten.

@prec/component/class meineKomponentenklasse

Die angegebene Klasse wird in der Rubrik component der Definition hinzugefügt. Nützlich bei Knoten, deren QF-Test ID der Komponente eine Variable ist, und somit das Klasse des Komponente nicht ermittelt werden kann. Ein eventuell vom Automatismus ermittelter Wert wird überschrieben.

Verwenden Sie das Doctag @prec/component/class, wenn die Klasse der Komponente ignoriert werden soll.

Das Doctag wird vererbt. Doctags von Kindknoten überschreiben die Werte derer von Elternknoten.

@prec/component/engine Technologie

Die Technologie für den Knoten: awt, android, fx, iOS, pdf, swt, web.

Das Doctag wird vererbt. Wenn es an einen Package-Knoten geschrieben wird, gilt es für alle Prozduren des Packages. Innere Doctags überschreiben äußere Werte.

@prec/component/feature meinKomponentenfeature

Das angegebene Merkmal wird in der Rubrik component der Definition hinzugefügt. Nützlich bei Knoten, deren QF-Test ID der Komponente eine Variable ist, und somit das Merkmal des Komponente nicht ermittelt werden kann. Ein eventuell vom Automatismus ermittelter Wert wird überschrieben.

Das Doctag wird vererbt. Doctags von Kindknoten überschreiben die Werte derer von Elternknoten.

@prec/component/extraFeatures meinFeaturename meinFeaturewert

Das angegebene Weiteres Merkmal wird unter in der Rubrik extra features in der Rubrik component der Definition hinzugefügt. Nützlich bei Knoten, deren QF-Test ID der Komponente eine Variable ist, und somit das Weiteres Merkmal des Komponente nicht ermittelt werden kann. Ein eventuell vom Automatismus ermittelter Wert wird überschrieben.

Wird das Doctag an einen Knoten mit Kindknoten geschrieben, wird das angegebene Extra-Feature allen Kindknoten hinzugefügt. Doctags von Kindknoten überschreiben die Werte derer von Elternknoten.

@prec/condition Ausdruck

Falls Attribute in der Definition genutzt werden sollen, für die im YAML-Code kein Eintrag vorgesehen ist, dafür aber ein passender Platzhalter zur Verfügung steht, können diese in einer Bedingung spezifiziert werden. Mehrere Bedingungen werden mit einem logischen und verknüpft. Das Doctag kann am Knoten in der Prozedur oder am zugehörigen Komponente-Knoten angegeben werden. Es kann nicht vererbt werden und muss direkt am Knoten gesetzt werden. Die Syntax der Bedingung muss für den Skriptsprache passen.

@prec/component/state/selected wert, @prec/component/state/checked wert, @prec/component/state/enabled wert, @prec/component/state/editable wert, @prec/component/state/visible wert

Fügt eine Zustandsbedingung zum Knoten in der Definition hinzu. Der Wert muss true oder false sein. Mehrere Zustandsbedingungen sowie @prec/condition werden mit einem logischen und verknüpft. Die Doctags können nicht vererbt werden und müssen direkt am Knoten angegeben werden.

55.6.7.3 Flags zum Hinzufügen oder Ignorieren von Knoten

Wenn ein Knoten auf jeden Fall oder auf keinen Fall in die Definition aufgenommen werden soll oder eine bestehende Definition nicht überschrieben werden soll, können Sie die folgenden Doctags verwenden:

@prec/addNode

Für nicht parametrisierte Check-Knoten und Warten auf Komponente-Knoten, außer Fenster-Komponenten, die andernfalls der Prozeduraufruf-Definition nicht hinzugefügt würden. Das Doctag kann vererbt werden.

@prec/ignore/start und @prec/ignore/end

Alle Knoten zwischen den gekennzeichneten Knoten - einschließlich dieser - werden nicht zur Prozeduraufruf-Definition hinzugefügt. Wenn Sie nur @prec/ignore/start angeben, werden alle Knoten bis zum Ende der Prozedur nicht zur Prozeduraufruf-Definition hinzugefügt.

@prec/ignore

Weder der Knoten noch seine Kindknoten werden zur Prozeduraufruf-Definition hinzugefügt. Bei Prozedur-Knoten wird keine Definition erstellt. Nicht aufnehmbare Knoten oder unparametrisierte Check-Knoten müssen Sie nicht kennzeichnen. Sie werden immer ignoriert.

@prec/duplicate

Nur für Prozedur-Knoten: Der Automatismus erstellt keine Prozeduraufruf-Definition für die Prozedur selbst, berücksichtigt die Knoten in der Prozedur jedoch, wenn sie aus einer anderen Prozedur aufgerufen wird.

@prec/noUpdate

Die entsprechende Prozeduraufruf-Definition wird bei der automatischen Aktualisierung von Definitionen übersprungen. In der Ergebnisliste wird dies mit dem Index "0" markiert. Das Doctag kann an den Prozedur oder den Prozeduraufruf-Definition-Knoten geschrieben werden. Die Funktion ist die gleiche.

55.6.7.4 Flags für Variablen

@prec/parameters/parametername wert

Fügt in der Rubrik set procedure call parameters einen Eintrag für das angegebene Parametername/-wert-Paar hinzu. Das Doctag kann verwendet werden, um weitergereichte Variablen zu ersetzen. Wenn in einem Prozeduraufruf jedoch Werte übergeben werden, hat das Doctag keine Wirkung. Dann werden diese in die Definition geschrieben. Nützlich bei Attributwerten, bei denen nur ein Teil eines Attributs eine Variable ist, siehe zweites Beispiel.

Das Doctag kann vererbt werden.

@prec/parameters/check <CHECKEDSTATE>

@prec/parameters/tableoption <NAME> Aktion: bitte den ersten Teil löschen (wird in OptionTable-$(tableoption) verwendet)

55.6.7.5 Flag für die Priorität

@prec/priority [+|-]zahl

Nur für Prozedur-Knoten: hiermit kann die vom Automatismus ermittelte Priorität überschrieben, beziehungsweise relativ dazu verändert werden: wenn ein "+" dem Wert vorangestellt wird, wird der angegebene Wert dem vom Automatismus ermittelten hinzugefügt, bei einem vorangestellt "-" abgezogen. Ansonsten wird der vom Automatismus ermittelte Wert überschrieben.

Das Doctag wird von Knoten aus Prozeduren oder Packages vererbt. Innere Doctags überschreiben äußere Werte.