Die Geburtsstunde der Testautomatisierung
Kehren wir in die 90er zurück, als der Webbrowser geboren wurde. Die Testautomatisierung wurde erst in den 2000er-Jahren Realität, als Selenium- und WebDriver-Projekte zur Bewältigung von Herausforderungen bei browser- und geräteübergreifenden Tests entwickelt wurden.
Die beiden Projekte haben sich 2011 unter dem Namen Selenium WebDriver zusammengeschlossen und wurden 2018 zu einem W3C-Standard. Wir bezeichnen sie in der Regel als WebDriver oder WebDriver „Classic“.
<ph type="x-smartling-placeholder">
Vor WebDriver „Classic“ war die Testautomatisierung ziemlich kompliziert. Durch die Automatisierung von Browsertests wurde das Leben von Entwicklern und Testern erheblich verbessert.
Der Aufstieg von JavaScript
Als die Webentwicklung sich immer mehr auf JavaScript stützte, entstanden neue Automatisierungslösungen wie WebdriverIO, Appium, Nightwatch, Protraktor (veraltet), TestCafe, Cypress, Puppeteer und Playwright.
<ph type="x-smartling-placeholder">
Automatisierungskonzepte
Grundsätzlich lassen sich diese Tools in zwei Hauptgruppen unterteilen, je nachdem, wie sie Browser automatisieren:
- Allgemeine Ebene: Tools, die JavaScript im Browser ausführen. Cypress und TestCafe nutzen beispielsweise 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. das Öffnen mehrerer Tabs oder die Simulation des Gerätemodus, müssen sie Remotebefehle ausführen, um den Browser über Protokolle zu steuern. Die beiden wichtigsten Automatisierungsprotokolle sind WebDriver Classic und Chrome DevTools Protocol (CDP).
Im nächsten Abschnitt werden wir uns diese beiden Protokolle genauer ansehen, um ihre Stärken und Einschränkungen zu verstehen.
WebDriver „Classic“ und Chrome DevTools Protocol (CDP)
WebDriver „Classic“ ist ein Webstandard, der von allen gängigen Browsern unterstützt wird. Automatisierungsskripts geben Befehle über HTTP-Anfragen an einen Treiberserver aus, der dann über interne, browserspezifische Protokolle mit Browsern kommuniziert.
Obwohl es eine hervorragende browserübergreifende Unterstützung bietet und seine APIs für Tests entwickelt wurden, kann es langsam sein und unterstützt einige Low-Level-Steuerelemente nicht.
<ph type="x-smartling-placeholder">
Angenommen, Sie haben ein Testskript, das auf ein Element await coffee.click(); klickt. Sie wird in eine Reihe von HTTP-Anfragen übersetzt.
# 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) hingegen wurde ursprünglich für Chrome-Entwicklertools und die Fehlerbehebung entwickelt, aber von Puppeteer für die Automatisierung verwendet. Das CDP kommuniziert direkt mit Chromium-basierten Browsern über WebSocket-Verbindungen, was eine schnellere Leistung und Kontrolle auf niedriger Ebene bietet.
Es funktioniert jedoch nur mit Chromium-basierten Browsern und ist kein offener Standard. Darüber hinaus sind die CDP APIs relativ komplex. In einigen Fällen ist die Arbeit mit CDP nicht ergonomisch. Beispielsweise ist die Arbeit mit Out-of-Process-iFrames sehr aufwendig.
<ph type="x-smartling-placeholder">
Beispielsweise wird das Klicken auf das Element await coffee.click(); in eine Reihe von CDP-Befehlen übersetzt.
// 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 Steuerelemente auf niedriger Ebene?
Als WebDriver „Classic“ entwickelt wurde, war eine Low-Level-Steuerung nicht erforderlich. Die Zeiten haben sich jedoch geändert, das Web ist heute viel leistungsfähiger und Tests erfordern heute präzisere Maßnahmen.
Da CDP für alle Debugging-Anforderungen entwickelt wurde, unterstützt es im Vergleich zu WebDriver Classic im Vergleich zu WebDriver Classic mehr Steuerelemente auf niedriger Ebene. Sie kann unter anderem folgende Funktionen verarbeiten:
- Konsolennachrichten erfassen
- Netzwerkanfragen abfangen
- Gerätemodus simulieren
- Standortbestimmung simulieren
- …und vieles mehr
Dies war in „WebDriver Classic“ aufgrund der unterschiedlichen Architektur nicht möglich. WebDriver „Classic“ ist HTTP-basiert, was das Abonnieren und Abhören von Browserereignissen erschwert. CDP hingegen basiert auf WebSocket und unterstützt standardmäßig bidirektionales Messaging.
Nächste Schritte: WebDriver BiDi
Hier eine Zusammenfassung der Stärken von WebDriver Classic und CDP:
| WebDriver „Classic“ | Protokoll der Chrome-Entwicklertools (CDP) |
|---|---|
| Beste browserübergreifende Unterstützung | Schnelle, bidirektionale Kommunikation |
| W3C-Standard | Bietet Low-Level-Kontrolle |
| Für Tests entwickelt |
WebDriver BiDi kombiniert die besten Aspekte von WebDriver „Classic“ und CDP. Es ist ein neues Standardprotokoll zur Browserautomatisierung, das sich derzeit noch in der Entwicklung befindet.
Hier erfahren Sie mehr über das WebDriver BiDi-Projekt – seine Funktionsweise, seine Vision und den Standardisierungsprozess.