E2E-Tests mit KI: Technische Hürden und warum es komplizierter ist als gedacht

Georg Dörgeloh 20. Mai 2025

“Können wir nicht einfach ChatGPT nutzen, um unsere E2E-Tests zu schreiben?” Diese Frage hören Sie als Entwickler wahrscheinlich häufiger. Die Antwort ist komplizierter als ein einfaches Ja oder Nein. In diesem Artikel zeige ich Ihnen die technische Realität hinter KI-gestützter Testautomatisierung - und warum das Problem interessanter (und schwieriger) ist, als es zunächst scheint.

Das Problem mit einfachen Ansätzen

Ansatz 1: Code-Generierung mit LLMs

Der naheliegendste Ansatz ist, ein LLM Test-Code generieren zu lassen:

// KI-generierter E2E-Test
test('User can login and update profile', async ({ page }) => {
  await page.goto('https://example.com');
  await page.fill('input[name="username"]', 'testuser');
  await page.fill('input[name="password"]', 'password123');
  await page.click('button[type="submit"]');
  await page.waitForNavigation();
  // und so weiter...
});

Technische Probleme:

• Context Window Limitation: Große Codebasen sprengen schnell das Context Window des LLMs
• Fehlender visueller Kontext: Das LLM sieht Code, aber nicht die laufende Anwendung
• Unzuverlässige Selektoren: Generierte CSS-Selektoren brechen bei UI-Änderungen

Ansatz 2: Browser-Automation mit LLMs

Der nächste Schritt: Lassen Sie das LLM direkt den Browser steuern. Das LLM bekommt Screenshots und DOM, analysiert den aktuellen Zustand und entscheidet, was als nächstes zu tun ist.

Warum das technisch funktioniert:

• Moderne Vision-Models (GPT-4V, Claude 3.5 Sonnet) können Screenshots erstaunlich gut interpretieren
• LLMs verstehen natürlichsprachliche Testbeschreibungen
• Browser-Automation APIs (Playwright, Selenium) sind gut dokumentiert

Warum es in der Praxis scheitert:

• Performance: Jeder Testschritt erfordert einen API-Call zum LLM (100-500ms+)
• Kosten: Ein einziger E2E-Test kann $0.10-1.00+ kosten
• Skalierung: CI-Pipelines werden unbezahlbar bei dutzenden Tests
• Determinismus: Gleicher Test, unterschiedliche Ausführung

Hybrid-Ansatz: Record & Replay

Der vielversprechendste Ansatz kombiniert KI-Generierung mit traditioneller Test-Ausführung:

1. Recording-Phase: KI führt Test einmal aus und zeichnet Aktionen auf
2. Code-Generation: Aktionen werden in stabilen Test-Code übersetzt
3. Replay-Phase: Tests laufen ohne KI-Involvement
4. Regeneration: Bei Fehlern kann KI Test neu aufzeichnen

class HybridTestRecorder {
  async recordTest(testDescription) {
    const actions = [];

    // KI-gesteuerte Ausführung mit Aufzeichnung
    while (!this.isTestComplete()) {
      const screenshot = await this.takeScreenshot();
      const action = await this.aiAgent.nextAction(screenshot, testDescription);

      actions.push({
        type: action.type,
        selector: this.generateStableSelector(action.element),
        data: action.data,
        screenshot: screenshot,
      });

      await this.executeAction(action);
    }

    return this.generatePlaywrightCode(actions);
  }
}

Warum bestehende Tools nicht ausreichen

Problem mit generischen KI-Assistenten

ChatGPT, Claude & Co. sind nicht für Browser-Automation optimiert:

• Keine spezialisierte DOM-Verarbeitung
• Keine robusten Selector-Strategien
• Keine Integration in Test-Frameworks
• Kein Verständnis für Test-Maintenance

Problem mit einfachen Browser-Automation-Tools

Tools wie Claude Desktop mit Playwright MCP lösen nur die Oberflächenprobleme:

• Funktionieren für Demos, nicht für Production
• Keine Selector-Optimierung
• Keine Test-Management-Features
• Keine Integration in CI/CD

Die drei technischen Kernprobleme

1. Das Context-Problem

Das DOM einer modernen Webapp kann schnell 2-10MB groß werden. LLMs haben begrenzte Context Windows. Selbst GPT-4 mit 128k Tokens kann nicht mit dem kompletten DOM einer modernen Single-Page-Application umgehen.

Lösungsansätze:

• DOM-Pruning: Irrelevante Elemente entfernen
• Semantic DOM: Nur interaktive Elemente extrahieren

2. Das Visual-DOM-Mapping Problem

Das LLM sieht einen “Search”-Button im Screenshot, aber der DOM enthält nur:

<button class="btn-primary">
  <svg viewBox="0 0 24 24">
    <path
      d="M15.5 14h-.79l-.28-.27C15.41 12.59 16 11.11 16 9.5 16 5.91 13.09 3 9.5 3S3 5.91 3 9.5 5.91 16 9.5 16c1.61 0 3.09-.59 4.23-1.57l.27.28v.79l5 4.99L20.49 19l-4.99-5zm-6 0C7.01 14 5 11.99 5 9.5S7.01 5 9.5 5 14 7.01 14 9.5 11.99 14 9.5 14z"
    />
  </svg>
</button>

Wie soll das LLM wissen, dass dieses SVG-Icon den “Search”-Button darstellt, den es sucht?

Technische Lösungsansätze:

• Computer Vision für Icon-Recognition
• Multi-Modal Embedding für Visual-DOM-Alignment
• Accessible Name Computation nach ARIA-Standards

3. Das Selector-Stabilitätsproblem

Ein zuverlässiger E2E-Test braucht stabile Selektoren. Das LLM muss nicht nur ein Element finden, sondern auch einen robusten Selector dafür generieren.

Selector-Hierarchie (von stabil zu fragil):

1. data-testid Attribute (ideal, aber selten vorhanden)
2. Semantic Selektoren (role, aria-label)
3. Relative Positioning zu bekannten Elementen
4. CSS-Klassen und IDs
5. XPath mit absoluten Positionen (fragil)

// Robuster Selector-Algorithmus
function generateSelector(element, dom) {
  if (element.dataset.testid) {
    return `[data-testid="${element.dataset.testid}"]`;
  }

  if (element.getAttribute('aria-label')) {
    return `[aria-label="${element.getAttribute('aria-label')}"]`;
  }

  // Fallback: Relative positioning
  const nearbyLandmark = findNearestLandmark(element, dom);
  if (nearbyLandmark) {
    return `${nearbyLandmark.selector} >> ${getRelativeSelector(element)}`;
  }

  // Last resort: CSS path
  return generateCSSPath(element);
}

Der Mehrwert spezialisierter Lösungen

Eine durchdachte KI-Testautomatisierung-Lösung sollte folgendes bieten:

Technische Exzellenz:

• Multi-Agent-Architektur für optimale Spezialisierung
• Intelligente Context-Optimierung
• Robuste Selector-Generierung
• Effiziente Caching und Retry-Mechanismen

Developer Experience:

• Nahtlose Integration in bestehende Test-Suites
• Export in gängige Frameworks (Playwright, Cypress, Selenium)
• Versionierung und Diffing von Tests
• CI/CD-Pipeline Integration

Business Value:

• Self-Service für Product Owner ohne Developer-Bottleneck
• Dramatische Reduktion der Test-Maintenance-Zeit
• Bessere Test-Coverage durch niedrigere Erstellungskosten

Fazit: Warum Sie Ihrem PO eine spezialisierte Lösung vorschlagen sollten

KI-Testautomatisierung ist ein faszinierendes Problem, das weit über “LLM + Browser” hinausgeht. Die technischen Herausforderungen sind real und komplex:

• Context-Management für große DOMs
• Visual-DOM-Mapping für robuste Element-Identifikation
• Selector-Strategien für wartbare Tests
• Multi-Agent-Orchestrierung für optimale Performance

Als Entwickler verstehen Sie diese Komplexität. Wenn Ihr Product Owner fragt: “Können wir nicht einfach ChatGPT nutzen?”, können Sie erklären, warum eine spezialisierte Lösung notwendig ist.

Der Mehrwert für Sie:

• Weniger Zeit für flaky Test-Maintenance
• Mehr Test-Coverage ohne proportional mehr Aufwand
• Bessere Zusammenarbeit mit Business-Stakeholdern
• Focus auf interessantere Entwicklungsaufgaben

Die Zukunft der E2E-Testautomatisierung liegt nicht in generischen KI-Tools, sondern in spezialisierten Systemen, die diese technischen Herausforderungen durchdacht lösen.