Cross-Browser-Testing: ein Test für jeden Browser und jedes Gerät

Was ist Cross-Browser-Testing?

Cross-Browser-Testing heißt prüfen, ob eine Website oder eine Web-App in jedem Browser Ihrer Nutzer funktioniert und richtig aussieht.Cross-Device-Testing tut dasselbe über Bildschirme und Eingabearten hinweg: Smartphones, Tablets und Desktop-Größen, Touch und Maus, Hochformat und Querformat.Zusammen beantworten sie eine einzige Frage.Funktioniert die Seite, die Ihr Team gebaut hat, für die Person, die sie auf einem Smartphone, in einem anderen Browser, in einer anderen Sprache öffnet?

Die Frage ist wichtig, weil eine Webseite kein festes Bild ist.Jeder Browser zeichnet dasselbe HTML, CSS und JavaScript mit seiner eigenen Engine.Jedes Gerät gibt der Seite einen anderen Bildschirm, in den sie passen muss.Eine Kasse, die auf einem breiten Monitor in Chrome funktioniert, kann ihre Schaltfläche „Bezahlen“ auf einem kleinen Smartphone unter den sichtbaren Bereich schieben.

Mobiles Web-Testing ist der Teil, der sich eine Website auf Smartphones und Tablets ansieht.Responsive Testing ist der Teil, der prüft, ob sich ein Layout an jede Bildschirmgröße anpasst.

Was sich zwischen Browsern und Geräten ändert

Ein Test, der in einem Browser auf einem Bildschirm besteht, beweist wenig über die anderen.Das sind die Unterschiede, die Seiten am häufigsten kaputt machen.

Viewport-Tests allein decken nur die zweite Zeile ab.Eine echte Cross-Device-Prüfung braucht Bildschirmgröße, Toucheingabe und Pixeldichte zusammen.

Wie gehen Teams beim Cross-Browser-Testing üblicherweise vor?

Zuerst kommen manuelle Prüfungen.Jemand aus dem Testteam öffnet die Seite in jedem Browser und ändert die Fenstergröße.Das funktioniert für ein Release, lässt sich aber nicht auf jeden Build übertragen.

Danach kommen automatisierte Testsuiten.Ihr Aufbau ist in jedem Framework ähnlich: ein in Code geschriebener Test, dann eine Konfiguration, die ihn für jeden Browser oder jedes Gerät erneut ausführt.

Projekte und Geräte in Playwright

Playwright gruppiert Tests in Projekte.Ein Projekt ist eine Gruppe von Tests, die mit einer Konfiguration läuft, etwa einem Browser oder einem emulierten Gerät.Playwright führt standardmäßig jedes Projekt aus.Sein Geräteverzeichnis beschreibt Smartphones, Tablets und Desktops, mit ihrer Bildschirmgröße, ihrem User-Agent und ihrer Touch-Unterstützung.

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    { name: 'Mobile Chrome', use: { ...devices['Pixel 5'] } },
    { name: 'Mobile Safari', use: { ...devices['iPhone 12'] } },
  ],
});

Browser und Viewports in Cypress

Cypress unterstützt Browser der Chrome-Familie, Firefox und WebKit, ausgewählt mit dem Flag --browser.Sein Befehl cy.viewport legt Größe und Ausrichtung des Bildschirms fest, mit Voreinstellungen wie iphone-6 und ipad-2.Seine Dokumentation weist darauf hin, dass das Gerätepixelverhältnis nicht simuliert wird.Sie empfiehlt außerdem, manche Browser seltener auszuführen, etwa Firefox jede Nacht statt bei jedem Commit, um Zeit und CI-Kosten zu sparen.

Selenium Grid

Selenium Grid führt WebDriver-Skripte auf entfernten Rechnern aus, parallel, über Browserversionen und Plattformen hinweg.Es ist der klassische Weg für plattformübergreifende Tests mit Selenium.Ihr Team richtet diese Rechner ein und hält ihre Browser auf dem neuesten Stand.

Geräte-Clouds

Geräte-Clouds wie BrowserStack, TestMu AI (früher LambdaTest) und Sauce Labs stellen die Browser und Geräte für Sie bereit.BrowserStack und TestMu AI führen jeweils Tausende Kombinationen aus Browser und Betriebssystem auf.Sauce Labs bietet Emulatoren, Simulatoren und echte Geräte.Ihre codierten Tests laufen auf deren Rechnern, und BrowserStack Automate bemisst seine Tarife nach parallelen Tests.

Einen breiteren Blick auf diese Tools bietet die Vergleichsstudie.

Was eine codierte Cross-Device-Testsuite kostet

Die Konfiguration ist der einfache Teil.Die Kosten liegen in allem, was jeder Test über jeden Bildschirm wissen muss.

test('open the checkout', async ({ page, isMobile }) => {
  if (isMobile)
    await page.getByRole('button', { name: 'Menu' }).click();
  await page.getByRole('link', { name: 'Checkout' }).click();
});

Multiplizieren Sie das mit jedem Element, das sich auf einem kleinen Bildschirm verschiebt.Der Cross-Device-Teil einer Testsuite wird schnell zu einer zweiten Testsuite, mit eigenem Pflegeaufwand.

Cross-Browser-Testing aus einer einzigen Aufzeichnung

GUI Test Studio, das End-to-End-Tests unter Windows automatisiert, geht einen anderen Weg.Sie zeichnen einen Webtest einmal auf, indem Sie den Ablauf selbst in dem Browser durchgehen, den Sie jeden Tag verwenden.Sie kreuzen die Browser, Geräte und Bedingungen an, die er abdecken soll.GUI Test Runner-Recorder erzeugt dann für jedes davon eine Version des Tests, einen sogenannten Zweig.

Wenn Sie eine Web-App aufzeichnen, setzen Sie unter ihrer Adresse das Häkchen bei Diesen Test auch für andere Browser und Geräte erzeugen.Die Browser sind die auf Ihrem Computer installierten: Chrome, Edge und Firefox.Die Geräte sind mehr als 80 Smartphones, Tablets und Desktop-Bildschirmgrößen, nach Hersteller gruppiert.Jedes Smartphone und Tablet kann aufrecht, quer oder in beiden Ausrichtungen gehalten werden.

Vergrößern

Das Fenster sagt, wie viele Tests Ihre Auswahl ergibt, wie lange ihre Erzeugung dauert und wie viel Speicherplatz sie belegen.Sobald der Test gespeichert ist, werden die Zweige im Hintergrund erzeugt.Bei der Aufzeichnung wird nichts endgültig festgelegt: Sie können später Browser und Geräte hinzufügen.

Neu beim Aufzeichnen?Einen Test aufzeichnen zeigt den ganzen Weg.Sie können den Test auch in einem Prompt beschreiben und die Browser und Geräte im selben Satz nennen: siehe Einen Test aus einem Prompt erstellen.

Was jede Browser- und Geräteversion tut

Ein Zweig ist nicht die an denselben Koordinaten wiedergegebene Aufzeichnung.Er entsteht, indem der Test auf diesem Browser und Gerät Schritt für Schritt wiedergegeben wird, über die eigenen Elemente der Seite.

Das ist der Teil, den eine codierte Testsuite von Hand schreibt.Hier kommt er von der Seite selbst: das Menü, das Scrollen und der neue Platz jedes Elements.

Jede Prüfung eines Zweigs wird aus dem ausgeschnitten, was dieses Gerät wirklich zeigt, sodass das eigene Layout eines Smartphones nie als Fehler gilt, eine echte Regression auf diesem Smartphone aber weiterhin schon.

Wenn ein Schritt auf einem Gerät nicht ausgeführt werden kann, sagt der Zweig das.Er braucht dann Ihre Aufmerksamkeit, und GUI Test Studio markiert den Schritt und sagt, warum.

Responsive Testing, Lokalisierungstests und langsame Netzwerke

Browser und Bildschirme sind die Hälfte dessen, was Nutzer mitbringen.Die andere Hälfte ist, wie ihr Browser eingerichtet ist.Ein Zweig kann unter Bedingungen laufen, und jede Bedingung, die Sie ankreuzen, wird mit den Browsern und Geräten kombiniert, die Sie gewählt haben.

Vergrößern

Headless und nebeneinander

Ein Zweig kann headless laufen: Der Browser arbeitet ohne Fenster, sodass Ihr Bildschirm und Ihr Computer frei für Sie bleiben.Smartphones, Tablets und Zweige mit einer Bedingung laufen immer so.Desktop-Zweige ebenfalls, wenn der Test es erlaubt, was die Standardeinstellung ist.Der aufgezeichnete Test selbst läuft in einem Fenster, so wie er aufgezeichnet wurde.

Headless-Browser-Tests machen auch paralleles Testen einfach.Die Zweige, die kein Fenster brauchen, laufen nebeneinander, je nach Computer bis zu vier gleichzeitig.

Klicken Sie bei einem solchen Test auf Test ausführen, und GUI Test Runner-Recorder fragt, welche Versionen dieser Lauf abdeckt.Jeder erzeugte Zweig ist angekreuzt, und die erwartete Zeit steht unter der Liste.Sie ergibt sich daraus, wie lange jeder beim letzten Mal gedauert hat: ein typischer Wert, keine Obergrenze.

Vergrößern

Am Ende listet ein Fenster das Ergebnis jedes Laufs auf, jeweils mit seinem Bericht.Zum Lauf selbst siehe Einen Test ausführen.

Cross-Browser-Testing in CI/CD

gtr-cli, das Befehlszeilen-Tool von GUI Test Studio, führt dieselben Zweige in jeder Pipeline aus.--branch all führt den aufgezeichneten Test und jeden Zweig aus, jeden mit eigenem Eintrag in der JUnit-Datei und eigener Historie.gtr-cli generate erstellt die Zweige, die fehlen oder veraltet sind.

gtr-cli generate Checkout.GTS --branch missing
gtr-cli run Checkout.GTS --branch all --junit results\junit.xml

Tests in Ihrer Pipeline ausführen listet jede Option auf.Das TeamCity-Beispiel geht eine echte Pipeline Schritt für Schritt durch und funktioniert mit jedem CI/CD-Tool genauso.

Ein Bericht pro Browser und Gerät

Jeder Zweig ist bei den Ergebnissen ein eigener Test: sein Konfidenzbericht, seine Laufhistorie und sein Video.So sagt ein Fehlschlag immer, wo er passiert ist: in Firefox, auf einem quer gehaltenen Smartphone oder auf Französisch.

Im Konfidenzbericht listet die Schaltfläche Browser & Geräte die Aufzeichnung und jeden Zweig mit seinem letzten Ergebnis auf.Sie öffnet den Bericht dessen, den Sie auswählen.

Änderungen folgen derselben Idee.Wenn Sie einen Zweig speichern, nachdem Sie geändert haben, was ein Schritt tut, fragt GUI Test Studio, ob die Änderung für jeden Browser und jedes Gerät gilt oder nur für diesen.Wenn Sie den aufgezeichneten Test ändern, bietet es an, jeden Browser und jedes Gerät daraus zu aktualisieren.

Was Sie vor dem Start wissen sollten

Ein paar Grenzen, damit Sie mit offenen Augen wählen können.

Sie möchten das ganze Bild dessen, was GUI Test Studio über den Browser hinaus abdeckt?Siehe End-to-End-Tests.

Fragen

Selenium, Playwright, Cypress, BrowserStack, TestMu AI, LambdaTest, Sauce Labs, Chrome, Edge, Firefox, Safari und iPhone sind Marken ihrer jeweiligen Inhaber.