Triage bei fehlgeschlagener Ausführung
Eine fehlgeschlagene Ausführung ist eine Information, kein Urteil. Diese Seite erläutert, wie Sie herausfinden, warum ein Schritt fehlgeschlagen ist und was Sie ändern müssen, damit der nächste Durchlauf erfolgreich ist – ohne den Cache zu leeren, den Test von Grund auf neu zu schreiben oder den Support zu kontaktieren, wenn es nicht nötig ist.
Der Triage-Kreislauf in einem Bild
┌──────────────────────────────────────────────────────────┐
│ Pop-over des fehlgeschlagenen Schritts öffnen │
└──────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ Ergebnis + Erklärung lesen │
└──────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────┐
│ War die KI verwirrt oder war│
│ die Seite tatsächlich defekt?│
└──────────────────────────────┘
↓ ↓
KI verwirrt Seite defekt
────────────── ──────────
• Tab "Warnings" • In der App verifizieren
• Cache für den Schritt löschen • Fehler melden (Bug)
• Beschreibung umschreiben • Als bekannten Fehler markieren
• Schritt-Empfehlung abrufen
↓
┌──────────────────────────────────────────────────────────┐
│ Erneuter Lauf — komplett, nur fehlgeschlagene oder │
│ ab dem Schritt (Aufzeichnung) │
└──────────────────────────────────────────────────────────┘
Der Rest dieser Seite ist lediglich eine Erweiterung dieses Kreislaufs.
Schritt 1 — das Fehlersignal lesen
Klicken Sie auf die Karte des fehlgeschlagenen Schritts (entweder in der Zeitachse der Schritte oder im linken Bereich), um das Schritt-Detail-Pop-over zu öffnen, und lesen Sie dann die drei Signalfelder:
| Feld | Was es Ihnen mitteilt |
|---|---|
| Result | Das Urteil der KI über den Schritt – Passed (bestanden), Failed (fehlgeschlagen) mit einer einzeiligen Zusammenfassung ("Expected button to be visible, but it was not"). |
| Explanation for result | Die Begründung der KI. Hier erfahren Sie, warum sie das Urteil gefällt hat – nach welchem Element sie gesucht hat, was sie beobachtet hat und was sie verglichen hat. |
| Suggestion for better description | Eine optionale, KI-generierte Umschreibung des Schritts. Oft deutet die KI hier an, dass die Beschreibung des Schritts mehrdeutig war. |
Die Kombination aus Ergebnis und Erklärung deutet fast immer auf eine von drei Grundursachen hin:
- Die Schrittbeschreibung war mehrdeutig – die KI hat das falsche Element ausgewählt, die falsche Behauptung aufgestellt oder "Klicke auf den Warenkorb" als "Klicke auf das Icon" statt als "Klicke auf den Button" interpretiert.
- Der Selektor-Cache ist veraltet – die KI hat einen zwischengespeicherten XPath wiederverwendet, der nicht mehr auf das beabsichtigte Element zeigt (typischerweise nach einer UI-Änderung).
- Die Anwendung ist tatsächlich defekt – das Element ist nicht vorhanden, oder der Arbeitsablauf funktioniert wirklich nicht.
Die nächsten Abschnitte behandeln das Vorgehen in jedem dieser Fälle.
Schritt 2 — den Tab "Warnings" prüfen
Wenn das Schritt-Pop-over einen Tab Warnings (Warnungen) enthält, öffnen Sie ihn. Der Runner fügt nur dann Warnungen hinzu, wenn er etwas erkannt hat, bei dem die KI selbst unsicher war. Häufige Warnungstypen:
| Warnung | Was sie bedeutet | Was zu tun ist |
|---|---|---|
| Multiple elements found | Die Elementbeschreibung passte auf mehr als ein Element auf der Seite; der Runner wählte das am besten bewertete aus. | Machen Sie die Beschreibung spezifischer (Container, Label, Position angeben). Nutzen Sie das Daumen-hoch/runter-Feedback beim richtigen Element. |
| DOM unstable | Die Seite wurde noch neu geladen, als die Aktion ausgeführt wurde. | Fügen Sie ein "Wait" hinzu oder prüfen Sie, ob das auto-waiting durch eine Animation oder Polling verhindert wird. |
| Cache semantic mismatch | Der gecachte XPath und der frisch extrahierte XPath sind sich nicht einig, welches das richtige Element ist. | Öffnen Sie den Cache-Info-Dialog und überprüfen oder löschen Sie den veralteten Eintrag. Siehe Schritt 3. |
| Fallback model used | Das primäre KI-Modell ist fehlgeschlagen (Rate Limit, Fehler); das konfigurierte Fallback wurde stattdessen ausgeführt. | Normalerweise nichts – seien Sie sich dessen nur bewusst. Wiederholte Fehler bedeuten, dass Ihr Primärmodell Kapazitätsprobleme hat. |
| Element low quality | Das gewählte Element hatte einen niedrigen Qualitätswert. | Schreiben Sie die Beschreibung um oder öffnen Sie den Cache-Dialog, um zu sehen, ob ein besserer Kandidat gecacht ist. |
Der Tab "Warnings" enthält auch ein Feedback-Widget: Daumen hoch, wenn der Agent das richtige Element gewählt hat, Daumen runter, falls nicht. Dies hilft der KI langfristig beim Lernen und gibt Ihnen die Möglichkeit zu bestätigen, ob das Problem bei der Auswahl oder der Aktion liegt.
Schritt 3 — Entscheidung: Cache löschen, Beschreibung oder Selektor korrigieren?
Dies ist die häufigste Entscheidung bei der Triage eines Fehlers. Nutzen Sie die folgende Tabelle.
| Symptom | Wahrscheinlichste Ursache | Empfohlene Aktion |
|---|---|---|
| Der gleiche Schritt, der früher funktionierte, schlägt nach einer UI-Änderung fehl. | Veralteter Cache-Eintrag. | Cache löschen für diesen Schritt. Dann erneut ausführen. Die meisten Probleme mit veraltetem Cache beheben sich nach dem Leeren von selbst. |
| Der Schritt war schon immer instabil – wählt manchmal das richtige Element, manchmal nicht. | Beschreibung ist zu allgemein. | Beschreibung umschreiben, um mehr Kontext hinzuzufügen (Label, Container-Bereich, Position). Cache-Löschung ist hier zwecklos – die KI hat jedes Mal geraten. |
| KI sagt "Ich konnte das Element nicht finden", aber Sie sehen es im Screenshot. | Elementbeschreibung stimmt nicht mit dem Label im DOM überein (z. B. Sie schrieben "Save", aber das sichtbare Label ist "Save changes"). | Beschreibung umschreiben, damit sie mit dem tatsächlich sichtbaren Text oder dem aria-label übereinstimmt. |
| Cache-Dialog zeigt mehrere XPath-Kandidaten, und der falsche hat den höchsten Wert. | Zwei ähnliche Elemente auf der Seite. | Cache-Info-Dialog öffnen, falschen XPath-Kandidaten löschen, dann der Beschreibung unterscheidenden Kontext hinzufügen. |
| Das Element befindet sich in einem iFrame / Shadow DOM / virtualisierter Liste. | Grundlagen des Selektors. | Selektor fixen – entweder einen spezifischeren XPath in den erweiterten Einstellungen fixieren oder den Test umstrukturieren, um zur Liste zu scrollen, bevor eine Aktion ausgeführt wird. |
| Die Argumentation der KI zeigt, dass sie die falsche Absicht verstanden hat. | Schrittbeschreibung ist irreführend. | Umschreiben mit Aktionsverben, die zu den unterstützten Aktionen passen. |
Faustregel: Cache nur löschen, wenn der Schritt früher funktionierte und plötzlich nicht mehr. Wenn der Schritt noch nie zuverlässig funktionierte, liegt das Problem in der Beschreibung, nicht im Cache.
Schritt 4 — Get step recommendation nutzen, wenn Sie feststecken
Wenn Sie anhand von "Result + Explanation" nicht erkennen können, wie die richtige Formulierung lauten sollte, bietet das Schritt-Pop-over die Option Get step recommendation (Schraubenschlüssel-Icon). Diese:
- Öffnet einen interaktiven Mini-Durchlauf, der beim fehlerhaften Schritt pausiert.
- Fordert Sie auf, auf das Element zu klicken, das Sie tatsächlich meinten.
- Gibt bis zu vier alternative Schrittbeschreibungen zurück, die für dieses Element formuliert sind.
Sie fügen dann die Formulierung, die am besten passt, in den Schritt ein. Der Empfehlungsmodus ist nur suggestiv – er ändert von sich aus nichts.
Siehe Recording → Recommendation mode für den vollständigen Ablauf.
Schritt 5 — das Protokoll (Log) für Kontext prüfen
Das Schritt-Pop-over zeigt die Schlussfolgerung der KI. Das Log zeigt den Pfad, den die KI zu dieser Schlussfolgerung nahm: welche Elementkandidaten wurden in Betracht gezogen, welchen Cache-Eintrag hat sie konsultiert, welches Modell gab was zurück, wie lange dauerte jede Unteraktion.
Öffnen Sie das Log, filtern Sie nach dem fehlerhaften Schritt und lesen Sie die Zeilen kurz vor dem Fehler. Die nützlichsten Muster:
Warning: picked candidate with quality 0.4x→ die KI war unsicher. Prüfen Sie die Beschreibung.Cache hit (semantic match)gefolgt von einem Fehler → der Cache-Eintrag war falsch. Löschen Sie ihn.Multiple elements found→ fügen Sie der Beschreibung mehr Kontext hinzu.Element not actionable→ das Element wurde gefunden, konnte aber nicht angeklickt werden (verdeckt durch Overlay, deaktiviert, außerhalb des Sichtbereichs). Prüfen Sie den Screenshot.
Schritt 6 — wenn die Anwendung tatsächlich defekt ist
Wenn Sie nach den Schritten 1-5 zu dem Schluss kommen, dass der Fehler ein echter Defekt in der Anwendung ist (nicht im Test):
- Erstellen Sie einen ausführlichen Snapshot für den Bug-Report. Öffnen Sie das Log, klicken Sie auf Collect Support Information (mit mindestens AI-Kommunikation und HTML-Inhalt ausgewählt) und laden Sie nach Abschluss des erneuten Durchlaufs die Support Information herunter.
- Markieren Sie den Schritt als bekannten Fehler (known error), falls zutreffend – das Schritt-Pop-over bietet einen Button Fix known error, wenn der Fehler einem registrierten Muster entspricht. Nutzen Sie dies, um den Gesamtstatus des Tests aussagekräftig zu halten, während der Anwendungsfehler behoben wird.
Schritt 7 — erneut ausführen
Sobald Sie eine Änderung vorgenommen haben (Cache gelöscht, Beschreibung umgeschrieben, Selektor korrigiert), führen Sie den Test erneut aus:
- Für einen einzelnen Test: Rerun (oder Strg+p).
- Für einen Testsatz mit überwiegend erfolgreichen Tests: Rerun failed ist die effiziente Option.
- Um ab dem Schritt, den Sie gerade geändert haben erneut auszuführen, ohne alles davor zu durchlaufen: Öffnen Sie das Pop-over des Schritts und wählen Sie Start recording from here – dies startet eine interaktive Sitzung, die direkt zu diesem Schritt vorspult.
Siehe Re-running an execution für einen schnellen Vergleich der vier Optionen zur erneuten Ausführung.
Was Sie nicht tun sollten
- Nicht als erste Reaktion manuell einen XPath verschärfen. XPaths in den erweiterten Schritt-Einstellungen reduzieren die Flexibilität der KI. Nutzen Sie diese erst, nachdem Beschreibung, Cache und Empfehlungsmodus ausgeschöpft wurden.
- Nicht den Cache bei einem Schritt löschen, der aus Gründen außerhalb des Caches fehlschlägt. Das verschwendet bei der nächsten Ausführung Zeit, da die KI die Elementidentifizierung erneut durchführen muss, ohne dass ein Nutzen entsteht.
- Nicht den gesamten Testsatz erneut ausführen, wenn nur ein Test fehlgeschlagen ist. Nutzen Sie Rerun failed – dies behält die bereits bestandenen Ergebnisse bei.
- Nicht die Testdefinition während eines ausführlichen "Verbose Reruns" ändern. Das gesammelte Paket würde eine inkonsistente Definition aufzeichnen. Warten Sie, bis der ausführliche Durchlauf beendet ist, und bearbeiten Sie dann die Definition.
Siehe auch
- Reading the Log – Log-Viewer + Verbose-Rerun-Ablauf.
- Recording → Recommendation mode – alternative Schrittbeschreibungen für ein Element erhalten.
- Caching – wie der Cache funktioniert und wann Einträge wiederverwendet werden.
- Prompting – wie man klare, eindeutige Schrittbeschreibungen schreibt.
- Test-Case Overview – Testdefinition zum Bearbeiten finden.