GUI Test Studio

Kapitel 8 — Diagnose & Aktionsquellen

Von der automatisch erfassten Exception bis zum Live-Call-Stack: der Ursache auf den Grund gehen.

Schritt 1

.NET-Exceptions automatisch erfassen

Screenshot: Automatisch erfasste .NET-Exception im Diagnose-Ereignis-Dialog

1 2 3

1 Exception-Zähler

2 Fehlermeldung im Klartext

3 Symbolisierte Methodenaufrufe

Nichts geht unbemerkt unter.

GUI Test Studio erkennt .NET-Exceptions der Zielanwendung automatisch mit Hilfe von ClrMD — ganz ohne eigenen Debugger oder Codeänderungen. Ein Zähler im Diagnose-Bereich zeigt jederzeit, wie viele bereits aufgetreten sind.

Ein Klick auf einen Eintrag öffnet die Exception im Detail — mit Fehlermeldung im Klartext und den ersten, bereits symbolisierten Methodenaufrufen.

Schritt 2

Stacktrace, Screenshot & Metriken zum Ereignis

Screenshot: Vollstaendiger Stacktrace mit Screenshot und Ressourcen-Metriken zum Ereigniszeitpunkt

1 2 3

1 Vollständiger Stacktrace

2 Screenshot zum Ereignis

3 Metriken zum Zeitpunkt

Direkt zur Ursache, nicht nur zur Fehlermeldung.

Weiter unten im selben Dialog folgt der vollständige Stacktrace bis in die .NET-Runtime hinein — und ein Screenshot der Zielanwendung genau zum Zeitpunkt der Exception.

Zusätzlich zeigt GUI Test Studio CPU, RAM, Threads, Handles, Module und Unterprozesse exakt zu diesem Moment — so lässt sich die Ursache einordnen, statt nur zu raten.

Schritt 3

Aktionsquellen-Fenster

1 2 3

1 Live-Call-Stack-Fenster

2 Methode + Datei:Zeile

3 Quelle & Call-Stack aufklappen

Welcher Code steckt hinter welchem Klick?

Das eigenständige Aktionsquellen-Fenster zeigt zu jedem Klick oder Tastendruck in der Zielanwendung die tatsächlich ausgeführte Methode — mit Datei und Zeilennummer, aktuellste Aktion oben.

„Quelle anzeigen“ öffnet die passende Codezeile, „Call-Stack“ klappt den vollständigen Aufrufpfad zu dieser Methode auf.

Schritt 4

Detailtiefe-Regler

1 2 3

1 Detailtiefe-Regler

2 Stufe 1 bis 10

3 Mehr erfasste Methodenaufrufe

So viel Detail wie nötig, so wenig wie möglich.

Mit dem Detailtiefe-Regler steuern Sie, wie viele Sekunden rund um jede Maus- oder Tastaturaktion erfasst werden — von Stufe 1 (nur der unmittelbare Moment) bis Stufe 10.

Eine höhere Stufe erfasst entsprechend mehr Methodenaufrufe je Aktion — praktisch, wenn die eigentliche Ursache etwas zeitversetzt zur Aktion selbst liegt.

Schritt 5

Fenster-, Navigations- und Fokus-Tracking

Screenshot: Screenshot-Ansicht zu einem Fokus-Ereignis

1 2 3

1 Fokus-Ereignis erfasst

2 Screenshot-Viewer öffnet sich

3 Zustand zum Zeitpunkt

Jede Bewegung durch die Anwendung nachvollziehbar.

GUI Test Studio protokolliert Fensterwechsel, Navigationsschritte und Fokusänderungen automatisch — inklusive der vollständigen Steuerelement-Eigenschaften des fokussierten Elements.

„Screenshot ansehen“ öffnet zu jedem dieser Ereignisse den Bildschirmzustand der Zielanwendung genau zu diesem Zeitpunkt — praktisch, um einen Ablauf im Nachhinein nachzuvollziehen.

Schritt 6

Debugger-Attach (experimentell)

Screenshot: Debugger-Attach aktiviert mit Hinweistext und Protokoll-Eintrag

1 2 3

1 Debugger-Attach aktivieren

2 Hinweis zu Einschränkungen

3 Ergebnis im Protokoll

Für den tiefsten Einblick, wenn nötig.

Optional hängt sich GUI Test Studio als Debugger an den ausgewählten Zielprozess an, um zusätzlich native Exceptions zu erfassen — als experimentell gekennzeichnet.

Ist bereits ein anderer Debugger (z. B. Visual Studio) angehängt, kollidiert der Attach-Versuch und schlägt fehl — auch das erscheint als eigener Eintrag im Diagnose-Protokoll.

Verstanden

Der Ursache auf den Grund gegangen

Im nächsten Kapitel geht es um Reconnect.

Jetzt testen →