Parallele Testausführung teilt eine Testsuite in unabhängige Teile auf und lässt diese gleichzeitig auf mehreren Prozessen, Maschinen oder Containern laufen. Das senkt die Testlaufzeit im CI, ohne Testfälle zu streichen. Eine Suite, die seriell 40 Minuten braucht, kann auf vier Workern in einem Bruchteil dieser Zeit fertig sein. Dieser Leitfaden zeigt Schritt für Schritt, wie Sie Tests parallelisieren: aufteilen, isolieren, auf mehreren Workern ausführen, Ergebnisse zusammenführen. Sie erfahren, welche Werkzeuge das unterstützen, wie Sie Tests trotz Parallelität stabil halten und ab wann zusätzliche Worker keinen Nutzen mehr bringen.

Kurz gefasst: Parallele Testausführung verteilt eine Testsuite auf mehrere Worker und verkürzt so die CI-Laufzeit. Bei vier gleich grossen Shards läuft die Suite laut Playwright-Dokumentation viermal schneller. Voraussetzung sind isolierte Tests ohne geteilten Zustand, sonst steigt das Risiko instabiler Ergebnisse.

Abbildung 1: Seriell gegen parallel - vier Worker verkuerzen 40 Minuten Laufzeit auf rund 10 Minuten.

Was ist parallele Testausführung?

Parallele Testausführung ist eine Technik, bei der eine Testsuite in mehrere unabhängige Gruppen aufgeteilt und zeitgleich ausgeführt wird, statt einen Test nach dem anderen abzuarbeiten. Das Ergebnis ist eine kürzere Gesamtlaufzeit, ohne dass Testfälle wegfallen.

Die Testlaufzeit ist in modernen Pipelines oft der Engpass. Jeder Commit löst einen Build und eine Testausführung aus; dauert diese 40 Minuten, warten Entwickler 40 Minuten auf Feedback. Kontinuierliches Testen im Pipeline-Prozess liefert nur dann schnelles Feedback, wenn die Tests schnell durchlaufen (DORA, 2024).

Serielle Ausführung wird mit jedem zusätzlichen Test langsamer: doppelt so viele Tests bedeuten doppelt so lange Wartezeit. Parallele Testausführung durchbricht diesen Zusammenhang, indem sie die Tests auf mehrere Ausführungseinheiten verteilt, die parallel arbeiten.

Wie verkürzt Parallelisierung die Testlaufzeit?

Abbildung 2: In vier Schritten parallelisieren - aufteilen, isolieren, ausfuehren, zusammenfuehren.

Parallelisierung verkürzt die Testlaufzeit, indem sie die Testfälle auf mehrere Worker verteilt, die gleichzeitig laufen. „The whole purpose is to divide your tests to speed up test runtime”, schreibt die Playwright-Dokumentation; teilt man eine Suite in vier Shards auf vier parallele Jobs, wird sie viermal schneller fertig (Playwright, 2024).

Sharding meint das Aufteilen der Testmenge in Teilmengen (Shards); jeder Worker führt genau einen Shard aus. Die eigentliche Ausführung folgt vier Schritten:

1. Aufteilen: Die Suite in N möglichst gleich grosse Shards zerlegen, etwa nach Testdatei oder Testfall.

2. Isolieren: Sicherstellen, dass jeder Shard ohne geteilten Zustand läuft und keine feste Reihenfolge voraussetzt.

3. Ausführen: Die N Shards gleichzeitig auf N Workern, Containern oder Maschinen starten.

4. Zusammenführen: Die Teilergebnisse zu einem Gesamtreport aggregieren, der Pass oder Fail über alle Shards zeigt.

Ein Rechenbeispiel: Eine Suite mit 800 Tests, die seriell 40 Minuten braucht, läuft auf vier gleich ausgelasteten Workern im Idealfall in rund 10 Minuten. In der Praxis liegt der Wert etwas höher, weil Start, Verteilung und Zusammenführung Zeit kosten.

Welche Werkzeuge unterstützen parallele Tests?

Abbildung 3: Drei Werkzeuge fuer parallele Tests - Playwright Workers, Selenium Grid und pytest-xdist im Vergleich.

Mehrere etablierte Werkzeuge führen Tests parallel aus, jedes mit einem eigenen Modell: Playwright verteilt auf Worker-Prozesse, Selenium Grid auf mehrere Browser-Knoten, pytest-xdist auf mehrere CPU-Kerne. Der CI-Runner selbst parallelisiert zusätzlich auf Job-Ebene.

„Stages run in sequence, while the jobs in a stage run in parallel”, beschreibt die GitLab-Dokumentation das Grundprinzip; das Schlüsselwort „parallel” startet N Job-Instanzen, die je einen Teil der Tests übernehmen (GitLab, 2024).

Autemos ist mit Playwright-, Selenium- und Appium-Codebasen kompatibel und führt Web-, Mobile-, API- und Desktop-Tests in einer Pipeline aus. In Kundenprojekten sehen wir, dass die Kombination aus Parallelisierung im Framework und auf CI-Job-Ebene die grössten Zeitgewinne bringt.

Wie bleiben parallele Tests stabil?

Abbildung 4: Vier Praktiken, die parallele Tests stabil halten und Flakiness vermeiden.

Parallele Tests bleiben stabil, wenn jeder Test unabhängig läuft: keine geteilten Daten, keine feste Reihenfolge, keine gemeinsamen Ressourcen ohne Absicherung. Sobald zwei Tests dieselbe Datenbankzeile oder Datei anfassen, entstehen instabile („flaky”) Ergebnisse, die mal bestehen und mal fehlschlagen.

Flakiness ist unter Parallelität besonders sichtbar. Die erste grosse empirische Studie zu flaky Tests untersuchte 201 Commits, die flaky Tests in 51 Apache-Projekten korrigierten; die häufigsten Ursachen waren asynchrones Warten, Nebenläufigkeit und Abhängigkeit von der Testreihenfolge (Luo et al., FSE 2014). Genau diese Ursachen treten bei paralleler Ausführung häufiger auf.

Wie verbreitet das Problem ist, zeigt eine oft zitierte Zahl von Google: Rund 16 Prozent der Tests wiesen eine gewisse Flakiness auf (John Micco / Google, GTAC 2016, berichtet). Diese Angabe stammt aus einem Vortrag, nicht aus einer geprüften Veröffentlichung, und ist entsprechend vorsichtig zu lesen.

Praktiken, die Tests unter Parallelität stabil halten:

• Jeder Test legt seine eigenen Testdaten an und räumt sie danach wieder weg.

• Kein globaler Zustand zwischen Tests; Fixtures pro Test oder pro Worker.

• Eindeutige Kennungen (etwa pro Worker) für Dateien, Nutzerkonten und Datenbankschemata.

• Stabile Locators, die UI-Änderungen überstehen, damit nicht ganze Shards an einem verschobenen Element scheitern.

Der letzte Punkt zählt im CI besonders: Selbstheilende Locators fangen kleine UI-Änderungen ab und verhindern Fehlalarme, die sonst einen kompletten Parallel-Lauf rot färben. Mehr dazu im Beitrag zu Self-Healing Locators. Wer parallele Läufe für den Regressionstest nutzt, profitiert doppelt, weil die grosse, wiederkehrende Suite den grössten Zeitanteil ausmacht.

Wann bringt mehr Parallelität nichts mehr?

Zusätzliche Worker bringen ab einem gewissen Punkt kaum noch Zeitgewinn, weil ein Teil der Arbeit nicht parallelisierbar ist. Build, Verteilung der Shards, Einrichtung der Testumgebung und das Zusammenführen der Ergebnisse laufen unabhängig von der Worker-Zahl. Dieser feste Anteil setzt eine untere Grenze für die erreichbare Laufzeit.

Ein Beispiel: Nehmen die nicht parallelisierbaren Schritte 5 Minuten in Anspruch, kommt die Suite nie unter 5 Minuten, egal wie viele Worker laufen. Von 4 auf 8 Worker halbiert sich der parallelisierbare Teil; von 16 auf 32 sinkt er kaum noch spürbar, während die Infrastrukturkosten weiter steigen.

Drei Grenzen setzen der Parallelität ein natürliches Ende:

• Fester Restanteil: Nicht parallelisierbare Schritte bestimmen die Mindestlaufzeit.

• Ungleiche Shards: Ist ein Shard viel langsamer, wartet die Pipeline auf ihn, nicht auf den Durchschnitt.

• Infrastruktur: Mehr Worker bedeuten mehr CI-Minuten, mehr Container und höhere Kosten pro Lauf.

In der Praxis lohnt es sich, die Shard-Zahl zu erhöhen, bis der Zeitgewinn pro zusätzlichem Worker klein wird, und dann bei der ungleichen Verteilung anzusetzen. Wie sich das in eine Pipeline einbettet, zeigt der Beitrag zur Testautomatisierung in CI/CD und der Überblick zu Continuous Testing.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Sharding und parallelen Workern?

Sharding teilt die Testmenge in Teilmengen auf; Worker sind die Prozesse oder Maschinen, die diese Teilmengen ausführen. Sharding beantwortet die Frage „welche Tests laufen zusammen”, Worker die Frage „wo laufen sie”. Beide zusammen ergeben parallele Testausführung: N Shards auf N Workern.

Wie viele parallele Worker sind sinnvoll?

Sinnvoll ist die Worker-Zahl, bei der jeder zusätzliche Worker noch spürbar Zeit spart. In der Praxis liegt das oft zwischen 4 und 16 für E2E-Suiten, abhängig vom festen, nicht parallelisierbaren Anteil und dem CI-Budget. Darüber hinaus sinkt der Nutzen pro Worker deutlich.

Machen parallele Tests die Ergebnisse instabiler?

Parallele Tests werden nur dann instabil, wenn sie geteilten Zustand oder eine feste Reihenfolge voraussetzen. Isolierte Tests mit eigenen Daten und ohne globale Ressourcen laufen parallel genauso zuverlässig wie seriell. Die Ursachen von Flakiness sind meist asynchrones Warten und Nebenläufigkeit (Luo et al., FSE 2014).

Kann ich Tests parallelisieren, ohne den Code umzuschreiben?

Teilweise: Werkzeuge wie Playwright und pytest-xdist verteilen bestehende Tests automatisch, sofern diese unabhängig sind. Voraussetzungen sind isolierte Testdaten und kein geteilter Zustand. Tests, die auf globalen Daten oder fester Reihenfolge beruhen, müssen vorher entkoppelt werden.

Welches Werkzeug eignet sich für parallele Browser-Tests?

Für parallele Browser-Tests eignen sich Playwright mit Worker-Prozessen und Selenium Grid mit mehreren Nodes. Playwright parallelisiert innerhalb einer Maschine und über Sharding hinweg; Selenium Grid verteilt Tests über einen Hub auf mehrere Browser-Knoten. Die Wahl hängt von der bestehenden Codebasis ab.

Fazit

Parallele Testausführung ist der direkteste Weg, um die Testlaufzeit im CI zu verkürzen: Suite aufteilen, Tests isolieren, auf mehreren Workern ausführen, Ergebnisse zusammenführen. Bei vier Shards läuft eine Suite laut Playwright viermal schneller, und der Effekt steigt mit der Zahl der Worker, bis der feste, nicht parallelisierbare Anteil die Grenze setzt. Der Preis dafür ist Disziplin bei der Testisolation: Ohne unabhängige Tests ohne geteilten Zustand kippt der Zeitgewinn in instabile Ergebnisse. Wer diese Grundlage legt, gewinnt schnelles Feedback für jeden Commit zurück. Autemos führt parallele Web-, Mobile-, API- und Desktop-Tests in einer Pipeline aus und synchronisiert die Ergebnisse mit GitLab, GitHub Actions und Jenkins. Sehen Sie sich den KI-Recorder von Autemos an oder sprechen Sie mit uns über Ihre Pipeline.