В 2024 году каждый SaaS добавляет AI. Кнопку "Написать с помощью AI". Умные подсказки. Чат-бот. Автодополнение. И почти все выпускают эти фичи в продакшн без автоматизированного тестирования — потому что "AI нельзя тестировать автоматически".
Это миф. Точнее, полуправда которая стала оправданием.
Качество ответа модели — да, тестировать автоматически сложно. Но большинство AI-багов которые видят пользователи — это не "модель дала плохой ответ". Это "приложение упало когда модель ответила слишком медленно". Это "пользователь увидел пустой экран вместо сообщения об ошибке". Это "при пустом вводе интерфейс завис".
Всё это — обычные баги. Тестируются обычными методами.
Что тестировать в AI-функциях: разделяем задачи
AI-функция в продукте — это интеграция. Ваш фронтенд, ваш бэкенд, внешний API языковой модели. У каждого слоя своя ответственность и свои тест-стратегии.
качество генерации, точность, релевантность, безопасность контента. Это задача для эвалюационных пайплайнов, Human-in-the-loop проверки, red-teaming. Не для Playwright.
всё вокруг модели. Интерфейс, обработка ошибок, граничные случаи, состояния загрузки, валидация ввода. Это обычное функциональное тестирование. Оно прекрасно автоматизируется.
Пять сценариев которые нужны для каждой AI-фичи
Пользователь вводит корректный запрос. Ответ приходит. Отображается правильно. Никаких артефактов в UI, никаких обрезанных текстов, форматирование сохранено.
Пользователь нажимает кнопку без ввода текста. Что происходит? Должно появиться сообщение-подсказка. Не должен уходить запрос к API. Кнопка должна быть задизейблена или показывать валидацию.
Модель отвечает слишком долго. Что видит пользователь? Спиннер который крутится вечно — это баг. Должно быть: таймаут, понятное сообщение об ошибке, возможность попробовать снова.
Провайдер модели вернул 500, 429 (rate limit), или сетевую ошибку. Что видит пользователь? Приложение должно обработать это gracefully: показать понятное сообщение, не крешнуть, не потерять введённый пользователем текст.
Пользователь вставил десять тысяч символов. Что происходит? Валидация с понятным сообщением? Обрезка с предупреждением? Или тихий сбой где часть текста теряется незаметно?
Это пять тестов. Не двести. Пять. Они покрывают большинство реальных AI-багов которые видят пользователи.
Как мокировать AI API в тестах
Тестировать с реальным AI-провайдером — дорого, медленно и недетерминированно. Решение: мокировать API-запросы к модели.
// Playwright: перехватываем запрос к OpenAI
await page.route('**/api/openai/chat**', route => {
route.fulfill({
status: 200,
contentType: 'application/json',
body: JSON.stringify({
choices: [{ message: { content: 'Мокированный ответ AI' } }]
})
})
})Теперь тест не зависит от OpenAI, работает мгновенно, детерминирован. Вы тестируете не модель — вы тестируете как ваше приложение обрабатывает ответ модели.
Для тестирования ошибочных состояний — мокируйте соответствующие ответы:
// Тест таймаута
await page.route('**/api/openai/chat**', route => {
route.abort('timedout')
})Тестирование стриминговых ответов
Многие AI-фичи используют streaming — ответ появляется постепенно, токен за токеном. Это создаёт дополнительные тест-сценарии.
Что нужно проверить:
Всё это — UI-поведение. Всё тестируется стандартными инструментами.
Почему "специальные AI testing tools" чаще всего не нужны
Рынок наполнен инструментами которые обещают "тестирование AI с помощью AI". Большинство из них решают задачу оценки качества генерации — нужен ли вам правда "судья-LLM" который оценивает ответы другого LLM.
Для большинства продуктовых команд ответ: нет. Вам нужно убедиться что ваше приложение не падает, не зависает, не теряет данные пользователя. Это стандартный функциональный тест.
Специализированные AI-эвалюации нужны когда: качество ответа — это ваш основной продукт (AI-ассистенты, генераторы контента, RAG-системы) и вам нужно измерять его регулярно. Это отдельная дисциплина, отдельный инструментарий, отдельная команда.
Для всех остальных — пяти сценариев с моком достаточно чтобы поймать девяносто процентов AI-багов в продакшне.
FAQ
Как тестировать AI-функции в продукте автоматически?
Разделите задачу на две части: качество ответа модели (сложно автоматизировать, нужна ручная или LLM-as-judge оценка) и поведение приложения вокруг модели (обычное функциональное тестирование). Для второй части: напишите тесты для пяти сценариев — успешный запрос, пустой ввод, таймаут, ошибка API, очень длинный ввод. Мокируйте AI API в тестах.
Можно ли использовать Playwright для тестирования AI функций?
Да. Playwright отлично подходит для тестирования UI-поведения AI-фич: проверки состояний загрузки, обработки ошибок, граничных случаев. Playwright умеет перехватывать сетевые запросы и возвращать мок-ответы вместо реальных вызовов к AI-провайдеру — это делает тесты быстрыми и детерминированными.
Как мокировать OpenAI или другой AI API в автотестах?
В Playwright используйте page.route() для перехвата запросов к AI-провайдеру и возврата фиксированных ответов. Это позволяет тестировать разные сценарии (успех, ошибка, таймаут) без реальных вызовов к API — тесты работают быстро и не зависят от доступности внешних сервисов.
Нужны ли специальные инструменты для тестирования AI приложений?
Для большинства продуктовых команд — нет. Специализированные AI-testing инструменты полезны когда качество генерации — это ваш основной продукт. Для обычного SaaS с AI-фичей достаточно обычных инструментов автоматизации (Playwright, TestManager) с правильно написанными сценариями и мокированием API.
Что чаще всего ломается в AI-фичах и как это ловить тестами?
Самые частые баги: отсутствие индикатора загрузки при долгом ответе, пустой экран при ошибке API вместо понятного сообщения, зависание при таймауте, сбой при пустом вводе. Все эти баги ловятся стандартными автотестами с мокированием соответствующих ответов API — они не требуют специальных AI-testing инструментов.