Проведение регрессионного тестирования игр
Регрессионное тестирование — это не про поиск новых багов. Это про подтверждение того, что старые баги не вернулись, а работающие сценарии не сломались после последних изменений. Без него каждый новый патч — это лотерея: разработчик правит коллайдер персонажа, а ломается система сохранений, потому что они оба зависят от одного ScriptableObject-контейнера, который никто не потрогал, но порядок инициализации компонентов изменился.
Почему регрессия в играх сложнее, чем в обычном ПО
В обычном веб-приложении регрессионный тест — это запрос к API и проверка ответа. В игре «сломалась анимация перехода при смерти персонажа» — это значит нужно: запустить сцену, войти в боевой режим, снизить HP до нуля, дождаться триггера анимации, проверить, что Animation Controller перешёл в состояние Death, что Collider отключился в нужный момент, что UI смерти показался без артефактов.
Это сложно автоматизировать полностью. Поэтому в игровой регрессии обычно работает гибридная модель: автотесты покрывают детерминированную логику (расчёты урона, инвентарь, прогрессию, сетевые протоколы), ручное тестирование — визуальные и поведенческие сценарии.
Конкретный случай: в мобильном RPG после обновления системы диалогов сломался триггер достижения «провести 10 разговоров». Автотест на DialogueManager.OnDialogueComplete отработал — событие вызывалось. Но логика подсчёта переехала в другой класс и потеряла подписку на событие. Ручной тест нашёл это за 10 минут; автотест — нет, потому что проверял только вызов события, а не финальное состояние счётчика достижения.
Как строится регрессионный суит для игры
Основа — regression pack: набор тест-кейсов, покрывающих критические пути. Для каждого патча определяем scope of impact: какие системы затронуты изменениями? Если правился ИИ врагов — тестируем не только ИИ, но и всё, что с ним взаимодействует: NavMesh, агрессию, лут, достижения, связанные с врагами.
Для автоматизации используем Unity Test Framework в режиме Play Mode с тестами, охватывающими:
- Критические game-loop сценарии (spawn → combat → death → respawn)
- Инвентарь и крафт при граничных значениях
- Сохранение и загрузка с разными версиями данных
- Сетевые события (через мок Photon-клиента или Mirror NetworkManager в offline-режиме)
Тесты запускаются через Unity Cloud Build или локальный CI (Jenkins, GitHub Actions) на каждый коммит в main/develop. Если суит из 200 тестов проходит за 8 минут — это приемлемо. Если за 40 минут — нужно разбирать тесты на быстрые (smoke) и медленные (full regression), запускать по расписанию.
Для мобильных платформ регрессионный прогон дополнительно проходит на реальных устройствах через Firebase Test Lab или физический device farm — эмулятор не воспроизводит OpenGL ES/Vulkan-специфику и не тестирует тепловой троттлинг.
Приоритизация и scope
Не каждый баг-фикс требует полного регрессионного прогона. Используем матрицу риска: насколько изменение затрагивает shared systems (EventBus, SceneManager, SaveSystem)? Если правился только UI-виджет одного экрана — достаточно smoke + экран-специфичная регрессия. Если менялся SaveSystem — полный прогон обязателен.
Важный артефакт — regression baseline: сохранённые состояния игры (save-файлы) для каждого типичного сценария. Это позволяет начинать тест не с начала игры, а с нужной точки — экономит часы ручного тестирования.
После каждого релиза патча обновляем regression pack: баги, которые были найдены в этом цикле, превращаются в новые тест-кейсы. Так суит растёт и охватывает реальные регрессионные риски, а не гипотетические.
| Масштаб | Ориентировочные сроки прогона |
|---|---|
| Smoke regression (50–80 кейсов) | 2–4 часа |
| Partial regression (scope of impact) | 1–3 дня |
| Full regression pack | 3–7 дней |
| Automated CI regression (каждый билд) | 15–60 минут |
Стоимость формирования regression pack и настройки CI рассчитывается после анализа проекта.