AI-система автотестирования и QA для игр: разработка под ключ

AI тестирование игр: где ломается ручной QA-прогон

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

Ложные срабатывания тестов съедают не время прогона, а доверие к нему. Проверка мигает из-за несинхронизированной анимации, всплывающего окна с событием или разного времени загрузки уровня — и инженер привыкает игнорировать красный результат. После этого настоящий отказ проходит мимо: отчёт зелёный, дефект в релизе, а сдвиг сроков объясняют «нестабильной сборкой».

Покрытие игровых сценариев упирается в комбинаторику: состояние инвентаря, прогресс, сложность, кооп на троих. Руками такие ветки не перебрать, а скриптовые прогоны обычно проверяют только основной путь. Непокрытой остаётся ровно та часть, где ломается чаще всего — переход между состояниями и сохранение прогресса.

Отдельная статья — визуальная сверка: уехавший элемент интерфейса на другом разрешении руками ищут по пачке снимков. Наши инженеры работают в том числе с проектами на Unity и знают, что в сборке даёт плавающий результат. Дальше разбираем, как это закрывается: как строится AI тестирование игр и автоматизация QA для игр, при которой прогон остаётся стабильным и растёт вместе с проектом.

Что меняется после внедрения: эффект в измеримых числах

Эффект автоматизации QA виден не по числу написанных проверок, а по четырём величинам: сколько идёт полный регресс, какую долю проверок система подтверждает сама, сколько дефектов доходит до игроков и как часто ломается сборка. Ниже — как меняется каждая из них после внедрения.

Сокращение времени регрессионного прогона

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

Меньше ложных срабатываний и мигающих проверок

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

Покрытие проверок и стабильность сборки

• Покрытие растёт в первую очередь на критичных путях — запуск, прогресс, платежи, сетевые сессии. Сценарии, до которых не доходили руки, становятся регулярными.
• Число пропущенных дефектов снижается: регресс идёт на каждой сборке, включая ночные и ветки на Unreal Engine.
• Отдельный класс отказов сборки исчезает — нестабильность и падения ловятся до того, как сборка уйдёт в публикацию.

Режимы прогона: записанный сценарий, автономный агент, гибрид

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

Когда достаточно записанных сценариев

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

Когда нужен автономный агент и гибрид

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

Этапы внедрения AI-агента: аудит, схема, проверка, передача

Внедрение агента — не установка инструмента, а последовательность шагов, где каждый опирается на артефакты предыдущего. Если пропустить аудит покрытия, агент уверенно проверяет то, что и так не ломалось, и молчит там, где регрессия уходит в релиз.

Аудит покрытия и постановка схемы проверок

1. Инвентаризация проверок — выгружаем тест-кейсы, автотесты и ручные чек-листы, сопоставляем с картой игровых систем: бой, экономика, прогрессия, сетевые сценарии. На выходе — список путей, которые не покрывает ни один прогон.
2. Отбор нестабильных проверок — помечаем тесты, которые плавают и требуют ручного разбора логов; их либо делаем детерминированными, либо выводим из обязательного набора.
3. Схема проверок и приоритеты — фиксируем, что агент гоняет на каждый коммит, что на ночных прогонах, а что перед релизом. Приоритет считаем по цене пропущенного дефекта, а не по числу тестов.

Настройка, проверка на стенде и передача

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

Что остаётся у команды: конфигурации, отчёты, регламенты

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

Конфигурации агента и приоритеты запуска

• Файлы конфигурации агента: параметры запуска клиента, наборы входных устройств, точки старта сценариев — правятся без пересборки самого агента.
• Карта покрытия сценариев: «игровой модуль → сценарий → статус автоматизации» с явной пометкой пробелов, которые остались на ручной проверке.
• Правила приоритетов запуска: что гоняется на каждое изменение, что по расписанию, что только перед релизом — с обоснованием границ.
• Скрипты подготовки окружения и эталонные данные, чтобы повторный прогон на другой машине давал тот же результат.

Отчёты, регламенты и инструкции

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

Кейс: как автономный агент закрыл регресс перед релизом

Кейс автоматизации QA в игровой студии: многопользовательский проект с сезонными патчами — раз в шесть недель новая сборка и обязательный регресс перед публикацией в Steam. Тестирование держалось на ручном прогоне: инженеры заново проходили один и тот же чек-лист, а часть проверок откладывали из-за сроков. Пропущенный сценарий входа в матч вылезал горячей правкой в первые сутки после релиза — уже на игроках.

Метрики до и после на релизном цикле

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

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

Что делать, если базовые проверки уже закрыты автотестами?

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

Перенос проверок идёт не целиком, а по одному сценарию. В агента уходит то, что тяжело описать жёстким скриптом: свободные последовательности действий, обход уровня в произвольном порядке, комбинации предметов и состояний, проверка на «похоже на баг» вместо точного сравнения. Миграция сценариев делается так: обе схемы прогоняются на одной сборке, вердикты сравниваются, а расхождения разбираются до того, как старый скрипт выключат.

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

Критерий простой: воспроизводимость и цена ложного срабатывания. Если проверка даёт стабильный однозначный вердикт — она остаётся скриптом. Если вердикт требует суждения или сценарий невозможно зафиксировать заранее — он уходит агенту, а результат прикладывается логом действий для ручного разбора. Так покрытие растёт без переписывания всего набора.

Технические сомнения перед пилотом: разбираем по пунктам

Перед пилотом поднимают один и тот же набор сомнений по автоматизации QA: смена интерфейса, ложные тревоги, доступы к сборкам, поддержка после передачи. Отвечаем коротко.

Насколько часты ложные срабатывания?

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

Какой доступ к сборкам нужен?

Сборка в вашем сборочном контуре, тестовый стенд и учётные записи для прогонов. Доступы выдаются под конкретный контур и отзываются по завершении — сборки за пределы инфраструктуры не уходят.

Что при смене интерфейса?

Привязка идёт к элементам и их состоянию, а не к координатам, поэтому сдвиг кнопки прогон не ломает. Новые экраны требуют пересъёмки эталонов — это процедура на несколько часов, а не переписывание сценариев.

Кто поддерживает после передачи и каковы сроки пилота?

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

Обсудим задачу и вернёмся с оценкой и планом работ

Старт пилота не требует готового стенда и полного пакета документации — достаточно минимального контура, на котором проверки начнут находить реальные дефекты. Чем точнее описаны критичные сценарии и ограничения, тем меньше времени уходит на первый прогон.

Чтобы перейти от разговора к старту пилота, от заказчика нужен минимальный набор — требования к запуску сводятся к шести пунктам:

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

Дальше мы собираем план работ по QA: разбиваем объём на этапы, фиксируем критерии выхода по каждому и называем срок первой итерации. Готовы обсудить задачу предметно — опишите текущее состояние тестирования, и вернёмся с оценкой и планом, где видно, что и когда вы получаете.

• Отдавать задачу формулировкой «сделайте, чтобы тестировалось само»: без перечня критичных сценариев и правил приёмки агент обучают на том, что удобно проверить, а не на том, что ломает релиз.
• Запускать автономный режим сразу, минуя записанные сценарии: команда не получает эталона поведения, и первые же расхождения невозможно отличить от ошибки системы.
• Гнаться за количеством проверок вместо покрытия рисков: сотни однотипных прогонов меню и настроек не спасают от отказа в самом нагруженном месте.
• Не выделять владельца на стороне заказчика: без человека, который принимает отчёты и правит конфигурации, система живёт до первой смены состава команды.
• Менять содержимое сборок и тестового окружения прямо во время проверки: эталонные данные устаревают, и рост ложных срабатываний списывают на некачественный инструмент.
• Ждать, что ручной прогон исчезнет полностью: агент закрывает повторяющееся, а исследовательские и «странные» случаи всё равно остаются за тестировщиком.
• Складывать все находки в общий список без разбора: если не отделять реальные отказы от шума, через несколько прогонов отчётам перестают верить.
• Считать, что одно решение подойдёт любому жанру и любой платформе: логика проверки строится под конкретную игру, и перенос её «как есть» даёт формальные, но бесполезные результаты.
• Оценивать результат по факту внедрения, а не по динамике: без сравнения первых и последних прогонов невозможно понять, стало ли лучше и где именно.
• Затягивать передачу знаний: если команда не видит, как устроены сценарии и отчёты, сопровождение после смены подрядчика превращается в перезапуск проекта.