Послуги з тестування та оптимізації ігор

Тестування та 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);
}

Практичне правило: покривайте тестами те, що ломиться частіше всього — зазвичай система збереження, економіка та логіка боїв. Не гонітесь за 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. Профілюйте на цільовому пристрої, не в редакторі. Редактор додає значний оверхед. Підключіть пристрій через USB та запустіть профілювання з Build Settings із включеним Development Build та Autoconnect Profiler.

2. Дивіться на Main Thread та Render Thread окремо. Типові проблеми:

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

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

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) — окремий інструмент для аналізу використання пам'яті. Дозволяє вам:

• Зробити снимок пам'яті в конкретний момент
• Знайти витечки — об'єкти, які не звільняються після вивантаження сцени
• Порівняти два снимки для виявлення росту пам'яті
• Побачити, що займає найбільше місця (зазвичай текстури)

Найпоширеніші причини проблем з пам'яттю на мобайлі:

• Текстури без правильного 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-клієнт — для специфічних ігрових протоколів часто простіше написати користувацький stress-клієнт на Go або C#.

Що перевіряти:

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

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

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

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

Важливо налаштувати ANR (Application Not Responding) репортинг окремо від крашів — це зависання без падіння, які Android Play Console фіксує окремо.

Типові помилки в QA-процесі

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