Modern QA2026Записи архитектурных решений для ИИ-фреймворка автоматизации тестирования
Join

Course › 01 Agent Skills for Browser Automation

Cutting-edge · Chapter 01

Записи архитектурных решений для ИИ-фреймворка автоматизации тестирования

Updated Jul 2026

ADR-001: Агентно-управляемое vs традиционное выполнение тестов

Контекст

Традиционные тестовые фреймворки (Selenium, Playwright, Cypress) выполняют тесты как детерминированные скрипты. ИИ-агенты вносят недетерминированные рассуждения в цикл выполнения тестов.

Решение

Использовать модель агент-как-оркестратор: ИИ-агент читает определения тестов (на естественном языке или структурированные), решает, как взаимодействовать с приложением, и сообщает результаты. Фреймворк предоставляет инструменты (vibe-check CLI), но агент определяет стратегию выполнения.

Последствия

  • (+) Тесты более устойчивы — агент может рассуждать о неожиданных состояниях
  • (+) Определения тестов могут быть более высокоуровневыми («проверить, что логин работает») вместо пошаговых
  • (+) Самовосстановление: когда селекторы ломаются, агент может найти альтернативы
  • (-) Недетерминированность — один и тот же тест может выполняться по-разному каждый раз
  • (-) Сложнее отлаживать — рассуждения агента непрозрачны по сравнению с построчными скриптами
  • (-) Медленнее на тест, чем детерминированное выполнение

Смягчение

  • Логировать каждую команду агента (для воспроизводимости)
  • Скриншот при каждом изменении состояния (для отладки)
  • Устанавливать детерминированные тайм-ауты (предотвращать бесконечные циклы)
  • Резервное переключение на детерминированные скрипты для критических путей

ADR-002: CLI-навык как основной интерфейс к браузеру

Контекст

Мы оценили три подхода:

  1. MCP-сервер Playwright (структурированные инструменты, деревья доступности)
  2. Навык vibe-check от Vibium (CLI-команды через Bash)
  3. Прямая клиентская библиотека Playwright/Vibium

Решение

Использовать CLI-навык vibe-check как основной интерфейс, с Playwright MCP доступным как резерв для обнаружения страницы.

Обоснование

Критерий MCP Skill Библиотека
Стоимость токенов за шаг ~5 000 ~130 Н/Д (не используется агентом)
Интеграция с агентом Нативная Через инструмент Bash Требует генерации кода
Сложность настройки Средняя Низкая Высокая
Понимание страницы Богатое Только текст Программное
Совместимость с CI Да Да Да

Подход через навык оставляет 98% контекста для рассуждений, обеспечивая при этом все необходимые браузерные взаимодействия.

Последствия

  • (+) В 29 раз ниже стоимость токенов, чем MCP
  • (+) Простая настройка (одна команда npx skills add)
  • (+) Компонуемость с другими CLI-инструментами
  • (-) Нет структурированного понимания страницы (только текст/скриншоты)
  • (-) Требует знания CSS-селекторов
  • (-) Менее богатый контекст ошибок, чем MCP

ADR-003: Формат определения тестов

Контекст

Тесты должны быть определены в формате, который агент может прочитать и выполнить. Варианты:

  1. Описания на естественном языке
  2. Gherkin (Given/When/Then)
  3. Структурированный YAML/JSON
  4. Гибрид (структурированный с шагами на естественном языке)

Решение

Использовать структурированный YAML с шагами на естественном языке:

test: Login with valid credentials
preconditions:
  - User "test@example.com" exists with password "secret123"
steps:
  - Navigate to the login page
  - Enter email "test@example.com"
  - Enter password "secret123"
  - Click the login button
  - Verify the dashboard loads with welcome message
expected:
  - Dashboard page is displayed
  - Welcome message contains "test@example.com"
selectors:  # Необязательные подсказки для агента
  login_page: https://app.example.com/login
  email_input: "input[name=email]"
  password_input: "input[name=password]"
  submit_button: "button[type=submit]"
  welcome_message: ".welcome-msg"

Обоснование

  • Шаги на естественном языке дают агенту свободу адаптации
  • Структурированный формат позволяет программное управление тестами
  • Необязательные подсказки по селекторам ускоряют выполнение, когда доступны
  • Агент может игнорировать подсказки и обнаруживать селекторы самостоятельно, если они устарели

ADR-004: Режим Daemon для разработки, Oneshot для CI

Контекст

Vibium поддерживает режим daemon (постоянный браузер) и режим oneshot (новый браузер для каждой команды).

Решение

  • Разработка/локально: Режим daemon для скорости (~100 мс на команду vs ~2 с)
  • CI/CD: Режим oneshot с --headless для изоляции

Конфигурация

# Разработка
export VIBIUM_MODE=daemon

# CI
export VIBIUM_ONESHOT=1
export VIBIUM_HEADLESS=1

Последствия

  • (+) Быстрая обратная связь во время разработки
  • (+) Чистая изоляция в CI
  • (-) Возможна утечка состояния в режиме daemon (смягчается явной очисткой между тестами)

ADR-005: Отладка через скриншоты

Контекст

Когда тест не проходит, агенту нужно понять, что пошло не так. Варианты:

  1. HTML-дамп страницы
  2. Скриншот
  3. Снимок дерева доступности
  4. Всё вышеперечисленное

Решение

Сохранять скриншот + текст страницы при каждом сбое. HTML-дамп — по запросу.

# При сбое агент выполняет:
vibe-check screenshot -o "failures/${TEST_NAME}_$(date +%s).png"
vibe-check text > "failures/${TEST_NAME}_$(date +%s).txt"
vibe-check url >> "failures/${TEST_NAME}_$(date +%s).txt"

Обоснование

  • Скриншоты предоставляют визуальный контекст для людей, проверяющих сбои
  • Текст страницы предоставляет семантический контекст для рассуждений агента
  • HTML-дампы редко нужны, но доступны через vibe-check html
  • Все три варианта дёшевы (без накладных расходов MCP)

ADR-006: Стратегия восстановления после ошибок

Контекст

Когда команда не срабатывает (селектор не найден, тайм-аут и т.д.), агенту нужна стратегия.

Решение

Трёхуровневое восстановление:

Уровень 1: Интеллектуальный повтор (рассуждения агента)

Агент: vibe-check click ".btn-submit" → TIMEOUT
Агент: "Кнопка отправки не найдена. Давайте исследуем."
Агент: vibe-check find-all "button" → список всех кнопок
Агент: vibe-check text "button" → читает текст кнопок
Агент: "Нашёл кнопку с текстом 'Submit'. Пробую другой селектор."
Агент: vibe-check click "button:has-text('Submit')" → УСПЕХ

Уровень 2: Анализ скриншотов

Агент: vibe-check screenshot -o debug.png
Агент: *анализирует скриншот*
Агент: "Вижу спиннер загрузки. Страница ещё не загрузилась."
Агент: vibe-check wait ".spinner" --state hidden --timeout 60000
Агент: vibe-check click ".btn-submit" → УСПЕХ

Уровень 3: Резерв MCP (если доступен)

Агент: "CLI-подход не сработал. Переключаюсь на MCP для глубокого анализа страницы."
Агент: browser_snapshot() → дерево доступности
Агент: *находит элемент через семантический анализ*
Агент: "Нашёл элемент. Он скрыт за модальным окном. Нужно сначала закрыть модальное окно."

Последствия

  • (+) Большинство сбоев разрешается на уровне 1 (дёшево)
  • (+) Уровень 2 обеспечивает визуальную отладку даже для автоматических запусков
  • (+) Уровень 3 даёт страховку для сложных сценариев
  • (-) Многоуровневое восстановление добавляет задержку при сбоях

ADR-007: Отчётность о результатах тестов

Контекст

Результаты тестов должны быть понятны:

  1. ИИ-агенту (для рассуждений о прошёл/не прошёл)
  2. Разработчикам (для отладки)
  3. CI-системам (для ворот прошёл/не прошёл)

Решение

Три формата вывода:

Консольный вывод (для CI):

PASS  login_valid_credentials      (2.3s)
PASS  login_invalid_password       (1.8s)
FAIL  login_expired_account        (5.1s) — Expected "Account expired", got "Welcome"
PASS  signup_new_user              (3.2s)

4 tests: 3 passed, 1 failed

JSON-отчёт (для программной обработки):

{
  "suite": "authentication",
  "tests": [
    {
      "name": "login_valid_credentials",
      "status": "pass",
      "duration_ms": 2300,
      "commands": ["navigate", "type", "type", "click", "wait", "text"],
      "screenshots": ["login_step1.png", "login_result.png"]
    }
  ]
}

Артефакты сбоев (для отладки):

failures/
├── login_expired_account/
│   ├── screenshot.png
│   ├── page_text.txt
│   ├── page_url.txt
│   └── agent_reasoning.md

ADR-008: Параллельное выполнение тестов

Контекст

Последовательный запуск тестов медленный. Но браузерные тесты имеют проблемы общего состояния.

Решение

  • Последовательно по умолчанию (режим daemon, общий браузер)
  • Параллельно через oneshot (каждый тест получает свой экземпляр браузера)
  • Лимит параллельности: Соответствовать доступным ядрам CPU (каждый экземпляр Chrome использует ~200 МБ RAM + 1 ядро)
# Параллельное выполнение (4 рабочих)
cat test_list.txt | xargs -P4 -I{} bash -c '
  VIBIUM_ONESHOT=1 run_test "{}"
'

Ограничения

  • Каждый параллельный рабочий нуждается в собственном экземпляре Chrome (~200 МБ RAM)
  • 8-ядерная CI-машина: максимум ~6 параллельных рабочих (оставить 2 ядра для ОС + агента)
  • Тесты, ограниченные сетью, могут не выиграть от параллелизма