TQL-Praxisbeispiele

Die Beispiele in diesem Kapitel behandeln typische Problemlösungen mittels der TQL und beziehen sich auf die Beispielapplikation KFZ-Angebotsrechner. Für die Beispiele wurden die Objekte Testfall und Modul ausgewählt, um nach deren Eigenschaften zu suchen.

Die folgende Grafik zeigt für jede Hierarchieebene jene Suchabfrage, die als Ergebnis layer 4 liefert.

Suche in Abhängigkeit vom Ausgangsobjekt

Einzelne Abfragen können beliebig oft aneinandergereiht und kombiniert werden.

Für die nachfolgenden Beispiele ist das Ausgangsobjekt der Suche, sofern nicht explizit angegeben, der Ordner Testfälle.

Testfall-Name

Ausgangssituation

Beispiel - Ausgangssituation

Aufgabe

Suchen Sie nach allen Testfällen im Ordner Testfälle, die den Namen Datenquelle Excel besitzen.

Lösung

=>SUBPARTS:TestCase[Name=="Datenquelle Excel"]

Hierarchieebenen

Ausgangssituation

Beispiel - Ausgangssituation

Aufgabe

Suchen Sie nach allen Testfällen mit dem Namen Datenquelle Excel, welche sich genau drei Ebenen unterhalb des Ordners Testfälle befinden.

Lösung

->SUBPARTS->SUBPARTS->SUBPARTS:TestCase[Name=="Datenquelle Excel"]

Die explizite Auswahl einer Ebene erfolgt mit dem einfachen arrowOperator->. Die Anzahl der Aufrufe bestimmt die Ebene.

Exklusion

Ausgangssituation

Beispiel - Ausgangssituation

Aufgabe

Suchen Sie nach allen Testfällen, die nicht den Namen Datenquelle Excel beinhalten.

Lösung

=>SUBPARTS:TestCase[Name!="Datenquelle Excel"]

Testschrittwerte, XTestschrittwert, XTestschrittwert Platzhalter

Ausgangssituation

Beispiel - Ausgangssituation

Aufgabe

Suchen Sie nach allen Testfällen, die einen Testschrittwert mit dem Wert Krafträder beinhalten.

Lösung

Zuerst wird nach allen Testschrittwerten mit dem entsprechenden Wert gesucht. Es wird nach Testfällen gesucht, daher muss das übergeordnete Objekt in allen Ebenen mit "=>SUPERPART" angesprochen werden.

=>SUBPARTS:TestStepValue[Value=="Kraftrad"]=>SUPERPART:TestCase

Alternative Variante

Mit RETURN wird festgelegt, welche Objekte zurückgegeben werden sollen.

=>RETURN SUBPARTS:TestCase=>SUBPARTS:TestStepValue[Value=="Kraftrad"]

Die Anweisung RETURN wird nicht in der Autovervollständigung angezeigt. Daher ist ein nachfolgendes Leerzeichen erforderlich.

Typ Vorlage

Ausgangssituation

Beispiel - Ausgangssituation

Aufgabe

Suchen Sie nach allen Testfällen, welche Vorlagen (Templates) sind. Die Groß-/Kleinschreibung soll dabei ignoriert werden.

Lösung

=>SUBPARTS:TestCase[IsTemplate=i="true"]

Anhand einer Testfalleigenschaft werden die gesuchten Elemente gefunden.

Der Operator "=i=" steht für einen Vergleich, der die Groß-/Kleinschreibung ignoriert.

Verknüpfte Suche

Ausgangssituation

Beispiel - Ausgangssituation

Aufgabe

Suchen Sie nach allen Testfällen, die Vorlagen (Templates) sind und den Testfallnamen LKW 01 haben.

Lösung

=>SUBPARTS:TestCase[(IsTemplate=="True") AND (Name=="LKW 01")]

LockedBy

Aufgabe

Widerrufen Sie das Auschecken des OwnedItem (Ausführungslisten, Ausführungs-Logs) von nur einem bestimmten Benutzer.

Lösung

=>RETURN SUBPARTS:OwnedItem[CheckOutState=="CheckedOut"]->LockedBy[Name=="samuel_smith"]

Teilzeichenfolge

Ausgangssituation

Beispiel - Ausgangssituation

Aufgabe

Suchen Sie alle Testfälle, deren Namen PKW enthalten.

Lösung

=>SUBPARTS:TestCase[Name=?"PKW"]

Reguläre Ausdrücke

Ausgangssituation

Beispiel - Ausgangssituation

Aufgabe

Suchen Sie alle Testfälle, deren Namen mit PKW beginnen.

Lösung

=>SUBPARTS:TestCase[Name=~"^PKW"]

Suche nach allen Testfällen, die ein bestimmtes Modul verwenden

Ausgangssituation

Beispiel - Ausgangssituation (Testfälle)

Beispiel - Ausgangssituation (Module)

Aufgabe

Suchen Sie nach allen Testfällen, die das Modul Fahrzeugdaten verwenden.

Lösung

Ausgangspunkt der Suche ist der Ordner Module.

=>SUBPARTS:Module[Name=="Fahrzeugdaten"]
=>AllReferences=>SUPERPART:TestCase

Lösung - Beschreibung

Zuerst werden alle Module gesucht, die den Namen Fahrzeugdaten haben. Der zweite ArrowOperator verweist auf alle referenzierten Objekte (Testschritte, Modulattribute, die ObjectMap, Ordner und Benutzer). Für die Aufgabenstellung relevant sind nur die Testschritte, da diese eindeutig mit den gesuchten Testfällen verknüpft sind. Der Zugriff auf diese übergeordneten Elemente erfolgt über "=>SUPERPART:TestCase".

Alternative Lösung

Ausgangspunkt der Suche ist der Ordner Module.

=>SUBPARTS:Module[Name=="Fahrzeugdaten"]->TestSteps=>SUPERPART:TestCase

Anmerkung

Sollen alle Testfälle gefunden werden, die mindestens eines der in der Suche angegebenen Module verwenden, kann eine Vereinigungsmenge gebildet werden.

Aufgabe

Suchen Sie nach allen Testfällen, die Modul1 und/oder Modul2 verwenden.

Lösung

Der Ausgang der Suche ist der Ordner Testfälle.

->UNION(=>return SUBPARTS:TestCase=>SUBPARTS:TestStep->Module[Name=="Modul1"],=>return SUBPARTS:TestCase=>SUBPARTS:TestStep->Module[Name=="Modul2"])

Alle XModule suchen

Aufgabe

Suchen Sie alle XModule.

Lösung

=>SUBPARTS:XModules

Tricentis Tosca verwendet Module und XModule. Weitere Informationen finden Sie hier: siehe Kapitel " Module erstellen und verwalten".

Suche nach Eigenschaften/Properties von Objekten

Ausgangssituation

Beispiel - Ausgangssituation

Aufgabe

Eine benutzerdefinierte Testfall-Eigenschaft hat den Namen TestProp1. Gesucht werden alle Testfälle, bei denen diese Eigenschaft den Wert Test-01 hat. Die Groß-/Kleinschreibung soll dabei ignoriert werden.

Lösung

Ausgangspunkt der Suche ist der Ordner Testfälle.

=>SUBPARTS:TestCase[TestProp1=i="test-01"]

Ausgangssituation

Beispiel - Ausgangssituation

Aufgabe

Eine benutzerdefinierte Eigenschaft eines Testfall-Ordners hat den Namen TestProp2. Gesucht werden alle Testfall-Ordner, bei denen diese Eigenschaft den Wert Test-02 hat. Die Groß-/Kleinschreibung soll dabei ignoriert werden.

Lösung

Ausgangspunkt der Suche ist das Projektwurzelelement.

=>SUBPARTS:TCFolder[TestProp2=i="test-02"]

Ausgangssituation

Beispiel - Ausgangssituation

Aufgabe

Eine benutzerdefinierte Modul Eigenschaft hat den Namen TestProp3. Gesucht werden alle Module, bei denen diese Eigenschaft den Wert Test-03 hat. Die Groß-/Kleinschreibung soll dabei ignoriert werden.

Lösung

Ausgangspunkt der Suche ist der Ordner Module.

=>SUBPARTS:Module[TestProp3=i="test-03"]

Suche nach TechnicalIDs

Ausgangssituation

Beispiel - Ausgangssituation

Beispiel - Ausgangssituation

Aufgabe

Suche nach einer bestimmten TechnicalID TechnicalID=YearOfConstruction.

Lösung

Ausgangspunkt der Suche ist der Ordner Module.

=>SUBPARTS[TechnicalId=="ID=YearOfConstruction"]

Zusatzaufgabe

Es sollen übergeordnete Module gefunden werden.

Lösung

Ausgangspunkt der Suche ist der Ordner Module. Der Ausdruck wird ergänzt um =>SUPERPART:Module

Endgültige Lösung:

=>SUBPARTS[TechnicalId=="ID=YearOfConstruction"]=>SUPERPART:Module

Anmerkung

Mehrere, verschiedene Objekte haben das Attribut TechnicalID. Demgemäß ist die Position der TechnicalIDs vom Objekt abhängig und kann unterschiedlich sein.

Ausgangssituation

Beispiel - Ausgangssituation

Aufgabe

Suche nach TechnicalIDs bei Modulen. Diese TechnicalID liegt unter der ObjectMap.

Lösung

Ausgangspunkt der Suche ist der Ordner Module.

=>SUBPARTS:ObjectMap[TechnicalId=="Caption=Tricentis Angebotsrechner*"]

Ausgangssituation

Beispiel - Ausgangssituation

Aufgabe

Suche nach TechnicalIDs von Modulattributen. Diese TechnicalID liegt unter dem ObjectControl.

Lösung

Ausgangspunkt der Suche ist der Ordner Module.

=>SUBPARTS:ObjectControl[TechnicalId=="ID=edit_price"]

Suche nach Modulen, die nicht in Testfällen verwendet werden

Ausgangssituation

Beispiel - Ausgangssituation (Module)

Beispiel - Ausgangssituation (Testfälle)

Aufgabe

Suche nach allen noch nicht in Testfällen verwendeten Modulen.

Lösung

Ausgangspunkt der Suche ist der Ordner Module.

=>COMPLEMENT(=>SUBPARTS:Module,=>RETURN SUBPARTS:Module->TestSteps)

Lösung - Beschreibung

Mit COMPLEMENT wird eine Komplementärmenge gesucht. Die erste Abfrage sucht alle Module während über die zweite Abfrage alle in Testfällen verwendeten Module gesucht werden. Die Komplementärmenge dieser beiden Abfragen entspricht allen Modulen, die noch nicht in einem Testfall verwendet werden.

Suche nach Testfällen, die nicht mit Anforderungen verknüpft sind

Ausgangssituation

Beispiel - Ausgangssituation (Anforderungen)

Beispiel - Ausgangssituation (Testfälle)

Aufgabe

Suche nach allen Testfällen, die noch nicht mit Anforderungen verknüpft sind. (Für die Suche muss das Tosca Requirements Management AddIn verfügbar sein.)

Lösung

Ausganspunkt der Suche ist das Projektwurzelelement.

=>COMPLEMENT(=>SUBPARTS:TestCase, =>SUBPARTS:RequirementTestCaseLink->TestedBy)

Lösung - Beschreibung

Mit COMPLEMENT wird eine Komplementärmenge gesucht. Die erste Abfrage sucht alle Testfälle während die zweite Abfrage alle Testfälle sucht die einen RequirementTestCaseLink besitzen. Die Komplementärmenge dieser beiden Abfragen entspricht allen Testfällen, die noch nicht mit einem RequirementTestCaseLink verknüpft sind. Mittels TestedBy wird direkt auf die Testfälle referenziert.

Suche nach allen Testfällen, die keiner Ausführungsliste zugeordnet sind

Ausgangssituation

Beispiel - Ausgangssituation

Aufgabe

Suche nach allen Testfällen, die noch keiner Ausführungsliste zugeordnet sind.

Lösung

Ausgangspunkt der Suche ist der Ordner Testfälle.

=>COMPLEMENT(=>SUBPARTS:TestCase, =>RETURN SUBPARTS:TestCase->ExecutionEntries)

Lösung - Beschreibung

Mit COMPLEMENT wird eine Komplementärmenge gesucht. Die erste Abfrage sucht alle Testfälle während über die zweite Abfrage alle Testfälle gesucht werden, die mit einem ExecutionEntry verknüpft sind. Die Komplementärmenge dieser beiden Abfragen entspricht allen Testfällen, die noch keinen ExecutionEntry besitzen.

Suche nach allen Ausführungseinträgen, die seit einer bestimmten Ausführung Ihren Ausführungsstatus geändert haben

Aufgabe

Suche nach allen Ausführungseinträgen, die Ihren Ausführungsstatus zwischen zwei verschiedenen Testausführungen von OK auf Fehlgeschlagen geändert haben.

Lösung

Ausgangspunkt der Suche ist der Ordner Ausführungslisten.

=>return SUBPARTS:ExecutionEntry->INTERSECTION(
->TestCase,
=>SUPERPART:ExecutionList->ExecutionLogs[Name == "ActualLog"]->TestCaseLogs[Result == "Failed"]->ExecutedTestCase,=>SUPERPART:ExecutionList->ExecutionLogs[Name == "Run1"]->TestCaseLogs[Result == "Passed"]->ExecutedTestCase

)

Lösung - Beschreibung

Zurückgegeben werden alle Unterelemente vom Typ Ausführungseintrag, die auf ein Element zeigen, das durch INTERSECTION definiert wird.

Mit INTERSECTION wird die Schnittmenge von drei Teilergebnisse beschrieben:

  1. Die Menge aller Testfälle.

  2. Die Menge aller Testfälle, die im ActualLog als Failed gekennzeichnet sind.

  3. Die Menge aller Testfälle, die im Ausführungslog Run1 als Passed gekennzeichnet wurden.

Der Ausdruck =>SUPERPART wird benötigt, um von den ExecutionEntries zu den ExecutionLists zu gelangen.

Das ergibt alle Testfälle, die im ActualLog als Failed ausgeführt wurden, die bei der Ausführung Run1 aber noch als Passed gelaufen sind. In einem anderen Kontext kann auch die umgekehrte Suche durchaus praktisch sein.

In einer ähnlichen Abfrage kann im ActualLog nach Testfällen gesucht werden, die noch nicht ausgeführt wurden, für die es jedoch im Log Run1 ein Ergebnis gibt.

=>return SUBPARTS:ExecutionEntry->INTERSECTION(

->TestCase,

=>SUPERPART:ExecutionList->ExecutionLogs[Name == "ActualLog"]
->TestCaseLogs[(Result != "Failed") AND (Result != "Passed")]->ExecutedTestCase,

=>SUPERPART:ExecutionList->ExecutionLogs[Name == "Run1"]
->TestCaseLogs[(Result == "Passed") OR (Result == "Failed")]->ExecutedTestCase
)

Suche nach Testfällen, die mit Anforderungen verknüpft aber noch nicht in einer Ausführungsliste vorhanden sind

Aufgabe

Es wird nach Testfällen gesucht, die mit einer Anforderung verknüpft sind, für die es jedoch noch keinen Ausführungseintrag in einer Ausführungsliste gibt.

Lösung

Ausgangspunkt ist das Projektwurzelelement:

->PROJECT->COMPLEMENT(=>SUBPARTS:RequirementSet[NodePath==“/Anforderungen/RS"]=>SUBPARTS:RequirementTestCaseLink->TestedBy,
=>SUBPARTS:RequirementSet[NodePath==“/Anforderungen/RS"]->UnconfiguredExecutionListLinks->ExecutedBy=>SUBPARTS:ExecutionEntry->TestCase)

Lösung - Beschreibung

Mit COMPLEMENT wird eine Komplementärmenge gesucht.

Die erste Abfrage sucht ausgehend vom Projektwurzelelement rekursiv nach Anforderungen, die sich in einem Anforderungs-Set RS befinden und mit Testfällen verknüpft sind.

Die zweite Abfrage sucht wieder ausgehend vom Projektwurzelelement nach Ausführungslisten die mit einem Anforderungsset RS verknüpft sind. Es werden alle Testfälle zurückgegeben, die mit einem Ausführungseintrag aus einer verknüpften Ausführungsliste verbunden sind.

Testfälle ohne Verknüpfung zu Ausführungseinträgen

Suche nach Vorkommnissen bestimmter Werte

Aufgabe

Es wird nach Objekten gesucht, deren Wert einen bestimmten Wert beinhaltet.

Lösung

->SUBPARTS:OwnedItem['<ANY>'=="letter" OR '<ANY>'=="number"]

Lösung - Beschreibung

Diese Abfrage sucht eine Ebene unterhalb des selektierten Elements alle Objekte, deren Wert entweder letter oder number oder beide Werte beinhaltet.

Suche nach Testkonfigurationsparametern mit bestimmten Werten

Aufgabe

Es sollen alle Testfälle gefunden werden, die einen Testkonfigurationsparameter mit einem bestimmten Wert besitzen. Vererbte Werte sollen berücksichtigt werden.

Lösung

=>SUBPARTS:TestCase[EVALCP("Browser") == "InternetExplorer"]

Lösung - Beschreibung

Diese Abfrage sucht in allen Ebenen unterhalb des selektierten Elements nach Testfällen, die einen Testkonfigurationsparameter Browser mit dem Wert InternetExplorer besitzen.

Aufgabe

Es sollen alle Testfälle gefunden werden, die einen initial angelegten Testkonfigurationsparameter mit einem bestimmten Wert besitzen. Vererbte Werte sollten bei der Suche nicht berücksichtigt werden.

Lösung

=>SUBPARTS:TestCase[Browser == "InternetExplorer"]

Lösung - Beschreibung

Diese Abfrage sucht in allen Ebenen unterhalb des selektierten Elements nach Testfällen, die einen initial angelegten Testkonfigurationsparameter Browser mit dem Wert InternetExplorer besitzen.

Suche nach Modulen, die keinem Testfall zugeordnet sind

Aufgabe

Es soll herausgefunden werden, ob es Module gibt, die keinem Testfall zugeordnet sind.

Lösung

=>SUBPARTS:Module[COUNT("TestSteps")==0]

Lösung - Beschreibung

Mit =>SUBPARTS:Module wird nach allen Modulen gesucht, die sich unterhalb des ausgewählten Elements befinden.

Mit dem Ausdruck [COUNT("TestSteps")==0] wird nach Modulen gesucht, die nicht mit Testschritten verknüpft sind.