Лучший способ проверить простые случаи в играх

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

Несколько вещей, которые я бы сказал, важны:

Поощряйте модульное тестирование программиста

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

Автоматизируйте все, что вы можете тестировать

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

Создать многоуровневый план тестирования

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

• Smoke Test: тестирует, что игра не падает в большинстве случаев.
• Обычный тест: тестирует больше необычных случаев.
• Тест на замачивание: Бегите как можно глубже, устраняя как можно больше общих ошибок. Также убедитесь, что игра может продолжаться очень долго (дни) без сбоев.

Создайте этот план тестирования и следуйте ему при каждой сборке.

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

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

Эта техника приписывается Мэтью Джеку, который реализовал ее в Crysis.

Несколько хороших ответов здесь на стороне программирования. Я добавлю один, который больше ориентирован на дизайн.

Пусть ваши разработчики систем напишут передовые планы тестирования для тестировщиков

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

Вы должны исследовать так называемое тестирование на обезьян. Он может поймать много ошибок этого типа:

https://secure.wikimedia.org/wikipedia/en/wiki/Monkey_test

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

Отличный вопрос, каждый ответ в этой теме - отличный ответ. Одна вещь, чтобы добавить:

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

Пример эффективного тестирования горилл см .: www.youtube.com/watch?v=8C-e96m4730;)

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

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

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

Конечно, войдите все.