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

35

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

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

brandizzi
источник
3
Насколько распространены автоматизированные вопросы на Stack Exchange?
MichaelHouse
2
Возможный дубликат Автоматического тестирования игр
bummzack
Тот факт, что они не распространены в игровой индустрии, не означает, что вам не следует продолжать их писать. Какую проблему вы пытаетесь решить с этим вопросом в любом случае?
Тетрад
@Tetrad Просто прочитайте вопрос. Второй абзац объясняет все.
brandizzi

Ответы:

37

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

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

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

thedaian
источник
17
+1 только потому, что мы все хотели бы быть одним из этих детей. :(
Бобби,
13
@ Бобби Говори за себя. Быть вынужденным играть в глючные и незавершенные игры снова и снова - ужасная мысль, даже если вам не в конечном итоге поручено тестировать что-то похожее на последнюю игру Барни Динозавра.
Дэн Нили
9
@Bobby, я был QA около 3-4 лет, это отличная работа, если тебе нравится ломать программное обеспечение и работать в этой отрасли, но не делай этого, потому что «ты любишь играть в игры весь день» :)
JuniorDeveloper1208
9
Я был в QA около шести месяцев. Когда я подошел к своей машине в конце моего второго рабочего дня, я прекрасно помню, как думал про себя: «Я вижу, что в конечном итоге я ненавижу эту работу». И в конце моего третьего дня: «Я действительно ненавижу эту работу». Хорошие тестировщики, которые могут справиться с требованиями работы, на вес золота, и это преступление, что они не ценятся и не получают более высокую компенсацию, чем они.
Тревор Пауэлл
16

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

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

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

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

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

Kylotan
источник
5
Замечательно, что результат трудно измерить. Легко автоматически проверить, что класс выплевывает, скажем, синтаксически правильный JSON, но единственный способ убедиться, что ваши тряпичные куклы не выходят из-под контроля при выстреле, - это действительно играть в игру. Хуже всего то, что из-за этого действительно трудно заметить побочные эффекты (т.е. вы исправляете ошибку, но теперь какая-то другая удаленная часть игры ведет себя по-другому.)
jhocking
8

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

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

Hand-E-Food
источник
8

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

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

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

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

krolth
источник
4

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

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

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

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

BRPocock
источник
3

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

OKeez
источник
3

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

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

Михаил Кристофик
источник
Я удивлен, что эта цифра настолько низкая (хотя я бы не ожидал, что более трети игровых разработчиков будут использовать такие тесты, как я уже сказал в своем ответе.) Чтобы добавить некоторые личные неподтвержденные данные, серверное программное обеспечение, над которым я работаю имеет более 70% покрытия модульных тестов. Вероятно, я мог бы довести его до 85% с небольшим количеством тяжелой работы, но последние 15% были бы связаны с различными приспособлениями для внедрения зависимостей, которые я не хотел бы делать. Для сравнения, клиентское программное обеспечение практически невозможно для модульного тестирования, поэтому мы сосредоточены на ручном тестировании.
Kylotan
В проекте Lua, благодаря легкости озвучивания и насмешек, мне удалось сохранить 100% охват во время разработки. Тем не менее, я заметил, что многие тесты были неинтересны (например, тестирование точного размещения пользовательского интерфейса или что-то, что должно быть управляемо данными, но на самом деле выполнялось в коде). Чтобы сделать вещи чище, я разделил код между «движком» (многоразовым) и специфичным для игры, и убедился, что он покрывает весь код движка, в то время как охват игрового кода колеблется (я все еще тестирую низкоуровневые классы, так как легко сделать, и пользовательскую физику, как легко испортить, но не высокоуровневый интерфейс / рендеринг больше).
hsandt