Стратегія тестування ігор

Я успадкував веб-навчальну гру. За останній рік я працював над стабілізацією коду та додаванням нових функцій. Більша частина логіки полягає в передовій, тому тести на задні модулі, корисні, охоплюють невеликий відсоток коду.

Гра дійшла до того, що вона починає складнішати. Для кожної гри є два різних режими, і гра поводиться по-різному в залежності від режиму. Існують також різні прапори, які впливають на гру.

Я розробник додатків вже більше 10 років, і це мене здивувало. У корпоративному світі алгоритм завжди функціонує однаково. Я напишу одиничний тест для алгоритму, я очікую значення 42, і воно помилиться, якщо я не отримаю цього значення.

Що стосується ігор, я втрачаю. Як їх перевірити? У мене є тестери. Я можу витратити час на тестування одиниць.

Тестери ... ненадійні. Вони не найкращі у вирішенні проблем, і я не дав їм найкращого напрямку. Якщо не витрачати тонна часу на кожен цикл випуску, тестуючи кожну перестановку та комбінацію гри, як я повинен використовувати їх як ресурс?

Одиничні тести здаються обмеженими. Оскільки більша частина логіки - це javascript (і я успадкував код спагетті), я можу використовувати фронтальний набір, наприклад, огірок або селен, щоб переконатися, що деякі функції працюють.

Це найкраща стратегія? Як ігрові компанії тестують ігри?

Я прочитав питання " Тестова розробка для складних ігор " (серед інших на сайті), але воно не стосується того, що я шукаю. Я прошу стратегії, а не конкретні приклади тестування.

У корпоративному світі алгоритм завжди функціонує однаково. Я напишу одиничний тест для алгоритму, я очікую значення 42, і воно помилиться, якщо я не отримаю цього значення.

Це не дуже відрізняється в іграх. Наявність двох режимів і декількох прапорів у грі, над якою ви працюєте, нічого не змінює: якщо ви будете приймати певний режим із певним набором прапорів, ви все одно отримаєте те саме значення знову і знову під час тестування частини вихідний код.

З занадто великою кількістю режимів і прапорів, гра може швидко стати дуже важкою для перевірки через кількість можливих варіантів. Для того, щоб зменшити ризик рано наштовхнутися на цю складність, слід:

• Суворо знущаються / заїкаються . Тримайте перевірені деталі невеликими та знущайтеся над усім, на що вони покладаються.

  Якщо вони покладаються на час, знущаються над тимчасовим об’єктом, щоб завжди давати конкретний результат або набір конкретних результатів, незалежно від фактичного часу.

  Якщо вони покладаються на них random(), знущайтеся над цим, щоб забезпечити постійне значення кожного разу.

• Рефактор . Якщо тести починають надмірно складно або якщо ви бачите, що для тестування класу потрібно дванадцять аргументів після того, як ви здійснили введення Dependency Injection, тоді як для цього потрібно лише два, вам потрібно перефактурувати код.

• Запитуйте фактичні правила роботи програми. Я перестала рахувати кількість проектів, які було майже неможливо перевірити через кількість різних варіацій, необхідних функціональним вимогам, які ніхто не потребував і не розумів - навіть зацікавлені сторони.

  Коли невеликому веб-сайту електронної комерції потрібні десять сторінок для пояснення функціональних вимог, що використовуються для визначення того, як розраховуються ціни на відвантаження, не слід починати з написання тестів чи коду, а натомість слід повертатися до зацікавлених сторін та працювати з ними для створення нормальні вимоги.

Нарешті, автоматизуйте кожен тест . Тестери потрібні для виявлення ситуацій, коли програма не працює. Використання тестерів для повторного і повторного виконання однієї і тієї ж дії на кожній редакції контрпродуктивне і неповажне для тестерів: тестування регресії повинно проводитися машинами, а не людьми. Люди, з іншого боку, набагато краще знаходять можливих помилок. "Що робити, якщо я ..." - це одна з методик, якими вони можуть користуватися ("Що робити, якщо я введіть кілька мегабайт бінарних даних, що містять кілька \ x00, у поле, яке запитує мій вік, і подивіться, що буде?"), але можна використовувати і більш формальні підходи.