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

54

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

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

slicedlime
источник

Ответы:

74

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

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

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

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

ZorbaTHut
источник
1
Действительно гладко! Да, кейлог это чистая победа.
Дэвид Макгроу
1
Я в замешательстве: «подтасовывать некоторые простые глупые ИИ» и «записывать нажатия клавиш» - кто такие нажатия клавиш? Я думал, что Ты позволил Своему ИИ играть самому без людей? Вы позволили своему ИИ играть в игру, имитируя нажатия клавиш, а не вызывая функции API? Теперь это было бы замечательно!
Дейв О.
4
@ Дэйв Да, я признаю, что это может сбить с толку. ИИ были спроектированы так, чтобы обеспечивать весь их вывод через симулированные контроллеры. Они взяли состояние игры в качестве входных данных, но никак не изменили состояние игры. Вероятно, это было бы ужасной идеей с пользовательским интерфейсом мыши, но весь интерфейс был сделан с геймпадами, поэтому он был немного уродливым, но функциональным. Я записал виртуальные нажатия клавиш ИИ, и, кроме того, тот же код записал реальные нажатия клавиш при тестировании с друзьями.
ZorbaTHut
32

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

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

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

  • Мы пытались добавить некоторые очень специфические боевые автоматизированные тесты для автоматизированного сборщика, но это в основном никогда не работало. Он будет работать в течение примерно 3 дней после реализации, пока дизайнер или художник не изменят что-либо, и тест не пройдёт, сбросив аварийные сигналы при сборке. 90% времени это не было настоящей проблемой. Эти тесты были слишком хрупкими, и на самом деле тестирование определенного геймплея на конкретной карте с определенными способностями может быть невозможным
  • Мы попытались внедрить автоматизированный тест производительности, который сравнивал бы производительность клиента (средний FPS и т. Д.) С записанной производительностью недели назад. Это также было довольно хрупким, так как демонстрации, которые мы использовали для этого, имели тенденцию гнить довольно часто, и было трудно определить, было ли замедление вызвано фактической потерей производительности или некоторым побочным эффектом процесса тестирования.
Бен Зейглер
источник
18

Работа над стратегической игрой 4х с трехмерным боем (думаю, что Homeworld встречается с Мастерами Ориона), которая, к сожалению, так и не вышла на свет, поскольку у компании кончились средства.

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

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

PhillC
источник
Хм, я бы не подумал об этом, как об автоматизированном тестировании, но, думаю, ты прав. Я делал то же самое в течение пары лет, просто никогда не думал об этом таким образом.
mmyers
13

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

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

kevin42
источник
8

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

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

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

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

tenpn
источник
6

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

Резюме:

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

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

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

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

Эд Роппл
источник
9
Но игроки никогда не делают то, что вы ожидаете от здравомыслящего человека. Вот почему вы не видите таких вещей, как глюки лифта в Call of Duty, до выхода. Потому что тысячи парней все делают вещи, которые разработчики и тестировщики никогда не думали попробовать. Как только кто-то создаст идеальный симулятор одержимо-навязчивого 16-летнего геймера, мы достигнем сингулярности разработки игры :)
Кейси Вагнер