Услуги по тестированию и оптимизации игр

Тестирование и QA

Проект на финишной прямой перед релизом. Вроде всё работает — на машине разработчика. Потом первый тестовый запуск на реальных устройствах: на Samsung Galaxy A12 игра падает при загрузке, на iPad Air 2019 текстуры мыльные, на Xiaomi Redmi Note 10 половина анимаций лагает. Это не гипотетический сценарий, это стандартное состояние мобильного проекта без выстроенного QA-процесса.

Автоматизированное тестирование в Unity

Самая ценная инвестиция в качество — это тесты, которые запускаются без участия человека. В Unity для этого есть Unity Test Framework (UTF) — встроенный инструмент на базе NUnit.

Edit Mode vs. Play Mode Tests

Edit Mode Tests запускаются без инициализации игрового цикла. Скорость выполнения — миллисекунды. Подходят для:

• Чистой бизнес-логики (формулы урона, расчёт экономики, валидация данных)
• Утилит и вспомогательных систем
• Парсеров конфигурационных файлов

Пример того, что имеет смысл покрывать Edit Mode тестами: система прогрессии уровней, формулы баланса, инвентарная система.

Play Mode Tests запускают полный игровой цикл в реальном времени. Дороже по времени выполнения, но позволяют тестировать:

• Логику, зависящую от MonoBehaviour и Update()
• Корутины и async-операции
• Переходы между сценами
• Интеграцию систем (UI + игровая логика + данные)

[UnityTest]
public IEnumerator PlayerTakeDamage_HealthReduces()
{
    var go = new GameObject();
    var health = go.AddComponent<HealthComponent>();
    health.Initialize(100);

    health.ApplyDamage(30);

    yield return null; // дать фрейм на обновление

    Assert.AreEqual(70, health.CurrentHealth);
}

Practical правило: покрывайте тестами то, что ломается чаще всего — а это обычно система сохранений, экономика и логика боя. Не нужно гнаться за 100% покрытием; нужно покрыть критические пути.

Тестирование UI

Unity UI Toolkit и старый UGUI сложно тестировать автоматически — большинство студий ограничиваются ручным тестированием. Для базовой автоматизации используют InputSystem.QueueEvent для симуляции ввода. Для более серьёзного UI-тестирования — кастомные утилиты или Appium для мобильных платформ.

Профилирование производительности

Тесты не поймают проблемы производительности — для этого нужен профилировщик. Unity предоставляет несколько инструментов, и их нужно использовать вместе, а не по отдельности.

Unity Profiler: CPU и GPU

Unity Profiler — отправная точка. Запускается через Window → Analysis → Profiler или через пакет com.unity.profiling.core. Ключевые шаги:

1. Профилируйте на целевом устройстве, не в редакторе. Editor добавляет значительный оверхед. Подключите устройство через USB и запустите профилирование через Build Settings с включённым Development Build и Autoconnect Profiler.

2. Смотрите на Main Thread и Render Thread отдельно. Типичные проблемы:

   • Physics.FixedUpdate занимает >2ms — слишком сложная физика
   • Canvas.BuildBatch на каждом кадре — UI перестраивается из-за лишних Dirty вызовов
   • GC.Collect — сборщик мусора. Означает выделение памяти в горячем пути (внутри Update() или корутин)

3. Markers помогают локализовать проблему:

using Unity.Profiling;

static readonly ProfilerMarker k_PathfindMarker = new ProfilerMarker("Pathfinding.Calculate");

void UpdateAI()
{
    using (k_PathfindMarker.Auto())
    {
        // ваш код паттфайндинга
    }
}

Memory Profiler

Memory Profiler (пакет com.unity.memoryprofiler) — отдельный инструмент для анализа использования памяти. Позволяет:

• Сделать snapshot памяти в конкретный момент
• Найти утечки — объекты, которые не освобождаются после выгрузки сцены
• Сравнить два snapshot для обнаружения роста памяти
• Посмотреть, что занимает больше всего места (обычно это текстуры)

Самые частые причины проблем с памятью на мобайле:

• Текстуры без правильного Compression Format (используйте ASTC для iOS, ETC2 для Android)
• Аудио в формате WAV вместо сжатого Vorbis
• Объекты в DontDestroyOnLoad, которые накапливаются между сессиями

Frame Debugger

Frame Debugger (Window → Analysis → Frame Debugger) — позволяет пройти по каждому draw call в конкретном кадре. Незаменим для:

• Поиска лишних draw calls (overdraw)
• Диагностики батчинга — почему объекты не объединяются в один draw call
• Проблем с тенями и постпроцессингом

Норма для мобильного проекта — 50-150 draw calls на кадр. Если больше 300 — значит батчинг не работает или сцена перегружена.

Функциональное и регрессионное тестирование

Тест-планы и чеклисты

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

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

Инструменты для управления тест-кейсами: TestRail, Qase, Zephyr (для Jira). Для небольших команд хватит Notion или Google Sheets со структурированными чеклистами.

Тестирование на устройствах

Мобильное тестирование без реальных устройств неполноценно. Эмуляторы не воспроизводят проблемы памяти, тепловой дросселинг, реальный GPU. Минимальный набор устройств для тестирования:

• Android Low-end: Snapdragon 662 / MediaTek Helio G85, 3GB RAM (Samsung A12, Redmi Note 10)
• Android Mid-range: Snapdragon 720G / 765G, 6GB RAM
• Android Flagship: Snapdragon 888+, 8GB RAM
• iOS: iPhone SE 2 (самый слабый поддерживаемый), iPhone 13/14, iPad (последнее поколение)

Для масштабного тестирования — облачные фермы устройств: Firebase Test Lab (интеграция с Google Play), BrowserStack App Automate, AWS Device Farm. Позволяют запускать автотесты на сотнях реальных устройств параллельно.

Нагрузочное тестирование

Актуально для мультиплеерных проектов. Цель — найти деградацию производительности сервера до релиза, а не после.

Инструменты:

• k6 — скриптовое нагрузочное тестирование WebSocket и HTTP API. Хорошо подходит для игровых бэкендов.
• Gatling — Java/Scala, поддерживает сложные сценарии с состоянием (авторизация → матчмейкинг → игровая сессия).
• локти собственная нагрузка — для специфических игровых протоколов часто проще написать кастомный stress-клиент на Go или C#.

Что проверять:

• Поведение при пиковом CCU (concurrent users)
• Деградация латентности под нагрузкой
• Утечки памяти на сервере при длительной работе (72+ часов)
• Поведение при graceful degradation — что происходит, когда один из узлов падает

Краш-репортинг и мониторинг

После релиза QA продолжается через мониторинг. Без краш-репортинга вы узнаёте о критических ошибках от пользователей в отзывах App Store — то есть слишком поздно.

• Firebase Crashlytics — стандарт для мобильных игр. Автоматический сбор крашей с символизацией стектрейсов, группировка по причинам, real-time уведомления.
• Sentry — для серверных компонентов и WebGL. Поддерживает C# и большинство серверных языков.

Важно настроить ANR (Application Not Responding) reporting отдельно от крашей — это зависания без падения, которые Android Play Console фиксирует и показывает в отдельном разделе.

Типичные ошибки в QA-процессе

• Тестирование только на флагманах разработчиков. Большинство игроков — на mid-end и low-end устройствах.
• Отсутствие автотестов для экономики и сохранений — именно они ломаются при рефакторинге.
• Пропуск нагрузочного тестирования сервера. Игра успешно прошла QA, вышла, набрала 10k DAU — и сервер лёг.
• Регрессионное тестирование только перед мажорными релизами. Регрессия нужна перед каждым публичным обновлением.