> Hol segítenek az AI-ágensek E2E-teszteknél: Playwright planner, generator és healer, MCP vagy CLI, és a korlátok, melyek őszintén tartják a javított teszteket.
>
> Web page: https://balazscsorba.com/hu/blog/browser-agents-e2e-testing-playwright · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/browser-agents-e2e-testing-playwright.md) · [Deutsch](https://balazscsorba.com/de/blog/browser-agents-e2e-testing-playwright.md)
> Author: Balázs Csorba · Published: 2026-10-16 · Keywords: playwright test agents, playwright planner generator healer, ai e2e testing, playwright mcp, llm generated playwright tests, self-healing tests, browser agent testing, playwright init-agents, ai test automation 2026, playwright cli skills

[Blog](https://balazscsorba.com/hu/blog)/MI-ágensek

# Böngészőágensek E2E-teszteléshez: írják az ágensek a Playwright-teszteket, ne futtassák

Hol segítenek az AI-ágensek E2E-teszteknél: Playwright planner, generator és healer, MCP vagy CLI, és a korlátok, melyek őszintén tartják a javított teszteket.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 16.·7 perc olvasás

-   Playwright
-   E2E testing
-   Coding agents
-   MCP
-   Test automation

![Egy ágens bejár egy webalkalmazást, Markdown tesztervet ír, Playwright-tesztekké alakítja, a healer pedig lokátorokat javít, miközben az ellenőrzések felülvizsgálat alatt maradnak.](https://balazscsorba.com/images/blog/browser-agents-e2e-testing-playwright/cover.webp?v=0ad9b19637)

## A lényeg röviden

-   Az ágensek írják és tartsák karban a determinisztikus Playwright-teszteket; a CI sima tesztfájlokat futtasson, ne egy LLM-et, amely eldönti, mi ment át.
-   A Playwright planner, generator és healer ágenseket ad, amelyek egy seed tesztből és egy kérésből Markdown tervet, majd tesztfájlokat készítenek.
-   Kódoló ágensekhez a Playwright saját dokumentációja ma már a skillekkel kiegészített CLI-t ajánlja az MCP-szervernél takarékosabbnak tokenben.
-   A healer önállóan módosíthat lokátorokat és várakozásokat; egy ellenőrzés bármilyen változtatásához vagy egy kihagyott teszthez emberi átnézés kell.
-   Az akadálymentes markup a szerződés: a szerepalapú lokátorokra építenek az ágensek és a stabil tesztek is.

Ezen az oldalon

1.  [Milyen három módon használhatók ágensek E2E-teszteléshez?](https://balazscsorba.com/#three-ways-agents-meet-e2e)
2.  [Hogyan működnek a Playwright tesztágensei?](https://balazscsorba.com/#playwright-test-agents)
3.  [Playwright MCP-t vagy CLI-t használjanak a kódoló ágensek?](https://balazscsorba.com/#mcp-or-cli)
4.  [Miért az akadálymentes markup a szerződés az ágensek és a tesztek között?](https://balazscsorba.com/#accessibility-is-the-contract)
5.  [Hogyan maradnak őszinték az önjavító tesztek?](https://balazscsorba.com/#healer-guardrails)
6.  [Mikor van mégis értelme a futásidejű böngészőágensnek?](https://balazscsorba.com/#runtime-agents)
7.  [Hogyan néz ki egy gyakorlati beállítás?](https://balazscsorba.com/#setup-checklist)
8.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

A böngészőágensek ma már meg tudnak nyitni egy alkalmazást, el tudják olvasni az oldalt, végig tudnak kattintani egy fizetési folyamaton, és meg tudják mondani, hogy működött-e. Csábító ebből tesztkészletet csinálni: hétköznapi nyelven leírni a folyamatokat, és minden pull requestnél egy modellel ellenőriztetni őket. Szerintem ez rossz hely a modellnek. A jobb munkamegosztás: az ágensek végzik a drága emberi munkát – az alkalmazás felderítését, a tesztek megírását és a törött lokátorok javítását –, a CI pedig sima Playwright-teszteket futtat, amelyek minden alkalommal ugyanazt a választ adják.

A cikk összeveti, milyen három módon találkoznak az ágensek az E2E-teszteléssel, végigmegy a Playwright saját tesztágensein, kitér az MCP és a CLI választására kódoló ágenseknél, és rögzíti azokat a korlátokat, amelyekkel elérem, hogy egy önjavító teszt ne „gyógyíthasson el” csendben egy valódi hibát.

## Milyen három módon használhatók ágensek E2E-teszteléshez?

Megközelítés

Mit csinál az ágens

Fut a CI-ban?

Fő kockázat

Az ágens tesztet ír

Bejárja az alkalmazást, tervet és Playwright-tesztfájlokat ír

Nem, a tesztek futnak

Rossz dolgot ellenőrző tesztek

Az ágens tesztet javít

Lefuttatja a hibás teszteket, megvizsgálja a felületet, javítja a lokátorokat és várakozásokat

Opcionálisan, külön jobként

Egy valódi regresszió „elgyógyítása”

Az ágens maga a teszt

Természetes nyelvű lépéseket követ élő böngészőben, és megítéli az eredményt

Igen

Lassú, drága, nem determinisztikus ítéletek

A teszt attól hasznos, hogy rögzített orákulum: ugyanaz a kód, ugyanaz az adat és ugyanaz az ellenőrzés ugyanazt az eredményt adja. Egy képernyőképet megítélő modell második vélemény, nem orákulum. Felderítésre hasznos, de a piros buildnek azt kell jelentenie, hogy a termék változott meg, nem azt, hogy a modell gondolta meg magát.

## Hogyan működnek a Playwright tesztágensei?

A Playwright három [tesztágenst](https://playwright.dev/docs/test-agents) ad ágensdefinícióként, amelyeket az `npx playwright init-agents` paranccsal teszel a repóba, VS Code-, Claude Code-, Codex- és OpenCode-változattal. A dokumentáció szerint minden Playwright-frissítés után újra kell generálni őket, hogy megkapják az új eszközöket és utasításokat.

Minden ágenskimenet egy fájl a repóban: a tervek, a tesztek és a javítások is a szokásos kódátnézésen mennek át.

-   **Planner:** kap egy kérést, például „tervezd meg a vendégként történő fizetést”, egy seed tesztet, amely előkészíti a fixture-öket és a belépést, és opcionálisan egy követelménydokumentumot. Lefuttatja a seed tesztet, bejárja az alkalmazást, és Markdown tervet ír a `specs/` mappába.
-   **Generator:** a tervből Playwright-teszteket készít a `tests/` alá, és a forgatókönyvek végrehajtása közben élőben ellenőrzi a szelektorokat és az ellenőrzéseket. A dokumentáció szerint a generált tesztek eleinte hibákat tartalmazhatnak.
-   **Healer:** egy hibás tesztnél újrajátssza a lépéseket, a jelenlegi felületen egyenértékű elemeket keres, javítást javasol, például lokátorfrissítést, várakozás-módosítást vagy adatjavítást, és addig futtatja újra, amíg a teszt át nem megy, vagy a korlátok meg nem állítják. Az eredmény egy sikeres teszt, vagy egy kihagyott, ha úgy ítéli, hogy a funkció hibás.

```
# Add the agent definitions for your coding agent (regenerate after Playwright upgrades)
npx playwright init-agents --loop=claude

# tests/seed.spec.ts: everything the agents need to reach a logged-in state
import { test, expect } from './fixtures'
test('seed', async ({ page }) => {
  await page.goto('/')
  await expect(page.getByRole('navigation')).toBeVisible()
})
```

## Playwright MCP-t vagy CLI-t használjanak a kódoló ágensek?

A [Playwright MCP](https://github.com/microsoft/playwright-mcp) révén a modell strukturált akadálymentességi pillanatképeken keresztül vezérli a böngészőt képernyőképek helyett, így nem kell hozzá vizuális modell, és elkerüli a pixelekre kattintás kétértelműségét. A saját README-je viszont ma már határt húz: kódoló ágensekhez a skillekkel kiegészített Playwright CLI-t ajánlja, mert a CLI-hívások nem töltenek nagy eszközsémákat és bőbeszédű akadálymentességi fákat a kontextusba. Az MCP azokhoz a ciklusokhoz marad jobb, amelyeknek jót tesz a tartós böngészőmunkamenet, például a felfedező automatizáláshoz és az önjavító tesztekhez.

Ez egybevág az [AGENTS.md, skillek, MCP vagy CLI](https://balazscsorba.com/hu/blog/agents-md-skills-mcp-cli-decision-matrix) cikk általános mérlegelésével: minden állandóan betöltött eszközséma és minden oldal-pillanatkép minden körben kontextusba kerül. Ha egy tesztmunkamenethez csak néhány oldalolvasás kell, a CLI olcsóbb; a [kódoló ágensek tokenspórolása](https://balazscsorba.com/hu/blog/token-saving-tools-coding-agents-top-20) cikk technikái itt is érvényesek.

## Miért az akadálymentes markup a szerződés az ágensek és a tesztek között?

A Playwright [bevált gyakorlatai](https://playwright.dev/docs/best-practices) a felhasználó által látott tulajdonságokra épülő lokátorokat ajánlják, például `getByRole('button', { name: 'Submit' })`, CSS-osztályok és XPath helyett, mert a DOM szerkezete gyakrabban változik, mint az, amit a felhasználó lát. A Playwright MCP ugyanezt az akadálymentességi fát olvassa. Ugyanaz a munka, amely képernyőolvasóval használhatóvá teszi az oldalt, az ágensnek is megkönnyíti a felderítést, és újratervezést is túlélő teszteket eredményez. Egy szerep nélküli, formázott `div` gomb mindhármuk számára láthatatlan.

Az EU-s webshopoknál ez amúgy sem választható; lásd [az európai akadálymentességi irányelv B2B-webshopoknak](https://balazscsorba.com/hu/blog/european-accessibility-act-b2b-shop) cikket. A szerepek és címkék javítása egyszerre szolgálja a megfelelést, az ágenseket és a tesztek stabilitását.

## Hogyan maradnak őszinték az önjavító tesztek?

A healer feladatleírásában benne van a kockázat: addig futtat újra, amíg a teszt át nem megy, és ha úgy véli, hogy a funkció hibás, kihagyottnak jelöli a tesztet. Mindkét kimenet rendben van, ha egy gombot átneveztek. Mindkettő rossz, ha a gomb egy valódi hiba miatt tűnt el. Az én szabályom egyszerű: a healer azt módosíthatja, hogyan talál meg a teszt dolgokat, azt soha, hogy mit ellenőriz.

**Egy meggyógyított, már nem bukó teszt még nem javított teszt**

Minden olyan healer-javítást, amely `expect(...)` sort érint, lépést töröl, vagy `test.skip`\-et, illetve `test.fixme`\-t ad hozzá, kezelj lehetséges termékhibaként. Küldd tovább egy embernek, a hibás futás trace-ével együtt.

```
#!/usr/bin/env bash
# CI gate for agent-made test changes: locator and wait edits pass, assertion edits need review
set -euo pipefail
changed=$(git diff --unified=0 origin/main -- 'tests/**/*.spec.ts' | grep -E '^[-+][^-+]' || true)
if echo "$changed" | grep -Eq 'expect\(|test\.(skip|fixme)\(|\.toHave|\.toBe'; then
  echo "Assertions or skips changed in tests/: needs a human reviewer (label: test-assertions)"
  exit 1
fi
```

Ugyanez érvényes azokra a tesztekre, amelyeket egy ágens hibajavításhoz ír. Egy regressziós teszt csak akkor ér valamit, ha elbukik, amikor a javítást visszavonják; ezt minden hibajavító PR-nél ellenőrzöm, ahogy [az ágensciklus](https://balazscsorba.com/hu/blog/agent-loop-explained) és a [hibától a PR-ig tartó munkafolyamatom](https://balazscsorba.com/hu/blog/coding-agent-skills-workflow) cikkben leírtam.

## Mikor van mégis értelme a futásidejű böngészőágensnek?

Vannak esetek, amikor a rögzített szelektor rossz eszköz. Kiadás előtti felfedező tesztelés, amikor egy ágens szokatlan útvonalakat próbál ki, és jelzi, mi tűnt hibásnak. Füstpróbák olyan külső oldalakon, amelyeket nem te irányítasz, például egy fizetési szolgáltató átirányításán. Hetente változó belső back-office folyamatok. Ezekre az olyan könyvtárak, mint a [Stagehand](https://github.com/browserbase/stagehand), a természetes nyelvű `act`, `extract` és `observe` hívásokat Playwright-stílusú oldal- és lokátor-API-kkal kombinálják, így egy szkript nagyrészt determinisztikus lehet néhány rugalmas lépéssel. Részletesebben a [Stagehand-ismertetőben](https://balazscsorba.com/hu/tools/browserbase-stagehand) hasonlítom össze.

Ezeket a futásokat tartsd távol a merge-kaputól. Az eredményeiket issue-ként vagy új determinisztikus tesztként jelentsd, a sikeres vagy sikertelen döntés pedig maradjon olvasható kódnál.

## Hogyan néz ki egy gyakorlati beállítás?

1.  Egy seed teszt fixture-ökkel a belépéshez és a tesztadatokhoz, hogy az ágensek ismert állapotból induljanak.
2.  A `specs/` terveit követelményként nézd át: egy rossz terv helyesnek látszó teszteket szül rossz viselkedésre.
3.  A generált tesztek csak szerepalapú lokátorokat használnak; a CSS-szelektorok elbuknak a linten.
4.  A CI sima `npx playwright test`\-et futtat, hiba esetén trace-szel; a merge-kapuban nincs modell.
5.  A healer külön jobként fut, amely PR-t nyit; az ellenőrzések változtatása és a kihagyások átnézésre blokkolva vannak.

Ez a [harness engineering](https://balazscsorba.com/hu/blog/harness-engineering-coding-agents) a tesztelésre alkalmazva: az ágens irányítókat (seed teszt, tervek, lokátorszabályok) és érzékelőket (tesztfutás, ellenőrzéskapu) kap, az emberi átnézés pedig ott van, ahol a döntések születnek, nem minden soron.

## Források

1.  [Playwright docs: Test agents (planner, generator, healer)](https://playwright.dev/docs/test-agents)
2.  [Microsoft: Playwright MCP README (MCP vs CLI, accessibility snapshots)](https://github.com/microsoft/playwright-mcp)
3.  [Playwright docs: Best practices](https://playwright.dev/docs/best-practices)
4.  [Playwright docs: Locators](https://playwright.dev/docs/locators)
5.  [Browserbase: Stagehand README (act, extract, observe)](https://github.com/browserbase/stagehand)

## Gyakori kérdések

Kiválthatja egy AI-ágens az E2E-tesztkészletemet?

Nem abban a szerepben, ami a CI-ban fut. Egy tesztidőben az alkalmazáson végigkattintó ágens lassabb, minden futásnál tokenbe kerül, és ugyanazt az eredményt kétszer különbözőképpen ítélheti meg. Az ágensekkel írass, bővíttess és javíttass egy normál Playwright-tesztkészletet, és azt futtasd determinisztikusan.

Mik a Playwright tesztágensek?

A Playwright három ágensdefiníciót ad: egy plannert, amely bejárja az alkalmazást és Markdown tesztervet ír, egy generatort, amely a tervet Playwright-tesztfájlokká alakítja, közben élőben ellenőrizve a szelektorokat, és egy healert, amely lefuttatja a hibás teszteket és javítást javasol. Az npx playwright init-agents paranccsal adhatod hozzá őket VS Code-hoz, Claude Code-hoz, Codexhez vagy OpenCode-hoz.

Playwright MCP-t vagy Playwright CLI-t használjak?

Repóban dolgozó kódoló ágensekhez a Playwright MCP README-je a skillekkel kiegészített CLI-t ajánlja, mert nem tölt nagy eszközsémákat és akadálymentességi fákat a kontextusba. Az MCP a hosszan futó felfedező vagy önjavító ciklusokhoz illik, amelyeknek jót tesz a tartós böngészőmunkamenet.

Biztonságosak az önjavító tesztek?

Csak korlátokkal. Egy átnevezett gomb lokátorát kijavítani rendben van. Megváltoztatni, mit ellenőriz a teszt, vagy kihagyottnak jelölni, mert a funkció hibásnak tűnik, elrejthet egy valódi regressziót. A healer módosíthasson lokátorokat és várakozásokat, az ellenőrzések változtatása és a kihagyások pedig menjenek átnézésre.

Mikor érdemes futásidejű böngészőágenst használni?

Felfedező teszteléshez, gyors füstpróbákhoz olyan oldalakon, amelyeket nem te irányítasz, és olyan feladatokhoz, ahol a felület túl gyakran változik a rögzített szelektorokhoz. Az olyan eszközök, mint a Stagehand, ilyenkor természetes nyelvű műveleteket kevernek Playwright-stílusú kóddal.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Kontextusromlás hosszan futó ügynököknél: törlés, tömörítés, memória és al-ügynökök](https://balazscsorba.com/hu/blog/context-rot-compaction-long-running-agents)
-   [Az A2A protokoll: agent cardok, taskok, és a helye az MCP mellett](https://balazscsorba.com/hu/blog/a2a-protocol-agent-interoperability)
-   [Egy senior MI-ügynökökkel vagy egy csapattal: mit mondanak a bizonyítékok](https://balazscsorba.com/hu/blog/ai-assisted-development-economics)
-   [Spec-driven fejlesztés kódoló ügynököknek: a terv a kód előtt](https://balazscsorba.com/hu/blog/spec-driven-development-coding-agents)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)