GUI Test Studio / Tipps & Tricks
Für den täglichen Einsatz

Mehr aus GUI Test Studio herausholen

Kleine Einstellungen mit großer Wirkung — von der Treffsicherheit der Bildanker-Suche bis zur frei anpassbaren Arbeitsfläche.

Aufnahme

Hotkeys während der Aufnahme

Alle drei Hotkeys funktionieren jederzeit während der Aufnahme, unabhängig davon, welches Fenster gerade fokussiert ist.

Bildanker-Suche

Treffsicherheit feinjustieren

Bei der Wiedergabe wird zuerst in der Nähe der ursprünglich aufgezeichneten Position gesucht, erst danach im gesamten Fenster — das beschleunigt die Suche und reduziert Fehltreffer bei wiederkehrenden UI-Elementen. Zwei Stellschrauben in den allgemeinen Einstellungen:

💡

Tipp: Schlägt ein Schritt nach einem Update öfter fehl, lohnt sich ein Blick auf die im Bericht angezeigte Trefferquote — oft hilft schon eine leicht geringere Mindest-Trefferquote, statt den Schritt neu aufzuzeichnen.

Wiedergabe

„Bei Fehler stoppen“ gezielt einsetzen

Standardmäßig bricht ein Testlauf beim ersten fehlgeschlagenen Schritt ab. Für eine vollständige Übersicht über alle Probleme in einem Testfall lässt sich „Bei Fehler stoppen“ in der Kopfleiste deaktivieren — der Testfall läuft dann komplett durch, und der Bericht zeigt alle fehlgeschlagenen Schritte auf einen Blick statt nur den ersten.

Metrik-Overlay

Ressourcen direkt am Mauszeiger im Blick

Das optionale Metrik-Overlay (Checkbox „Metrik-Overlay“) zeigt CPU, RAM, Threads, Handles, Module und laufende .NET-Exceptions direkt neben dem Mauszeiger — standardmäßig klickdurchlässig, damit es aufgezeichnete oder abgespielte Klicks nicht abfängt.

Bedienkomfort

Arbeitsfläche anpassen

Zwischen Hauptbereich und Testlauf-Protokoll lässt sich die Höhe per GridSplitter frei ziehen — praktisch, wenn während eines Laufs viele Protokollzeilen gleichzeitig sichtbar sein sollen. Ebenso lassen sich die Spalten zwischen Testschritten/Eigenschaften und dem Diagnose-Panel per Splitter verbreitern oder schmaler ziehen.

RAM-Schwellwerte

Sinnvolle Warnschwellen setzen

Die RAM-Warnschwellen in den Projekteigenschaften sind bewusst getrennt für x86- und x64-Zielprozesse, da 32-Bit-Anwendungen durch ihren begrenzten Adressraum naturgemäß deutlich früher kritisch werden als 64-Bit-Anwendungen. Ein guter Ausgangspunkt: den normalen RAM-Verbrauch der Zielanwendung im Leerlauf beobachten und den Schwellwert mit ausreichend Puffer knapp darüber ansetzen — 0 deaktiviert die Warnung vollständig, falls (noch) keine sinnvolle Grenze feststeht.

Weiter geht's

Als Nächstes

Jetzt starten

Ihr erster Testlauf wartet

Kontakt aufnehmen →