Automatyzacja testowania interfejsu za pomocą interfejsu wiersza poleceń Gemini, BrowserMCP i Playwright

1. Wprowadzenie

Testowanie aplikacji internetowych może być uciążliwe. Tradycyjne testowanie interfejsu często przypomina nieustanną walkę z niestabilnością. Piszesz złożone skrypty, zarządzasz niestabilnymi selektorami CSS i XPath oraz wykonujesz skomplikowane czynności, aby zweryfikować prosty przepływ użytkownika.

A gdyby tak po prostu powiedzieć agentowi, co ma przetestować, w języku naturalnym, a on by to zrobił?

W tym ćwiczeniu dowiesz się, jak korzystać z interfejsu wiersza poleceń Gemini i narzędzi multimodalnych, takich jak BrowserMCP. Dowiesz się, jak tworzyć i uruchamiać zautomatyzowane testy interfejsu przy użyciu języka naturalnego. Ten Codelabs nie wymaga wcześniejszej wiedzy na temat platform i narzędzi do testowania interfejsu.

Czego się nauczysz

Czym jest protokół Model Context Protocol (MCP) i dlaczego jest to przełomowa technologia.
Jak BrowserMCP umożliwia agentom AI sterowanie przeglądarkami.
Jak uruchamiać automatyczne testy interfejsu z interfejsu wiersza poleceń Gemini.
Informacje o umiejętnościach agenta i ich zaletach
Uczenie agenta korzystania z Playwright za pomocą umiejętności.
Krótki opis podagenta przeglądarki Antigravity.
Inne przypadki użycia sterowania przeglądarką.

Co zrobisz

Skonfiguruj środowisko programistyczne.
Zapoznaj się z aplikacją demonstracyjną, która wymaga testowania.
Użyj interfejsu wiersza poleceń Gemini, aby korzystać z aplikacji za pomocą BrowserMCP.
Naucz agenta, jak korzystać z Playwright, za pomocą umiejętności agenta.

2. Wymagania wstępne

Zanim przejdziemy do ciekawych rzeczy, upewnijmy się, że masz wszystko, czego potrzebujesz.

W tym ćwiczeniu w Codelabs wykorzystujemy interfejs wiersza poleceń Gemini, narzędzia MCP, umiejętności agenta i aplikację demonstracyjną React.

Narzędzia

W tym module zakładamy, że masz już:

Przeglądarka Chrome
interfejs wiersza poleceń Gemini (który zależy od nodejs);
Git

Instrukcje zakładają, że pracujesz w środowisku Linux (lub WSL) albo macOS. Jeśli korzystasz z systemu Windows (tak jak ja), możesz użyć WSL.

(Pamiętaj, że

BrowserMCP nie będzie działać w Google Cloud Shell

, ponieważ połączy się tylko z lokalną przeglądarką działającą na tym samym komputerze).

Tworzenie projektu Google Cloud

Jeśli masz już klucz interfejsu Gemini API, możesz go użyć i pominąć ten krok.

W przeciwnym razie musisz mieć projekt w Google Cloud, aby móc wykonać zadania z tego samouczka. Nie będziemy wdrażać żadnych usług Google Cloud, ale projekt jest potrzebny do powiązania klucza interfejsu Gemini API. (Klucz jest potrzebny do korzystania z Gemini).

Jeśli znasz Google Cloud, możesz utworzyć nowy projekt tutaj. Możesz też utworzyć projekt w chmurze Google Cloud bezpośrednio w Google AI Studio.

Utwórz bezpłatny klucz interfejsu Gemini API

Teraz utworzysz klucz interfejsu Gemini API w Google AI Studio. Kliknij „Get API Key” (Pobierz klucz interfejsu API).

Zobaczysz menu podobne do tego:

Jeśli masz już jakieś klucze, pojawią się one na tej liście. Aby utworzyć nowy klucz, kliknij „Utwórz klucz interfejsu API”.

Możesz tu wybrać istniejący projekt Google Cloud lub utworzyć nowy. Utworzono nowy projekt o nazwie agentic-ui-demo:

W tym momencie mamy projekt i powiązany z nim klucz interfejsu Gemini API. Nie mamy włączonych płatności, więc obowiązuje nas duży bezpłatny limit. Jeśli jednak potrzebujesz większego limitu, możesz włączyć płatności, klikając „Skonfiguruj płatności”.

Konfigurowanie środowiska programistycznego

Mam utworzone repozytorium demonstracyjne w GitHubie. Zawiera przykładową aplikację, której możemy użyć do testowania interfejsu. Sklonuj go, uruchamiając to polecenie w terminalu lokalnym:

git clone https://github.com/derailed-dash/agentic-ui-testing
cd agentic-ui-testing

Następnie utwórz kopię przykładowego pliku .env.template o nazwie .env. Możesz to zrobić w edytorze lub po prostu uruchomić to polecenie:

cp .env.template .env

Zaktualizuj ten plik .env, podając własny klucz interfejsu API. (Pamiętaj: nigdy nie przesyłaj pliku .env z informacjami takimi jak klucz interfejsu API). Najłatwiej to zrobić, otwierając go w edytorze.

Teraz wczytajmy zmienną środowiskową:

source .env

Utworzyłem plik Makefile, aby ułatwić Ci skonfigurowanie środowiska do uruchomienia aplikacji w wersji demonstracyjnej. Uruchommy go, aby zainicjować nasze środowisko:

make install

3. Nasza aplikacja demonstracyjna

Testowana dziś aplikacja to The Dazbo Omni-Dash – futurystyczny panel w ciemnej kolorystyce do zarządzania danymi telemetrycznymi dotyczącymi bezpieczeństwa. (Tak, został zakodowany za pomocą vibe coding).

Dlaczego ta aplikacja?

Został on stworzony, aby zapewnić realistyczną powierzchnię testową dzięki:

Uwierzytelnianie próbne: proces logowania wymagający określonych danych logowania.
Treści dynamiczne: karty telemetryczne i dzienniki zabezpieczeń, które symulują dane w czasie rzeczywistym.
Stany interaktywne: menu nawigacyjne i pola formularza, które zmieniają się w zależności od działania użytkownika.
Nowoczesna technologia: aplikacja została stworzona w technologii React i Vite, co zapewnia szybkie działanie i krótki czas reakcji.

Uruchamianie aplikacji

Aby uruchomić aplikację, wpisz:

make dev

Serwer deweloperski powinien uruchomić się bardzo szybko, a aplikacja będzie dostępna pod adresem http://localhost:5173.

Wystarczy kliknąć link, aby otworzyć aplikację w przeglądarce. Po prostu pozostaw ten proces uruchomiony w terminalu. Kolejne polecenia terminala wykonamy w osobnej sesji terminala.

4. Wyzwania związane z testowaniem interfejsu

Tradycyjne testowanie interfejsu użytkownika jest bardzo trudne do przeprowadzenia i utrzymania. Typowe problemy to:

Test „niestabilności”: testy, które w jednej minucie kończą się sukcesem, a w następnej niepowodzeniem z powodu problemów z czasem, warunków wyścigu lub wolno wczytujących się komponentów.
Kruche selektory: poleganie na konkretnych strukturach DOM (np. div > div > button), które ulegają uszkodzeniu przy najmniejszej zmianie interfejsu, co prowadzi do ciągłej konserwacji skryptu.
Wysoka krzywa uczenia się: wymaga od deweloperów opanowania złożonych języków specyficznych dla domeny i osobliwości platformy (Cypress, Selenium, Playwright) tylko po to, aby zautomatyzować podstawowe kliknięcie.
Spójność środowiska: zmaganie się z trudnymi do odtworzenia stanami aplikacji i kosztami oczyszczania danych testowych.

Potrzebujemy sposobu testowania, który skupia się na intencjach, a nie na implementacji.

5. MCP na ratunek

Model Context Protocol (MCP) to otwarty standard, który umożliwia modelom i agentom AI interakcję z zewnętrznymi narzędziami, interfejsami API i danymi. Można go porównać do uniwersalnego adaptera, który umożliwia modelom i agentom znajdowanie i wykonywanie narzędzi, do których mają dostęp.

Tradycyjnie integracja dużych modeli językowych (LLM) z zewnętrznymi danymi i narzędziami wymagała od deweloperów pisania niestandardowych, zakodowanych na stałe połączeń API dla każdego nowego źródła danych, co powodowało problem integracji „M x N”, w którym każdy nowy model i narzędzie zwiększały obciążenie związane z konserwacją. Protokół kontekstu modelu (MCP) rozwiązuje ten problem, eliminując konieczność pisania specjalnego kodu do koordynowania tych funkcji. Zamiast jawnie kodować złożone przepływy pracy, deweloperzy mogą polegać na LLM, który interpretuje żądania użytkownika w języku naturalnym i dynamicznie określa, których narzędzi użyć.

Gdy użytkownik wyda polecenie w języku naturalnym (np. „Przejdź do localhost:5173, zaloguj się jako „admin” i kliknij przycisk Prześlij”), LLM wykryje dostępne funkcje i wygeneruje uporządkowane żądanie wywołania konkretnego narzędzia. Klient MCP działa jako tłumacz, przekazując to żądanie do wyznaczonego serwera MCP, który wykonuje działanie lub pobiera dane i zwraca kontekst do modelu. Dzięki temu AI może działać autonomicznie bez konieczności zakodowania przez programistę konkretnej ścieżki wykonania.

MCP tworzy uniwersalny standard, często opisywany jako „USB-C dla aplikacji AI”, co zapewnia ogromną gotową do użycia funkcjonalność. Programiści mogą zbudować serwer MCP tylko raz, a każdy prezenter AI zgodny z MCP może się z nim natychmiast połączyć, eliminując problem integracji M x N. Nie musisz już tworzyć niestandardowych pomostów API dla każdej platformy. Zamiast tego możesz korzystać z ekosystemu gotowych serwerów MCP typu open source dla popularnych usług, takich jak GitHub, Slack czy bazy danych, i podłączać je bezpośrednio do przepływów pracy opartych na agentach. Ta modułowa architektura typu plug-and-play sprawia, że jeśli później zmienisz dostawcę LLM lub uaktualnisz narzędzia, podstawowa infrastruktura integracji pozostanie całkowicie niezmieniona.

6. Automatyzacja za pomocą BrowserMCP

Co to jest BrowserMCP?

To pierwsze narzędzie, z którego dziś skorzystamy. BrowserMCP to serwer MCP, który zapewnia agentom AI „oczy” i „ręce” potrzebne do interakcji z przeglądarką. W skrócie: naśladuje interakcję człowieka z przeglądarką. Jest to projekt open source, a repozytorium GitHub znajdziesz tutaj. Główną dokumentację BrowserMCP znajdziesz tutaj.

Oto niektóre z jej możliwości:

Może otwierać adresy URL.
Może sprawdzać DOM.
Może klikać przyciski i wpisywać tekst w formularzach.
Możesz przeciągać i upuścić.
Może odczytywać logi konsoli przeglądarki.
Jest szybka: automatyzacja odbywa się lokalnie na Twoim komputerze.

Instalowanie Browser MCP

Aby korzystać z BrowserMCP, musisz wykonać 2 czynności:

Zainstaluj rozszerzenie BrowserMCP w Chrome (lub w dowolnej przeglądarce opartej na Chromium).
Skonfiguruj serwer MCP dla agenta.

Aby zainstalować rozszerzenie, postępuj zgodnie z instrukcjami podanymi tutaj. Zajmie to tylko kilka sekund. Po zainstalowaniu kliknij „Połącz” w rozszerzeniu, aby zezwolić agentowi na sterowanie bieżącą kartą. (Oczywiście chcesz, aby bieżąca karta była tą, na której działa aplikacja demonstracyjna).

Następnie musimy dodać konfigurację MCP do naszego klienta:

 "mcpServers": {
    "browsermcp": {
      "command": "npx",
      "args": ["@browsermcp/mcp@latest"]
    }
  }

Gdzie można to skonfigurować? To zależy od agenta. Na przykład w interfejsie wiersza poleceń Gemini: ~/.gemini/settings.json. Będzie to wyglądać mniej więcej tak:

Testowanie za pomocą BrowserMCP

A teraz magia. Najpierw uruchom interfejs wiersza poleceń Gemini (uruchamiając gemini) w nowej sesji terminala. (Pamiętaj, że aplikacja demonstracyjna jest uruchomiona w naszej początkowej sesji terminala). W interfejsie wiersza poleceń Gemini uruchom polecenie /mcp, aby sprawdzić, czy został on prawidłowo zainstalowany. Powinna się wyświetlić lista narzędzi, np. taka:

Jeśli nie została jeszcze uruchomiona, uruchom teraz aplikację demonstracyjną:

make dev

Musimy otworzyć aplikację w przeglądarce Chrome i połączyć rozszerzenie BrowserMCP na tej karcie. Kliknij link z polecenia run. Następnie kliknij ikonę rozszerzenia BrowserMCP i wybierz „Połącz”.

Teraz możemy użyć interfejsu wiersza poleceń Gemini, aby uruchomić test. Skopiuj ten prompt i wklej go w interfejsie wiersza poleceń Gemini:

Using BrowserMCP, connect to the application at http://localhost:5173. If the application is not showing a login screen, first logout. Then login as 'admin' with password 'password', and verify that the dashboard title says 'System Overview'. In the main dashboard, read the telemetry values shown, and present them back to me in a markdown table.

Interfejs wiersza poleceń Gemini może najpierw sprawdzić, czy aplikacja demonstracyjna działa na określonym porcie. Następnie poprosi Cię o potwierdzenie działań, które planuje wykonać:

Zezwól interfejsowi wiersza poleceń Gemini na uruchamianie wszystkich narzędzi BrowserMCP w tej sesji. Następnie wróć do przeglądarki i obserwuj automatyczne interakcje.

Kilka uwag na temat powyższego prompta:

Najpierw informujemy agenta, aby się wylogował, jeśli aplikacja jest już zalogowana. Pamiętaj, że nie musimy mówić agentowi, aby kliknął konkretny tekst, np. „Wyjdź z bramy”. Jest na tyle inteligentny, że wie, co kliknąć.
Po zalogowaniu się i wyrenderowaniu strony głównej agent rejestruje informacje telemetryczne. Ponownie nie musimy mówić agentowi, aby szukał w określonych kafelkach lub dopasowywał konkretne słowa. Jeśli później rozszerzymy lub zmienimy informacje wyświetlane na tej stronie, ten prompt nadal będzie działać, a wynik będzie nadal rejestrowany w naszej tabeli Markdown.

Fajnie, prawda?

Na razie kończymy pracę z BrowserMCP, więc odłącz go w przeglądarce.

7. Automatyzacja za pomocą umiejętności i narzędzia Playwright

Ograniczenia BrowserMCP

BrowserMCP to świetne rozwiązanie, ale ma kilka ograniczeń. Na przykład:

Wymaga to istniejącej sesji przeglądarki z połączonym rozszerzeniem BrowserMCP. (Nie powoduje to rozpoczęcia nowych sesji).
Nie obsługuje przeglądarek innych niż Chromium.
Wymaga uruchomienia osobnego procesu przeglądarki na tym samym komputerze, na którym działa serwer MCP.
Nie może on współpracować z lokalnym systemem plików. Nie może na przykład tworzyć lokalnych plików z zrzutami ekranu ani pobierać i przechowywać plików z aplikacji internetowej, takich jak pliki PDF do pobrania.
Nie jest deterministyczna. Będzie próbować wykonywać działania, o które je poprosisz, ale stan lokalny, np. nieoczekiwane wyskakujące okienko, może przerwać interakcję.
Nie obsługuje działania „headless”, co oznacza, że nie może działać w potoku CI/CD bez prawdziwego okna przeglądarki.

Playwright

Playwright to znacznie bardziej zaawansowane narzędzie. Jest to sprawdzona platforma open source do automatyzacji przeglądarek i testowania. Może robić wiele rzeczy, których nie potrafi BrowserMCP, w tym wszystkie wymienione powyżej.

Znacznie lepiej nadaje się do przeprowadzania złożonych, wiarygodnych i powtarzalnych scenariuszy testowych. Szczególnie dobrze sprawdza się w przypadku długotrwałych sesji lub równoległego prowadzenia wielu niezależnych sesji.

Jednak ta dodatkowa funkcja wiąże się ze znacznie bardziej stromą krzywą uczenia się.

Umiejętności

Na szczęście nie musimy uczyć się bezpośrednio korzystania z Playwright. Zamiast tego możemy użyć umiejętności agenta.

Czym dokładnie jest umiejętność agenta? Możesz to sobie wyobrazić jako ściśle powiązany pakiet wiedzy specjalistycznej, który możesz przekazać agentowi AI, gdy musi on wykonać określone zadanie. Zawiera instrukcje, sprawdzone metody, a czasami nawet skrypty pomocnicze dostosowane do konkretnego zadania.

Najciekawsza jest jednak funkcja stopniowego ujawniania informacji. Zamiast umieszczać w początkowym promcie systemowym LLM wszystkie możliwe dokumenty API i reguły platformy testowej, co zużywa okno kontekstowe i tokeny w zawrotnym tempie, agent odczytuje umiejętność tylko wtedy, gdy jest mu potrzebna. Utrzymuje podstawowy kontekst w prostej i zwięzłej formie, pobierając szczegółowe instrukcje w odpowiednim momencie. Tak, umiejętność może zawierać instrukcje, jak wykorzystać konkretne serwery MCP do wykonania zadania.

Wyobraź sobie scenę z filmu „Matrix”: agent patrzy na problem, zdaje sobie sprawę, że musi znać Playwright, pobiera umiejętność i nagle mówi: „Znam kung-fu”. Na wysięgniku Błyskawicznie zdobywaj wiedzę.

Jeśli chcesz dowiedzieć się więcej o umiejętnościach, zapoznaj się z tymi materiałami:

Dlaczego umiejętności są idealne dla Playwright

Użycie umiejętności w tym miejscu to świetny wybór. Playwright jest niezwykle potężny, ale jego składnia może być trudna. Dzięki temu, że agent ma umiejętność Playwright, nie musimy się martwić, że LLM będzie halucynować przestarzałą składnię lub pisać niestabilne selektory. Dostarczamy mu wyselekcjonowany, wiarygodny przewodnik po tym, jak prawidłowo korzystać z Playwright.

Będę korzystać z interfejsu wiersza poleceń Playwright i powiązanych z nim umiejętności.

W tym podejściu instalujemy interfejs wiersza poleceń Playwright lokalnie, a następnie przekazujemy agentowi wiedzę potrzebną do jego używania. Aby uniknąć nieporozumień: nie instaluję żadnego serwera MCP Playwright.

Instalowanie

Najpierw zainstalujmy interfejs wiersza poleceń Microsoft Playwright o otwartym kodzie źródłowym. Jeśli nie zostało to jeszcze zrobione, zamknij interfejs wiersza poleceń Gemini, wpisując /quit``. Następnie w terminalu:

# Pre-req: nodejs installed
npm install -g @playwright/cli@latest # Install Playwright CLI globally
npm install @playwright/test # Install Playwright test framework

npx playwright install-deps # Install dependencies
npx playwright install chromium chrome # Install browser binaries in Linux / WSL

Teraz dodajmy umiejętność. To polecenie pobierze podfolder umiejętności bezpośrednio z GitHuba do folderu umiejętności Gemini:

mkdir -p ~/.gemini/skills
npx degit microsoft/playwright-cli/skills/playwright-cli ~/.gemini/skills/playwright-cli

Teraz możemy go przetestować.

# Launch Playwright CLI with visible browser
playwright-cli open https://playwright.dev --headed

Powinno to spowodować uruchomienie sesji przeglądarki otwartej pod określonym adresem URL.

Chcę też, aby Gemini mógł używać Playwright w trybie „z interfejsem”, czyli z widocznym interfejsem. Ale ta umiejętność nie mówi Gemini, jak to zrobić. W sekcji Core dodałem te wiersze do pliku ~/.gemini/skills/playwright-cli/SKILL.md:

# Add the following under the "playwright-cli open" command

# Run in headed mode so we can see the browser
playwright-cli open https://playwright.dev --headed

Testowanie za pomocą Playwright

Jak poprzednio, musimy uruchomić aplikację (jeśli nie jest jeszcze uruchomiona). W początkowej sesji terminala wykonaj te czynności:

make dev

Następnie w drugiej sesji terminala tymczasowo wyłączmy BrowserMCP, aby agent nie miał problemu z wyborem narzędzi. Uruchom ponownie interfejs wiersza poleceń Gemini, a następnie uruchom to polecenie:

/mcp disable browsermcp

Teraz poprosimy Gemini o przejście do naszej aplikacji za pomocą Playwright. W przeciwieństwie do BrowserMCP nie musimy jednak najpierw uruchamiać przeglądarki. Playwright zrobi to za nas w ramach lokalnego procesu.

Wpisz ten prompt w interfejsie wiersza poleceń Gemini:

Using Playwright, connect to the application at http://localhost:5173. Then login as 'admin' with password 'password', and verify that the dashboard title says 'System Overview'. Take a screenshot of the dashboard and save it to output/dashboard.png. In the main dashboard, read the telemetry values shown, and present them back to me in a markdown table.

(Jak zawsze, interfejs wiersza poleceń Gemini poprosi o zezwolenie przed uruchomieniem narzędzi).

Co się zmieniło?

Nie musieliśmy najpierw uruchamiać przeglądarki.
Nie musieliśmy uruchamiać rozszerzenia przeglądarki ani się z nim łączyć.
Nie musimy najpierw prosić agenta o wylogowanie się. Test jest przeprowadzany w ramach „czystej” sesji.
Możemy robić zrzuty ekranu i zapisywać je jako pliki lokalne.

Wkrótce w folderze output powinien pojawić się plik dashboard.png.

Pamiętaj, że wywołania narzędzi będą wykonywane w interfejsie wiersza poleceń Gemini, ale nie zobaczysz interfejsu przeglądarki. Dzieje się tak, ponieważ Playwright domyślnie działa w „trybie bez interfejsu graficznego”.

Jeśli jednak ponownie uruchomisz go z tym zmienionym promptem, zobaczysz też interfejs:

Using Playwright, connect to the application at http://localhost:5173 in **headed** mode, and keep the browser open when you're done. Login as 'admin' with password 'password', and verify that the dashboard title says 'System Overview'. Take a screenshot of the dashboard and save it to output/dashboard.png. In the main dashboard, read the telemetry values shown, and present them back to me in a markdown table.

Dane wyjściowe interfejsu wiersza poleceń Gemini powinny wyglądać mniej więcej tak:

Jakie to było niesamowite?

8. You Can Do This in Antigravity Out of the Box!

Google Antigravity zawiera Browser Subagent, który zapewnia funkcje podobne do interfejsu wiersza poleceń Playwright. Gdy poprosisz Gemini w Antigravity o interaktywne uruchomienie adresu URL, automatycznie uruchomi on tego subagenta.

Ten podagent przyjmuje Twój ogólny cel (np. „Sprawdź, czy formularz logowania działa”), wizualnie analizuje układ strony za pomocą zrzutów ekranu i DOM oraz samodzielnie określa kliknięcia i naciśnięcia klawiszy. To w zasadzie wizualna, multimodalna AI, która porusza się po internecie tak jak człowiek. A co najlepsze, Automatycznie nagrywa filmy i robi zrzuty ekranu wszystkiego, co robi, zapisując je bezpośrednio w lokalnym obszarze roboczym jako wizualne potwierdzenie wykonanych czynności. Antigravity nazywa te dowody wizualne artefaktami.

Uwaga dla użytkowników WSL: uruchomienie agenta przeglądarki w Antigravity jest nieco kłopotliwe. Udało mi się go uruchomić, ale w tym środowisku podagent jest niespójny i niezbyt niezawodny. To jeden z powodów, dla których uwielbiam interfejs wiersza poleceń Playwright.

9. Inne przypadki użycia automatyzacji przeglądarki

Automatyzacja przeglądarki nie polega tylko na sprawdzaniu, czy przycisk logowania działa przed wdrożeniem w piątkowe popołudnie. Gdy zdasz sobie sprawę, że możesz połączyć LLM bezpośrednio z przeglądarką, otworzy się przed Tobą zupełnie nowy świat projektów opartych na agentach.

Jeśli tworzysz własnych agentów AI, oto kilka sposobów, w jakie możesz wykorzystać narzędzia takie jak BrowserMCP czy Playwright CLI, aby wykonać za Ciebie najtrudniejsze zadania:

Osobisty asystent badawczy: wyobraź sobie, że wskazujesz agentowi konkretny adres URL i prosisz go o zbadanie tematu, ale witryna wymaga zalogowania się i przejścia przez złożone menu. Zamiast pisać niestandardowy skrypt do pobierania danych z internetu, który w przyszłym tygodniu może przestać działać, możesz po prostu poprosić agenta o zalogowanie się, przejście do danych i ich podsumowanie.
Integrator „Swivel-Chair”: wszyscy mamy starsze systemy intranetowe, które nie mają interfejsów API. Chodzi o sytuacje, w których musisz ręcznie skopiować dane z systemu A i wkleić je do formularza w systemie B. Agent z automatyzacją przeglądarki może działać jako uniwersalny łącznik, odczytując ekran starszego systemu i wypełniając formularz w nowym.
Automatyczne triage i usuwanie problemów: czy o 3 w nocy system monitorowania wysłał Ci alert P1? Agent może automatycznie otwierać adres URL konkretnego panelu, odczytywać wykresy lub dzienniki (korzystając z funkcji widzenia multimodalnego) i publikować podsumowanie bezpośrednio na kanale Slack, co pozwala zaoszczędzić cenny czas podczas incydentu.

Zaletą tego podejścia jest to, że nie musisz już ograniczać się do dostępnych interfejsów API. Jeśli człowiek może to zrobić w przeglądarce, Twój agent też może.

10. Podsumowanie

Gratulacje! Właśnie udało Ci się utworzyć i przeprowadzić automatyczne, niezawodne testy interfejsu, po prostu mówiąc agentowi AI, co ma zrobić, w zwykłym języku. Bez niestabilnych selektorów CSS i złożonych skryptów konfiguracji.

Wiesz już:

Testowanie interfejsu nie musi być trudne: skupiając się na celu testu, a nie na niestabilnej implementacji DOM, możemy znacznie zmniejszyć nakłady na utrzymanie.
Protokół kontekstu modelu (MCP) zapewnia agentom uniwersalny dostęp do narzędzi, danych i środowisk.
BrowserMCP to niesamowite narzędzie, które umożliwia korzystanie z funkcji agenta w lokalnych, istniejących sesjach Chrome.
Umiejętności i interfejs wiersza poleceń Playwright zapewniają nowy poziom powtarzalnych i deterministycznych testów automatyzacji – wszystko to dzięki progresywnemu ujawnianiu informacji.
Subagent przeglądarki Antigravity idzie o krok dalej, wprowadzając autonomiczne, multimodalne nawigowanie i nagrywanie artefaktów od razu po wyjęciu z pudełka.

A teraz idź i zautomatyzuj nudne czynności!

Useful Links

Jeśli chcesz dowiedzieć się więcej o narzędziach i koncepcjach, które omówiliśmy dzisiaj, zapoznaj się z tymi materiałami:

Kod repozytorium

Repozytorium GitHub agentic-ui-testing

Podstawowe narzędzia i metodologie

Koncepcje i umiejętności agentowe

Inne

Praca z Google Antigravity w WSL