как автоматизировать тестирование игры?

Я новичок в этой области тестирования. Я только что разработал базовую игру, используя движок Unity, но я хочу проверить его.

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

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

Для модульного тестированиявы тестируете внутреннюю работу игры, фактически не запуская ее. Вы можете сделать это для определенных модулей, у которых есть абстрагированные зависимости (например, логика, которая вычисляет Quest XP, которую вы получаете, основываясь на заданном наборе факторов; воспроизводится ли данный звук). В зависимости от того, насколько вы абстрагируете свою логику, вы можете протестировать больше, но конкретно для единства, это может быть сложнее, если учесть, как устроена игровая архитектура (например, наследование от monobehaviour). Тем не менее, применяя шаблоны ООП, такие как композиция, вы можете извлечь кусочки логики, которые можно протестировать детерминистическим способом (например, физикой), даже если иногда это может показаться немного экстремальным. Все зависит от того, сколько времени у вас есть, независимо от того, начали вы с проекта или нет, сколько у вас опыта и т. Д. В общем, я не имею В играх по сравнению с другими проектами, не относящимися к игровому программному обеспечению, было много юнит-тестирования. Этот вид тестирования довольно легко автоматизировать, поскольку вы предоставляете имитируемые модели поведения.

Для интеграционного тестирования вы взаимодействуете со «целой» игрой в определенный момент времени, когда все части работают. В зависимости от глубины вещей, которые вы хотите проверить, я вижу, что это может быть очень легко или просто невозможно.

Одной из идей было бы иметь сборку «интеграционного теста», в которой регистрируются все (большинство) выполняемые им действия (т. Е. Порождение монстра, воспроизведение звука, стартовый эффект, порождение частицы). После того, как он запускается в течение заданного времени, вы можете проверить журналы, чтобы увидеть, соответствует ли он заданному шаблону (это также зависит от того, насколько случайной является игра, на основе входных данных). Теперь это звучит просто, но вопрос заключается в следующем: как вы говорите игре делать нужные действия? Что подводит меня ко второй идее.

Другая идея состояла бы в том, чтобы иметь своего рода сервер в игре, опять же, для целей тестирования, который способен обрабатывать запросы (например, через REST API) и который воздействует на сущности. Запросы могут быть такими: перемещение влево, прыжок, поворот на X градусов, изменение области просмотра и т. Д. При таком подходе вы также можете выполнять «проверки» того, что игра работает, как ожидалось, либо проверяя состояние напрямую, либо проверяя виртуальный журнал событий, которые произошли. Этот подход используется другими инструментами UI-тестирования для мобильных телефонов (например, Xamarin Test Cloud)

Для контролирующей части, если ваша игра основана на сенсорном / браузерном подходе, вы можете вместо этого смоделировать действия через виртуальное сенсорное / вводное устройство, но это немного сложнее, в зависимости от сложности действий.

Другая идея, касающаяся визуального аспекта, состоит в том, чтобы сделать некоторые эталонные снимки экрана, изображения на начальном этапе и сравнить их после той же последовательности действий, которая произошла в новой сборке. Сравнение может иметь определенное отклонение, чтобы избежать незначительных изменений. Во время тестов вы можете регистрировать не соответствующие друг другу экраны и видеть разницу. Может случиться, что справочные экраны необходимо обновить из-за различных изменений. В этом случае игра может быть запущена снова с заданными действиями, и эталонные изображения будут обновлены. Это, вероятно, не очень хорошо будет работать с системами частиц или случайно генерируемыми сценами, если только вы не используете предыдущую идею для установки какого-либо начального числа, которое используется для генерации частиц.

Что касается звуков, это может быть немного сложнее, потому что это будет включать «прослушивание» устройства OUT (что не всегда возможно IIRC, так как это зависит от аппаратного обеспечения системы). Но если это возможно, вы можете сделать такое же сравнение на основе ссылок, как и с изображениями.

Я надеюсь, что это проливает некоторый свет на то, как можно автоматизировать тестирование игры.

Позже Правка: я просто вижу, что был еще один связанный вопрос, который может дать вам некоторые подсказки о том, как вы будете делать определенные моменты: Автоматическое тестирование игр