Існує кілька способів тестування гри, два найбільш використовувані: тестування блоків та інтеграції.
Для одиничного тестуванняви тестуєте внутрішню роботу гри, фактично не запускаючи її. Це можна зробити для конкретних модулів, у яких залежність абстрагується (наприклад, логіка, яка обчислює отриманий вами Quest XP, виходячи із заданого набору факторів; чи відтворюється поданий звук). Залежно від того, наскільки ви абстрагуєте свою логіку, ви можете перевірити більше, але для єдності конкретно це може бути складніше з огляду на те, як робиться архітектура ігор (наприклад, успадковування від моно-поведінки). Тим не менш, застосовуючи схеми OOP, як композиція, ви можете витягти біти логіки, які можна перевірити детермінованим способом (наприклад, фізика), навіть якщо іноді це можна розглядати як трохи екстремальне. Все залежить від того, скільки часу у вас є, почали ви з нуля з проектом чи ні, скільки у вас досвіду тощо. Загалом, у мене немає Ви бачили багато тестування в іграх в порівнянні з іншими програмними програмами, що не стосуються ігор. Цей вид тестування досить легко автоматизувати, оскільки ви надаєте глузливі поведінки, які ви імітуєте.
Для тестування інтеграції ви взаємодієте з цілою грою в даний момент часу, коли всі частини запущені. Залежно від глибини речей, які ви хочете перевірити, я бачу, що це може бути дуже просто, а відверто неможливо.
Однією з ідей було б скласти "тест на інтеграцію", який записує всі (більшість) дій, які він виконує (наприклад, нерестовий монстр, відтворення звуку, стартовий ефект, нерестовина). Після того, як він працює протягом певного часу, ви можете перевірити журнали, щоб побачити, чи відповідає він заданому шаблону (це також залежить від того, наскільки випадкова гра, виходячи з введених даних). Зараз це звучить просто, але питання полягає в тому, як ви наказали грі робити потрібні дії? Що підводить мене до другої ідеї.
Інша ідея полягала б у тому, щоб у грі знову був створений сервер для тестування, який може обробляти запити (наприклад, через REST API) і який діє на сутності. Запити можуть бути такими, як: рухатись вліво, стрибати, обертати X градусів, змінювати область перегляду тощо. При такому підході ви також можете робити "перевірки", що гра діє так, як очікувалося, або перевіряючи стан, або перевіряючи віртуальний журнал подій, що сталися. Цей підхід використовується іншими інструментами тестування інтерфейсу для мобільних пристроїв (наприклад, тестова хмара Xamarin)
Що стосується контрольної частини, якщо ваша гра заснована на сенсорному / браузерному режимі, ви можете замість цього моделювати дії через віртуальний пристрій сенсорного введення / введення, але це трохи складніше, залежно від складності дій.
Інша ідея, що стосується візуального аспекту, полягає в тому, щоб зробити кілька еталонних скріншотів, зображень під час початкової фази та порівняти їх після того, як відбулася та ж послідовність дій у новій збірці. Порівняння може мати специфічний припуск для відхилення для запобігання незначних змін. Під час тестів ви можете реєструвати екрани, які не відповідали, і бачити різницю. Може статися так, що опорні екрани потребують оновлення через різні зміни. У такому випадку гру можна буде запустити ще раз із заданими діями, а еталонні зображення оновити. Це, ймовірно, не дуже добре спрацює із системами частинок або випадковими породженими сценами, якщо ви не використовуєте попередню ідею для встановлення якогось насіння, яке використовується для отримання частинок.
Що стосується звуків, це може бути трохи важче, тому що це буде включати "прослуховування" пристрою OUT (що не завжди можливо IIRC, оскільки це залежить від апаратного забезпечення системи). Але якщо це можливо, ви можете зробити те саме порівняння на основі довідника, як і ви з зображеннями.
Я сподіваюся, що це проливає трохи світла на те, як ви могли автоматизувати тестування гри.
Пізніше Редагувати: Я просто бачу, що виникло ще одне пов’язане питання, яке може дати вам вказівки щодо того, як ви зробите певні біти: Автоматизоване тестування ігор