Der Button ist noch da. Nur dein Locator findet ihn nicht mehr.
Wenn die Anwendung funktioniert, aber der Test an einer ID-, XPath-, CSS-, Rollen- oder Accessibility-Änderung scheitert, kann Self-Healing Wartungsrauschen reduzieren.
Typische Ursachen für gebrochene Locator
Refactoring, neue Komponenten, dynamische IDs, geänderte Labels oder eine andere DOM-/View-Hierarchie können valide User Flows rot werden lassen.
Web Locator
Selenium und Playwright bei geänderten IDs, CSS, XPath, Rollen, Labels und Text stabilisieren.
Mobile Locator
Appium bei geänderten Accessibility IDs, Resource IDs und Mobile UI-Hierarchien unterstützen.
Nicht blind ersetzen
Kandidaten werden anhand mehrerer Signale bewertet; bei unsicherem Ergebnis bleibt der Fehler bestehen.
So wird aus „Element not found“ ein kontrolliertes Healing
Fehler erkennen
Der Test meldet, dass der ursprünglich erwartete Locator kein Element liefert.
Ziel rekonstruieren
TestZombie nutzt vorhandenen Kontext, um mögliche Ziel-Elemente zu bewerten.
Healing dokumentieren
Ein belastbarer Ersatz kann genutzt und für Review beziehungsweise Code-Update gespeichert werden.
FAQ zu Broken Locators
Ist ein gebrochener Locator automatisch ein Flaky Test?
Nicht zwingend. Ein Locator kann nach einer UI-Änderung deterministisch kaputt sein; Self-Healing kann trotzdem denselben Wartungsfall adressieren.
Welche Frameworks deckt TestZombie ab?
Die Public Site stellt Self-Healing für Selenium, Playwright und Appium dar.
Was passiert bei einem unsicheren Kandidaten?
Wenn kein ausreichend sicherer Ersatz existiert, sollte der Test fehlschlagen statt ein falsches Element zu verwenden.
Ihre Tests sollen Änderungen überleben.
Ergänzen Sie bestehende Selenium-, Playwright- und Appium-Tests um Healing, Analyse und konkrete Fix-Empfehlungen.