Как использовать LLM для автоматизации тестирования UI-приложений

Ты тестируешь интерфейс вручную — кликаешь, проверяешь отступы, ждёшь, пока загрузится форма, потом снова кликаешь, потому что что-то сломалось после пуша. И так каждый день. Ты не один. Многие команды тратят до 40% времени на рутинные проверки UI, которые можно автоматизировать. Но обычные инструменты вроде Selenium или Cypress требуют писать костыли под каждый элемент, а когда дизайн меняется — всё ломается. LLM (языковые модели) могут помочь не просто автоматизировать, а сделать тестирование гибким, адаптивным и почти не требующим поддержки. Давай разберёмся, как это работает на практике.

Почему обычные инструменты тестирования UI не справляются

Ты знаешь, как это бывает: ты пишешь тест, который ищет кнопку по CSS-селектору .btn-primary. Через неделю дизайнер меняет стили — кнопка становится .ui-button--accent. Тест падает. Ты идёшь в код, правишь — всё хорошо. Через две недели — снова изменение. И снова. Это не редкость — это норма в быстроразвивающихся продуктах.

Проблема в том, что классические инструменты работают на уровне структурных признаков: ID, классы, XPath. Они не понимают, что кнопка — это кнопка, если она выглядит как кнопка, имеет текст «Отправить» и находится в нижней части формы. LLM умеют интерпретировать семантику — то, что человек видит и понимает.

Как LLM помогает тестировать UI — простыми словами

Представь, что ты даёшь модели скриншот экрана и текстовое описание: «Пользователь должен увидеть кнопку «Зарегистрироваться» под формой, и при нажатии — появляется уведомление «Успешно!»».

Модель не ищет CSS-селекторы. Она анализирует изображение: где текст, где кнопки, где контейнеры. Она сопоставляет это с твоим описанием и говорит: «Кнопка есть, текст есть, уведомление появилось — всё ок». Или: «Кнопка есть, но текст «Зарегистрироваться» написан как «Регистрация» — не совпадает».

Это не теория. Такие системы уже работают в продакшне у команд, которые тестируют мобильные приложения, веб-панели и даже чат-боты с интерфейсом. Их преимущество — устойчивость к визуальным изменениям. Не нужно переписывать тесты, когда меняется дизайн — достаточно обновить описание.

Как это работает на практике — пошагово

1. Ты запускаешь тест на реальном браузере (Chrome, Firefox) с помощью Playwright или Puppeteer — они делают скриншоты и собирают DOM-структуру.
2. Скриншот и текстовое описание тест-кейса (например, «Пользователь вводит email и пароль, нажимает «Войти» — попадает на главную») отправляются в LLM.
3. Модель анализирует изображение: находит элементы, определяет их назначение (кнопка, поле ввода, сообщение об ошибке), сверяет с описанием.
4. Возвращает ответ: «Пройдено» / «Ошибка: кнопка «Войти» не нажимается» / «Предупреждение: текст ошибки не соответствует ожидаемому».
5. Результат пишется в отчёт, и ты видишь, что именно пошло не так — без копания в логах.

Пример: тест проверяет, что после оплаты пользователь видит «Спасибо за покупку!» и кнопку «Вернуться в магазин». Вместо того чтобы писать XPath для каждого элемента, ты пишешь:

Ожидаемый результат: После успешной оплаты отображается текст "Спасибо за покупку!" и кнопка с надписью "Вернуться в магазин".

LLM смотрит на скриншот — и говорит, что всё верно. Даже если кнопка теперь зелёная, а не синяя, а текст сдвинут на 5 пикселей — это не важно. Главное — семантика.

Что можно тестировать с помощью LLM

Не всё. Но многое. Вот реальные сценарии, где LLM действительно выручает:

• Проверка наличия и текста кнопок, заголовков, уведомлений.
• Валидация визуального расположения элементов (например, «Форма должна быть по центру»).
• Проверка отображения изображений — «Картинка товара должна быть видна».
• Тестирование адаптивности: «На мобильном экране кнопки должны быть в столбик».
• Проверка доступности: «Кнопка должна иметь альтернативный текст» (если модель поддерживает анализ ARIA-атрибутов).
• Сравнение визуальных изменений между версиями (например, «Чем отличается новая версия от старой?»).

Но LLM не подойдут для:

• Проверки логики бэкенда (например, «После нажатия кнопки должен создаться заказ в БД»).
• Тестирования производительности (время загрузки, размеры ресурсов).
• Проверки CORS, HTTP-статусов, сетевых ошибок.

Используй LLM как «глаза» для визуальной части, а остальное оставь классическим инструментам.

Сравнение подходов: LLM vs классические инструменты

Критерий	LLM + скриншоты	Playwright / Cypress
Устойчивость к изменениям дизайна	Высокая — не зависит от классов и ID	Низкая — ломается при любом изменении селектора
Скорость написания тестов	Быстро — пишешь описания на естественном языке	Медленно — нужно писать код, выбирать селекторы
Точность распознавания	Высокая, но требует настройки	Высокая, если селекторы стабильны
Скорость выполнения	Медленнее — нужно генерировать и анализировать изображения	Быстрее — работает с DOM напрямую
Требует знаний кода	Минимальные — достаточно понимать, что тестируешь	Высокие — нужно писать на JavaScript/TypeScript
Поддержка визуальных ошибок	Отличная — видит смещения, обрезанные тексты, пропавшие картинки	Плохая — только если ты явно проверяешь стили

Если твой продукт меняет дизайн раз в неделю — LLM спасает. Если ты тестируешь стабильный корпоративный портал с жёсткой спецификацией — классические инструменты быстрее и дешевле.

Что выбрать в зависимости от ситуации

• Если у тебя: частые изменения дизайна, команда без глубоких знаний кода, много мобильных экранов — используй LLM. Это сэкономит тебе 5–10 часов в неделю на поддержку тестов.
• Если у тебя: стабильный интерфейс, строгие требования к производительности, много интеграций с API — оставь Playwright/Cypress. Добавь LLM только для проверки ключевых сценариев (например, регистрация, оплата).
• Если ты в стартапе и ресурсы ограничены — начни с LLM на 2–3 самых критичных сценариях. Это даст быстрый эффект без вложений в сложную инфраструктуру.
• Если ты в крупной компании с отделом QA — используй гибрид: LLM для визуальной валидации, классические инструменты для логики и API.

Частые ошибки — и как их избежать

1. Пишу слишком общее описание — «Кнопка должна быть видна». Модель не знает, какая кнопка. Нужно: «Кнопка с текстом «Оформить заказ» в нижнем правом углу формы».
2. Использую бесплатные модели без настройки — GPT-4o или Claude 3 могут работать, но с высокой погрешностью. Лучше использовать специализированные модели вроде GPT-4 Vision, Gemini 1.5 Pro или LLaVA, которые лучше работают с изображениями.
3. Проверяю всё подряд — LLM медленнее. Не тестируй 50 страниц. Выбери 3–5 ключевых сценариев: вход, покупка, регистрация, восстановление пароля.
4. Забываю про контекст — если тест зависит от авторизации, LLM не знает, что пользователь залогинен. Нужно передавать не только скриншот, но и состояние (например, «Пользователь уже авторизован»).
5. Думаю, что LLM заменит QA — нет. Он заменяет рутину. Человек всё равно должен проверять сложные сценарии, эмоциональные реакции, юзабилити.

Как лучше сделать — практические рекомендации

Вот что работает на практике:

• Начни с одного сценария — например, «Пользователь вводит неверный пароль — видит сообщение об ошибке».
• Используй Playwright для снятия скриншотов — он надёжный, легко интегрируется и поддерживает разные разрешения.
• Отправляй скриншоты в модель через API (например, OpenAI Vision или Anthropic Claude). Не используй локальные модели без GPU — они не справятся с качеством изображений.
• Сохраняй все скриншоты и ответы модели — это твой архив. Потом можно сравнивать версии, откатывать изменения, анализировать тренды.
• Добавь порог уверенности — если модель говорит «возможно, кнопка есть», а не «да», тест считается не пройденным. Не доверяй 80% уверенности — нужна 95%+.
• Интегрируй в CI/CD: после каждого пуша — запускается скриншот + анализ. Если тест падает — уведомление в Slack.

Пример структуры теста:

1. Открыть страницу входа
2. Ввести неверный email и пароль
3. Нажать «Войти»
4. Сделать скриншот
5. Отправить скриншот + описание в LLM
6. Получить ответ: "Ошибка: текст 'Неверный email или пароль' отсутствует"
7. Записать в отчёт: FAILED — UI-ошибка

Что делать дальше — пошаговый план

1. Выбери один критичный сценарий (например, вход в систему).
2. Запиши его на естественном языке: «Пользователь вводит email и пароль, нажимает «Войти» — попадает на главную страницу».
3. Напиши простой скрипт на Playwright, который открывает страницу, заполняет поля, нажимает кнопку и делает скриншот.
4. Зарегистрируйся в OpenAI, Anthropic или используй локальную модель (например, LLaVA).
5. Напиши запрос к API: отправь скриншот + описание, получи ответ.
6. Создай простой скрипт, который парсит ответ: если «пройдено» — всё ок, если «ошибка» — падает тест.
7. Запусти вручную — проверь, работает ли.
8. Добавь в CI/CD — пусть запускается после каждого пуша в main.
9. После месяца — оцени: сколько времени сэкономлено, сколько ошибок поймано, сколько тестов больше не ломаются.

Ты не переписываешь 500 тестов. Ты пишешь 5 описаний — и получаешь устойчивую систему. Это не магия — это просто другой способ думать о тестировании.

Итог: что делать прямо сейчас

Если ты тестируешь UI вручную и устаёшь от того, что каждый пуш ломает тесты — начни с одного сценария. Не пытайся автоматизировать всё. Выбери самую болезненную часть: то, что ломается чаще всего, требует больше всего времени на исправление. Напиши простое описание. Сделай скриншот. Отправь в модель. Увидишь результат за час.

LLM не заменяет тестировщика. Он заменяет рутину. Он даёт тебе время думать о том, что действительно важно: как пользователь чувствует интерфейс, где он теряется, что вызывает фрустрацию. А не искать, почему кнопка с классом .btn-primary теперь называется .btn--primary-v2.

Начни с одного теста. Увидишь — и поймёшь, почему это работает. Не жди идеальной системы. Сделай минимально жизнеспособную. Потом — улучшай. Это не про технологии. Это про то, чтобы не тратить жизнь на повторяющиеся действия, которые можно автоматизировать — и сделать это без страха, что всё сломается завтра.

Информация в статье носит ознакомительный характер. Выбор инструментов, архитектуры и подходов к тестированию должен учитывать специфику продукта, команды и бизнес-целей. Перед внедрением в продакшн проконсультируйтесь с опытным инженером по качеству или DevOps-специалистом.