Насколько распространено автоматическое тестирование в разработке игр? [закрыто]

Используют ли разработчики геймеров для написания юнит-тестов и интеграционных тестов? Насколько распространено это среди разработчиков головоломок? А среди разработчиков MMORPG и FPS?

(У меня нет опыта в разработке игр, и я не задумываюсь над тем, чтобы работать с ней - это просто сомнение, которое пришло мне в голову. Поэтому нет необходимости пытаться убедить меня написать их, даже потому что я уже люблю писать автоматизированные тесты. )

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

Тем не менее, модульное тестирование может происходить при разработке игры, и если для него настроен код, это может принести большую пользу. Однако гораздо чаще можно написать автоматические тесты для игр, обычно в форме программы ИИ, которая может эффективно играть в игру с большей скоростью, чем обычный игрок. В этом вопросе об автоматическом тестировании есть несколько замечательных историй разработчиков . Этот вид автоматического тестирования потенциально лучше, так как модульное тестирование может не обнаружить ошибку в механизме рендеринга, но автоматический тест с большей вероятностью выявит такую ​​проблему.

В конце концов, все зависит от студии. В некоторых студиях будет проводиться какое-то автоматическое тестирование, в то время как другие могут просто нанять 20 старшеклассников летом, чтобы они часами играли в свою игру.

По моему опыту, это не очень часто.

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

Отчасти это связано с тем, что доминирующим языком в индустрии разработки игр является C ++, и это делает модульное тестирование немного более громоздким, чем другие языки. Структуры модульного тестирования существуют, но они не так просты в использовании, как аналогичные системы на более современных языках, которые могут использовать рефлексию и аналогичные приемы для ускорения обнаружения тестовых случаев.

Кроме того, это потому, что игры, как правило, не поддаются юнит-тестированию - большая часть логики зависит от полудетерминированных источников (например, графическое оборудование, тайминги ввода, частота кадров), большую часть результата трудно измерить (например, экранная графика, звуковые эффекты) и некоторые из них почти бессмысленны вне создания полного игрового контекста (например, сложный реактивный ИИ, физические симуляции). Есть исключения - многие, если вы усердно работаете над созданием кода таким образом - но в целом тестирование в играх обходится дороже, чем в большинстве других типов программного обеспечения, и поэтому соотношение цены и выгоды более сомнительно.

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

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

Проверка возможности завершения игры - это другое дело, и она не так сильно подпадает под юнит или интеграционное тестирование.

В целом автоматизировать тестирование пользовательского интерфейса (даже в обычных программах) сложнее, чем в обычной автоматизации. Таким образом, даже если вы можете написать модульные тесты для своих игр, тестирование реальной игры сложнее. Большинство компаний используют человеческие тестеры , которые работают в игру время и снова.

Например, вот статья, объясняющая, как они это делают в небольшой Game Studio (2 разработчика). Из того, что я прочитал, кажется, что их проверка не очень детальна (автоматизация запускает игру и регистрирует любые ошибки / утверждения).

Однако некоторые компании очень успешны с полуавтоматизацией (например, Microsoft Test Studios). То есть разработчики или SDET создают инструменты, которые значительно облегчают тестирование игры. Были обсуждения Gamefest, где они обсуждали, как они тестировали Crackdown, например или Fable. Например, они все еще используют тестеров, которые проверяют, что каждый объект находится там, где он должен быть, но они используют инструмент, который делает снимок этого местоположения, так что все, что делает человек, это визуально проверяет, что он там, без необходимости играть в игру.

Вот хороший разговор о том, какие инструменты они создают / используют для тестирования игр. Он называется «Test Lead Gems: выход из-за возрастающей сложности наших игр»

Держу пари, что код MMO и многопользовательского сервера, однако, немного чаще тестируется.

По крайней мере, автоматические регрессионные тесты были распространены. Я видел, что они реализованы как массовые проверки работоспособности во время запуска сервера, например, чтобы убедиться, что новый «облачный» сервер был настроен правильно, прежде чем он начнет принимать игроков; довольно хороший набор регрессии, созданный за 3-4 года, в этом случае работал примерно за 4 секунды, в то время как запуск виртуального хоста (из пустого образа ОС) занял почти 10 минут, так что оно того стоило. Мы провели те же тесты на «tinderbox» (системе непрерывной сборки) в нашем репозитории Subversion, чтобы проверить наличие некоторых раздражающих, довольно распространенных ошибок, которые нравились, чтобы вернуться обратно. В частности, многосерверная функциональность имела неприятную привычку пытаться создавать дубликаты объектов по мере их передачи: создание объектов, кэширование, и код прохождения сети был почти на 100% покрыт; мы продолжали думать, что подумали обо всем, что можно было бы протестировать, а затем обнаружили какой-то «забавный» новый передовой случай.

В нескольких ММО, над которыми я работал, мы также разрабатывали «заглушки» для первоначального модульного тестирования и обычно предоставляли «операторские» команды для специального модульного тестирования новых функций. Это позволило нам выполнить серверный код до того, как клиент был готов использовать его, и использовать «невозможные» ситуации (например, телепортирование игрока внутри стены), чтобы гарантировать, что обработчики восстановления ошибок будут работать хорошо. Включение новой функции в онлайн на сервере иногда может занять много дней меньше, чем поддержка клиента; и наоборот, нам иногда приходилось бы создавать «фиктивный» серверный метод для клиента, который возвращал бы ложные, но хорошо сформированные данные, если они опередили нас.

Тем не менее, развитие MMO в целом связано с гораздо большим количеством таких проблем, которые могут отражать окружающую среду. Когда я работал над встраиваемыми игровыми системами, «тестирование» было практически неслыханным для чего-либо, кроме некоторого многократно используемого кода виджета (например, текстовых редакторов).

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

Я участвовал в дискуссии за круглым столом об автоматизированном тестировании на GDC 2011 . IIRC, в комнате было около 60 человек. В какой-то момент модератор взял обзор охвата модульных тестов. Был один человек, который утверждал, что охват кода превышал 90%. Все остальные смеялись над мыслью о достижении 1% охвата. Если эта группа является хорошим представителем отрасли в целом, я бы сказал, что автоматизированное тестирование, как правило, мало что происходит, если вообще.

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