Rückblick auf die Entwicklung der Testautomatisierung

Jecelyn Yeen

Maksim Sadym

Die Geburtsstunde der Testautomatisierung

Schauen wir mal zurück in die 1990er Jahre, als der Webbrowser geboren wurde. Die Testautomatisierung wurde erst in den 2000er-Jahren realisiert, als die Projekte Selenium und WebDriver auf den Markt kamen, um die Herausforderungen bei browserübergreifenden und geräteübergreifenden Tests anzugehen.

Diese beiden Projekte wurden 2011 als Selenium WebDriver zusammengeführt und wurden 2018 zu einem W3C-Standard. Wir bezeichnen sie in der Regel als WebDriver oder WebDriver „Classic“.

Vor der Einführung von WebDriver „Classic“ war die Testautomatisierung ziemlich schwierig. Die Möglichkeit zur Automatisierung von Browsertests hat die Lebensqualität von Entwicklern und Testern erheblich verbessert.

Auf dem Weg zu JavaScript

Während sich die Webentwicklung immer mehr auf JavaScript stützte, traten neue Automatisierungslösungen wie WebdriverIO, Appium, Nightwatch, Protractor (veraltet), Testcafé, Cypress, Puppeteer und Playwright auf.

Automatisierungsansätze

Diese Tools lassen sich grob in zwei Hauptgruppen einteilen, je nachdem, wie sie die Browser automatisieren:

• Allgemein: Tools, die JavaScript im Browser ausführen. Beispielsweise nutzen Cypress und TestCafe Web APIs und Node.js, um Tests direkt im Browser auszuführen. Übrigens: In der ersten Version von Selenium wurde derselbe Ansatz verwendet.
• Niedrige Ebene: Tools, die Remotebefehle außerhalb des Browsers ausführen. Wenn Tools noch mehr Kontrolle benötigen, z. B. mehrere Tabs öffnen oder den Gerätemodus simulieren, müssen sie Remotebefehle zur Steuerung des Browsers über Protokolle ausführen. Die beiden Hauptautomatisierungsprotokolle sind WebDriver Classic und Chrome DevTools Protocol (CDP).

Im nächsten Abschnitt werden wir uns diese beiden Protokolle ansehen, um ihre Stärken und Einschränkungen zu verstehen.

WebDriver „Classic“ im Vergleich zum Chrome DevTools Protocol (CDP)

WebDriver „Classic“ ist ein Webstandard, der von allen gängigen Browsern unterstützt wird. Automatisierungsscripts geben Befehle über HTTP-Anfragen an einen Treiberserver aus, der dann über interne, browserspezifische Protokolle mit Browsern kommuniziert.

Obwohl sie eine hervorragende browserübergreifende Unterstützung bietet und die APIs für Tests entwickelt wurden, ist sie möglicherweise langsam und unterstützt einige untergeordnete Steuerelemente nicht.

Angenommen, Sie haben ein Testskript, das auf ein Element await coffee.click(); klickt. Sie werden in eine Reihe von HTTP-Anfragen umgewandelt.

# WebDriver: Click on a coffee element

curl -X POST http://127.0.0.1:4444/session/:element_id/element/click
   -H 'Content-Type: application/json'
   -d '{}'

Das Chrome DevTools Protocol (CDP) wurde ursprünglich für die Chrome-Entwicklertools und die Fehlerbehebung entwickelt, wurde aber für die Automatisierung von Puppeteer übernommen. CDP kommuniziert über WebSocket-Verbindungen direkt mit Chromium-basierten Browsern und bietet so eine höhere Leistung und einfache Kontrolle.

Er funktioniert jedoch nur in Chromium-basierten Browsern und ist kein offener Standard. Außerdem sind CDP APIs relativ komplex. In einigen Fällen ist die Arbeit mit CDP nicht ergonomisch. Das Arbeiten mit Out-of-Process-iFrames ist beispielsweise sehr aufwendig.

Wenn Sie beispielsweise auf ein Element await coffee.click(); klicken, wird dies in eine Reihe von CDP-Befehlen umgewandelt.

// CDP: Click on a coffee element

// Mouse pressed
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mousePressed', x: 10.34, y: 27.1, clickCount: 1 }
}

// Mouse released
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mouseReleased', x: 10.34, y: 27.1, clickCount: 1 }
}

Was sind die untergeordneten Steuerelemente?

Damals, als WebDriver Classic entwickelt wurde, war keine Low-Level-Steuerung erforderlich. Die Zeiten haben sich jedoch verändert. Das Web kann mittlerweile viel leistungsfähiger werden und das Testen von heute erfordert genauere Maßnahmen.

Da CDP für alle Debugging-Anforderungen entwickelt wurde, unterstützt es im Vergleich zu WebDriver Classic mehr Low-Level-Steuerelemente und bietet unter anderem folgende Möglichkeiten:

• Konsolennachrichten erfassen
• Netzwerkanfragen werden abfangen
• Gerätemodus simulieren
• Standortbestimmung simulieren
• …und vieles mehr

In WebDriver Classic war das aufgrund der unterschiedlichen Architektur nicht möglich. WebDriver „Classic“ ist HTTP-basiert, was es schwierig macht, Browserereignisse zu abonnieren und zu überwachen. CDP hingegen ist WebSocket-basiert und unterstützt standardmäßig bidirektionales Messaging.

Der nächste Schritt: WebDriver BiDi

Hier eine Zusammenfassung der Stärken von WebDriver „Classic“ und CDP:

WebDriver BiDi kombiniert die besten Aspekte von WebDriver „Classic“ und CDP. Es handelt sich um ein neues standardmäßiges Browser-Automatisierungsprotokoll, das derzeit in Entwicklung ist.

Weitere Informationen zum WebDriver BiDi-Projekt – seine Funktionsweise, die Vision und den Standardisierungsprozess