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:
-
Die Menge aller Testfälle.
-
Die Menge aller Testfälle, die im ActualLog als Failed gekennzeichnet sind.
-
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.