Testowanie automatyczne w środowisku chmurowym: Selenium Grid 4, Playwright i koszty równoległości

Automatyzacja testów w chmurze to uruchamianie testów automatycznych na przeglądarkach, urządzeniach i maszynach, które wynajmujecie na żądanie, zamiast trzymać je w pokoju obok. W praktyce oznacza to trzy rzeczy: równoległość, czyli wiele testów naraz, szeroką macierz przeglądarek i urządzeń oraz rachunek za minuty albo sesje. Poniżej znajdziecie działający Selenium Grid 4, konfigurację Playwright z podziałem na shardy, gotowy plik GitHub Actions i nasz pomiar czasu dla 1, 2, 4 i 8 workerów.

Ten tekst jest dla zespołów, które mają już testy automatyczne i chcą, żeby kończyły się w minutach, a nie w trakcie lunchu. Jeśli dopiero wybieracie narzędzie, zacznijcie od porównania Selenium, Cypress i Playwright. Jeśli interesuje Was testowanie aplikacji, które same działają w chmurze (skalowanie, odporność, koszty infrastruktury), to osobny temat, który omawiamy na szkoleniu testowanie oprogramowania w chmurze.

Czym jest automatyzacja testów w chmurze?

Automatyzacja testów w chmurze to przeniesienie wykonania testów z jednego komputera na pulę zasobów, którą można powiększyć na czas przebiegu i oddać zaraz po nim. NIST SP 800-145 z 2011 roku opisuje chmurę przez 5 cech, a dla testerów liczą się dwie z nich: samoobsługa na żądanie i szybka elastyczność. Wy zamawiacie 8 przeglądarek na 10 minut, płacicie za 10 minut i nie myślicie o serwerze przez resztę tygodnia.

Same testy się nie zmieniają. Zmienia się to, gdzie startuje przeglądarka: zamiast lokalnego sterownika test łączy się ze zdalnym punktem, na przykład adresem Selenium Grid, albo jest jednym z kilku zadań w pipeline CI. Dlatego najczęstszy błąd przy migracji nie leży w chmurze, tylko w testach, które zakładały, że zawsze biegną pojedynczo, po kolei i na tych samych danych.

Jakie są trzy modele uruchamiania testów w chmurze?

Pierwszy akapit odpowiedzi jest prosty: albo sami stawiacie przeglądarki (Selenium Grid w kontenerach), albo wynajmujecie moc obliczeniową i dzielicie testy między maszyny CI (Playwright z shardami), albo kupujecie gotową farmę przeglądarek i urządzeń. Każdy model ma inny rachunek i innego właściciela problemów.

Porównanie dwóch najpopularniejszych farm, czyli Sauce Labs i BrowserStack, opisaliśmy osobno w artykule Sauce Labs i BrowserStack: chmurowe platformy do testów cross-browser. Tutaj skupiamy się na tym, co jest wspólne dla wszystkich modeli: jak zaprojektować testy pod równoległość i jak policzyć, czy się to opłaca.

Jak działa Selenium Grid 4?

Selenium Grid 4 przyjmuje polecenia WebDriver od testu i przekazuje je do zdalnej przeglądarki na jednym z węzłów. Według dokumentacji Selenium Grid 4 składa się z 6 komponentów, które w trybie standalone działają w jednym procesie, a w trybie rozproszonym mogą stać na osobnych maszynach.

Grid ma 3 tryby: standalone (wszystko w jednym procesie, idealny na start), hub i node (klasyczny podział na koordynatora i węzły) oraz tryb w pełni rozproszony dla dużych instalacji. Do uruchomienia potrzebujecie Javy 11 lub nowszej i jednego pliku jar; my w przykładach używamy Selenium 4.51.0 z 9 października 2026 roku. Dokumentacja Selenium podaje prosty wzór: liczba testów razy średni czas testu podzielone przez liczbę węzłów. Według tego samego źródła 100 testów po 120 sekund na 15 węzłach kończy się po 13 minutach i 20 sekundach, a bez Grida trwałoby ponad 3 godziny.

Terminal: Grid standalone z czterema slotami

java -jar selenium-server-4.51.0.jar standalone --max-sessions 4

Jak uruchomić Selenium Grid w kontenerach i podłączyć test w Javie?

Najprostsza droga to obrazy z projektu docker-selenium: jeden kontener z hubem i po jednym kontenerze na przeglądarkę. Ten sam plik uruchomicie lokalnie, na maszynie wirtualnej w dowolnej chmurze publicznej albo jako punkt wyjścia do klastra Kubernetes. Poniżej konfiguracja na wydaniu 4.49.0-20260909, najnowszym w repozytorium w dniu pisania.

docker-compose.yml

services:
  selenium-hub:
    image: selenium/hub:4.49.0-20260909
    container_name: selenium-hub
    ports:
      - "4442:4442"
      - "4443:4443"
      - "4444:4444"

  chrome:
    image: selenium/node-chrome:4.49.0-20260909
    shm_size: 2gb
    depends_on:
      - selenium-hub
    environment:
      - SE_EVENT_BUS_HOST=selenium-hub
      - SE_NODE_MAX_SESSIONS=4
      - SE_NODE_OVERRIDE_MAX_SESSIONS=true

  firefox:
    image: selenium/node-firefox:4.49.0-20260909
    shm_size: 2gb
    depends_on:
      - selenium-hub
    environment:
      - SE_EVENT_BUS_HOST=selenium-hub

Dwie linie robią tu największą różnicę. shm_size: 2gb to zalecenie z dokumentacji projektu, bo przeglądarka w kontenerze z domyślną, małą pamięcią współdzieloną potrafi się wyłożyć przy cięższych stronach. Para SE_NODE_MAX_SESSIONS i SE_NODE_OVERRIDE_MAX_SESSIONS pozwala węzłowi Chrome obsłużyć 4 sesje naraz; bez drugiej zmiennej Grid ograniczy się do liczby procesorów kontenera. Bezpieczniejszą praktyką jest jednak więcej małych węzłów niż jeden duży, bo awaria jednej przeglądarki nie zabiera wtedy ze sobą trzech pozostałych.

Test nie wie, gdzie stoi przeglądarka. Zamiast new ChromeDriver() tworzycie RemoteWebDriver z adresem Grida. Poniższą klasę skompilowaliśmy w Javie 21 i uruchomiliśmy 10.10.2026 na Grid standalone 4.51.0 z Chrome 154: dodaje 4 produkty do koszyka na naszej stronie treningowej selenium-shop.pl.

GridKoszykTest.java

package pl.qualityisland.grid;

import java.net.URI;
import java.time.Duration;
import java.util.List;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

public class GridKoszykTest {

    static final String GRID = System.getenv().getOrDefault("GRID_URL", "http://localhost:4444");
    static final String SKLEP = "http://www.selenium-shop.pl/produkt/";

    static String dodajDoKoszyka(String slug) throws Exception {
        ChromeOptions opcje = new ChromeOptions();
        opcje.addArguments("--headless=new");
        WebDriver driver = new RemoteWebDriver(URI.create(GRID).toURL(), opcje);
        try {
            driver.get(SKLEP + slug + "/");
            driver.findElement(By.name("add-to-cart")).click();
            String komunikat = new WebDriverWait(driver, Duration.ofSeconds(10))
                    .until(ExpectedConditions.visibilityOfElementLocated(By.className("woocommerce-message")))
                    .getText();
            if (!komunikat.contains("has been added to your cart")) {
                throw new AssertionError(slug + ": " + komunikat);
            }
            return slug + " OK";
        } finally {
            driver.quit();
        }
    }

    public static void main(String[] args) throws Exception {
        List<String> produkty = List.of(
                "pilka-nozna-kipsta-f100", "pilka-nozna-adidas-euro-2020",
                "koszulka-west-ham-united", "koszulka-leicester-fc-city");
        int watki = Integer.parseInt(System.getenv().getOrDefault("WATKI", "4"));
        long start = System.nanoTime();
        try (ExecutorService pula = Executors.newFixedThreadPool(watki)) {
            List<Future<String>> wyniki = pula.invokeAll(
                    produkty.stream().map(p -> (java.util.concurrent.Callable<String>) () -> dodajDoKoszyka(p)).toList());
            for (Future<String> w : wyniki) {
                System.out.println(w.get());
            }
        }
        System.out.printf("Czas: %.1f s przy %d watkach%n", (System.nanoTime() - start) / 1e9, watki);
    }
}

Z naszego pomiaru wynika, że przy 1 wątku cały przebieg trwał 8,7 sekundy, a przy 4 wątkach 3,5 sekundy, w tym start czterech przeglądarek. Adres Grida pochodzi ze zmiennej GRID_URL, więc ten sam kod pójdzie na lokalny Grid, na Grid w kontenerach i na komercyjną farmę, która też udostępnia punkt zgodny z WebDriver. W prawdziwym projekcie równoległość oddajecie frameworkowi testowemu, na przykład JUnit 5 albo TestNG, a nie ręcznej puli wątków, ale mechanika jest ta sama.

Jak Playwright uruchamia testy równolegle?

Playwright nie potrzebuje Grida, bo sam uruchamia testy równolegle w procesach roboczych, czyli workerach. Według dokumentacji Playwright domyślna liczba workerów to połowa logicznych rdzeni procesora, czyli na naszym komputerze z 12 rdzeniami logicznymi 6 workerów. Każdy worker to osobny proces z własną przeglądarką, a po nieudanym teście worker jest zamykany i startuje od nowa, żeby kolejne testy miały czyste środowisko.

playwright.config.ts

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

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  workers: process.env.CI ? 2 : undefined,
  retries: process.env.CI ? 1 : 0,
  reporter: process.env.CI ? 'blob' : 'list',
  use: {
    baseURL: 'http://www.selenium-shop.pl',
    trace: 'on-first-retry',
  },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  ],
});

tests/koszyk.spec.ts

import { test, expect } from '@playwright/test';

const produkty = [
  'pilka-nozna-kipsta-f100',
  'pilka-nozna-adidas-replika-liga-mistrzow',
  'pilka-nozna-adidas-euro-2020',
  'koszulka-newcastle-fc-united',
  'koszulka-west-ham-united',
  'koszulka-tottenham-hotspur-f-c',
  'koszulka-leicester-fc-city',
  'koszulka-manchester-fc-city',
];

for (const slug of produkty) {
  test(`dodanie do koszyka: ${slug}`, async ({ page }) => {
    await page.goto(`/produkt/${slug}/`);
    await expect(page.locator('h1.product_title')).toBeVisible();
    await page.locator('button[name="add-to-cart"]').click();
    await expect(page.locator('.woocommerce-message')).toContainText('has been added to your cart');
  });
}

Wykres pokazuje rzecz ważniejszą niż samo przyspieszenie. Z 1 na 2 workery czas spadł prawie o połowę, ale z 4 na 8 już tylko o 0,3 sekundy, bo 8 testów nie da się podzielić drobniej, a start przeglądarki i ładowanie konfiguracji zostają stałe. Ten sam efekt zobaczycie w chmurze: dokładanie maszyn ma sens, dopóki testów jest wyraźnie więcej niż slotów, a każdy test trwa dłużej niż jego przygotowanie.

Opcja fullyParallel: true pozwala dzielić między workery pojedyncze testy, a nie całe pliki. Bez niej plik z 40 testami zawsze biegnie w jednym workerze, a reszta czeka bezczynnie. Testy muszą być wtedy niezależne: każdy loguje się sam, tworzy własne dane i nie liczy na to, że poprzedni zostawił coś w koszyku.

Jak wygląda konfiguracja CI z podziałem testów na shardy?

Gdy jedna maszyna przestaje wystarczać, Playwright dzieli zestaw na shardy poleceniem --shard=1/4, --shard=2/4 i tak dalej, a każdy shard biegnie na osobnym runnerze CI. Według dokumentacji Playwright do równego podziału warto włączyć fullyParallel, a wyniki z shardów zapisuje się reporterem blob i scala poleceniem merge-reports. Poniższy plik dla GitHub Actions odpowiada przykładowi z dokumentacji, z 4 shardami i wspólnym raportem HTML.

.github/workflows/playwright.yml

name: Testy Playwright
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  testy:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    strategy:
      fail-fast: false
      matrix:
        shardIndex: [1, 2, 3, 4]
        shardTotal: [4]
    steps:
    - uses: actions/checkout@v6
    - uses: actions/setup-node@v6
      with:
        node-version: lts/*
    - name: Instalacja zależności
      run: npm ci
    - name: Instalacja przeglądarki
      run: npx playwright install --with-deps chromium
    - name: Testy, shard ${{ matrix.shardIndex }} z ${{ matrix.shardTotal }}
      run: npx playwright test --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}
    - name: Zapis raportu blob
      if: ${{ !cancelled() }}
      uses: actions/upload-artifact@v4
      with:
        name: blob-report-${{ matrix.shardIndex }}
        path: blob-report
        retention-days: 1

  raport:
    if: ${{ !cancelled() }}
    needs: [testy]
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v6
    - uses: actions/setup-node@v6
      with:
        node-version: lts/*
    - name: Instalacja zależności
      run: npm ci
    - name: Pobranie raportów z shardów
      uses: actions/download-artifact@v5
      with:
        path: all-blob-reports
        pattern: blob-report-*
        merge-multiple: true
    - name: Scalenie w raport HTML
      run: npx playwright merge-reports --reporter html ./all-blob-reports
    - name: Zapis raportu HTML
      uses: actions/upload-artifact@v4
      with:
        name: raport-html
        path: playwright-report
        retention-days: 14

Według GitHub Docs standardowy runner Linux ma 4 procesory i 16 GB pamięci w repozytorium publicznym, ale 2 procesory i 8 GB w prywatnym. Dlatego w konfiguracji wyżej ustawiamy na CI 2 workery, tak jak w przykładzie z dokumentacji Playwright: na runnerze z 2 procesorami 4 przeglądarki przepychałyby się o czas procesora i testy zaczęłyby przekraczać limity czasu. Lepiej dodać shard niż dokładać workery na słabej maszynie. Tę konfigurację uruchomiliśmy lokalnie ze zmienną CI=1: 8 testów przeszło, a reporter blob zapisał plik do scalenia. Jeśli budujecie pipeline od zera albo chcecie go uporządkować, pomagamy przy budowie procesów CI/CD razem z testami, które w nim biegną.

Ile kosztuje równoległość i gdzie uciekają pieniądze?

Równoległość skraca czas oczekiwania na wynik, ale nie zmniejsza ilości pracy do wykonania. Minuty procesora i tak trzeba przepalić, a każdy dodatkowy shard dokłada stały narzut: pobranie repozytorium, instalację zależności i przeglądarek. Rachunek najlepiej pokazać na liczbach, z zastrzeżeniem, że wolumen poniżej jest przykładowy, a stawki pochodzą z cennika.

Według cennika GitHub Actions odczytanego 10.10.2026 minuta runnera Linux 2-core kosztuje 0,006 USD, Windows 2-core 0,010 USD, a macOS 0,062 USD, czyli ponad 10 razy więcej niż Linux. Ten sam cennik daje kontu GitHub Free 2 000 minut miesięcznie dla repozytoriów prywatnych, a w repozytoriach publicznych standardowe runnery są bezpłatne. Wniosek z tabeli: dziesięć shardów zamiast jednego skraca oczekiwanie z prawie dwóch godzin do kwadransa, a rachunek rośnie o kilkanaście centów. Najdroższym zasobem w tym równaniu jest czas programistów czekających na wynik, nie minuty runnera.

W farmach przeglądarek rachunek wygląda inaczej. Płacicie za liczbę równoległych sesji w abonamencie, więc pytanie brzmi nie „ile minut”, tylko „ile testów naraz”. Jeśli zestaw ma 600 testów, a plan 5 sesji, to farma i tak wykona je po 5. Dlatego przed zakupem zmierzcie średni czas testu i policzcie z wzoru z dokumentacji Selenium, ile slotów potrzebujecie, żeby zmieścić się w Waszym budżecie czasu, na przykład 15 minut na pull request. Konkretnych cen nie podajemy, bo zmieniają się częściej niż wersje przeglądarek; sprawdzajcie je w dniu decyzji na stronie dostawcy.

Kiedy chmura nie pomoże Waszym testom?

Chmura przyspiesza testy dobre i zwielokrotnia problemy testów złych. W naszych projektach audytowych najczęściej widzimy trzy przyczyny, przez które przeniesienie do chmury kończy się rozczarowaniem, i żadna z nich nie dotyczy dostawcy.

Osobna sprawa to dane. Kopiowanie bazy produkcyjnej na środowisko testowe w chmurze to prosta droga do problemu z RODO, o czym szerzej piszemy na Strefie QA w tekście Dane testowe a GDPR: dlaczego kopiowanie produkcji to proszenie się o kłopoty. Dane syntetyczne generowane przez sam test rozwiązują przy okazji problem niezależności testów z pierwszego wiersza tabeli.

Druga uwaga: chmura nie naprawi niestabilnych testów. Jeżeli 3 testy na 100 padają losowo, to przy 10 równoległych przebiegach dziennie zespół codziennie ogląda czerwony pipeline i po tygodniu przestaje mu wierzyć. Zanim zapłacicie za równoległość, warto policzyć, ile testów rzeczywiście daje informację; o tym, kiedy automatyzacja się opłaca, a kiedy przepala budżet, piszemy w artykule zalety i wady automatyzacji testów.

Od czego zacząć przeniesienie testów do chmury?

Zacznijcie od pomiaru, nie od wyboru dostawcy. Ten plan w pięciu krokach sprawdza się u naszych klientów niezależnie od tego, czy kończy się własnym Gridem, czy farmą przeglądarek.

W projekcie dla Argos, sklepu internetowego, uporządkowanie procesów QA i automatyzacja testów skróciły regresję przed wydaniem z 5 dni do 10 godzin, a pełny opis znajdziecie w artykule jak skrócić testy regresyjne z 5 dni do 10 godzin. Według naszych danych zespół Quality Island napisał dotąd ponad 450 000 testów automatycznych i to doświadczenie mówi jedno: o czasie regresji częściej decyduje projekt testów niż moc obliczeniowa. Jeśli chcecie przejść tę drogę z zespołem, prowadzimy szkolenia automatyzacja testów z Playwright i automatyzacja testów Selenium, a infrastrukturę kontenerową omawiamy na szkoleniu CI/CD dla kontenerów.

Powiązane na blogu Quality Island

• Sauce Labs i BrowserStack: chmurowe platformy do testów cross-browser i cross-device
• Selenium, Cypress czy Playwright: porównanie narzędzi do automatyzacji testów
• Jak skrócić testy regresyjne z 5 dni do 10 godzin: case Argos
• CI/CD dla testerów oprogramowania: Jenkins, szkolenie

Pełna lista źródeł

• Selenium, Selenium Grid components, dokumentacja, 2026. Stąd 6 komponentów Grida.
• Selenium, Getting started with Selenium Grid, 2026. Stąd tryby, porty 4444, 4442, 4443, wymóg Javy 11 i domyślna liczba sesji równa liczbie procesorów.
• Selenium, When to use Grid, 2026. Stąd wzór na czas przebiegu i przykład 100 testów na 15 węzłach.
• SeleniumHQ, docker-selenium i ENV_VARIABLES, wydanie 4.49.0-20260909, 2026. Stąd obrazy, shm_size 2gb i SE_NODE_MAX_SESSIONS domyślnie 1.
• Microsoft, Playwright: Parallelism, Sharding i TestConfig, wersja 1.64, 2026.
• GitHub, GitHub-hosted runners reference, 2026. Stąd parametry runnerów publicznych i prywatnych.
• GitHub, GitHub Actions billing, odczyt 10.10.2026. Stąd stawki za minutę i 2 000 minut w planie Free.
• BrowserStack, Automate pricing, odczyt 10.10.2026. Stąd model planów według liczby testów równoległych, bez cen.
• NIST, SP 800-145 The NIST Definition of Cloud Computing, 2011.
• Quality Island, pomiar Playwright 1.64.0 i Selenium Grid 4.51.0 na selenium-shop.pl, 10.10.2026; case Argos i liczba 450 000 testów automatycznych z danych firmy, 2026.

Autor: Tomasz Stelmach, Quality Island.