Monkey-Testing Ihrer Website mit GitHub Copilot × Playwright: Ein praktischer Leitfaden

Einführung

Die Qualitätssicherung einer Website ist mit einer einmaligen Prüfung vor dem Release nicht ausreichend. Unerwartete Probleme können jederzeit auftreten – bei Inhaltserweiterungen, Bibliotheks-Updates, CDN-Konfigurationsänderungen und mehr.

Dieser Artikel dokumentiert eine praxisnahe Monkey-Testing-Sitzung, bei der der VS Code Agent Mode (GitHub Copilot) direkt einen Browser steuerte, um eine gesamte Website zu testen. Wir haben die Testmethodik systematisiert, die die KI konsistent ausführte – von der statischen Quellcode-Analyse bis zur dynamischen Browser-Überprüfung.

Testumgebung

Im Agent Mode führt Copilot selbstständig Terminal-Befehle aus, liest/schreibt Dateien und steuert den Browser. Der Tester gibt lediglich die Anweisung „bitte testen”, und die KI führt den gesamten nachfolgenden Prozess automatisch aus.

Phase 1: Bestandsaufnahme der Testziele

Vollständiges Lesen des Quellcodes

Die KI scannt zunächst die Verzeichnisstruktur des Projekts und liest den gesamten Quellcode aller Komponenten, Seiten und Hilfsfunktionen.

src/
├── components/    ← Alle 28 Komponenten gelesen
├── content/blog/  ← Frontmatter von 16 Artikeln analysiert
├── pages/         ← Alle Routing-Dateien identifiziert
├── layouts/       ← BaseLayout-Struktur verstanden
└── utils/         ← rehype-Plugins & OG-Bildgenerierung geprüft

In dieser Phase identifiziert die KI automatisch:

• Vollständige Routenliste: 7 statische Seiten + Blog-bezogene Routen (Artikel, Tags, Archiv, Autoren, Paginierung)
• Interaktive Elemente: Such-Modal, FAQ-Toggles, Kopier-Buttons, YouTube-Fassade, Scroll-nach-oben, Hero-Slider
• Externe Integrationen: ssgform.com (Formulare), Cloudflare Turnstile (Bot-Schutz), Google AdSense, GA4

Automatische Testplan-Erstellung

Aus den Analyseergebnissen des Quellcodes generiert die KI automatisch einen Testplan als Todo-Liste. Menschen müssen keine Checklisten erstellen.

Phase 2: Vollständiges Routen-Crawl-Testing

HTTP-Status-Überprüfung

Die gebaute Website wird mit npm run preview gestartet, und Playwright greift auf alle Routen zu.

Testziele: 31 Routen
├── Statische Seiten    7 (/, /about/, /services/, etc.)
├── Blog-Beiträge      16
├── Tag-Seiten         24
├── Archiv              4
├── Paginierung         2 (/blog/page/2/, /blog/page/3/)
├── Autorenseiten       2
├── RSS                 1
└── 404-Test            1

Ergebnis: Alle Routen 200 OK (außer beabsichtigter 404)

DOM-Strukturprüfung

Folgendes wird auf jeder Seite automatisch überprüft:

Dead-Link-Prüfung

Interne Links wurden rekursiv von der Einstiegsseite gesammelt und die Erreichbarkeit aller 55 eindeutigen URLs bestätigt. 0 tote Links wurden gefunden.

Phase 3: Interaktionsüberprüfung

Die KI manipuliert Browserelemente direkt mit Playwright, um JavaScript-gesteuerte Funktionalität zu überprüfen.

FAQ (<details>-Elemente)

// Beispiel-Testcode, der von der KI ausgeführt wird
const details = document.querySelectorAll('details');
// Anfangszustand: alle geschlossen → OK
// Klicken zum Öffnen → OK
// Erneut klicken zum Schließen → OK

Such-Modal (Pagefind)

1. Such-Dialog mit window.openSearch() öffnen
2. Warten, bis die Pagefind-UI vollständig geladen ist
3. „Astro” eingeben und bestätigen, dass Suchergebnisse angezeigt werden
4. Schließen mit ESC-Taste bestätigen

YouTube-Fassaden-Muster

1. Das .yt-facade-Element anklicken
2. Bestätigen, dass ein iframe für youtube-nocookie.com/embed/ dynamisch generiert wird
3. Bestätigen, dass der autoplay=1-Parameter enthalten ist

Kopier-Button (nach View Transitions)

Bestätigt, dass Kopier-Buttons für Code-Blöcke nach Seitenübergängen via View Transitions neu initialisiert werden und funktionieren. Die Neuregistrierung über das astro:page-load-Event funktionierte korrekt.

ScrollToTop-Button

Zum Seitenende scrollen → Button erscheint → klicken → bestätigen, dass window.scrollY auf 0 zurückkehrt.

Phase 4: SEO- & Strukturierte-Daten-Audit

OGP-Meta-Tags

Folgendes wurde auf allen Seiten überprüft:

• og:title / og:description / og:image / og:url / og:type sind gesetzt
• twitter:card ist auf summary_large_image gesetzt
• canonical-URL ist korrekt
• OG-Bild-URL existiert und hat die empfohlene Größe (1200×630)

Strukturierte Daten (JSON-LD)

JSON-LD auf jeder Seite wurde geparst, um Schema-Typen und Inhalte zu überprüfen.

Sitemap

Bestätigt, dass sitemap-index.xml → sitemap-0.xml alle 57 URLs enthält. Die Sitemap-Referenz aus robots.txt funktionierte ebenfalls korrekt.

Phase 5: Barrierefreiheits-Überprüfung

AXE-Engine-äquivalente Prüfungen wurden via Playwright auf mehreren Seiten durchgeführt.

Keine Verstöße auf allen 4 Seiten und allen Prüfpunkten.

Phase 6: View-Transitions-Navigationstests

Bei Astro View Transitions wird das DOM differenziell aktualisiert, was die JavaScript-Neuinitialisierung zur Herausforderung macht. Folgende Übergangsmuster wurden überprüft:

Startseite → Blog-Liste → Artikel → Tag → Autor → Kontakt → Dienstleistungen → Startseite

Nach jedem Übergang bestätigte Punkte:

• URL, Titel und H1 werden korrekt aktualisiert
• Such-Button funktioniert
• Kopier-Buttons werden neu initialisiert
• Breadcrumb-Navigation wird aktualisiert
• Keine JS-Fehler

Phase 7: Sicherheitsheader-Überprüfung

Überprüfung der Antwort-Header auf der Produktions-Website:

Entdeckte Fehler und Korrekturen

Diese Testsitzung deckte 2 Fehler auf, die beide in derselben Sitzung behoben wurden.

Fehler 1: Fehlende Resilienz beim Such-Modal

Symptom: Wird der Such-Button gedrückt, bevor das Pagefind-Skript vollständig geladen ist, reagiert die Oberfläche nicht mehr.

Ursache: loadPagefindScript() hatte keinen Retry-Mechanismus nach einem anfänglichen Fehler.

Behebung: Implementierung des Löschens des Promise-Caches bei Fehler und Anzeige eines „Neu laden”-Buttons als Fallback-UI.

Fehler 2: Fehlende Google-Ursprünge im CSP-Header

Symptom: Google AdSense-bezogene Ressourcen werden durch CSP blockiert, was Konsolenfehler verursacht.

Ursache: connect-src und frame-src enthielten nicht https://www.google.com / https://www.google.co.jp.

Behebung: Hinzufügen der Google-bezogenen Ursprünge zu den CSP-Direktiven in public/_headers.

Systematisierung der Testmethodik

Wenn man diesen KI-Monkey-Testing-Ansatz organisiert, lässt er sich in folgende Schichten einteilen:

Schicht 1: Statische Analyse (Quellcode lesen)

• Verzeichnisstruktur scannen
• Komponentenabhängigkeiten kartieren
• Frontmatter-Schema (Zod) analysieren
• CSP- und Weiterleitungskonfiguration prüfen

Schicht 2: HTTP-Schicht-Tests (vollständiges Routen-Crawling)

• Statuscode-Überprüfung (200/404/301)
• Antwort-Header-Audit (Sicherheit, Cache)
• Konsistenz von Sitemap, robots.txt, ads.txt

Schicht 3: DOM-Schicht-Tests (Strukturüberprüfung)

• Fehlerhafte Bilder, leere Links, unsichere externe Links