Entwicklerkonsole & Netzwerküberprüfung

Die Entwicklerkonsole (Developer Console) ist ein ausklappbares Tool-Fenster, das neben einer laufenden Ausführung angezeigt wird und Ihnen direkten, KI-gestützten Zugriff auf den Browser gibt, den der Runner steuert. Es ist der richtige Ort, wenn Sie eine interaktive Aufnahmesitzung debuggen, eine Seite erkunden, die Sie noch nie getestet haben, oder einen schwierigen Selektor erstellen.

Für abgeschlossene Ausführungen gibt es einen separaten Timing-Analyse-Dialog, mit dem Sie den Netzwerkverkehr und die Warteereignisse des Laufs untersuchen können. Beide Tools werden auf dieser Seite behandelt.

Öffnen der Entwicklerkonsole

Die Entwicklerkonsole ist nur verfügbar, während eine Testausführung läuft. Es gibt zwei Möglichkeiten, sie zu öffnen:

• Über die Symbolleiste des Log-Popovers – das Entwicklerkonsolen-Symbol (nur sichtbar, während die Ausführung läuft). Siehe Log lesen.
• Über den Browser-Frame in der Ausführungsdetailansicht – die Schaltfläche für die Entwicklerkonsole in der Symbolleiste des simulierten Browsers.

Die Konsole öffnet sich in einem separaten Browserfenster, damit sie nicht mit der Ausführungsansicht um Platz konkurriert. Das Schließen des Konsolenfensters hat keine Auswirkungen auf die laufende Ausführung.

Wenn für die Ausführung bereits ein Konsolenfenster geöffnet ist, fokussiert ein Klick auf das Symbol dieses Fenster, anstatt ein zweites zu öffnen.

Die drei Registerkarten

Das Konsolenfenster verfügt über drei Registerkarten. Diese sind unabhängig voneinander – Sie können die Registerkarte "KI-Tools" mitten im Prozess verlassen, zum DOM-Inspektor wechseln, um einen Selektor zu prüfen, und zurückkehren, ohne den Status zu verlieren.

KI-Tools

Die Registerkarte "KI-Tools" bietet ein Paar von Mini-Prompts, die Sie auf die Live-Seite anwenden können.

• Element-Finder. Beschreiben Sie ein Element in einfacher Sprache (z. B. "der Speichern-Button in der oberen rechten Ecke des Dialogs") und die KI liefert einen potenziellen XPath sowie einen hervorgehobenen Screenshot, der zeigt, was sie ausgewählt hat. Verwenden Sie dies, um zu überprüfen, ob Ihre Beschreibung eindeutig ist, bevor Sie sie als Schritt übernehmen.
• Assertion-Tester. Schreiben Sie einen Satz im Expect-Stil (z. B. "der Warenkorb enthält genau 3 Positionen") und die KI bewertet diesen anhand des aktuellen Screenshots und liefert ein Ergebnis (Bestanden/Nicht bestanden) mit einer Erklärung. Verwenden Sie dies, um die Formulierung einer Assertion zu validieren, bevor Sie sie als Schritt aufzeichnen.

Beide Abläufe sind schreibgeschützt – sie ändern weder den Test noch die Seite.

tipp

Die Registerkarte "KI-Tools" ist der schnellste Weg, um während der Aufnahme an der Formulierung der Prompts zu arbeiten. Wenn der Element-Finder mit Ihrer Beschreibung das falsche Element auswählt, schreiben Sie die Beschreibung so lange um, bis das richtige ausgewählt wird, und übernehmen Sie diese Formulierung dann in einen aufgezeichneten Schritt.

DOM-Inspektor

Eine Live-Ansicht des DOM der Seite, auf der sich der Runner gerade befindet, durch die navigiert werden kann.

Funktionen:

• Baumansicht. Der DOM-Baum mit aufklappbaren Knoten, Attributen und Textinhalten.
• Frame-Auswahl. Ein Dropdown-Menü mit jedem iframe / Shadow-DOM-Root auf der Seite; wählen Sie eines aus, um darin zu inspizieren. Der Haupt-Frame ist die Standardeinstellung.
• Suche. Suchen Sie nach Tag-Name, Attribut oder Textinhalt.
• Klicken zum Lokalisieren. Klicken Sie auf eine beliebige Stelle im Screenshot der Ausführungsansicht, und der entsprechende DOM-Knoten wird im Inspektor hervorgehoben. Umgekehrt funktioniert dies ebenfalls: Ein Klick auf einen Knoten im Inspektor hebt diesen im Screenshot hervor.
• Kopieren. Kopieren Sie XPath / outer HTML / Attribute des ausgewählten Knotens.

Der Inspektor ist schreibgeschützt – Sie können das DOM nicht darüber bearbeiten. Um Änderungen an der Seite auszuführen, verwenden Sie die Registerkarte "Konsole".

Konsole

Eine Standard-JavaScript-Konsole, die mit der Seite verbunden ist. Geben Sie einen beliebigen Ausdruck ein und sehen Sie das Ergebnis. Häufige Anwendungsbereiche:

• Anwendungsstatus prüfen – z. B. einen Redux-Store, eine Vue / Angular-Komponente oder eine Variable auf Window-Ebene lesen.
• Einmalige Hilfsfunktionen auslösen – z. B. ein hartnäckiges Cookie löschen oder ein ausgeblendetes Flag während einer Aufnahmesitzung zurücksetzen.
• Den Wert eines Parameters überprüfen, den der Test später von der Seite lesen wird.

Alles, was Sie hier tun, geschieht im echten Browser, den der Runner verwendet. Wenn Sie den Status verändern, wird der nächste Schritt, den der Runner ausführt, Ihre Änderungen sehen.

Wann man die Entwicklerkonsole öffnet

Die Konsole ist in folgenden Situationen am nützlichsten:

• Sie zeichnen einen neuen Test auf und der KI-Element-Finder wählt ständig das falsche Element aus. Verwenden Sie die Registerkarte "KI-Tools", um die Beschreibung umzuformulieren, bis der Finder das richtige auswählt, und übernehmen Sie dann diese Formulierung.
• Sie suchen während der Aufnahme nach einer Ursache für den Fehler "keine Kandidaten gefunden". Verwenden Sie den DOM-Inspektor, um zu prüfen, ob das Element tatsächlich existiert, welche Attribute es hat und in welchem Frame es sich befindet.
• Sie müssen die Formulierung einer Assertion überprüfen. Verwenden Sie den KI-Assertion-Tester, bevor Sie den Schritt übernehmen.
• Sie müssen die Seite auf eine Weise einrichten, die über die Benutzeroberfläche umständlich ist – z. B. ein Banner ausblenden, ein Feature-Flag setzen, ein Datum in der Anwendung erzwingen. Verwenden Sie die Registerkarte "Konsole", während der Browser entsperrt ist.

Die Konsole ist nicht nützlich für abgeschlossene Ausführungen – zu diesem Zeitpunkt ist der Browser geschlossen, nur die Aufzeichnung bleibt bestehen. Verwenden Sie für abgeschlossene Läufe den Dialog "Timing-Analyse" (nächster Abschnitt).

Timing-Analyse (abgeschlossene Läufe)

Für abgeschlossene Läufe (Bestanden oder Nicht bestanden) ermöglicht der Timing-Analyse-Dialog das Untersuchen der Netzwerkereignisse während der Ausführung.

Öffnen Sie ihn über das ⓘ Info-Popover eines Tests im linken Bereich (Diagramm-Symbol, nur für abgeschlossene Läufe sichtbar).

Der Dialog hat zwei Registerkarten:

Zusammenfassung

Übergeordnete Summen für den Lauf: Wie viele Netzwerkanfragen, wie viele Fehlgeschlagene, wie viel Zeit wurde mit Warten auf das Netzwerk vs. Warten auf die UI verbracht, schnellste/langsamste Anfragen und welche Schritte die höchsten Netzwerkkosten verursachten. Nützlich, um z. B. einen einzelnen langsamen API-Aufruf zu identifizieren, der die Testlaufzeit dominiert.

Details

Eine filterbare Zeitleiste jedes erfassten Ereignisses:

• Netzwerkanfragen – URL, HTTP-Methode, Statuscode, Dauer, Ressourcentyp (XHR, fetch, document, script, image, …) und ggf. der Grund für das Scheitern.
• Warteereignisse – die Auto-Waiting-Entscheidungen, die der Runner getroffen hat (welche Bedingung wurde abgewartet, wie lange, ob ein Timeout auftrat).

Filter-Chips oben in der Registerkarte "Details" ermöglichen es Ihnen, die Ansicht einzugrenzen auf:

• Einen bestimmten Schritt – nur Anfragen sehen, die während dieses Schrittes ausgelöst wurden.
• Einen bestimmten Ereignistyp – nur Netzwerkanfragen, nur Warteereignisse.
• Einen bestimmten Ressourcentyp – nur XHR / fetch, nur Dokument-Ladevorgänge, nur Bilder, …
• Nur Fehlgeschlagene – nur Anfragen, die einen Fehlerstatus zurückgegeben haben oder nie abgeschlossen wurden.
• Nur Timeouts – nur Warteereignisse, die ihr Zeitlimit erreicht haben.

Die Zeitleistenansicht ordnet Anfragen und Warteereignisse dem auslösenden Schritt zu, sodass Sie auf einen Blick Fragen beantworten können wie: "War Schritt 5 langsam wegen des Netzwerks oder wegen des Seiten-Renderings?"

tipp

Der nützlichste Filter ist Nur Fehlgeschlagene, wenn ein Schritt laut KI erfolgreich war, der Bildschirm aber fehlerhaft aussah. Ein 500er-Fehler bei einem Hintergrund-XHR korreliert oft mit dem für den Benutzer sichtbaren Fehler, selbst wenn der Schritt selbst als erfolgreich markiert wurde.

Netzwerkverkehr während einer laufenden Ausführung

Netzwerkanfragen während einer laufenden Ausführung werden nicht direkt in den Registerkarten der Entwicklerkonsole angezeigt. Sie werden erfasst und sind im Dialog "Timing-Analyse" sichtbar, nachdem die Ausführung abgeschlossen ist. Wenn Sie das Netzwerkverhalten live untersuchen müssen, verwenden Sie die eigenen Entwicklertools des Browsers (öffnen Sie diese über Ihren normalen F12-Shortcut im eingebetteten Browser).

Was die Konsole kann und was nicht

Die Entwicklerkonsole ist eine Debugging-Hilfe, keine Methode, um einen Test dauerhaft zu ändern. Alles, was Sie in der Konsole tun, ist lokal auf eine laufende Browserinstanz beschränkt:

• ✅ Sehen, was der Runner sieht – gleiches DOM, gleicher Status.
• ✅ Die Seite manuell steuern (Registerkarte "Konsole" – JavaScript), während der Browser entsperrt ist.
• ✅ Mit der Registerkarte "KI-Tools" nach Elementen suchen und Beschreibungen ausprobieren.
• ❌ Die Testdefinition ändern. Verwenden Sie dafür die Aufnahme-UI oder die Registerkarte "Schritte".
• ❌ Assertions gegen historische Screenshots erneut abspielen. Der KI-Assertion-Tester läuft gegen den aktuellen Live-Screenshot.
• ❌ Netzwerkverkehr in Echtzeit sehen. Verwenden Sie die Timing-Analyse nach dem Lauf oder die nativen Entwicklertools des Browsers live.

Siehe auch

• Log lesen – das eigene Log des Runners; öffnet die Entwicklerkonsole über dessen Symbolleiste.
• Aufnahme – der interaktive Aufnahmeablauf, mit dem die Entwicklerkonsole zusammenarbeitet.
• Auto-Waiting – was die Warteereignisse in der Timing-Analyse bedeuten.
• Triage bei fehlgeschlagenen Ausführungen – wenn Netzwerkfehler mit Testfehlern korrelieren.