Несколько вещей, которые я бы сказал, важны:
Поощряйте модульное тестирование программиста
Это гарантирует, что некоторые глупые ошибки, если для них есть модульный тест, не будут повторяться, потому что модульный тест не пройдёт, если они это сделают. Это требует изменения методологии программирования, но, на мой взгляд, оно того стоит.
Автоматизируйте все, что вы можете тестировать
Помимо модульного тестирования, создайте набор автоматизированных функциональных и приемочных тестов, которые запускаются на каждой сборке, чтобы убедиться, что определенные сборки хороши. Если у вас есть скриптовые элементы управления, и ваша игра в целом соответствует, вы можете автоматически тестировать множество ошибок.
Создать многоуровневый план тестирования
Убедитесь, что у ваших тестеров есть план тестирования, который проверяет наиболее важные ошибки. Это должно быть многоуровневым:
- Smoke Test: тестирует, что игра не падает в большинстве случаев.
- Обычный тест: тестирует больше необычных случаев.
- Тест на замачивание: Бегите как можно глубже, устраняя как можно больше общих ошибок. Также убедитесь, что игра может продолжаться очень долго (дни) без сбоев.
Создайте этот план тестирования и следуйте ему при каждой сборке.
-debugFlags
grep, убедитесь, что мы установилиx
количество флагов». +1Несколько хороших ответов здесь на стороне программирования. Я добавлю один, который больше ориентирован на дизайн.
Пусть ваши разработчики систем напишут передовые планы тестирования для тестировщиков
Если они знают, что делают, то человек, стоящий за разработкой системы или написанием сценариев внутриигровой последовательности, с большой вероятностью узнает о крайних случаях этой системы и о том, где она может выйти из строя. Они также должны иметь представление о том, где система взаимодействует с другими. Если они напишут план тестирования или обсудят с тестировщиками, где что-то может пойти не так, это может сэкономить каждому время.
источник
Вы должны исследовать так называемое тестирование на обезьян. Он может поймать много ошибок этого типа:
https://secure.wikimedia.org/wikipedia/en/wiki/Monkey_test
Вам также необходимо организовать тестирование пользовательского опыта с помощью «тестеров Kleenex», тестеров, которые видят вашу игру впервые и которые вы никогда больше не будете использовать. Это немного дорого и сложно организовать, но оно того стоит. Если вы это сделаете, снимите каждый тест с 3-х камер: одна на экране, одна на контроллерах и одна на лице тестера, чтобы обнаружить разочарование.
источник
Отличный вопрос, каждый ответ в этой теме - отличный ответ. Одна вещь, чтобы добавить:
По моему опыту (30 лет разработки программного обеспечения): приложения и игры более надежны, если хотя бы один из участников тестовой группы является опытным тестировщиком горилл , мастерским в специальном тестировании, злоупотреблении приложениями и преднамеренном использовании игр - неправильный способ найти ошибки, описанные оригинальным постером. У горилл-тестеров есть необычное умение - когда вы найдете хороший, оставьте его в своей команде.
Пример эффективного тестирования горилл см .: www.youtube.com/watch?v=8C-e96m4730;)
Подводя итоги ответов в этой теме: эффективные стратегии качества программного обеспечения являются многогранными , объединяя несколько подходов для достижения высокого уровня уверенности в функциональном качестве и надежности вашей игры.
источник
Интересный трюк, о котором я слышал от друга, чтобы проверить графику; во время заведомо удачного прогона уровня записывает статистику производительности с графического процессора через регулярные промежутки времени (например, на экране). Затем вы можете воспроизвести этот маршрут, и если числа меняются вне заданного допуска, это может означать, что что-то отображается неправильно.
источник
Одна простая и простая вещь, которая очень помогает, особенно при стресс-тестировании и тестировании сети. Сделайте так, чтобы ваш ИИ играл против другого ИИ. Если вы можете оставить свою игру в одиночестве, играя в одиночку, или небольшую группу ИИ по сети на выходные, вы можете многому научиться.
Конечно, войдите все.
источник