Проведение функционального тестирования игр
Функциональное тестирование игры — это не «поиграть и найти баги». Это систематическая верификация того, что каждый игровой сценарий работает согласно Game Design Document: механики, UI-флоу, инвентарь, прогрессия, сохранения, сетевые взаимодействия. Разница между «поиграли — всё работает» и полноценным функциональным тестированием обычно выясняется на релизе, когда от игроков приходят репорты о сценариях, которые команда не тестировала намеренно.
Что функциональное тестирование покрывает на самом деле
Типичный пример из практики: шутер с системой крафта. Команда вручную проверила основной флоу — открыл инвентарь, скрафтил предмет, закрыл. Всё работает. На релизе выяснилось, что если скрафтить предмет в момент, когда инвентарь переполнен (99/100 слотов), а предмет крафта занимает последний слот и одновременно является ингредиентом — счётчик слотов уходит в -1, и вся дальнейшая сессия ломается. Это классический граничный кейс на пересечении двух механик, который находится только при системном подходе к тест-кейсам, а не при свободном исследовании.
Функциональное тестирование в геймдеве охватывает несколько слоёв:
Геймплейные механики — каждая механика тестируется изолированно, потом в комбинации с другими. Прыжок работает? Прыжок на движущейся платформе? Прыжок в момент получения урона? Прыжок при нулевом HP?
UI и навигация — все экраны, все переходы, все состояния элементов (disabled, loading, error). Особое внимание к переходам между сценами: если игрок нажимает кнопку «в главное меню» в момент завершения матча, оба события могут попытаться сделать LoadScene одновременно.
Сохранение и загрузка — самая недооценённая область. Сохранение посреди катсцены, загрузка на новом устройстве, миграция данных при обновлении версии. В Unity PlayerPrefs и JSON-сериализаторы не имеют встроенной версионной миграции — при изменении структуры данных старые сохранения просто не парсятся, и игра крашится без внятной ошибки.
Сетевые сценарии для мультиплеера: потеря пакетов, выход игрока в середине матча, реконнект, десинхронизация состояния.
Инструменты и подходы
Для автоматизации функциональных тестов в Unity используем Unity Test Framework (UTF) с режимом Play Mode Tests. UTF позволяет писать тесты, которые запускаются внутри игровой сессии с полным доступом к компонентам сцены. Типичный тест на механику крафта выглядит так: создать инвентарь с предопределённым состоянием через фикстуру, вызвать CraftingSystem.TryCraft(recipeId), проверить Assert на состояние инвентаря и возвращённый результат.
Для UI-тестирования используем комбинацию UTF + Unity UI Test Helpers или кастомные обёртки над EventSystem.RaiseEvent. Ручное тестирование UI через Selenium или Playwright не применимо к игровым интерфейсам — нужны инструменты, которые понимают Canvas, EventSystem и InputSystem от Unity.
Для мобильных платформ — Unity Remote для быстрой проверки на девайсе без полной сборки, и реальные девайсы (не только эмуляторы) для верификации специфики платформы: жесты, back-кнопка Android, прерывания звонком.
Дефекты фиксируются в трекере (Jira, YouTrack) с обязательными полями: шаги воспроизведения, ожидаемый результат, фактический результат, версия билда, устройство, скриншот или видео. Без этого воспроизведение бага на стороне разработчика занимает в 3–5 раз больше времени.
Как строится процесс
Тестирование начинается ещё до передачи билда: аудит GDD на полноту описания сценариев, составление тест-плана и тест-кейсов. Хороший тест-кейс привязан к конкретному требованию из документации — это позволяет отслеживать coverage.
Smoke-тестирование нового билда: 15–20 ключевых кейсов, которые проверяют, что ничего фундаментального не сломано. Если smoke прошёл — полный регрессионный прогон. Функциональное тестирование новой фичи — отдельно, с фокусом на интеграционные кейсы.
Финальный этап перед релизом — certification testing: проверка соответствия требованиям платформы (для Steam, App Store, Google Play, консолей — у каждого свои чеклисты). Это технически тоже функциональное тестирование, просто с внешними критериями.
| Объём проекта | Ориентировочные сроки |
|---|---|
| Инди-игра, одиночная, до 5 механик | 1–2 недели |
| Mid-core, мультиплеер, 10–20 механик | 3–6 недель |
| Крупный проект, несколько платформ | 2–4 месяца |
| Continuous testing (поддержка релиза) | по договорённости |
Стоимость рассчитывается после анализа GDD, количества тест-кейсов и требуемого покрытия.