ИИ-агенты для тестирования: проверка приложения по шагам

ИИ-агент для тестирования приложения может пройти заранее заданные сценарии, собрать снимки экрана, журналы и отчёт о воспроизводимых ошибках. Для первого запуска нужен тестовый стенд, контрольный аккаунт и список ожидаемых результатов. Агент помогает расширить проверку, но итог о готовности выпуска принимает человек. Здесь речь о проверке самого приложения, а не о тестировании качества ИИ-агента. Для последней задачи есть отдельный разбор сценариев.

Какую задачу поручить агенту первой

Начните с одного ограниченного пользовательского пути: открыть тестовую страницу, заполнить безопасную форму, увидеть подтверждение, затем повторить путь с ошибочным вводом. Результат каждого шага должен быть наблюдаемым. Проверка «найди все проблемы сайта» не задаёт границ, поэтому агент может пропустить главный путь и при этом выдать уверенный отчёт. Playwright позволяет автоматизировать браузер и сохранять состояние страницы после действий; его официальный пример для агента предлагает фиксировать снимки успешных и неуспешных сценариев. Playwright Agent CLI.

Если сценарий уже записан как автотест, агенту лучше поручить разобраться с конкретным падением: прочитать ошибку, воспроизвести её и предложить минимальное исправление. Если тестов нет, сначала зафиксируйте вручную, что пользователь должен увидеть. Иначе агент начнёт принимать текущее поведение за правильное. Для организации отдельного проекта помогут основы вайбкодинга с проверкой результата.

Что подготовить до запуска

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

• Адрес тестового стенда и список страниц, которые разрешено открывать.
• Тестовый аккаунт с минимальными правами и данные, которые можно удалить после опыта.
• Три контрольных сценария: обычный путь, ошибочный ввод и повтор после обновления страницы.
• Ожидаемый результат каждого шага: текст, адрес страницы, изменение состояния или сообщение об ошибке.
• Правило остановки: неожиданная отправка письма, списание, изменение чужой записи или выход за разрешённый домен.

Дефектом считайте не уверенное объяснение агента, а расхождение между ожидаемым и фактическим поведением, которое можно повторить на том же стенде.

По теме: Язык ИИ-агентов: Python или TypeScript для первого проекта

Как провести пробную проверку

Запишите задачу так, чтобы агент вернул доказательства вместо общего впечатления. Playwright поддерживает реальные действия в браузере, проверки ожидаемого состояния и трассировку. Однако наличие инструментов не гарантирует корректной проверки: критерий нужно задать до запуска. Возможности Playwright Test, документация проверок.

1. Выберите один маршрут, например вход в тестовый кабинет. Запишите исходное состояние и ожидаемый результат для правильного и неправильного пароля.
2. Передайте агенту адрес тестового стенда, тестовые данные и запрет на изменение настоящих записей. Попросите сначала описать план и уточнить недостающие условия.
3. Поручите выполнить сценарий в браузере и для каждого шага сохранить наблюдаемое состояние: адрес, видимый текст, снимок или журнал ошибки.
4. Попросите оформить каждую находку как воспроизведение: начальное состояние, действия, ожидаемый результат, фактический результат и доказательство.
5. Сами повторите хотя бы одну найденную ошибку и один успешный путь. Только после этого решайте, нужен ли патч или новый автотест.

Пример формулировки: «Проверьте вход на тестовом стенде для корректного и неверного пароля. Ничего не отправляйте на внешние адреса и не меняйте код. Для каждого шага укажите ожидаемый и фактический результат. Если обнаружите ошибку, сохраните снимок и точную последовательность воспроизведения. Если тестовые данные не подходят, остановитесь и сообщите об этом». Такой контракт удобно адаптировать к вашему приложению.

Как проверить отчёт и не принять ложную находку

Используйте матрицу покрытия: строка на каждый запланированный сценарий, столбцы «выполнен», «ожидаемое», «наблюдаемое», «доказательство», «повторено человеком». Пустое поле означает непроверенный участок, а не успешный тест. Если агент сообщил об ошибке без исходного состояния и шагов воспроизведения, верните задачу на уточнение. Для серьёзных изменений кода сверяйте разницу файлов, запускайте тесты и делайте собственный обзор: GitHub отдельно рекомендует проверять изменения, созданные ИИ, до запроса внешнего ревью. Рекомендации GitHub.

Важный граничный случай: тест прошёл в одном браузере, но падает на телефоне. Это разные окружения, и один успешный запуск не покрывает все устройства. Playwright позволяет задать отдельные проекты для браузеров и эмулируемых устройств. Добавляйте такую проверку, только когда соответствующая платформа действительно нужна вашим пользователям. Проекты Playwright.

По теме: MCP-серверы в Cursor: подключение и безопасная проверка

Что делать при нестабильных или неверных результатах

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

Если сценарий меняет данные, возвращайте стенд в исходное состояние перед следующей попыткой. Сравнивайте одинаковые версии приложения: проверка на изменённом коде и старом снимке не даёт честного сравнения. Для поиска причин пригодится статья о проверке ответов ИИ-агента, но финальное доказательство дефекта всегда лежит в поведении вашего приложения.

Частые вопросы

Может ли агент полностью заменить тестировщика?

Нет. Он может выполнять повторяемые шаги и собирать доказательства, но человек задаёт ожидаемое поведение, проверяет спорные находки и принимает решение о выпуске.

Нужно ли сразу писать автотест?

Для разовой разведки достаточно контролируемого браузерного сценария. Если проверка повторяется при каждом выпуске, закрепите её автотестом с явными утверждениями и тестовыми данными.

Почему агент называет ошибкой намеренное ограничение?

В задании не описан ожидаемый результат или роль пользователя. Добавьте требование продукта и повторите сценарий на нужном аккаунте.

Можно ли проверять боевой сайт?

Проверки только для чтения возможны при разрешении владельца. Формы, заказы и действия с данными сначала испытывайте на тестовом стенде.