Регресійне тестування ігор: автоматизація та ручні перевірки

Ви випустили патч, що виправляє баг з колайдером. Наступного дня — шквал скарг: у половини гравців не завантажується збереження. Виявляється, колайдер і система збережень залежали від одного ScriptableObject, а порядок ініціалізації компонентів змінився.

Ми називаємо регресійне тестування страховкою від таких сценаріїв. Без нього кожен реліз — лотерея. Наші інженери будують гібридну модель: автотести покривають детерміновану логіку (розрахунки шкоди, інвентар, прогресію, мережеві протоколи), а ручне тестування — візуальні та поведінкові сценарії. Такий підхід знижує кількість багів у продакшені щонайменше на 80% і скорочує час ручних перевірок на 40%.

Чому регресійне тестування ігор складніше, ніж у вебі?

У веб-додатку регресійний тест — запит до API та перевірка відповіді. У грі «зламалася анімація переходу при смерті персонажа» — значить, потрібно запустити сцену, увійти в бій, знизити HP, дочекатися тригера, перевірити, що Animation Controller перейшов у стан Death, Collider вимкнувся, UI смерті показався без артефактів. Повністю автоматизувати таке неможливо. Тому для візуально-орієнтованих проєктів ми використовуємо пропорцію 70% ручного та 30% автоматизованого тестування, для логіко-орієнтованих (стратегії, симулятори) — навпаки. Економія бюджету на регресії сягає 40% при грамотному гібриді.

Як зібрати regression pack для гри?

Основа — 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-специфіку і не тестує тепловий тротлінг. Вартість регресії на мобільних можна знизити за рахунок пріоритезації smoke-тестів.

Покроковий план впровадження регресії

1. Аналіз scope of impact — визначаємо, які системи зачеплені зміною.
2. Формування regression pack — створюємо тест-кейси критичних шляхів.
3. Налаштування CI — інтегруємо Unity Test Framework у пайплайн.
4. Baseline save-файли — готуємо збережені стани для швидкого старту.
5. Регулярні прогони — включаємо регресію в процес кожного білда.

Що входить у deliverables?

Ми створюємо інфраструктуру регресії, яка живе з проєктом:

• Регресійний pack у вигляді документованих тест-кейсів (Google Sheets/TestRail)
• Автоматизований CI з інтеграційними тестами
• Smoke suite для швидкої перевірки кожного білда (50–80 кейсів за 2–4 години)
• Baseline save-файли для ключових точок гри
• Регулярні звіти про покриття та результати прогонів
• Навчання команди з оновлення pack

Приклад matrix ризику: зміна лише UI-віджета — достатньо smoke + екран-специфічна регресія (1–2 години). Зміна SaveSystem — повний прогон обов'язковий (3–7 днів). Зміна EventBus — часткова регресія за scope (1–3 дні). Для детального аудиту зв'яжіться з нами.

Порівняння підходів: ручне vs автоматизоване

Орієнтовні терміни прогону

Як ми оцінимо ваш проєкт

Хороший regression pack окупається вже на третьому патчі — знижує кількість регресійних багів у продакшені на 80% і скорочує час ручних перевірок на 50%. Вартість формування pack та налаштування CI розраховується після аналізу проєкту. Ми оцінимо обсяг, складність систем і поточне покриття тестами за 1 день. Зв'яжіться з нами для консультації — отримайте попередній план та оцінку. Наша команда QA-інженерів з досвідом у геймдеві від 8 років гарантує результат.

Замовте аудит поточного регресійного покриття — ми знайдемо слабкі місця та запропонуємо план покращень.

Ми використовуємо регресійне тестування та Unity Test Framework як основні інструменти.

Тестування та QA

Ми не раз бачили, як проєкт на фінішній прямій перетворюється на кошмар: на машині розробника все літає, а на Samsung Galaxy A12 — 15 FPS і вильоти, на iPad Air — мильні текстури. Без вибудуваного QA-процесу тестування ігор стає лотереєю. Наша команда з 8-річним досвідом протестувала понад 30 мобільних ігор і в кожному проєкті знаходила критичні проблеми, які не виявили звичайні прогони. Тестування ігор під ключ — від функціонального до навантажувального — з гарантією якості та звітом, готовим до впровадження. Оцінимо ваш проєкт за 3 дні — зв'яжіться з нами.

Як автоматизувати тестування в Unity?

Найефективніший спосіб зловити регресію — автотести, які запускаються без людини. У Unity це Unity Test Framework (UTF) на базі NUnit. Два режими.

Edit Mode Tests працюють без ігрового циклу — швидкість виконання в мілісекундах. Підходять для формул урону, розрахунку економіки, валідації конфігів. Play Mode Tests запускають повний ігровий цикл — тестують логіку MonoBehaviour, корутини, переходи між сценами.

Приклад:

[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 (UGUI, UI Toolkit) автоматизувати складніше: для цього використовують InputSystem.QueueEvent або Appium на мобільних платформах. Автотести виконуються в 50 разів швидше ручних прогонів при регресії — це скорочує бюджет на регресійне тестування на 40%.

Чому профілювання на реальному пристрої критичне?

Тести не ловлять проблеми продуктивності. Для цього потрібен профілювальник на цільовій платформі. Unity Profiler — стартова точка. Ключові кроки:

1. Профілюйте на пристрої, а не в редакторі — Editor додає оверхед. Підключіть девайс через USB з Development Build і Autoconnect Profiler.
2. Дивіться Main Thread і Render Thread окремо. Типові проблеми:
   • Physics.FixedUpdate >2ms — складна фізика
   • Canvas.BuildBatch на кожному кадрі — зайві Dirty виклики UI
   • GC.Collect — виділення пам'яті в гарячому шляху (всередині Update)
3. Використовуйте ProfilerMarker для локалізації:

using Unity.Profiling;

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

void UpdateAI()
{
    using (k_PathfindMarker.Auto())
    {
        // pathfinding code
    }
}

Memory Profiler (пакет com.unity.memoryprofiler) дає знімки пам'яті: знаходить витоки (об'єкти, не звільнені після зміни сцени), порівнює два знімки. Найчастіші причини проблем на мобайлі: текстури без правильного формату (ASTC для iOS, ETC2 для Android), аудіо в WAV замість Vorbis, об'єкти в DontDestroyOnLoad, які накопичуються.

Frame Debugger (Window → Analysis → Frame Debugger) дозволяє пройти по кожному draw call у кадрі. Для мобільних проєктів норма — 50–150 draw calls; якщо більше 300 — батчинг не працює або сцена перевантажена. Важливість профілювання на реальному обладнанні підкреслюється в літературі з тестування продуктивності.

Профілювання на реальному пристрої обов'язкове — редактор Unity дає спотворені результати через власний оверхед, тому завжди використовуйте Development Build на цільовому пристрої.

Функціональне та регресійне тестування

Функціональне тестування будується на тест-планах: для кожної фічі — очікуваний результат, кроки відтворення, критерії проходження. Покриваємо smoke, sanity і acceptance-тести. Регресійне тестування — запуск накопичених кейсів перед кожним релізом, а не тільки перед мажорними.

Інструменти управління: TestRail, Qase, Zephyr. Для невеликих команд — Notion або Google Sheets зі структурованими чеклістами.

Тестування на реальних пристроях

Емулятори не відтворюють тепловий дросселінг, реальний GPU та обмеження пам'яті. Мінімальний набір — 20+ пристроїв усіх сегментів:

Для масштабного тестування — хмарні ферми: Firebase Test Lab, BrowserStack App Automate, AWS Device Farm. Вони дозволяють запускати сотні паралельних тестів на реальних пристроях.

Навантажувальне тестування (мультиплеєр)

Мета — знайти деградацію сервера до релізу. Інструменти: k6 (WebSocket/HTTP API), Gatling (складні сценарії зі станом). Для специфічних протоколів пишуть кастомний stress-клієнт на Go або C#.

Параметри перевірки:

• Поведінка при піковому CCU (concurrent users) — до 1000+ CCU
• Деградація латентності під навантаженням (p95 latency)
• Витоки пам'яті на сервері за 72+ години роботи
• Graceful degradation при відмові одного з вузлів

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

Після релізу QA продовжується через моніторинг. Firebase Crashlytics — стандарт для мобільних ігор: автоматичний збір крашів із символізацією стектрейсів, real-time сповіщення. Sentry — для серверних компонентів і WebGL. ANR (Application Not Responding) налаштовується окремо — Play Console показує їх в окремому розділі. Інвестиції в тестування окупаються за 2–3 релізи, знижуючи витрати на виправлення багів після релізу на 60%.

Що входить у нашу роботу

• Детальний план тестування (чек-лист, сценарії, пріоритети)
• Набір автоматизованих тестів (економіка, збереження, критичні шляхи — покриття 70%)
• Профілювання CPU/GPU/пам'яті зі звітом по кожному багу
• Ручне тестування на 20+ реальних пристроях (low-end / mid-range / flagship)
• Навантажувальне тестування сервера (до 1000+ CCU протягом 12 годин)
• Дашборд з метриками та історією прогонів
• Навчання вашої команди основам автотестування та профілювання

Отримайте консультацію щодо вашого проєкту — ми оцінимо поточну збірку та запропонуємо план оптимізації.

Процес роботи

1. Аналіз — вивчаємо архітектуру, збираємо метрики поточної збірки, визначаємо цілі по FPS та стабільності.
2. План тестування — створюємо чек-лист, обираємо інструменти, узгоджуємо обсяг.
3. Автоматизація — пишемо тести для критичних шляхів, налаштовуємо CI-прогони.
4. Ручне тестування — проганяємо сценарії на пристроях, фіксуємо баги в трекері.
5. Звіт та рекомендації — надаємо документ зі знайденими проблемами, їх пріоритетом і конкретними правками (оптимізація шейдерів, налаштування батчингу, витоки).

Наші метрики

• 8+ років досвіду в геймдеві (Unity, Unreal, мобільні/PC/консолі)
• 30+ протестованих мобільних ігор
• Середнє підвищення FPS після оптимізації — 30%
• Скорочення часу регресійного тестування — 40%
• Гарантія: всі бази з Critical/High пріоритетом виправляються до релізу

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

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

Замовте тестування ігор під ключ. Ми оцінимо ваш проєкт за 3 дні та запропонуємо план з гарантією результату. Пишіть — розберемо вашу збірку безкоштовно.