Автоматизированное тестирование игр [закрыто]

Существуют ли методы автоматического тестирования игр?

Особый опыт оценивается с соответствующей информацией о проекте, такой как платформа и тип игры, если это помогает с разъяснением.

52 голоса | спросил slicedlime 16 J000000Friday10 2010, 11:35:27

7 ответов


72

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

Я закончил тем, что подтасовал некоторые базовые немые ИИ («глупыми», я имею в виду «абсолютно идиотские» - они случайным образом выбирали «движение к вражескому танку», «уезжать от вражеского танка» и «водить случайное направление ", при случайном стрельбе по основному оружию) и игра в игру с максимальной частотой кадров при записи нажатия клавиш. Я получил 10-15 раз в реальном времени. Код был жестко заявлен, поэтому, если что-то пошло не так, оно будет выгружать весь журнал нажатия клавиш на диск вместе с сообщением об ошибке и начальным случайным семенем. Затем я мог перейти и воспроизвести журнал нажатия клавиш, чтобы точно воспроизвести состояние или просто отладить отчет об ошибке.

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

Это было бесценно, и я от всей души рекомендую его.

ответил ZorbaTHut 16 J000000Friday10 2010, 11:55:31
31

Для MMO, над которой я работал (100 разработчиков, ПК сфокусирован), мы попытались добавить огромное разнообразие автоматизированных тестов с переменным успехом. Вот что сработало:

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

Что не работает:

  • Мы попытались добавить к автоматизированному строителю очень специфичные боевые автоматизированные тесты, но это в принципе никогда не работало. Он будет работать примерно через 3 дня после того, как он будет реализован, пока дизайнер или художник ничего не изменит, и тест не сработает, отбросив аварийные сигналы сбоя сборки. 90% времени это не была настоящая проблема. Эти тесты были слишком хрупкими, и на самом деле тестирование определенного игрового процесса на определенной карте со специфическими полномочиями может быть недостижимым.
  • Мы попытались реализовать автоматизированный тест производительности, который бы сравнил производительность клиента (средний FPS и т. д.) с записанной производительностью неделю назад. Это также было довольно хрупким, поскольку демонстрации, которые мы использовали для этого, имели тенденцию к гниению довольно часто, и было сложно установить, произошло ли замедление в результате фактической потери производительности или какого-либо побочного эффекта процесса тестирования.
ответил Ben Zeigler 17 J000000Saturday10 2010, 08:58:09
18

Работа над 4-кратной стратегической игрой с 3D-боем (думаю, Homeworld встречается с мастерами Ориона), которая, к сожалению, никогда не видела свет дня, когда у компании закончилось финансирование.

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

Мы могли бы отключить 3D-бой (упрощенный до случайного результата), и мы оставили сам механизм разработки AI. Это нашло многочисленные ошибки и проблемы. Не только показывать ошибки проб, но и ошибки стратегии, в которых (например) стратегии ИИ зашли бы в тупик и потратили бы 1000 секунд оборота, не делая «правильную вещь». Этих ошибок было трудно определить просто «играть в игру».

ответил PhillC 16 J000000Friday10 2010, 13:24:28
13

В шутер от первого лица, над которым я работал (Descent 3 - linux /mac /windows, ~ 30 человек в команде в 1999 году), возможность демонстрации /воспроизведения демо оказалась чрезвычайно полезной. Я сделал вариант, в котором вы могли бы воспроизводить демо так быстро, как игра могла отображать кадры, и это стало отличным способом проверить производительность после смены вещей.

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

ответил kevin42 17 J000000Saturday10 2010, 14:31:27
8

У нас был шутер openworld (x360, PS3, ПК), который использовал быстрый smoketest на сервере сборки - он загрузил игру, прошел через переднюю часть, побежал [аватар] вперед, сбросил снимок экрана и вышел. Если cctray обнаружил чистый выход, сборка была успешной.

Мы запускали его примерно за последний год проекта и с размером команды ~ 100 разработчиков.

Это было эффективно при ловле ошибок showstopping, но было легко создать сборку, которая прошла smoketest, но не удалась большинство «реальных» уровней, или не работала в многопользовательском режиме, или обескураживала AI, поэтому она не была идеальной. Это определенно стоило делать.

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

ответил tenpn 16 J000000Friday10 2010, 11:51:42
6

Мой опыт работы с Automated Testing во время разработки Crysis 2 доступен здесь: http://yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html

Резюме:

  • Автоматизированное тестирование улучшило стабильность результатов, повысив производительность как для создателей контента, так и для инженеров
  • Автоматическое тестирование - эффективный инструмент для улучшения качества кода и снижения шансов на сверхурочную работу.
  • Игровая индустрия в целом очень реакционная в целом, автоматическое тестирование соответствует нескольким иррациональным аргументам против
  • Не называйте это тестированием, назовите это чем-то другим, почти всем остальным (посмотрите на поведение, управляемое развитием)
  • Быть гибким, писать хорошие тесты сложно и требовать навыков, которые не широко доступны в игровой индустрии.
ответил Francesco Carucci 13 PMpSat, 13 Apr 2013 19:31:19 +040031Saturday 2013, 19:31:19
1

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

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

Это довольно сложно, очевидно. Тактика, которая работает в других приложениях (fuzzing, expected-pass /expected-fail и т. Д.), Не так хорошо работает здесь. В скриптовых системах кажется, что создание тестового набора сценариев для имитации игрока - это путь (см. Ответ JZig). Но тестирование специально для вещей, которые игрок может встретить, прямо поражает меня как лучшее место, чтобы сосредоточить свое время как на человеческом, так и на автоматическом тестировании.

ответил Ed Ropple 18 J000000Sunday10 2010, 02:17:09

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132