Вы находитесь на странице: 1из 424

15.07.2021 Game Testing All in One Чарльз П.

ll in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Страница 1

Тестирование игр все в одном


Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл
Курс Технология © 2005 (520 страниц)

ISBN: 1592003737

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

Оглавление
Тестирование игр все в одном
Вступление
Часть I. О тестировании игр

Глава 1 - Два правила тестирования игры


Глава 2 - Быть тестером игр
Глава 3 - Почему важно тестирование
Часть II - Создание игр

Глава 4 - Игровая команда


Глава 5 - Цикл производства игры
Часть III - Основы тестирования

Глава 6 - Качество программного обеспечения


Глава 7 - Фазы испытаний

Глава 8 - Процесс тестирования


Глава 9 - Проверка цифрами
Часть IV - Методы тестирования

Глава 10 - Комбинаторное тестирование


Глава 11 - Блок-схемы испытаний
Глава 12 - Тестирование чистых помещений
Глава 13 - Тестовые деревья
Глава 14 - Игровое тестирование и специальное тестирование
Часть V - Более эффективное тестирование

Глава 15 - Триггеры дефекта

Глава 16 - Автоматизация игрового тестирования


Глава 17 - Тестирование захвата / воспроизведения
Часть VI - Приложения

Приложение А. Ответы к упражнениям


Приложение B - Документы жизненного цикла проекта
Приложение C - Шаблоны комбинаторных таблиц
Приложение D - Шаблоны блок-схем тестирования (TFD)
Приложение E - Пример набора тестов: Контрольный список построения RTS
Приложение F. Что на компакт-диске

Индекс
список рисунков
Список таблиц
Список боковых панелей

Содержимое компакт-диска

Страница 2

https://translate.googleusercontent.com/translate_f 1/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Задняя обложка
Game Testing All in One показывает, как применять методологии инженера-тестировщика программного обеспечения в игровой индустрии. Это
исследует несколько игровых жанров, детализируя цикл продукта и тестируя основы, специфичные для каждого из них. Владелец
методы тестирования, когда вы работаете с набором руководств по четырем методикам создания тестов для вашей игры.
Узнайте, как быстро создавать полезные тестовые документы, собирать важные данные и анализировать измерения. Игра
«Все в одном» описывает роли и обязанности тестировщика игр, предлагая более подробный анализ
обязанности каждого члена игровой команды. Вы даже получите советы по поиску работы в отрасли в качестве
тестер игр.

Об авторах

Чарльз П. Шульц - операционный менеджер подразделения Motorola Global Software Group, занимающийся тестированием программного обеспечения.
и мобильные игры. На его счету более 20 технических публикаций, и он выступал в отрасли.
конференции в области персональной робототехники, качества программного обеспечения и тестирования программного обеспечения. Чарльз также разработал
и преподавал компьютерные классы на разных уровнях, начиная от детских программ в Музее науки Майами.
до окончания университетских курсов.

Роберт Брайант в настоящее время является директором студии в издательстве видеоигр Crave Entertainment, где он также работал.
в качестве QA-менеджера и исполнительного продюсера таких игр, как World Championship Poker, Pinball Hall of Fame, Future
Тактика: Восстание, Моджо !, Tokyo Xtreme Racer 3 и Intellivision Lives !. Свою игровую карьеру он начал в
интерактивное подразделение Mattel, Inc., где он был ведущим тестировщиком десятков проектов и соавтором Ника Клик
Цифровая камера и компакт-диск. Он часто говорит о методах тестирования игр и управлении ими.
Он имеет степень бакалавра наук Университета Вашингтона и Ли и степень магистра иностранных дел Университета Южной Калифорнии.

Тим Лэнгделл, ветеран игровой индустрии, работает полный рабочий день в инженерной школе Университета Калифорнии в Витерби.
Программа информационных технологий, где он возглавляет подкомитет по игровой учебной программе и преподает игровой дизайн.
и тестирование игры. Тим также является председателем компании EDGE Games, которую он основал в 1979 году, - одного из ведущих игровых брендов.
хорошо известен инновационными играми, игровыми журналами и игровым оборудованием. Тим произвел более 180
игры (включая Гарфилд, Каратель, Фэрлайт и культовый классический хит 1980-х Брайан Кровавый Топор) и написанные
несколько книг по программированию компьютерных игр, в том числе The Spectrum Handbook . Он новатор игр
образование: в 1992 году он разработал первый учебный курс по интерактивным развлечениям в киношколе USC, где
он преподавал несколько лет. Тим является соучредителем Академии интерактивных искусств и наук, является членом IGDA,
член Гильдии писателей Америки, а также член BAFTA и BAFTA / LA (где он работал на
Совет директоров).

Стр. 3

Тестирование игр все в одном


ЧАРЛЬЗ П. ШУЛЬЦ
РОБЕРТ БРАЙАНТ
ТИМ ЛАНГДЕЛЛ, PH.D.

© 2005 г., компания Thomson Course Technology, PTR.

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

https://translate.googleusercontent.com/translate_f 2/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
электронные или механические, включая ксерокопирование, запись или хранение или поиск любой информации
системе без письменного разрешения Thomson Course Technology PTR, за исключением включения
краткие цитаты в обзоре.

Логотипы Premier Press и Thomson Course Technology PTR и соответствующий товарный знак являются товарными знаками.
Thomson Course Technology PTR и не может использоваться без письменного разрешения.

Все остальные товарные знаки являются собственностью соответствующих владельцев.

Важный: Thomson Course Technology PTR не может предоставлять поддержку программного обеспечения. Пожалуйста, свяжитесь с
линия технической поддержки соответствующего производителя программного обеспечения или веб-сайт для
помощь.

Thomson Course Technology PTR и авторы в этой книге пытались различать


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

Информация, содержащаяся в этой книге, была получена компанией Thomson Course Technology PTR из источников.
считается надежным. Однако из-за возможности человеческой или механической ошибки из наших источников,
Thomson Course Technology PTR или другие, Издатель не гарантирует точность, адекватность,
или полноту любой информации и не несет ответственности за какие-либо ошибки или упущения или результаты
полученные в результате использования такой информации. Читателям следует особенно помнить о том, что в Интернете
постоянно меняющаяся сущность. Некоторые факты могли измениться с тех пор, как эта книга была напечатана.

Образовательные учреждения, компании и организации, заинтересованные в получении нескольких копий или лицензировании этой книги.
следует связаться с издателем для получения информации о скидке за количество. Учебные пособия, компакт-диски и части
этой книги также доступны индивидуально или могут быть адаптированы для конкретных нужд.
ISBN: 1-59200-373-7

Номер карточки в каталоге Библиотеки Конгресса: 2004090735

Отпечатано в Соединенных Штатах Америки.

04 05 06 07 08 ЧД 10 9 8 7 6 5 4 3 2 1

Издатель и генеральный менеджер: Стейси Л. Хике

Заместитель директора по маркетингу: Сара О'Доннелл

Менеджер по маркетингу: Хизер Херли

Стр. 4

Менеджер по редакционным услугам: Хизер Талбот

Редактор по приобретениям: Митци Кунц

Старший редактор: Марк Гарви

Координатор по маркетингу: Джордан Кейси

Редактор по развитию: Дэйв Эстл

Редакторы проекта: Шон Медлок и Дженни Дэвидсон

Технический обозреватель: Роберт Брайант

Координатор редакционных услуг PTR: Элизабет Фёрбиш

Редактор: Ким Кофер

Технология внутренней планировки: Шон Морнингстар

Художник по обложке: Майк Танамачи

Производитель CD-ROM: Брэндон Пентикафф

Индексатор: Шэрон Шок

Корректор: Кезия Эндсли

Thomson Course Technology PTR,


подразделение Thomson Course Technology
Томсон Плейс, 25
Бостон, Массачусетс 02210
http://www.courseptr.com

Моим маме, отцу и бабушке за принесенные ими жертвы.

—Чарльз Шульц

Моей жене Лизе, терпение которой безгранично.

https://translate.googleusercontent.com/translate_f 3/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
—Роберт Брайант
Для Чери, Мелиссы, Себастьяна, Сибил, Теда и Дженни.

—Тим Лэнгделл

БЛАГОДАРНОСТИ

Чарльз Шульц

Для начала я должен отметить работу сотрудников курса PTR. Вы бы не читали мои слова, если бы
Митци Кунц не нашла времени поговорить со мной на GDC 2004 и впоследствии дала мне возможность
Автор этой моей первой книги. Особого упоминания заслуживают также Дженни Дэвидсон и Брэндон Пентикафф.
полировать мою работу и принимать участие в любое время дня и ночи.

Большое спасибо Дэйву Эстлу за его отзывы, поддержку и за то, что он предоставил дом для книги.
Веб-страница на testbook.gamedev.net .

В моем сердце есть особое место для подчиненных Шульца - людей, которые работали на меня над
в течение многих лет в Motorola претворял в жизнь свои идеи по тестированию. Я ценю все трудные
работу и навыки, которые они применили под моим руководством. Их труд и их откровенные отзывы сделали
Методы тестирования, описанные в этой книге, более эффективны и просты в использовании.

Стр. 5

Я также хотел бы поблагодарить моих друзей-фанатиков игр Джеймса Дусека, Дэнни Санчеса и Теда О'Хара. Как и я
во время написания этой книги они выступали в качестве резонатора моих идей, записывали со мной многопользовательское время и
предоставил мне попробовать новые игры.

Моя работа в Motorola остается увлекательной и сложной благодаря усилиям Арни Питтлера и
Жак Микель. Я ценю их веру в мои способности и новые задачи, которые они продолжают ставить
меня.

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

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

Роберт Брайант

Что касается моей небольшой части, я хотел бы посвятить эту книгу Дону ДеЛусии, который научил меня, что такое ошибка, и Рэю
Бойлан, который научил меня бороться, чтобы исправить это. Также Марку Бёрку за то, что он выбрал меня из хора,
а также Джону Бладворту и Туану Тринху, у которых я продолжаю учиться каждый день. Наконец, моей жене Лизе,
чье терпение безгранично.

Тим Лэнгделл

Мой вклад в эту книгу не мог бы быть написан без любезной поддержки и помощи
несколько человек. Я хочу поблагодарить Энтони Боркеса, директора программы информационных технологий USC.
за его любезную поддержку. Также спасибо всем моим коллегам по отрасли, некоторых из которых я называю здесь: Джон
Высота Атари; Майкл Гилмартин, руководитель отдела тестирования игр Blizzard Entertainment; Майкл Гонсалес, руководитель
тестирования игр в Universal Vivendi Games; Шеннон Стадстилл из Sony; Бинг Гордон, Стив Андерсон,
и Нил Янг из Electronic Arts; и Уилл Райт из Maxis. И последнее, но не менее важное: моя работа не будет
возможно без невероятной поддержки моей жены Шери и моих неизменно удивительных детей
Себастьян и Мелисса.

ОБ АВТОРАХ

ЧАРЛЬЗ П. ШУЛЬТЦ ( CHARLES P. SCHULTZ ) - операционный менеджер подразделения Motorola Global Software Group, работающий над
тестирование программного обеспечения и мобильные игры. На его счету более 20 технических публикаций и
выступал на отраслевых конференциях в области персональной робототехники, качества программного обеспечения и тестирования программного обеспечения.
Чарльз также разработал и вел компьютерные классы на разных уровнях, начиная от детских
программы в Музее науки Майами, чтобы закончить университетские курсы.

РОБЕРТ БРАЙАНТ в настоящее время является директором студии в издательстве видеоигр Crave Entertainment, где он
также работал менеджером по обеспечению качества и исполнительным продюсером таких игр, как World Championship Poker ,
Зал славы пинбола , Future Tactics: Восстание , Mojo! , Tokyo Xtreme Racer 3 и Intellivision Lives! .
Он начал свою игровую карьеру в интерактивном подразделении Mattel, Inc., где он был ведущим тестером десятков
проектов и совместно разработан Nick Click Digital Camera и CD-ROM . Он часто выступает на
тематика методов и управления игровым тестированием. Он имеет степень бакалавра Вашингтонского университета и Университета Ли.
и МИД Университета Южной Калифорнии.

ТИМ ЛАНГДЕЛЛ , ветеран игровой индустрии, работает полный рабочий день в Школе Витерби Университета Южной Калифорнии.
Инженерная программа информационных технологий, где он возглавляет подкомитет по игровой учебной программе,
и обучает игровому дизайну и тестированию игр. Тим также является председателем компании EDGE Games, которую он основал в
1979 - один из ведущих игровых брендов, известный своими инновационными играми, игровыми журналами и играми.
аппаратное обеспечение. Тим написал более 180 игр (в том числе Garfield , The Punisher , Fairlight и
хит культового классика 1980-х Брайана Бладакси ) и написал несколько книг по программированию компьютерных игр,
включая Справочник по спектру . Он является новатором в области игрового образования: в 1992 году он изобрел первый

https://translate.googleusercontent.com/translate_f 4/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
учебный курс по интерактивным развлечениям в киношколе USC, где он преподавал в течение нескольких лет.
Тим является соучредителем Академии интерактивных искусств и наук, является членом IGDA, членом
Гильдия писателей Америки, член как BAFTA, так и BAFTA / LA (где он работал в совете директоров

Стр. 6

директоров).

Стр.7

https://translate.googleusercontent.com/translate_f 5/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

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

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

Как устроена книга


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

Часть I «О тестировании игр» знакомит читателя с тестированием игр с точки зрения культуры, философии и
вклад тестирования в финальный выпуск игры, который все (надеюсь!) бросятся покупать. Я упал
идет хорошо, пользователи дадут вам знать.

Часть II «Создание игр» показывает, какой вклад вносит человек в общий игровой проект. Это включает в себя
различные роли и обязанности, которые требуются от тестировщиков на разных этапах
разработка и производство игрового программного обеспечения.

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

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

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

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

Стр. 8

Приложения содержат ответы на вопросы главы, подробности о содержимом компакт-диска и дополнительные


информация о методах тестирования, описанных в Части IV .

https://translate.googleusercontent.com/translate_f 6/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.9

Кому следует прочитать эту книгу?


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

Если вы уже являетесь опытным тестером игр, я рекомендую вам прочитать главу 1, а затем бегло просмотреть
Главы 2 и 3 и всю Часть II, прежде чем сосредоточить ваше внимание на частях с III по V. Затем идите и
примените то, что вы узнали из частей IV и V, в своей реальной работе. Если вы являетесь испытателем, примените содержимое
в части III к вашей работе, и получить ваши тестеры начать использовать то , что в частях IV и V в ваших проектах.

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

Если вы хотите пробиться в игровую индустрию в качестве тестировщика, у вас есть над чем поработать. Читать
все, что написано в книге, выполняйте все упражнения, а пока вы ищете работу, практикуйте техники в частях
IV и V . Вы можете сделать это как бета-тестер (см. Особенно главы 4 и 14 ) или просто выбрав некоторые из
ваши любимые игры, чтобы протестировать их самостоятельно.

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

Роль Глава 1 Глава 2 Глава 3 Часть II Часть III. Часть IV. Часть V

Тестер игр р S S S р А А

https://translate.googleusercontent.com/translate_f 7/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Другой тестер р р S р р А А
Тестер будущих игр р р р р р А А

Руководитель игрового тестирования


р S S S А р р

Game Project Mgr. р р р S р р р

R = читать и делать упражнения

S = Skip or Skim, необязательно выполнение упражнений

A = Подайте заявку на работу после прочтения и выполнения упражнений

Стр.10

Использование этой книги

CD
Сопутствующие файлы сгруппированы по папкам для каждой главы. Некоторые файлы требуют установки других
программное обеспечение, которое у вас может не быть, и оно находится в папке Tools на компакт-диске. Многие инструменты на
компакт-диск представляет собой демонстрационную или условно-бесплатную версию, поэтому, если они вам нравятся и вы собираетесь использовать их в своих
работы, пожалуйста, соблюдайте свои обязательства по лицензированию и покупке. Если вам нужны инструменты, которые делают больше, чем
были включены здесь, посмотрите, предоставляют ли компании-производители инструментов более продвинутые версии того, что у вас есть
сейчас. В противном случае посоветуйтесь с коллегами или поищите в Интернете то, что вы ищете. Более
подробности о содержимом компакт-диска приведены в приложении «Что на компакт-диске» в конце этой книги.

Ваши инструменты
Microsoft Excel и Word - единственное программное обеспечение, которое у вас уже должно быть для использования файлов.
предоставляется на компакт-диске. При установке исполняемых программ, указанных на компакт-диске, выберите
варианты установки, которые лучше всего подходят для вашей машины, или обратитесь к веб-сайту программы для загрузки
варианты или версии.

Веб-сайт поддержки
Вы найдете веб-сайт этой книги по адресу http://testbook.gamedev.net.. Этот сайт будет содержать исправления, новые или
обновленные примеры, документы, шаблоны и полезная информация. Заходите время от времени, чтобы увидеть
что нового и, может быть, вы найдете там что-нибудь интересное.

А теперь приступайте к практическому применению прочитанного в этой книге и сделайте продуктивную, приносящую удовлетворение и увлекательную карьеру.
в игровой индустрии.

https://translate.googleusercontent.com/translate_f 8/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. 11

Часть I. О тестировании игр


Список глав

Глава 1: Два правила тестирования игры

Глава 2: Быть тестером игр

Глава 3: Почему важно тестирование

Стр. 12
https://translate.googleusercontent.com/translate_f 9/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Глава 1: Два правила тестирования игры


Каждый раз, когда я начинаю новую команду тестировщиков или привожу в нее нового тестировщика, я даю им эти два правила:

Правило 1: не паникуйте

Правило 2: не доверяйте никому

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

Аквалангисты попадают в ситуацию, с которой могут столкнуться тестеры игр: ограниченные ресурсы (
оборудование, которое вы приносите с собой), временные ограничения (подача воздуха), правила, которым необходимо следовать (скорость спуска / подъема) и
прочие сюрпризы (неожиданные морские посетители). По словам доктора Уильяма Моргана, эпизоды паники или почти
паника может объяснить многие несчастные случаи и смертельные случаи, связанные с дайвингом-любителями. Паническая атака часто вызывалась
то, что не-дайвер счел бы серьезным - запутывание, неисправность оборудования или прицел
акулы. Но атаки не улучшают ситуацию, говорит Морган - они могут привести к иррациональным и
опасное поведение. [ 1 ] Даже аквалангисты с многолетним опытом иногда впадают в панику из-за
без видимой причины. [ 2 ]

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

Паника в игровом проекте возникает, когда вы

Незнакомый

Неподготовленный

Под давлением

Незаинтересованный

Близорукий

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

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

Стр. 13

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

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

Неподготовленный
Никто не ждет испанской инквизиции, и на вашем проекте произойдет много неожиданностей.
Ожидать неожидаемое! Многие части игры необходимо протестировать на разных этапах жизненного цикла игры.
цикл. За кулисами задействовано множество различных технологий - 3D-графика, аудио, пользовательские интерфейсы,
многопоточность и файловые системы и многие другие. Если вы не готовы к множеству тестовых заданий и
не обладаете навыками, необходимыми для их успешного выполнения, тогда вы скорее споткнетесь, чем начнете играть.

https://translate.googleusercontent.com/translate_f 10/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Учеба, практика
чтобы узнать и опыт
больше - вотигры.
о коде составляющие хорошей
Идите в ногу подготовки.
с отраслью, чтобыВзнать,
ходе что
проекта попробуйте
следующее поколение игр и технологий будет нравиться. Станьте экспертом в требованиях и
дизайн частей игры, за тестирование которых вы отвечаете, а затем ознакомьтесь с теми, которые вы
не несут ответственности за. Когда вы меньше всего этого ожидаете, вам, возможно, придется перейти на другую должность, заполните
другой тестировщик, или стать более ответственным. Будьте готовы, когда это произойдет.

Примечание . Информация в главе 5 «Цикл разработки игры» дает вам представление о том, как
подготовка к успеху в качестве тестировщика игр, а также понимание того, в каких средах
проекты, роли и рабочие места, в которых вы можете когда-нибудь оказаться.

Под давлением
Давление может поступать с любого из трех направлений:

График (календарное время для завершения проекта)

Бюджет (деньги, которые нужно потратить на проект)

Штат (количество и типы людей, назначенных для работы над игрой)

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

Рисунок 1.1: Ресурсы сбалансированы с объемом проекта.

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

Стр. 14

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

Рисунок 1.2: Уменьшение бюджета вызывает давление.

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

https://translate.googleusercontent.com/translate_f 11/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
численность персонала, если они не увеличиваются.

Рисунок 1.3: Бюджетная и кадровая нагрузка, вызванная увеличением масштабов проекта.

Когда есть давление на проект, вы можете ожидать, что его передадут. Кто-то что-то требует
от вас и использует такие фразы:

Мне / нам нужно… немедленно

Стр. 15

Мне все равно ...

Это было тогда, это сейчас

Разберись, как это сделать

Сделай это

Смирись с этим

Мы не можем себе позволить…

Ничего другого не имеет значения, кроме ...

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

Обратите внимание на главу 2 «Работа тестировщиком игр», которая знакомит вас с тем, что от вас ожидается в вашей роли
тестировщик, и как повлиять на качество игры.

Глава 5 , «Цикл разработки игры», описывает, как меняются цели и ожидания по мере того, как
игра постепенно превращается в концепцию на полки магазинов, и как это влияет на
работа по пути.

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

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

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

Обратите внимание: в главе 16 «Автоматизация игрового тестирования» и в главе 17 «Тестирование захвата / воспроизведения» описывается
методы и инструменты, которые вы можете использовать, чтобы максимально использовать время тестирования и отдыха.

https://translate.googleusercontent.com/translate_f 12/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

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

Стр.16

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

Контрольный список для позднего ночного тестирования

Предварительный тест

У вас есть подходящая версия теста?

Тестовая версия: ________________

Вы используете правильную версию сборки?

Версия сборки: ________________

Вы используете правильную конфигурацию / настройки оборудования?

Описывать: __________________________________

Вы используете правильный игровой контроллер и настройки?

Описывать: __________________________________

Какие варианты установки вы использовали (если есть)?

Описывать: __________________________________

Находится ли игра в правильном начальном состоянии перед запуском тестового примера?

Описывать: __________________________________

Пост-тест

Вы выполнили все шаги теста по порядку?

Вы задокументировали завершение тестов и их результаты?

Вы записали все обнаруженные проблемы?

Если вы сообщили о проблеме, заполнили ли вы все обязательные поля?

Обратите внимание на главу 7 , «Фазы тестирования», где показано, какие виды тестирования следует проводить в процессе.
код игры созревает. Это поможет вам правильно провести тестирование в конкретной ситуации, а также узнать
что вы можете рассчитывать на дополнительное тестирование, которое вы проведете позже в игре.
[ 1 ] «Боюсь, мы должны говорить о… панике под водой». The Why Files ™
< http://whyfiles.org/sports/scuba > (21 января 2005 г.)

[ 2 ] «Еще вопросы и ответы о Panic Underwater…» The Why Files ™


< http://whyfiles.org/sports/scubaq4.html> (21 января 2005 г.)

https://translate.googleusercontent.com/translate_f 13/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.17

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

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

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

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

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

Не принимайте это на свой счет. Это вопрос бизнеса, технологий и конкуренции. Много денег на
line, и инвесторы не хотят терять ее на вашем проекте. Технологии, необходимые для создания игры
возможно, даже не было доступно на момент начала разработки, что дает вашей команде возможность
создать игру, которую еще никто не делал. Пытаясь сломать игру и терпя неудачу, вы
установить уверенность в том, что это сработает. Игры, которые выходят неправильно, становятся жертвами разглагольствований и жалоб
размещен в Интернете. Не позволяйте этому случиться с вами!

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

Измерение и анализ результатов тестирования - даже из прошлых игр - дает вам данные о вашей игре
сильные и слабые стороны. Части, которым вы меньше всего доверяете - слабые - потребуют больше всего
внимание в плане тестирования, повторного тестирования и анализа. Эта взаимосвязь проиллюстрирована на рисунке 1.4.

Рисунок 1.4: Низкое доверие означает большее тестирование.

Части, которым вы можете доверять больше всего - сильные - потребуют от вас меньше всего внимания, как показано на рисунке.
на рисунке 1.5. Их следует время от времени проверять повторно, чтобы восстановить ваше доверие. Глава 5 помогает
вы определяете, какое тестирование и когда проводить. Глава 8 дает вам конкретные стратегии и
критерии для планирования, выбора и пересмотра тестирования.

Стр.18

Рисунок 1.5: Больше доверия ведет к меньшему количеству тестирования.

Обратите внимание, что Глава 6 «Качество программного обеспечения» знакомит вас с некоторыми основными принципами оценки доверия:
достоинства вашего игрового кода. В главе 9 «Численное тестирование» описаны измерения.
которые вы можете скомпилировать из тестовых данных, которые вы обычно собираете, и объясняет, как их анализировать
измерения для увеличения конкретных проблемных областей.

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

https://translate.googleusercontent.com/translate_f 14/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
перейти границу от недоверия к враждебному. Вся команда работает над тем, чтобы доставить самое лучшее
может, даже если тестировщику так не кажется.

Общая форма утверждений, на которые следует обращать внимание: «X произошло, поэтому (только / не делать) Y». Вот некоторые
Примеры:

«Изменилось только несколько строк кода, поэтому не проверяйте никакие другие строки».

«Новая аудиоподсистема работает так же, как и старая, поэтому вам нужно только запустить старые тесты».

"Мы добавили строки на иностранном языке для диалогов, поэтому просто отметьте несколько из них в одном из
языки и все остальное тоже должно быть в порядке ".

И несколько вариантов:

«Мы внесли только небольшие изменения, поэтому не беспокойтесь о тестировании <вставьте здесь название функции>».

«Вы можете просто провести один или два теста и сообщить мне, работает ли он».

«Мы должны выпустить это сегодня, так что просто…».

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

Не приравнивайте позицию «никому не доверять» с позицией «не делайте ничего, что вас просят сделать». Если тестовый провод или
руководителю проекта нужно, чтобы вы соответствовали целям для проведения определенных видов тестирования, убедитесь, что вы выполняете
ваши обязательства перед ними, прежде чем уйти и работать над тем, чему вы не доверяете. Разница в том
между тем, чтобы быть героем ("Я закончил испытания, которые вы хотели, а также смог начать смотреть на
режим турнира и обнаружил там некоторые проблемы. В следующий раз мы должны провести дополнительные испытания ")
или ноль ("У меня не было времени провести тесты, которые вы хотели, потому что я получал несколько новых тестов для работы
турнирный режим »).

Примечание. В главе 4 «Игровая команда» вы узнаете кое-что о том, что другие участники
игрового проекта, и как ваше тестирование влияет на их работу и влияет на прогресс
игра.

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

По мере развития игры руководство и разработчики хотят чувствовать себя комфортно в


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

Стр.19

не следует убаюкивать себя самоуспокоенностью. Я часто наполняю свою команду энергией, говоря им: «Относитесь к этому
выпускаем так, будто это наш последний шанс найти проблемы ". Возникнут конфликты по поводу того, вводить или нет
новые тесты, и вы услышите жалобы на то, почему важные проблемы обнаруживаются так поздно в проекте.
Существует множество причин позднего выявления дефектов, которые не имеют ничего общего с некомпетентным тестированием.
Вот некоторые из них, с которыми вы столкнетесь:

Дефекты были внесены поздно, незадолго до того, как вы их обнаружили.

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

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

В любом случае, даже если ошибки были с самого первого выпуска, они не были исправлены тестировщиками.
Где-то есть воображаемый мир, где тестировщики игр слышат: «Спасибо, что нашли это».
важный дефект прямо перед отправкой! », но не рассчитывайте, что это произойдет в нашем мире (см.
Рисунок 1.6).

Рисунок 1.6: Наш мир (слева) и мир любви тестировщика (справа).

Обратите внимание на главу 12 «Тестирование в чистых помещениях» и главу 14 «Игровое тестирование и специальное тестирование».

https://translate.googleusercontent.com/translate_f 15/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
методы, которые можно использовать для тестирования игры, основанные на вашей интуиции и проницательности при тестировании.

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

Тестировщик: "Привет, Билл, есть ли что-то, что вас особенно беспокоит, на что мне следует сосредоточиться в моем
тестирование? "

Билл: «Ну, мы просто переделали логику квеста « Нечеткий меч » , так что мы определенно хотим, чтобы это рассмотрели».

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

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

Стр.20

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

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

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

Итак, как тестировщик, вы можете сделать и то, и другое одновременно , следуя этому совету:

Знайте свою роль в команде на основе возложенных на вас обязанностей

Выполняйте свои задачи агрессивно и точно

Сначала сделайте самые важные тесты

Часто проводите тесты, чтобы найти дефекты

Принимайте максимально безэмоциональные и объективные решения

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

https://translate.googleusercontent.com/translate_f 16/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.21

Остальная часть истории


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

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

Помните, что как тестировщик игры, все верят, что вы найдете проблемы еще до выхода игры. Не надо
дайте им повод для паники!

Обратите внимание на главу 10 «Комбинаторное тестирование», главу 11 «Блок-схемы тестирования» и главу 13 «Проверка.
Деревья », познакомит вас с тремя важными методами тестирования игр. Используйте их, чтобы понять
игровое программное обеспечение на ранней стадии разработки и систематически изучать особенности игры и
функционирует на протяжении всего проекта.

https://translate.googleusercontent.com/translate_f 17/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. 22

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

Паника приводит к

Плохое суждение и принятие решений

Ненадежные результаты испытаний

Слишком большой упор на краткосрочное

Паника стоит проекту в

Ненужная переделка

Потраченные впустую усилия

Потеря доверия и авторитета

Избегайте паники

Узнавать, когда вам нужна помощь, и получать ее

Подготовка к неожиданному

Опираясь на процедуры

Достаточно отдыхать

Не верь

Слухи

Мнения

Эмоции

Полагаться на

Факты

Полученные результаты

Опыт

Тестируйте каждую версию игры, как если бы

Это не последний

Это последний

Стр. 23

Упражнения
1. Что такое Правило 1?

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

https://translate.googleusercontent.com/translate_f 18/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
3. Что такое Правило 2?

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

5. Что из перечисленного оказывает давление на игровой проект?


а. Новое финансирование

б. Забирать людей, чтобы они поработали над другой игрой

c. Требование добавить больше уровней, чтобы быть сопоставимыми с недавними уровнями конкурента.
объявленное название

d. бив

6. ДОПОЛНИТЕЛЬНЫЙ КРЕДИТ. Назовите две научно-фантастические игры, в которых есть фраза « Не паникуйте ».
и « Никому не верь ».

Ответы

1. Не паникуйте.

2. Ответ специфичен для читателя.

3. Никому не доверяйте.

4. Ответ специфичен для читателя.

5. г

6. « Не паникуйте » из « Автостопом по галактике» Дугласа Адамса.


( www.douglasadams.com/creations/infocom.html ) и « Не доверяйте никому » изначально из Секретных материалов.
( www.thexfilesgame.com ). Вы можете потребовать дополнительный кредит, если вы также признали " Не доверяйте никому "
слоган из игры Ice Nine .

Стр. 24

Глава 2: Быть тестером игр


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

Но просто играть в игру недостаточно, чтобы быть хорошим тестером. Конечно, вам нужно научиться находить
проблемы, но вам также необходимо хорошо поработать над другими вещами, такими как документирование и сообщение об ошибках,
сообщать о ходе тестирования и помогать разработчикам находить и исправлять ваши ошибки. Эти задачи выполняются снова и снова.
снова, пока игра не выйдет. Подумайте о аббревиатурой "Пианино TV" - P лежал, я dentify, A mplify, N otify и
О ptionally, Т estify и V erify. Рисунок 2.1 иллюстрирует эту последовательность действий.

Рисунок 2.1: Действия по тестированию игры.

https://translate.googleusercontent.com/translate_f 19/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Играть в игры
Дома вы играете в игры, чтобы повеселиться. Вы можете выбирать, во что играть, когда и как играть.
Тестирование игр по-прежнему может быть увлекательным занятием, но у вас меньше выбора, во что, когда и как играть. Все
вы делаете это, когда играете, с определенной целью - либо исследовать какую-то область игры, либо проверить, что
применяется правило, или ищите конкретную проблему.

Ваша работа начинается с выполнения серии назначенных вам тестов. Некоторые тесты очень специфичны
и состоят из пошаговых инструкций. Они полагаются на ваши внимательные наблюдения и внимание к деталям.
Это хороший формат для тестирования пользовательского интерфейса (UI). Вот небольшой пример для тестирования части
Пользовательский интерфейс выбора персонажа в Star Wars: Knights of the Old Republic для Xbox:
1. Выберите «Новая игра» в главном меню.

Убедитесь, что изображение и заголовок «Мужчина-негодяй» выделены (см. Рисунок 2.2).

Убедитесь, что описание негодяйского персонажа отображается правильно.

2. Прокрутите влево с помощью D-Pad.

Убедитесь, что изображение и заголовок «Женщина-негодяй» выделены.

Убедитесь, что описание персонажа негодяя не изменилось.

3. Прокрутите вправо с помощью D-Pad.

Убедитесь, что изображение и заголовок «Мужчина-негодяй» выделены.

Убедитесь, что описание персонажа негодяя не изменилось.

4. Прокрутите вправо с помощью ЛЕВОГО аналогового джойстика.

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

Стр.25

Убедитесь, что описание персонажа разведчика отображается правильно.

5. Прокрутите влево с помощью ЛЕВОГО аналогового джойстика.

Убедитесь, что изображение и заголовок «Мужчина-негодяй» выделены.

Убедитесь, что описание негодяйского персонажа отображается правильно.

6. Прокрутите вправо с помощью ПРАВОГО аналогового джойстика.

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

Убедитесь, что описание персонажа негодяя не изменилось.

7. Нажмите кнопку X.

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

Убедитесь, что описание персонажа негодяя не изменилось.

8. Нажмите кнопку Y.

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

Убедитесь, что описание персонажа негодяя не изменилось.

9. Нажмите кнопку B.

Убедитесь, что на экране главного меню выделено «Новая игра».

https://translate.googleusercontent.com/translate_f 20/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Рисунок 2.2: Начальное состояние экрана выбора персонажей Knights of the Old Republic с изображением мужчины.
Негодяй.

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

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

Ситуация, в которой вы можете столкнуться с контрольным списком, - это проверка специальных приемов в файтинге. Для
Например, следующий контрольный список предназначен для проверки специальных атак Тины Армстронг в Dead or Alive 3 . К

Стр. 26

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

q Ракета-пулемет

q Тройной локоть

q Комбо-удар

q Поверните апперкот

q Апперкот дельфина

q Коленный молоток

q Нога Лариат

q Передний шаговый удар

q Разбитое колено

q Лариат ближнего действия

q Самоубийство локтя

q Колено переднего ролика

q Передний роликовый удар

q Атака летающим телом

В то время как контрольный список, как правило, сосредоточен на проверке узкого набора игрового поведения, план может быть
используется для тестирования более широкого диапазона результатов, не беспокоясь о подробных шагах, которые необходимо предпринять для достижения
эта цель. Например, в NBA Street Vol. 2 , у вас есть возможность разблокировать специальные футболки игроков,
достижение определенных результатов во время игры или серии игр. Представьте, что вам нужно определить кнопку или следовать ей.
по кнопке серии шагов, чтобы пройти всю игру! Значит, вам, тестировщику, нужно хорошо знать игру
достаточно, чтобы выбрать правильных игроков для своей команды, а затем сыграть в игру достаточно хорошо, чтобы достичь целей, которые
разблокировать каждую из майок. Для этой цели достаточно схемы, подобной приведенной ниже.

Разблокируйте специальные майки


Билл Рассел

Победите все команды Северо-Западного региона, не проигрывая.

Билл Уолтон

Набрать более 1000000 очков за игру

Конни Хокинс
Получите 20 блоков в игре и выиграйте игру

Элгин Бэйлор
Выключите противостоящую команду

Джеймс Уорти
Победите все команды Северо-Восточного региона, не проиграв.

Джерри Уэст
Выиграйте игру, не заблокировав ни одного броска.

Оскар Робертсон

https://translate.googleusercontent.com/translate_f 21/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. 27

Победите все команды Юго-Западного региона, не проигрывая.

Уолт Фрейзер
Обыграть все команды Центрального региона, не проигрывая

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

Стр.28

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

https://translate.googleusercontent.com/translate_f 22/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
проблемы, оно "проходит". Когда тест обнаруживает проблему, он «терпит неудачу».
Другой возможный результат теста - «Заблокирован», что означает, что существующая проблема не позволяет вам получить
к другим частям теста, например, когда компьютерная версия игры American Idol вылетает после того, как вы
дойти до финальной 10-ки (см. следующую боковую панель). Это блокирует вас от проведения каких-либо тестов в финальных раундах.
конкурса.

Тест также может быть "Недоступен", что означает, что часть, которую вы должны тестировать, не была включена.
в той версии игры, которую вам дали на тестирование. Это может быть потому, что разработчики все еще находятся в
процесс объединения всех игровых элементов, так что уровень, предмет, функция или персонаж
намеренно исключен из тестового релиза. Также может быть, что версия игры для вашей платформы
тестирование не включает в себя то, что вы пытаетесь протестировать, например многопользовательский режим True Crime: Streets of LA.
режимы, доступные только для ПК.

Заголовок> Обновление встроенного звукового меню

Дата загрузки> 28 ноября 2003 г.

Описание> Для решения проблем с вылетом игры American Idol обратно в Windows
рабочий стол при навигации по меню в начале игры ИЛИ после того, как игрок перешел к
финал 10 конкурсантов.

http://www.codemasters.com/downloads/?downloadid=12431

А вот и судья
Не каждый тестировщик заметит одни и те же дефекты при тестировании одной и той же части игры. Точно так же не каждый
tester выполнит тот же тест таким же образом. Психология может объяснить, почему это
происходит в виде индикатора типа Майерс-Бриггс (MBTI). Одна из категорий в этом индикаторе
оценивает человека как Судьи или Воспринимающего.

Судьи любят быть организованными, организованными и продуктивными.

Если вы судья, вы предпочитаете структурированную, упорядоченную и достаточно предсказуемую среду.


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

Воспринимающие любят быть гибкими, любопытными и несогласными.

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

Стр.29

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

http://www.boomspeed.com/zsnp/mbti.htm

Примечание. Не уверены, что вы больше судья или воспринимающий? Вы можете пройти тест на темперамент в
www.personalitytest.net/cgi-bin/q.pl, чтобы узнать.

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

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

https://translate.googleusercontent.com/translate_f 23/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Вы, вероятно, не на 100% относитесь к одному типу, но, скорее всего, у вас есть склонность к одному или другому.
Не воспринимайте это как ограничение. Используйте эти знания, чтобы лучше понять области, которые вы можете улучшить, чтобы
вы можете найти больше ошибок в тестируемых играх. Ваша цель должна заключаться в использовании обоих наборов качеств в
подходящее время и для правильной цели. Когда вы видите ошибку, которую нашел кто-то другой, и она делает
вы думаете: «Вау! Я бы никогда не пробовал этого», а затем идете поговорить с этим человеком и спросите, что заставило
она думает об этом. Делайте это часто, и вы сможете начать находить те же самые ошибки, спросив себя
«Как бы Линда это проверила?». Убедитесь, что вы тоже делитесь своими «историями об ошибках». Пару книг по
дефекты программного обеспечения, которые могут дать вам больше информации: Компьютерные риски , Питер Г.
Нойман и « Фатальный дефект » Иварса Петерсона.

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

Таблица 2.1: Сравнение личностей тестировщиков

Судья Воспринимающий

Запускает тесты для… Находит способ…

Обычная игра Нетрадиционная игра

Повторное тестирование Тестирование разнообразия

Руководство пользователя, тестирование скриптов Геймплей, юзабилити-тестирование

Фактическая точность игры Реалистичный опыт игры

Пошаговое тестирование или тестирование на основе контрольного списка


Открытое или схематичное тестирование

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

Обеспокоен содержанием игры Обеспокоен игровым контекстом

Стр.30

Усиливающие проблемы
Обычно слово «усилить» заставляет вас думать о том, что что-то становится больше или громче. В таком случае,
"усиление" вашего дефекта сузит его для разработчиков, повысит вероятность того, что дефект будет исправлен
правильно с первого раза и сократите общие затраты времени и средств на решение проблемы.

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

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

Новые уровни, персонажи, предметы, кат-сцены и т. Д., Как только они появятся.

Новая анимация, освещение, физика, эффекты частиц и т. Д.

Новый код, который добавляет функциональность или исправляет дефекты

Новые подсистемы, промежуточное ПО, движки, драйверы и т. Д.

Новый диалог, текст, переводы и т. Д.

Новая музыка, звуковые эффекты, закадровый голос, аудио аксессуары и т. Д.

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

Найдите дефекты в большем количестве мест в игре, ища следующее:

https://translate.googleusercontent.com/translate_f 24/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Все места в игре, где может быть активировано одно и то же неправильное поведение.

Все места в коде, которые вызывают дефектный класс, функцию или подпрограмму.

Все игровые функции, использующие один и тот же неисправный предмет, сцену и т. Д.

Все предметы, уровни, персонажи и т. Д., Которые имеют общий атрибут с неисправным (для
например, раса персонажа, тип оружия, уровни со снегом и т. д.)

А затем используйте этот двухэтапный процесс, чтобы увеличить частоту дефекта:

1. Избавьтесь от ненужных шагов, чтобы дефект проявился.

2. Найдите более частые и / или более распространенные сценарии, которые могут включать оставшиеся важные
шаги.

Стр.31

https://translate.googleusercontent.com/translate_f 25/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.32

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

Использование системы отслеживания дефектов

Информация, необходимая для составления хороших отчетов о дефектах

Некоторые типичные ошибки и упущения

Дополнительные действия, которые вы можете сделать, чтобы помочь выявить и исправить ошибку

На рисунке 2.3 показано новое окно ввода дефектов инструмента DevTrack. Основные элементы этого окна
- это выбор функции вверху, выбор вида слева и экран просмотра / ввода данных на
право.

Рисунок 2.3: Новое окно дефекта DevTrack.

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

Экран ввода данных - это то место, где вы вносите свой вклад, поэтому в следующих разделах рассматриваются некоторые из
ключевые поля, с которыми вам нужно работать. Чтобы узнать больше об использовании других функций DevTrack, вы можете изучить
демо на www.techexcel.com .

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

Стр. 33

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

https://translate.googleusercontent.com/translate_f 26/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
На рисунке 2.4 есть название и описание проблемы, обнаруженной во время игры в Neverwinter Nights Gold . В этом
case в заголовке упоминается, что произошло и где это произошло. Всегда включайте «что», а затем добавляйте
один или два отличительных фактора «кто», «где», «когда» или «как».

Рисунок 2.4: Название и описание дефекта.

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

Еще один способ подробно описать дефект - это пошаговое описание того, как вы
нашел это. Не начинайте с того момента, когда вы включили компьютер, но включите шаги, относящиеся к
воспроизведение проблемы. Итак, альтернативное описание ошибки Neverwinter Nights было бы:
Создайте персонажа-истребителя. Идите в тренировочный зал и посетите тренера заклинаний. Оставьте наставника заклинаний
комнату и запрыгните на стену напротив его двери. Персонаж может перемещаться по стене
но не может спрыгнуть, чтобы продолжить игру.

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

Расставлять приоритеты
В зависимости от «правил взаимодействия» для вашего проекта от вас также может потребоваться классифицировать дефект.
приоритет (или «серьезность») и / или тип. На рисунке 2.5 показан пример раскрывающегося меню вариантов для назначения
первоначальный приоритет этого дефекта.

Стр. 34

Рисунок 2.5: Выбор приоритета дефекта.

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

https://translate.googleusercontent.com/translate_f 27/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
включая недавно выигранные или обнаруженные предметы. Если ваш персонаж был заморожен в многопользовательской игре, это могло
также приводят к смерти игрока и связанным с этим штрафам после продолжения злой орды, с которой вы сражались
с удовольствием избивает вас, пока ваше здоровье не достигнет нуля.

Ошибка с «высоким» приоритетом может быть проблемой, которая приводит к серьезным последствиям для игрока, например, не
получение квестового предмета после успешного выполнения квеста. Этот приоритет также можно использовать для
«Срочный» дефект, возникающий при невыясненных обстоятельствах. Вам следует поскупиться на создание
это своего рода понижение, когда вы впервые регистрируете ошибку, особенно в многопользовательской игре, потому что гнусные
игроки могут использовать эту ошибку в своих интересах или в ущерб вам, если неясные
обстоятельства раскрываются в выпущенной игре и впоследствии публикуются. Пример такого рода
злоупотреблений произошло в компьютерной онлайн-игре Asheron's Call, где игроки убивали своего персонажа
а затем намеренно вылетает из игрового сервера. После того, как сервер был восстановлен, они смогли получить
дубликат редкого предмета с их трупа. См. На следующей боковой панели ответ разработчиков на это
дефект, когда он произошел в январе 2001 года.

«Средние» дефекты вызывают заметные проблемы, но, вероятно, не влияют на игрока с точки зрения вознаграждения.
или прогресс. Разница между "Высоким" и "Средним" может быть разницей между получением вашего
ошибка рассмотрена и исправлена, отложена для исправления в пост-релизном патче или оставлена ​в игре как есть. Когда в
сомневаюсь, если руководители вашего проекта не указали иное, назначьте приоритет «Высокий», чтобы это было справедливо
оценивается перед понижением. Будьте осторожны, чтобы не злоупотреблять этой тактикой, иначе обнаруженные вами дефекты не исчезнут.
воспринимаются так серьезно, как должны.

«Низкий» приоритет обычно присваивается очень мелким дефектам, не влияющим на игровой процесс, тем, которые возникают в
невыполнимые условия, или те, которые являются делом личного вкуса. Например, в игре GBA Yu-Gi-
Ой! Душа вечного дуэлянта , когда Ями Бакура побежден в 10-й раз, диалоговое окно обращается к
«Великая схема вещей» вместо «Великой схемы вещей».

Заметка об исправлении вызова Ашерона

23 января 2001 г.

Мы хотели подробно объяснить причину сегодняшнего исправления и то, как оно повлияет на вас,
игроков.

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

Стр. 35

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

Нам удалось отследить эту ошибку, и мы отключили серверы, чтобы предотвратить доступ дополнительных людей.
сбой серверов и / или дублирование элементов.

Хорошей новостью является то, что мы смогли отследить всех игроков, которые использовали эту ошибку, и
сбой серверов. Как мы уже заявляли ранее: с тех пор, как Asheron's Call был коммерчески выпущен,
наша политика заключалась в том, что если игроки используют ошибку, которую мы не обнаружили или не успели исправить
перед выпуском игры мы не будем наказывать их за нашу ошибку, а направим свои усилия
чтобы исправить эти ошибки как можно скорее. Исключения составляют те ошибки, которые
существенно влияют на производительность или стабильность игры .

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

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

- Команда вызова Ашерона

http://classic.zone.msn.com/asheronscall/news/ASHEletterJan2.asp

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

Выберите тип
Поле типа дефекта также важно для маршрутизации и обработки вашего дефекта. На рисунке 2.6 показан список
представлен в демонстрации DevTrack.

https://translate.googleusercontent.com/translate_f 28/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.36

Рисунок 2.6: Выбор типа дефекта.

Не все, что вы обнаруживаете в качестве тестировщика, является ошибкой в ​том смысле, что что-то работает не так, как планировалось. Ты сможешь
найти то, что можно улучшить или добавить в игру, чтобы сделать ее лучше. Такого рода проблемы были бы
классифицируется как «Незначительное улучшение» или «Новая функция» соответственно.

Точно так же вы можете ввести «Улучшение будущего» для таких вещей, как
Идея сиквела

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

Добавление поддержки для совершенно нового типа контроллера

Функция или элемент, который будет доступен для загрузки после выхода игры.

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

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

Для тех видов дефектов, при которых игра просто не работает должным образом, "Несоответствие
Тип отчета может быть указан, а вариант «Запрос на изменение» может использоваться для чего-то, что
имеет более широкие возможности, например переделывает механизм обнаружения столкновений в игре.

Быть полезным
Наконец, убедитесь, что вы включили любые другие артефакты или информацию, которые могут помочь любому, кто пытается
оценить или устранить проблему. Помимо добавления деталей к описанию, с DevTrack вы можете использовать
функция «Примечания» для добавления полезных файлов в запись о дефекте. Прикрепите или предоставьте ссылки на любой из следующих
предметы, которые вы можете достать:

Журналы сервера

Снимки экрана

Стенограммы из дневника персонажа

Звуковые файлы

Файл сохраненных персонажей

Видеозапись (включая аудио) событий, приведших к ошибке, включительно

Следы кода в отладчике

Файлы журнала, хранящиеся игровой платформой, промежуточным программным обеспечением или оборудованием

Всплывающие окна операционной системы и коды ошибок

Данные, собранные симуляторами для мобильных игровых сред, таких как BREW®, Java, Palm OS ™ или
Microsoft® Windows® CE

https://translate.googleusercontent.com/translate_f 29/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. 37

Примечание. Не все системы отслеживания дефектов, которые вы используете, будут иметь такую ​структуру или выглядеть точно так же, как DevTrack.
Просто обратите внимание на правильное понимание основ и спросите других тестировщиков или своего тест-лидера, что еще
ожидается от вас при сообщении об ошибке. Например, вы можете ожидать, что отправите электронное письмо
в специальный список рассылки, если используемая вами система отслеживания дефектов этого не делает.
автоматически, или вы можете использовать общую электронную таблицу вместо специально разработанного инструмента
для отслеживания дефектов. Для онлайн-списка некоторых других инструментов отслеживания дефектов см.
http://www.aptest.com/bugtrack.html .

Пройден или не пройден


Неудачные тесты хороши с вашей точки зрения, но для проекта также важно знать, какие тесты
прошедший. Вы, вероятно, должны будете записывать завершение и результаты ваших тестов, указав
которые прошли, а какие нет. Другие типы статуса могут включать «Заблокировано» или «Недоступно», где
"Заблокировано" означает, что существующая проблема не позволяет вам выполнить один или несколько шагов в
tests, а "Недоступно" означает, что функция или возможность, которые являются частью теста, недоступны в
версия игры, которую вы тестируете. Например, тест многопользовательского сценария будет «Заблокирован», если дефект в
игра не позволяет вам подключиться к многопользовательскому серверу. Тест, который нельзя запустить, потому что уровень
не был добавлен в игру, но будет классифицирован как «Недоступно».

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

Примечание. В процессе тестирования отслеживайте, какую версию игры вы используете, какую


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

Стр. 38

https://translate.googleusercontent.com/translate_f 30/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Свидетельствуйте другим
Как бы сильно вы ни были привязаны к обнаруженным вами дефектам, вы можете очень мало сказать прямо
о том, будут ли они исправлены. Ваши драгоценные недостатки, скорее всего, попадут в руки беспощадного
Совет по контролю за изменениями (CCB). В вашей компании или проектной группе это может быть другое название, но
цель этой группы - расставить приоритеты, контролировать и стимулировать завершение наиболее необходимых
дефекты, чтобы создать лучшую возможную игру по доставке, когда наступит крайний срок проекта. Это означает, что
дефекты легче исправить, если они обнаружены на ранней стадии проекта, чем когда они будут обнаружены позже.
Угроза испортить остальную часть игры и пропустить крайний срок доставки напугает многие команды.
от исправления сложных дефектов ближе к концу проекта. Вот почему вы хотите найти важные вещи
рано!

В CCB обычно входят представители отдела разработки, тестирования и управления проектами. На


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

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

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

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

Стр. 39

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

https://translate.googleusercontent.com/translate_f 31/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. 40

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

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

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

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

https://translate.googleusercontent.com/translate_f 32/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. 41

Упражнения
1. Что такое Правило 2?

2. Определите каждое из следующих действий как Судьи (J) или Воспринимающего (P):
а. Заметил опечатку в руководстве пользователя

б. Создан персонаж со всеми навыками, установленными на 0, чтобы посмотреть, что произойдет.

c. Сообщается, что АК-47 не стреляет с правильной скоростью

d. Нашел способ убрать своего фигуриста с карты

3. Что из нижеперечисленного является соответствующим подробным заголовком дефекта?


а. Игра вылетает

б. Нашли ошибку в многопользовательском режиме

c. Невозможно загнать машину Fastkat в коридор к югу от главного зала.

d. Персонаж неожиданно умирает

4. Что из перечисленного должно быть в описании дефекта?


а. Где случился дефект

б. Как возник дефект

c. Кто в игре вызвал проблему

d. Что дефект сделал с игрой

е. Все вышеперечисленное

5. Ваше первое задание для Gamecorp - испытать шутер от первого лица. Ваш персонаж,
киборг в тяжелой броне, на втором уровне с ножом и боеприпасами для
мегазука оружие. Вы находите пустую мегазуку, поднимаете ее и пытаетесь выстрелить, но она не
стрелять, потому что он показывает 0 патронов. Вы знаете из своих встреч по проекту, что оружие
должен автоматически загружать любые боеприпасы, которые вы несете для него. Какие вещи ты
что делать, чтобы "усилить" этот недочет?

6. Какие проблемы вы можете обнаружить, выполнив пошаговый тест.


пример из раздела « Игры » этой главы?

7. Перепишите пошаговый тест в виде схемы. Каковы преимущества этого? Какие


есть какие-то недостатки?

Ответы

1. Никому не доверяйте.

2. aJ, bP, cJ, dP

https://translate.googleusercontent.com/translate_f 33/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
3. c

4. e

Стр. 42

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

6. Некоторые потенциальные проблемы: Изображение или заголовок "Мужчина-негодяй" могут не выделяться в


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

7. Контурный тест:
Главное меню

Новая игра

Выбор персонажа

Негодяй

Разведчик

Негодяй

Недействительные элементы управления

Главное меню
Преимущества:
Короче

Меньше шансов ошибиться при написании теста

Легче повторно использовать на разных игровых платформах

Может запускаться разными тестировщиками по-разному

Недостатки:
Не указывает "Недействительные элементы управления"

Не обращает внимания тестировщика на то, что проверять на каждом этапе

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

Может не повторяться точно так же другим тестером

Обратите внимание, что 4- е преимущество и недостаток совпадают. Запустив его по-другому,


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

Стр. 43

https://translate.googleusercontent.com/translate_f 34/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Глава 3: Почему важно тестирование


Обзор
Написание этой главы привело к появлению большого списка ответов на вопрос «Почему важно тестирование?»

Игровое программное обеспечение может выйти из строя

Есть много возможностей ошибиться

Софт игры сложный

Люди пишут игровой софт, а люди делают ошибки

Для создания игр используются программные инструменты, и эти инструменты не идеальны.

На кону много денег, чтобы игры преуспели

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

Люди ожидают большего от каждой вашей игры

Лучше работать правильно, если у вас будет 100000 человек одновременно играть онлайн и
ожидайте, что они будут платить ежемесячную плату за эту привилегию

Критики готовы поставить вашу игру в печати и в Интернете.

Игры должны быть интересными, соответствовать ожиданиям и выходить вовремя

Короткий и простой ответ, который суммирует все в этом списке: «Потому что игры создаются
неправильно ". Если вы можете определить механизмы или закономерности, которые описывают, как игры становятся неправильными, вы можете
соотнесите это с тем, какие проблемы должны выявлять и предвидеть ваши тесты, когда вы будете следовать своим
путь к тому, чтобы стать первоклассным тестером игр. [Убеждение джедаев] Образцов, которые вы ищете, здесь нет. Может быть
люди, которые больше всего заботятся о тестировании игр, могут помочь вам разобраться.

Стр.44

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

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

Тестирование важно из-за договорных обязательств и сложной природы программного обеспечения.


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

https://translate.googleusercontent.com/translate_f 35/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
В противном случае ваши продажи и прибыль могут испариться.

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

Стр.45

Дефект ввода
Давайте на минутку оставим людей позади и посмотрим на программное обеспечение. Программное обеспечение может давать сбой по-разному.
Полезно классифицировать дефекты по категориям, которые показывают, как дефект был обнаружен и как его можно устранить.
найдены или, что еще лучше, избегнуты в будущем. Система классификации ортогональных дефектов (ODC),
Разработанный IBM, был разработан для этой цели. Эта система определяет несколько категорий
классификация в зависимости от осуществляемой деятельности по развитию. В этой главе исследуются восемь
классификации типов дефектов и исследует их отношение к дефектам игры. По типу дефекта классифицируется
способ появления дефекта в коде. По мере продвижения помните, что каждый дефект может быть либо
результат неправильной реализации или просто отсутствующего кода. Типы дефектов, перечисленные далее
Обобщите различные категории элементов программного обеспечения, которые используются при создании кода игры:
Функция

Назначение

Проверка

Сроки

Сборка / Пакет / Слияние

Алгоритм

Документация

Интерфейс
Примечание

Если вам сложно запомнить этот список, попробуйте запомнить аббревиатуру «FACT BADI».

Примеры дефектов в этом разделе взяты из игры Dark Age of Camelot (DAOC) версии 1.70i.

https://translate.googleusercontent.com/translate_f 36/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Примечания к выпуску, опубликованные 1 июля 2004 г. Dark Age of Camelot - это массовая многопользовательская ролевая онлайн-игра.
Игра (MMORPG), которая постоянно изменяется по дизайну, чтобы продолжать расширять и улучшать игроков.
игровой опыт. В результате он часто исправляется с двойной целью: исправление ошибок и добавление или
модифицирующие возможности. Это дает нам возможность изучить его по мере его разработки, в отличие от
игра, имеющая единую точку выпуска для публики.

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

Вот исправление, выпущенное в патче для Dark Age of Camelot, на которое будут ссылаться во всех примерах.
в этой главе:

"Способность царства Исчезновения теперь сообщает, сколько секунд супер-невидимости у вас есть, когда
использовал."

Если это так, как это должно работать, то вы можете представить, что ошибка была зарегистрирована с описанием, которое
что-то вроде этого:

"Способность царства Исчезновения не сообщает, сколько секунд вы имеете сверхстелс, когда


он используется ".

Стр. 46

См. Дополнительную информацию об этой способности на боковой панели «Исчезновение».

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

БЕЗОПАСНЫЙ

Описание:

Обеспечивает скрытность, которую невозможно сломать. Также удалит DoTs и Bleeds.


и обеспечивает невосприимчивость к борьбе с толпой. Эта способность длится от 1 до 5 секунд в зависимости от уровня
Исчезни. Сталтер также получает увеличение скорости передвижения, как указано. Stealther не может
атаковать в течение 30 секунд после использования этой способности.

Эффект:

L1 - нормальная скорость, невосприимчивость к 1 сек.

L2 - Скорость 1, невосприимчивость 2 сек.

L3 - Скорость 5, иммунитет 5 секунд

Тип: Активный

Повторное использование: 10 мин.

Уровень 1: 5

Уровень 2:10

Уровень 3:15

Классы для умения Исчезновение:

Лазутчик, Паслен, Теневой клинок

из Magical Realmat Аллахазама http://camelot.allakhazam.com/ability.html?cabil=73

Вот фрагмент воображаемого кода, который иллюстрирует код, который можно использовать для настройки и запуска Vanish.
способность. Уровень способности «Исчезновение» игрока передается обработчику, относящемуся к способности «Исчезновение». Этот
требуется подпрограмма для выполнения всех вызовов функций, необходимых для активации этой способности. g_vanishSpeed
и массивы g_vanishTime хранят значения для каждого из трех уровней этой способности, плюс значение 0 для
уровень 0. Эти массивы названы с префиксом " g_ ", чтобы указать, что они глобальные, поскольку те же результаты
подайте заявку на всех персонажей, обладающих этой способностью. Значения, написанные заглавными буквами, указывают на то, что это
константы.

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

https://translate.googleusercontent.com/translate_f 37/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

void HandleVanish (уровень)


{
если (уровень == 0)
возвращаться; // у игрока нет этой способности, поэтому оставьте

Стр. 47

PurgeEffects (damageOverTime);
IncreaseSpeed ​
(g_vanishSpeed ​
[уровень]);
SetAttack (ПРИОСТАНОВИТЬ, 30 СЕКУНД);
StartTimer (g_vanishTime [уровень]);
возвращаться;
} // упс! Не сообщал пользователю оставшиеся секунды - надеюсь, они не заметят

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

ShowDuration (FALSE, g_vanishTime [уровень]);

Задания
Дефект классифицируется как тип присвоения, если он является результатом неправильной установки или инициализации значения.
используется программой или когда отсутствует обязательное присвоение значения. Многие задания выполняются
в начале игры, на новом уровне или в игровом режиме. Вот несколько примеров для разных игровых жанров:
Виды спорта
График команды

Инициализировать счет для каждой игры

Первоначальные составы команд

Корт, поле, каток и т. Д., Где идет игра

Погодные условия и время суток

Ролевая игра, Приключение


Начальное местоположение на карте

Начальные атрибуты, навыки, предметы и способности

Инициализировать данные для текущей карты

Инициализировать журнал

Гонки
Инициализировать данные дорожки / цепи

Первоначальное количество топлива или энергии на старте гонки

Размещение бонусов и препятствий

Погодные условия и время суток

Казино, Коллекционные карточные игры, Настольные игры

Начальная сумма баллов или денег для начала

Первоначальная раздача карт или расстановка фишек

Первоначальный рейтинг / посев в турнирах

Положение за игровым столом и порядок хода

Боевые действия

Стр. 48

https://translate.googleusercontent.com/translate_f 38/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Начальное здоровье, энергия

Исходное положение на ринге или арене

Первоначальный рейтинг / посев в турнирах

Ринг, арена и т. Д., Где идет бой

Стратегия
Первоначальное размещение единиц

Первоначальное распределение ресурсов

Стартовая локация и размещение юнитов и ресурсов

Цели для текущего сценария

Шутеры от первого лица (FPS)


Начальное здоровье, энергия

Стартовое оборудование и боеприпасы

Стартовая локация игроков

Количество и сила противников CPU

Головоломки
Стартовая конфигурация головоломки

Выделенное время и критерии для завершения головоломки

Пазлы или целевые значения

Скорость, с которой решается головоломка

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

Даже дефект «Исчезновение» мог быть результатом проблемы с назначением. В воображаемом


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

ABILITY_STRUCT реальность;
realmAbility.ability = VANISH_ABILITY;
reamAbility.purge = DAMAGE_OVER_TIME_PURGE;
realmAbility.level = g_currentCharacterLevel [VANISH_ABILITY];
reamAbility.speed = g_vanishSpeed ​
[realmAbility.level]
realmAbility.attackDelay = 30 СЕКУНД;
realmAbility.duration = g_vanishTime [realmAbility.level];
realmAbility.displayDuration = ЛОЖЬ; // неправильное значение флага
HandleAbility (realmAbility);

В качестве альтернативы назначение флага displayDuration может вообще отсутствовать. Опять вырезать и
пастой может быть то, как возникла ошибка, или она могла быть неправильной или упущенной из-за ошибки на
часть программиста, или непонимание требований.

Проверка

Стр. 49

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

"=" вместо "==" используется для сравнения двух значений

Неправильные предположения о приоритете операторов, когда серия сравнений не выполняется.


в скобках

Сравнение "Off by one", например использование "<=" вместо "<"

Значение ( * указатель ) по сравнению с NULL вместо адреса ( указателя ) - либо непосредственно из


сохраненная переменная или как возвращаемое значение из вызова функции

Игнорируемые (не проверенные) значения, возвращаемые вызовами функций библиотеки C, например strcpy

https://translate.googleusercontent.com/translate_f 39/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

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

HandleAbility (способность ABILITY_STRUCT)


{
PurgeEffect (способность. Очистка);
если (capacity.attackDelay> 0)
StartAttackDelayTimer (capacity.attackDelay);
если (способность.immunityDuration == ИСТИНА)
// должна проверяться способность .displayImmunityDuration!
DisplayAbilityDuration (ability.immunityDuration);
}

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

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

В качестве примера схемы уведомления о звуковых событиях Microsoft DirectMusic предоставляет


Подпрограмма AddNotificationType , которую программисты могут настроить для уведомления своей игры, когда музыка
был запущен, остановлен, удален из очереди, зациклен или закончился. SetNotificationHandle - это
используется для назначения дескриптора события (созданного функцией CreateEvent ), который используется, когда игра
вызывает WaitForSingleObject с дескриптором уведомления, а затем вызывает GetNotificationPMsg для
получить событие уведомления.

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

Стр.50

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

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


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

Возвращаясь к знакомой ошибке Vanish, давайте рассмотрим сценарий ошибки синхронизации. В этом случае представьте, что
одна функция запускает анимацию для применения способности Исчезновение, а глобальная переменная
g_animationDone устанавливается после завершения воспроизведения анимации. Как только g_animationDone станет ИСТИНА ,
должна отображаться продолжительность. Ошибка синхронизации может возникнуть при вызове функции ShowDuration.
не дожидаясь индикации завершения анимации исчезновения. Анимация перезапишется
все, что попадает на экран. Вот как может выглядеть дефектный фрагмент кода:

StartAnimation (VANISH_ABILITY);
ShowDuration (ИСТИНА, g_vanishImmunityTime [уровень]);

И это будет правильный код:

StartAnimation (VANISH_ABILITY);
while (g_animationDone == FALSE)
; // ждем ИСТИНА
ShowDuration (ИСТИНА, g_vanishImmunityTime [уровень]);

Сборка / Пакет / Слияние


Сборка / упаковка / слияние или, проще говоря, дефекты сборки являются результатом ошибок при использовании исходного кода игры.

https://translate.googleusercontent.com/translate_f 40/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
библиотечная система, управляющая изменениями в файлах игры или определяющая и контролирующая, какие версии будут созданы.
Сборка - это процесс компиляции и связывания исходного кода и игровых ресурсов, таких как графика, текст и
звуковые файлы для создания исполняемой игры. Программное обеспечение для управления конфигурацией часто используется для
помогают управлять и контролировать использование игровых файлов. Каждый файл может содержать более одного актива или кода.
модуль. Каждый уникальный экземпляр файла идентифицируется уникальным идентификатором версии.

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

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

[PcOnly]

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

[TestRelease]

Определяет конкретный набор файлов для использования в выпуске для тестировщиков. Подразумевается, что программист
в некоторой степени уверен, что изменения будут работать. Если тестирование прошло успешно, следующим шагом может быть изменение метки.
к "официальному" номеру выпуска.
[Release1.1]

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

Стр. 51

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

Таблица 3.1: Типовые этикетки и способы их использования

Этикетка Применение

У каждого файла есть особый эволюционный путь, называемый основной линией . Любые новые версии файлов, производных
из одного, уже находящегося на основной линии, называются ветвями . Файлы в ветвях также могут иметь новые ветки
которые развиваются отдельно от первой ветви. Изменения, внесенные в одну или несколько веток, могут быть
в сочетании с другими изменениями, вносимыми параллельно в процессе, называемом слиянием . Слияние можно сделать
вручную, автоматически или с некоторой помощью системы управления конфигурацией, например
выделение конкретных строк кода, различающихся между двумя объединяемыми версиями. версия
tree обеспечивает графическое представление всех версий файла и их взаимосвязи. См. Рисунки 3.1.
через 3.3 приведены примеры того, как дерево версий развивается в результате добавления и обновления файлов в различных
способами.

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

Имея это в виду, давайте рассмотрим некоторые способы ошибки.

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

Также возможно, что спецификация конфигурации верна, но один или несколько программистов не сделали этого.
правильно обозначить версию, которая должна быть построена. Ярлык можно оставить, оставив позади на более раннем
version или введен неправильно, поэтому он не совсем соответствует метке в спецификации конфигурации.

Рисунок 3.1: Основная линия простого дерева версий.

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

https://translate.googleusercontent.com/translate_f 41/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Сложность слияния увеличивается, когда одна версия файла удаляет часть кода, которая была
обновляется версией, с которой происходит слияние. Если слияниями занимается настоящий живой человек, эти проблемы
может быть легче обнаружить, чем если бы компьютер сборки принимал эти решения и полностью изменял свои
собственный.

Стр.52

Рисунок 3.2: Дерево версий с ветвью.

Иногда код подсказывает, что со сборкой что-то не так. Комментарии в коде вроде //
ПРИНИМАЙТЕ ЭТО ПЕРЕД ОТПРАВКОЙ! может быть признаком того, что программист забыл переместить метку
или проверьте более новую версию файла в системе до начала процесса сборки.

Возвращаясь к рисунку 3.3, предположим, что для кода исчезновения следующее:


1. Версии 1 и 2 не отображают длительность исчезновения.

2. Версия 1.1 представила код отображения продолжительности.

3. Слияние версий 2 и 1.1 дает версию 3, но удаляет часть кода в версии 1.1, которая
отображает продолжительность.

Рисунок 3.3: Возвращение к основной линии.

Для ошибки отображения исчезновения, вот несколько возможных сценариев типа дефекта сборки:

https://translate.googleusercontent.com/translate_f 42/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. 53

В результате слияния версии 3 была удалена часть кода версии 1.1, отображающая
продолжительность. Версия 3 построена, но мы не видим отображения продолжительности.

Версии 1.1 и 2 были правильно объединены, поэтому в коде версии 3 будет отображаться продолжительность. Тем не мение,
метка, используемая спецификацией сборки, не была перенесена с версии 2 на версию 3, поэтому версия 2
строится, и мы не получаем отображения продолжительности.

Версии 1.1 и 2 были правильно объединены, поэтому в коде версии 3 будет отображаться продолжительность. Сборка
метка также была перенесена с версии 2 на версию 3. Однако спецификация сборки была жестко запрограммирована
для создания версии 2 этого файла вместо использования метки, чтобы не отображалась длительность.

Алгоритмы
К дефектам алгоритма относятся проблемы с эффективностью или правильностью, возникающие в результате некоторых вычислений или решений.
процесс. Думайте об алгоритме как о процессе достижения результата (например, ответ 42) или
результат (например, дверь открывается). Каждая игра наполнена алгоритмами, которые вы даже не можете
обратите внимание, правильно ли они работают. Неправильная разработка алгоритма часто лежит в основе способов, которыми люди могут
неожиданное преимущество в игре. Вот несколько мест, где можно найти алгоритмы и алгоритм
недочеты в играх разных жанров:
Виды спорта
Варианты игры, расстановки и замены соперника CPU

Торговые решения CPU

Моделирование постановки игры и принятия решений фактическим тренером или соперником

Индивидуальное поведение ИИ для всех позиций обеих команд в игре.

Определение угла камеры изменяется по мере того, как действие перемещается в различные части
поле / корт / лед и т. д.

Определение штрафов и судейских решений

Определение травм игрока

Развитие характеристик игрока в течение сезона

Включение специальных бонусов, наград или режимов (NBA Street Vol.2, NCAA Football 2005)

Ролевая игра, Приключение


Дружественные и враждебные диалоги персонажей

Боевые решения и действия противостоящего и дружелюбного персонажа

Расчет урона на основе навыков, брони, типа и силы оружия и т. Д.

Расчет спасброска

Определение результата использования навыка, например скрытности, крафтинга, убеждения и т. Д.

Расчет очков опыта и бонусы

Стоимость способностей, продолжительность и эффекты

Ресурсы и условия, необходимые для приобретения и использования способностей и предметов

Прицеливание оружия и способностей, область действия и урон с течением времени

Гонки

Стр.54

Характеристики драйвера ЦП, решения и поведение - когда нужно пит-стоп, использовать бонусы,
и т.п.

Расчеты повреждений и износа автомобилей, а также поведение поврежденных автомобилей

Нанесение ущерба автомобилю

Автоматическое переключение передач

Факторинговые эффекты окружающей среды, такие как поверхность пути, крен, погода

Насмешки с драйверами процессора

https://translate.googleusercontent.com/translate_f 43/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Казино, Коллекционные карточные игры, Настольные игры
Противоположные стили игроков и степень их мастерства

Применение правил игры

Внутренние правила, например, когда дилер должен оставаться в блэкджеке.

Варианты ставок и выплаты / награды

Справедливое распределение результатов, например отсутствие конкретного результата (карта, бросок кубиков, рулетка
число и т. д.) является предпочтительным

Боевые действия
Выбор центрального процессора: удар (наступление) и блок (защита)

Выбор команды CPU и переключение между ними во время боя

Расчет повреждений / точек, включая воздействие на окружающую среду

Расчет и визуализация боевых воздействий на окружающую среду

Расчет и учет усталости

Включение специальных приемов, цепочек и т. Д.

Стратегия
Движение противника CPU и боевые решения

Решения о создании и развертывании ЦП

Правила создания ресурсов и юнитов (предварительные условия, необходимые ресурсы и т. Д.)

Расчет повреждений и эффектов

Возможность использования новых юнитов, оружия, технологий, устройств и т. Д.

Шутеры от первого лица (FPS)

ЦП противник и товарищ по команде ИИ

Боевые решения и действия противостоящего и дружелюбного персонажа

Расчет урона на основе навыков, брони, типа и силы оружия и т. Д.

Прицеливание оружия, область действия и урон с течением времени

Влияние окружающей среды на скорость, урон игроку, отклонение или концентрацию


оружие (например, снаряды Unreal Tournament Flak Cannon будут отражаться от стен)

Головоломки

Стр.55

Баллы, активация бонусов и расчеты

Определение критериев завершения раунда или перехода на следующий уровень

Определение успеха целей головоломки, таких как формирование специального слова или сопоставление
определенное количество блоков

Включение специальных бонусов, наград или режимов

Еще больше усложняет ситуацию то, что некоторые игры включают в себя более одного игрового "типа" и его
алгоритмы. Например, Star Wars: Knights of the Old Republic (KOTOR) - это ролевая игра / приключенческая игра.
в котором также есть точки в сюжетной линии, где вы можете сыграть в карточную игру против неигровых персонажей в
играйте и участвуйте в гонках на свупах - но не одновременно! Unreal Tournament 2004 - это
обычно считается шутером от первого лица, но он также включает в себя приключенческие и спортивные элементы на разных этапах игры.
Турнир.

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

Для ошибки исчезновения рассмотрим сценарий неисправности алгоритма, в котором значение длительности вычисляется, а не
чем взяты из массива или файла. Также предположим, что продолжительность 0 или меньше не будет отображаться на
экран. Если расчет (алгоритм) дает сбой, всегда выдает 0 или отрицательное число, или
расчет вообще отсутствует, то длительность отображаться не будет.

Длительность иммунитета, предоставляемого Vanish, составляет одну секунду на уровне 1, две секунды на уровне 2 и пять.
секунд на уровне 3. Эту взаимосвязь можно выразить уравнением

vanishDuration = (2 << level) - уровень;

https://translate.googleusercontent.com/translate_f 44/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Таким образом, на уровне 1 это становится 2–1 = 1. Для уровня 2 4–2 = 2 и уровня 3 8–3 = 5. Вот результаты.
хотим, согласно спецификации.

А что, если бы случайно оператор модуля (%) был использован вместо оператора сдвига влево (<<)? Этот
даст результат 0-1 = -1 для Уровня 1, 0-2 = -2 для Уровня 2 и 2-5 = -3 для Уровня 3. Иммунитет
Продолжительность не будет отображаться, несмотря на наличие хорошего кода для отображения этой длительности пользователю.
Дефект алгоритма!

Документация
Дефекты документации возникают в основных активах данных, которые входят в игру. Сюда входят текст, аудио и
содержимое графического файла, как указано здесь:
Текст

Диалоги

Элементы пользовательского интерфейса (метки, предупреждения, подсказки и т. Д.)

Текст справки

инструкции

Журналы квестов

Аудио

Звуковые эффекты

Стр.56

Фоновая музыка

Диалог (человек, инопланетянин, животное)

Окружающие звуки (проточная вода, щебетание птиц и т. Д.)

Праздничные песни

видео

Кинематографические представления

Кат-сцены

Объекты окружения

Определения уровней

Выбор частей тела и одежды

Предметы (оружие, техника и т. Д.)

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

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

В примерах в этом разделе делается краткий обход ошибки Vanish и исследуются некоторые другие исправленные ошибки.
в выпуске Dark Age of Camelot 1.70i, которые появляются в конце списка «Новые вещи и исправления ошибок»:

Если что-то повреждает вас с помощью DoT, а затем умирает, вы увидите: «Теперь мертвый враг ударит вас за
X повреждений "вместо мусора.

Это может быть дефект типа документации, в котором для этого была указана ПУСКАЯ строка или нет строки.
конкретное сообщение, а не текст сообщения, который правильно отображается в новой версии. Тем не мение,
в коде могут быть другие причины. Обратите внимание, что эта проблема имеет условие «… а затем умирает», поэтому
возможно, есть этап проверки, который нужно было добавить для получения специальной текстовой строки. Точка на
помните, что описания дефекта обычно недостаточно для определения конкретного дефекта
типа, хотя это может помочь сузить круг вопросов. Кто-то должен вникнуть в плохой код, чтобы определить, как
возник дефект.

Грамматические исправления, внесенные в сообщения об ошибках, сообщения автотренинга и серьезные.


Сообщения об ошибках.

https://translate.googleusercontent.com/translate_f 45/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Это почти наверняка дефект типа документации. Никаких упоминаний о каком-либо конкретном состоянии не делается.
под которым они неверны. Ошибка грамматическая, поэтому текст был предоставлен и отображен, но текст
сам был неисправен.

Sabotage ML delve больше не относится к осадному снаряжению.

Это описание относится к выполнению команды / delve в игре для способности уровня мастера саботажа.
Быстрый вывод: это был дефект документации, исправленный путем исправления текста. Еще меньше
Вероятно, что текст углубления был получен для какой-то другой способности, подобной Саботажу, из-за ошибочного
индекс массива указателей - возможно, из-за дефекта присваивания или функции.

Стр.57

Интерфейсы
Последний тип дефекта ODC, который необходимо обсудить, - это тип интерфейса . Интерфейс возникает в любой момент
где информация передается или обменивается. Внутри кода игры дефекты интерфейса возникают при
что-то не так с тем, как один модуль обращается к другому. Если переданные параметры
как-то не совпадают с тем, что предназначено для процедуры вызова, тогда возникают нежелательные результаты. Дефекты интерфейса
могут быть представлены различными способами. К счастью, они тоже попадают в логические категории:

1. Вызов функции с неправильным значением одного или нескольких аргументов

2. Вызов функции с аргументами, переданными в неправильном порядке

3. Вызов функции с отсутствующим аргументом

4. Вызов функции с отрицательным значением параметра

5. Вызов функции с побитовым инвертированным значением параметра

6. Вызов функции с аргументом, увеличенным от предполагаемого значения

7. Вызов функции с аргументом, уменьшенным от предполагаемого значения

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

void ShowDuration (BOOLEAN_T bShow, int duration);

Эта процедура не возвращает никакого значения и принимает определенный в проекте логический тип, чтобы определить, следует ли
чтобы не отображать значение плюс значение продолжительности , которое должно отображаться, если оно больше 0. Итак, вот
Примеры дефектов типа интерфейса для каждой из семи причин:
1. ShowDuration (ИСТИНА, g_vanishSpeed ​
[уровень]);

В этом случае для получения продолжительности используется неправильный глобальный массив (скорость вместо продолжительности). Это могло, это может
приведет к отображению неправильного значения или отсутствию отображения вообще, если передан 0.
2. ShowDuration (g_vanishDuration [уровень], ИСТИНА);

Скажем, тип данных BOOLEAN_T # определен как int , поэтому внутри ShowDuration значение продолжительности
(первый параметр) будет сравниваться с ИСТИНА , а значение ИСТИНА (второй параметр) будет использоваться в качестве
номер для отображения. Если значение продолжительности не соответствует #define для ИСТИНА , то значение не будет
отображается. Кроме того, если TRUE равно #define d как 0 или отрицательное число, то значение не будет отображаться, потому что
нашего правила для ShowDuration, что длительность, меньшая или равная нулю, не отображается.

3. ShowDuration (ИСТИНА);

Значение продолжительности не указано. Если по умолчанию 0 в результате объявления локальной переменной в


ShowDuration , то значение отображаться не будет.
4. ShowDuration (TRUE, g_vanishDuration [уровень] | 0x8000);

Вот случай, когда код излишне причудлив и вызывает проблемы. Было сделано предположение, что
старший бит в значении длительности действует как флаг, который должен быть установлен, чтобы значение отображалось.
Это могло быть оставлено от более старой реализации этой функции или ошибки, допущенной при повторном использовании
код из какой-то другой функции. Вместо ожидаемого результата это меняет знаковый бит длительности.
ценность и отрицает это. Поскольку значение, используемое внутри ShowDuration, будет меньше нуля, оно не будет
отображается.
5. ShowDuration (ИСТИНА, g_vanishDuration [уровень] ^ ИСТИНА);

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

https://translate.googleusercontent.com/translate_f 46/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.58

следует ли отображать значение. В случае, когда ИСТИНА равно 0xFFFF , это инвертирует все биты в
длительность, заставляя его быть переданным как отрицательное число, таким образом изменяя его значение и предотвращая его
отображается.
6. ShowDuration (FALSE, g_vanishDuration [уровень + 1]);

Это может произойти, если сделано неверное предположение, что значение уровня необходимо увеличить до
начните с элемента массива 1 в течение первой продолжительности. Когда уровень равен 3, это может привести к нулевой продолжительности, так как
g_vanishDuration [4] не определен. Это предотвратит отображение значения.
7. ShowDuration (FALSE, g_vanishDuration [уровень-1]);

Здесь сделано неверное предположение, что значение уровня необходимо уменьшить, чтобы начать с массива
элемент 0 для первой продолжительности. Когда уровень равен 1, это может вернуть значение 0 и предотвратить изменение значения
отображается.

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

Стр.59

Резюме
Тестирование происходит.

Каждый раз, когда кто-то играет в игру, она проверяется. Когда кто-то обнаруживает проблему с игрой, он
производит впечатление. Бета-версия публикуется специально для тестирования. Не имеет
игра уже была тщательно протестирована перед выпуском бета-версии? Почему проблемы все еще обнаруживаются бета-версией

https://translate.googleusercontent.com/translate_f 47/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
тестеры? Даже после того, как игра будет выпущена для широкой публики, она все еще проходит испытания. Игровые компании
изо всех сил стараются выпускать патчи для исправления ошибок в компьютерных и онлайн-играх, но, к сожалению, издатели консольных игр
приходится жить с ошибками, записанными на игровой картридж или CD-ROM. Даже патчи могут пропустить
вещи или создать новые проблемы, которые должны быть исправлены в еще одном патче. Все эти ошибки сбежали из игры
платные и добровольные тестировщики компании.

Несмотря на все усилия всех участников игровой команды, игры складываются не так. Когда игры идут не так
это из-за дефектов, описанных восемью типами дефектов ODC, описанными в этой главе: Функция,
Назначение, проверка, сроки, сборка / упаковка / слияние, алгоритм, документация и интерфейс.

В «Воспоминаниях о константе», том III, глава IX, написано: «… есть много общего между
контрабандистов и полицейских, великое искусство контрабандиста - уметь прятаться, а
детектив, чтобы знать, как найти ». ( www.napoleonic-literature.com/Book_11/V3C9.html ) В этой главе
показал вам пути контрабандиста в надежде, что это сделает вас лучшим полицейским, тестирующим игры.

Стр. 60

Упражнения
1. Важно ли тестирование игры?

2. Какие типы дефектов, по вашему мнению, труднее всего найти тестировщикам? Объяснить, почему.

3. Перечислите пять ситуаций, в которых задания могут возникнуть в игре-симуляторе, например :


SIMS или Zoo Tycoon .

4. Перечислите пять типов алгоритмов, которые вы можете найти в игре-симуляторе.

5. Из следующего примера кода из общедоступного исходного кода Castle.


Wolfenstein: Enemy Territory , определите номера строк (добавлены в скобки), которые могут быть
источник дефекта для каждого типа дефекта ODC.

/ *
===============
RespawnItem
===============
* /
(0) void RespawnItem (gentity_t * ent) {
(1) // произвольно выбираем из объединенных сущностей
(2) if (ent-> team) {

https://translate.googleusercontent.com/translate_f 48/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
(3) kindity_t *владелец;
(4) int count;
(5) int выбор;

(6) if (! ent-> teammaster) {


(7) G_Error ("RespawnItem: плохой командир");
(8) }
(9) master = ent-> teammaster;

(10) for (count = 0, ent = master;


(11) ent;
(12) ent = ent-> teamchain, count ++)
(13) ;

(14) выбор = rand ()% count;

(15) для ( count = 0, ent = master;


(16) count <выбор;
(17) ent = ent-> teamchain, count ++)
(18) ;
(19) }
(20) ent-> r.contents = CONTENTS_TRIGGER;
(21) //ent->s.eFlags & = ~ EF_NODRAW;
(22) ent-> flags & = ~ FL_NODRAW;
(23) ent-> r.svFlags & = ~ SVF_NOCLIENT;
(24) trap_LinkEntity (ent);

(25) // воспроизводим обычный звук возрождения только для ближайших клиентов


(26) G_AddEvent (ent, EV_ITEM_RESPAWN, 0);

Стр.61

(27) ent-> nextthink = 0;


}

6. Было весело! Сделаем это еще раз с другим примером Wolfenstein :

/ *
============
G_SpawnItem

Устанавливает размер обрезки и устанавливает объект на пол.

Предметы нельзя сразу бросать на пол, так как они могут


быть на сущности, которая еще не появилась.
============
* /
(0) void G_SpawnItem (gentity_t * ent, gitem_t * item) {
(1) уголь * шум;

(2) G_SpawnFloat («случайный», «0», & ent-> случайный);


(3) G_SpawnFloat ("ждать", "0", & ent-> ждать);

(4) ent-> item = элемент;


(5) // некоторые двигатели появляются во втором кадре, поэтому задерживаем элемент
(6) // появляется до третьего кадра, чтобы они могли ездить на поездах
(7) ent-> nextthink = level.time + FRAMETIME * 2;
(8) ent-> think = FinishSpawningItem;

(9) if (G_SpawnString ("шум", 0, & шум))


(10) ent-> noise_index = G_SoundIndex (шум);

(11) ent-> PhysicsBounce = 0.50; // предметы подпрыгивают

(12) if (ent-> model) {


(13) ent-> s.modelindex2 = G_ModelIndex (ent-> модель);
(14)}

(15) if (item-> giType == IT_TEAM) {


(16) G_SpawnInt ("количество", "1", & ent-> s.de density);
(17) G_SpawnInt ("шкала скорости", "100", & ent-> splashDamage);
(18) if (! ent-> splashDamage) {
(19) ent-> splashDamage = 100;

https://translate.googleusercontent.com/translate_f 49/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
(20) }
(21)}
}

Ответы

Стр.62

1. Да.

2. Ответ специфичен для читателя.

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

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

5. Возможные типы дефектов RespawnItem :

Функция - от 1 до 19 (случайный выбор), 20–24 (флаги установки и использования), 25–26 (воспроизведение возрождения).
звук)
Задание - 9, 10 (2), 12 (2), 15 (2), 17 (2), 20, 27.

Проверка - 2, 6, 11, 16

Время - 26

Сборка / упаковка / слияние — 21

Алгоритм - 14, 22, 23

Документация - 7 (буквальная строка используется для сообщения об ошибке)


Интерфейс - 0, 7, 24, 26

6. И снова для G_SpawnItem :


Функция - 2-8 (предмет вызова), 9-10 (издавать звук), 15-20 (наносить урон). Другие строки, такие
как 11, установить значения, но не выполнять функцию в этой подпрограмме.

Присвоение - 1 (возможно отсутствие инициализации локальной переменной), 4, 8, 10, 13, 19

Проверка - 9, 12, 15, 18

Время - 7 (если этой строки нет, время появления может быть неправильным)

Сборка / Пакет / Слияние - нет

Алгоритм - 7

Документация - нет (строки, переданные функциям в этой подпрограмме, не предназначены для


отображается как текст)

Интерфейс - 0, 2, 3, 8, 9, 10, 13, 16, 17.

https://translate.googleusercontent.com/translate_f 50/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.63

Часть II: Создание игр


Список глав

Глава 4: Игровая команда

Глава 5: Цикл производства игры

Стр.64

Глава 4: Игровая команда


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

https://translate.googleusercontent.com/translate_f 51/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
организованы в отдельные команды внутри общей игровой команды. Люди в игровой команде должны работать
вместе, чтобы выполнить задачи, необходимые для выполнения игры вовремя и без серьезных дефектов.
В этой главе рассматриваются типичные командные роли, различные команды внутри игровой команды и некоторые типичные способы
люди организованы в команды и игровые проекты.

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

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

Руководитель разработки также устанавливает технические процедуры и стандарты. Обычно он отвечает за


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

В ходе проекта ведущий разработчик обеспечивает техническое руководство и помощь другим


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

В небольших группах разработчиков игр руководитель разработки также отвечает за разработку некоторых из
код.

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

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

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

Стр.65

Программисты также могут участвовать в переносе игрового кода с одной платформы на другую. Определенный
части кода должны остаться прежними, тогда как другие должны быть изменены, чтобы приспособить
отличия в новой платформе. Перенос с Xbox на ПК может быть не так уж и сложен из-за платформы
сходства с точки зрения операционной системы и базовых API DirectX. Однако версия для ПК должна
учитывать различные разрешения экрана, видеокарты, установленную память, аудиоустройства и ввод
устройств. Переход с Xbox на PS2 вызовет другой набор проблем, а перенос ПК или консоли
игра, такая как True Crime: Streets of LA, на мобильное или портативное устройство может превратиться в совершенно новую
усилия по проектированию и развитию.

Некоторые команды или проекты могут определять своих программистов по их конкретной сфере ответственности или
специальность. В Интернете есть список вакансий по следующим специальностям программистов. Каждый из
у них есть свой собственный набор навыков и обязанностей.

Программист консолей нового поколения

Программист двигателя PS2

Программист консоли Xbox / GameCube

Программист Max Tools

Беспроводной разработчик

Онлайн-программист PS2

Программист спецэффектов

https://translate.googleusercontent.com/translate_f 52/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Младший (сценарий) программист

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

Обязанности инженера по сборке могут включать следующее:


1. Настройка библиотек кода и игровых ресурсов и файловых структур

2. Определять и поддерживать спецификации сборки для каждого выпуска

3. Выполнить слияние

4. Делайте сборки

5. Сделайте "тест на работоспособность" после сборки

6. Документируйте и публикуйте примечания к выпуску для команды

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

Какие недочеты предполагается исправить в новой сборке.

Какой новый код был добавлен с момента предыдущей сборки.

Какой код изменился с момента предыдущей сборки.

Какие ошибки сборки или предупреждения были выданы компилятором или компоновщиком.

Стр.66

Сколько памяти (RAM и ROM) используется игрой.

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

https://translate.googleusercontent.com/translate_f 53/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.67

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

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

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

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

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

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

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

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

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

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

https://translate.googleusercontent.com/translate_f 54/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.68

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

За свои усилия бета-тестеры могут быть вознаграждены различными способами, например:

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

чтобы сохранить своих персонажей

получение первых фишек на конкретных именах персонажей

хвастаться правом быть первым в своем блоке, кто увидит и узнает все об игре еще до того, как она
был выпущен

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

их имена указаны в титрах игры, в коде игры и / или в печатном руководстве к игре.

Стать бета-тестером - хороший способ для тех, у кого нет формального обучения или игровой индустрии.
опыт, чтобы составить резюме достижений. Один из способов привлечь внимание к своей работе - найти
о важных дефектах и ​профессионально сообщайте о них, как описано ранее в этой книге. Ты можешь идти
на www.betawatcher.com, а также на веб-сайты игровых компаний, чтобы проверить наличие последнего бета-теста
новости и возможности.

Стр.69

Команда художников

https://translate.googleusercontent.com/translate_f 55/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Без команды художников мы бы играли только в текстовые игры, такие как Colossal Caverns или Pirate.
Приключение . Ожидания публики от художественного опыта игры выше, чем когда-либо.
Уже вышли названия, основанные на таких фильмах, как « Властелин колец» , « Человек-паук» и « Звездные войны».
со встроенным ожиданием визуального опыта игры, аналогичного тому, что вы увидите в фильме
театр. Это ожидание охватывает реалистичность рисунка, движений персонажей и используемых ракурсов.
для рендеринга и представления игровых сцен на экране.

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

Раскадровки - это средство для захвата последовательности сцен, которые будут происходить во время развития сюжета.
игра. Их можно использовать для создания художественного направления и последовательности для игры с линейным сюжетом.
таких как StarWars: Knights of the Old Republic , или используется для планирования сцен для других типов игр, как показано на
следующие примеры спортивных игр. Видение арт-директора обеспечивает последовательность и близость, когда
игра является продолжением предыдущей сюжетной линии, следует сюжету фильма или является новейшей версией продолжающегося
франшиза. При тестировании игры необходимо вызвать появление каждой из различных сцен, чтобы убедиться, что они
появляются в игре и правильно отображаются в соответствии с намерениями арт-директора.
Футбольные сцены (например, НФЛ).

Подбрасывание монет

Подать мяч

Игрок в нападении

Игрок в защите

Рефери объявляет штраф

Тренер спорит с судьей

Празднование игрока после приземления

Травмированный игрок удален с поля

Удар по дополнительному очку или попаданию с игры

Сцены бейсбольного матча

Тесто подходит к тарелке

Качка кувшина

Баттер реагирует на удар смолой

Баттер отправляется на прогулку на первую базу

Ловец выбрасывает бегуна, пытающегося украсть

Улавливатель и бегун сталкиваются у плиты

Стр.70

Менеджер спорит с судьей

Команда в землянке празднует

Тренер выходит на замену питчера

Сцены баскетбольного матча

Открытие подсказки

Регулярная игра на площадке

Рефери фиксирует нарушение

Игрок выполняет бросок с линии штрафного броска

Игрок данк

Игроки скамейки реагируют на игровые события

Игрок заменен в

Дежурный вытирает пот с двора

Чирлидеры выступают в перерыве между таймами

https://translate.googleusercontent.com/translate_f 56/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Сцены хоккейного матча

Вбрасывания

Регулярная игра вверх и вниз по льду

Игроки сражаются

Рефери назначает пенальти

Игрок реагирует в штрафной

Игрок реагирует на спасбросок вратаря

Пенальти

Игроки выходят на лед и выходят из него во время остановки игры

Травмированный игрок унесен со льда

Игрок исключается из игры

Футбол («настоящий» футбол). Сцены из игры


Команды позируют для фото перед игрой

Открытие владения мячом в центре поля в начале каждого тайма

Игрок реагирует на фол

Судья дает желтую или красную карточку

Угловой

Штрафной удар

Вратарь реагирует на попадание в ворота

Игроки празднуют гол

Стр.71

Пенальти

Команда-победитель празднует конец игры

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

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

Сила искусства

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

Из превью выпуска Snowblindin № 34 официального журнала Xbox.

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

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

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

https://translate.googleusercontent.com/translate_f 57/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
игра с поведенческими и текстовыми изменениями, такими как изменение имен юнитов или определение нового типа оружия
который может стрелять из миномета по горизонтали. Другой распространенный тип мода - создание новых карт или
изменить существующие карты, чтобы отразить крупные города, такие как Нью-Йорк или Чикаго. Остальные моды сделаны для
цель - придать игре совершенно новый вид, например, заменить существующих игровых персонажей и
элементы из Simpsons или DragonballZ .

Вот список игровых элементов, которые могут быть изменены или добавлены модами:

Карты

Модели персонажей

Скины персонажей

Экраны запуска

Оружие

Транспортные средства

Стр.72

Самые популярные игры для моддинга - это игры с боями, боевиками, шутерами от первого лица или ролевыми играми.
такие темы, как StarWars: Knights of the Old Republic , Unreal Tournament и Battlefield 1942 . Некоторый
модифицируемые игры, которые попадают в другие категории: SimCity 3000 , Midnight Club 2 и MVP Baseball.
2004 .

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

Некоторые компании или проекты могут создавать специализированные должности артистов с такими названиями, как:
2D художник

3D Художник

Художник по окружению

Художник по текстурам

Художник по машинам

Модельер персонажей

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

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

Рисунок 4.1: 3D каркас каркаса.

https://translate.googleusercontent.com/translate_f 58/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.73

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

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

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

В спортивных играх анимация персонажей очень важна, потому что есть определенные ожидания в отношении
как должно выглядеть конкретное действие, например, бросок бейсбольного мяча, бросок футбольного мяча или нанесение удара. В
Чтобы не выглядеть как робот, может быть множество анимаций, разбитых на разные категории для каждого
Мероприятия. Например, в бейсболе может быть предусмотрена анимация броска как из пистолета, так и сверху.
кувшины. Во время игры следует выбирать правильную анимацию в зависимости от реального стиля питчера.
Некоторые игры идут дальше, предоставляя анимацию для одного или нескольких игроков в зависимости от их специфики.
стиль и оснащение. Также должны быть анимированы элементы спортивного инвентаря. Шары вращаются при броске,
пнули или ударили. Летучие мыши разлетаются, когда ломаются. Шлемы и мундштуки разлетаются после сильных ударов. Перчатки гибкие
и отскок при получении мяча.

Взрывные и разрушительные эффекты придают игре азарт и остроту. Взрыв мог произойти
от конца пистолета или от дистанционного взрыва. Будет центральный основной эффект, такой как
расширяющийся шар света с последующими эффектами, такими как дым или сотрясение. Сам взрыв
может отправить в полет камни, транспортные средства или ваших противников. Камни или стены могут сломаться, когда игрока отправляют
врезаться в них.

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

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

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

Определение формы уровня и маршрутов, по которым вы можете путешествовать по уровню.

Выбор плиток, сеток и текстур в соответствии с тематикой уровня и игры.

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

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

Стр.74

ценный камень.

Размещение «точек защемления», которые замедляют действие и позволяют загружать новые игровые ресурсы.

https://translate.googleusercontent.com/translate_f 59/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Размещение и маркировка путей, дверей или шлюзов, ведущих на новый уровень.

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

Стратегия тестирования для каждого уровня должна включать элементы, перечисленные в таблице 4.1.

Таблица 4.1: Контрольный список проверки уровня

Проверить размещение и поведение предметов на уровне

Проверьте размещение и поведение NPC

Проверьте соответствие и форму каждой уникальной плитки, сетки и текстуры, используемых на уровне.

Проверьте функцию и время загрузки переходов с одного уровня на другой

Стр.75

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

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

https://translate.googleusercontent.com/translate_f 60/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Виды спорта
Шум толпы: аплодисменты, свист, окружение, продавцы

Звуки движения игрока: бег, катание, плавание и т. Д.

Один объект ударяет другой: мяч и перчатка, мяч и летучая мышь, мяч и ступня и т. Д.

Столкновения игроков

Насмешки игроков

Дикторы и тренеры

Погодные эффекты: дождь, гром, ветер

Ролевая игра, Приключение


Колдовство и эффекты заклинаний

Стрельба из оружия, столкновение и эффекты

Звуки существа: ходьба, кряхтение, вой и т. Д.

Звуки автомобиля

Диалог игрока и NPC

Гонки

Звуки двигателя автомобиля: запуск, переключение передач и т. Д.

Звуки колес: торможение, вращение, прохождение поворотов и т. Д.

Дорожные эффекты: выбоины, лужи, съезды и т. Д.

Звуки открывания и закрывания: дверей, капота, багажника, ремня безопасности и т. Д.

Сирены: полиция, скорая помощь, пожарная машина и т. Д.

Звуки при включении

Стр.76

Диалог и насмешки

Казино, Коллекционные карточные игры, Настольные игры

Окружающие звуки: окружающая среда, толпа

Укажите успех или неудачу поворота

Движение и размещение фигур: карт, кубиков, блоков, фишек на доске и т. Д.

Звуки ставок: внесение монеты, укладка фишек и т. Д.

Боевые действия
Звуки оружия

Ударные и блокирующие звуки

Звуки окружающей среды: погода, арена и т. Д.

Звуки толпы: ура, бу, эмбиент

Дикторы

Насмешки игроков и NPC

Стратегия
Звуки боя

Принять или отклонить действие

Движение юнитов

Создание агрегатов и строений

Укажите достигнутую цель, команду или веху

Предупреждение о действиях противника

Шутеры от первого лица (FPS)


Игрок бежит, идёт

https://translate.googleusercontent.com/translate_f 61/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Подбор, загрузка и перезарядка боеприпасов

Эффекты стрельбы из оружия: выстрел, взрыв, молния и т. Д.

Команды игрока и NPC, подтверждения и насмешки

Звуки автомобиля

Звуки существа: ходьба, кряхтение, вой и т. Д.

Головоломки
Укажите достигнутую цель, команду или веху

Укажите успех или неудачу хода

Укажите увеличение или уменьшение точки

Тиканье таймера и предупреждения

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

Стр.77

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

Музыкальный руководитель / продюсер


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

Вот несколько примеров того, как песни популярных исполнителей были включены в видеоигры:

Выбор музыкального автомата в The Crib ( ESPN NFL 2K5 ), который также можно выбрать для музыки на стадионе
во время домашних игр

Настройка на радиостанции за рулем угнанной машины ( Grand Theft Auto: Vice City )

Музыка для танцевальных конкурсов ( Britney's Dance Beat , Dance Dance Revolution Ultramix )

https://translate.googleusercontent.com/translate_f 62/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.78

Другие технические роли


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

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

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

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

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

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

Одновременно будут тестироваться две игры; может не хватить тестировщиков для обоих.

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

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

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

Игровой дизайнер
Гейм-дизайнер обычно - это человек, который несет основную ответственность за разработку и определение
игра, которую вы тестируете. Он рассказчик, артист и изобретатель в одном лице. Это его концепции
которые порождают игровые миры, персонажей и мифологии. Настойчивость - полезная черта для игры
дизайнеры, которым, возможно, придется сделать много предложений, прежде чем получить одобрение игровой компании, чтобы продолжить
и сделай игру.

Разработчик игры также пытается определить игровую механику, которую легко изучить, запомнить и получить к ней доступ.
во время игры. Успешные игры приводят к сиквелам и становятся стандартом, которому соответствуют новые игры.
по сравнению. Некоторыми примерами успешных долговечных дизайнов являются Pokémon , Final Fantasy , Madden.

Стр.79

https://translate.googleusercontent.com/translate_f 63/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Титулы Football и Ultima . При тестировании любой новой игры из серии вы безоговорочно принимаете на себя ответственность
для проверки последовательности и преемственности со своими предшественниками.

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

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

Рисунок 4.2 показывает игру диаграмма состояний потока из игрового дизайна документа для Super Street Racer ,
который был разработан студентами курса игрового программирования в Университете Калгари. Рисунок 4.3.
показывает макет экрана для экрана дилерского центра, также из документа по дизайну игры. Тестеры
может использовать эту информацию, чтобы как можно раньше приступить к планированию и созданию тестов для игры. Полный
документ находится на компакт-диске, прилагаемом к этой книге.

Рисунок 4.2: Поток состояний игры Super Street Racer .

Стр. 80

Рисунок 4.3: Внешний вид экрана представительства Super Street Racer .

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

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

Таблица 4.2: Контрольный список проверки макета экрана

Убедитесь, что каждая заданная область отображается на экране

Убедитесь, что текст в каждом регионе правильный

https://translate.googleusercontent.com/translate_f 64/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Убедитесь, что графика в каждом регионе верна

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

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

Убедитесь, что кнопки управления в каждом регионе работают правильно

Убедитесь, что значения или графика в каждом регионе не изменяются и не исчезают, кроме случаев, когда
решил сделать это

Стр. 81

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

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

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

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

https://translate.googleusercontent.com/translate_f 65/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Рисунок 4.4: Матрица ролей / назначений в проекте.

В небольших игровых компаниях может одновременно быть достаточно людей только для одной игры, поэтому один и тот же человек
могут иметь разные роли. Команда Digital Eel, создавшая игру Dr. Blob's Organism, включает:
один человек, который внес свой вклад в код, дизайн и искусство, а другой - над дизайном, искусством и
звук. Простая диаграмма или электронное письмо могут сообщить всем, кто чем занимается.

Стр.82

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

https://translate.googleusercontent.com/translate_f 66/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. 83

Упражнения
1. Существуют ли игровые команды?

2. Перечислите все переходы между состояниями игры для диаграммы состояний игры на рис. 4.2 .

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

4. В части экрана «Вид транспортного средства», показанной на рис. 4.3 , отображается транспортное средство.
выбирается, щелкая стрелки влево и вправо под окном обзора транспортного средства. Напишите хотя бы
три теста для проверки правильности совместной работы этих двух функций.

5. 5. Представьте, что ваш дом, квартира, общежитие или любимый магазин - это первый уровень крупного
ролевая игра, которую разрабатывает ваша компания. Используя контрольный список проверки уровня в Таблице 4.1 ,
напишите набор тестов для этого уровня вашей игры. Начните с перечисления элементов, которые применяются (для
например, NPC, текстуры, двери и т. д.) до вашего уровня, а затем напишите тесты для каждого элемента,
согласно чек-листу.

Ответы

1. Команды разработчиков, тестовые команды, арт-команды, звуковые команды и матричные команды

2. а. Начать игру в Front-End

б. Front-End в стартовую сетку

c. От Front-End до End Game

d. От сетки к гонкам

е. Подведение итогов гонки к гонке

f. Гонка до паузы

грамм.
Пауза в Front-End

час Пауза в стартовой сетке

я. Пауза в гонке

j. Пауза до окончания игры

k. Подведение итогов гонки до Front-End

л. Подведение итогов гонки к стартовой решетке

м. Подведение итогов гонки до конца игры

3. а. Начать в стартовую сетку

б. Начать гонку

c. Подведение итогов старта гонки

d. Начать паузу

е.

Стр. Решебника 84

https://translate.googleusercontent.com/translate_f 67/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

d.

е. От начала до конца игры

f. Front-End на паузу

грамм.
Front-End для гонок

час Фронтенд к гонке: итоги

я. Начальная сетка к Front-End

j. Запуск сетки на паузу

k. Подведение итогов от стартовой сетки к гонке

л. Стартовая сетка до конца игры

м. Гонка к Front-End

п. Гонка к стартовой решетке

о. Гонка до конца игры

п. Пауза перед финалом гонки

q. Подведение итогов гонки к гонке

р. Подведение итогов гонки до паузы

4. Некоторые тесты с обзором вращающегося транспортного средства:


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

б. С первого автомобиля: щелкните один раз стрелку влево, дождитесь, пока новый автомобиль не повернет на 360 градусов. Проверять
для плавного вращения, появления трещин или мерцания графики. Повторяйте, пока не вернетесь сначала
транспортное средство.

c. От первого автомобиля: щелкните один раз стрелку вправо, дождитесь, пока новый автомобиль не повернет на 360 градусов.
Проверьте, нет ли на графике плавного вращения, трещин или мерцания. Щелкните стрелку влево один раз. Проверь это
первый автомобиль показан и вращается правильно.

d. С первого автомобиля: щелкните один раз стрелку влево, дождитесь, пока новый автомобиль не повернет на 360 градусов. Проверять
для плавного вращения, появления трещин или мерцания графики. Щелкните стрелку вправо один раз. Проверьте это в первую очередь
автомобиль показан и вращается правильно.

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

f. С первого автомобиля: быстро нажмите стрелку влево, затем вправо, убедитесь, что первое транспортное средство показано и вращается.
должным образом.

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

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

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

II.

Стр.85

я.

II. проверьте, что левая и правая задние двери открываются и закрываются в обоих направлениях

iii. проверьте пост охраны, расположенный за задней дверью справа, когда вы войдете

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

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

vi. убедитесь, что при подъезде лифта на первый этаж его двери открываются и кнопка вызова
свет гаснет, если он был зажжен

Б. Проверить поведение и размещение неигровых персонажей


я. убедитесь, что охранник стоит на посту охраны

II. убедитесь, что охранник приветствует вас, когда вы входите через заднюю дверь

https://translate.googleusercontent.com/translate_f 68/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

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

II. проверьте цвет металлической дверной ручки, отражательную способность и совместимость со стеклянной дверью

iii. проверить текстуру и блеск мраморного пола и настенной плитки

iv. проверить прилегание кромок мраморной плитки к стенам и дверям лифта

v. проверить текстуру стальной двери лифта и отражательную способность для каждого лифта

Д. Проверить функции и время загрузки переходов с одного уровня на другой


я. проверьте, нет ли заметных перерывов или мерцания в игровом процессе при входе через
либо входная дверь

II. убедитесь, что нет заметных разрывов или мерцания игрового процесса при входе через
задняя дверь

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

Стр.86

Глава 5: Цикл производства игры


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

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

1. Развитие концепции

2. Подготовка к производству

3. Разработка

4. Альфа

5. Бета

6. Замораживание кода

7. Выпуск в производство (RTM)

8. Патчи

9. Обновления

https://translate.googleusercontent.com/translate_f 69/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. Решебника 87

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

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

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

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

Документы, которые появляются в результате разработки концепции, - это высокая концепция, предложение игры (или
"pitch doc") и концептуальный документ.

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

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

Высокая концепция должна включать некоторые из следующих элементов, адаптированных из списка Бонни Орр на
screentalk.biz [1] :

1. У игрока должна быть БОЛЬШАЯ ПРОБЛЕМА. Если в вашей игре есть сюжетная линия, в ней должна быть
как внутренний, так и внешний конфликт.

2. Некоторые визуальные сцены огромны. Мы не видим в небе пары истребителей. Мы видим


десятки или сотни!

3. Игрок - обычный герой в необычном мире или неординарный герой в обычном мире.
Мир. Solid Metal Gear серии о выдающемся человеке. Final Fantasy Tactics Advance
использует обычный мальчик.

4. Концепция должна быть оригинальной. Может быть несколько игр про борьбу с инопланетным вторжением,
но что, если история написана с точки зрения инопланетянина (например, Гоминида-пришельца )?

5. Эта концепция представляет собой разновидность известной успешной игры.

https://translate.googleusercontent.com/translate_f 70/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Предложение по игре («Презентационный документ»)
Предложение игры - это раздаточный материал на двух страницах, на котором вы говорите во время питч-встреч, чтобы найти финансирование для своей
игра. Всего на нескольких страницах вы должны кратко изложить, о чем ваша игра, почему она будет успешной и
как это будет зарабатывать деньги. Этот документ охватывает ту же территорию, что и концептуальный документ, но в
сокращенная форма.

Концептуальный документ

Стр.88

Концептуальный документ является конкретизирован выходом версии кромешного дока. Это 10–20 страниц, оставленных после того, как
у членов команды публикации не будет времени на обзор во время питча, но они захотят
Прочтите потом, чтобы получить более подробное представление о вашей игре.

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

Высокая концепция

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

Жанр

Объясните, к какому жанру принадлежит ваша игра, а также укажите элементы перехода на другие жанры, если применимо.

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

Функции

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

Параметр

Опишите мир, в котором разворачивается ваша игра. Включите концепт-арт, если он у вас есть. Если это сюжетная игра,
выделите наиболее интересные особенности сеттинга и объясните, как они влияют на сюжет. Рисунок 5.1 показывает
фрагмент концепт-арта, использованный в игре « Джеймс Бонд 007: Все или ничего» .

Рисунок 5.1: Концепт-арт поезда «преследование» из « Все или ничего» .

Сказка
Если в вашей игре есть сюжет, возьмите страницу или около того, чтобы кратко изложить сюжет. Представьте главного героя, определите
свою проблему, опишите злодея и объясните, как герой в конечном итоге его победит. Эта часть может также
включить диаграмму рассказа. На рис. 5.2 показаны различные шаблоны, которые можно использовать для рассказа истории вашей игры.

https://translate.googleusercontent.com/translate_f 71/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.89

Рисунок 5.2: Шаблоны рассказов разной длины и сложности.

Целевая аудитория
Объясните, для кого вы разрабатываете игру и почему вы думаете, что она им понравится. Вы также можете
укажите, какой рейтинг ESRB (Entertainment Software Rating Board) вы ожидаете получить за
игра: для детей младшего возраста, для всех, для подростков, для взрослых или только для взрослых.

Аппаратные платформы
Перечислите устройства, на которых будет играть игра: ПК, консоли, карманные компьютеры, мобильные телефоны и т. Д.

Предполагаемый график, бюджет и прибыль и убытки

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

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

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

Вы не можете самостоятельно вычислить все значения прибылей и убытков. Работаем с несколькими подразделениями
компании, чтобы дать достоверные оценки:

Группа разработчиков покрывает прямые затраты на создание игры. Это получается путем умножения
оценка человеко-месяцев по заработной плате группы с добавлением затрат на оборудование, накладных расходов,
и любые внешние расходы (плата за лицензию на технологию, запись голоса, съемку Full Motion Video (FMV),
и так далее).

От производственной группы исходит оценка себестоимости (COGS). Это затраты на


физические материалы, которые входят в коробку с игрой - носители, футляр для драгоценностей, руководство, сама коробка,
и так далее.

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


в журнальной рекламе, телевизионной рекламе, дисплеях в местах продажи, рекламных листах и ​т. д.

Стр. 90

Из группы продаж поступают расходы Фонда развития рынка (MDF), которые оплачивает издатель.
магазины в розничном канале для получения основного места на полках, заглушек, говорящих с полок и рекламы в своих проспектах.

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

От бизнес-группы поступают скидки на возврат, корпоративные накладные расходы и расчеты на


выплаты роялти, если ваша игра основана на внешней лицензии.

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

https://translate.googleusercontent.com/translate_f 72/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
убедите их, что ваша игра будет достаточно прибыльной, чтобы оправдать риск, она никогда не будет одобрена.

Конкурентный анализ

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

Команда

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


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

Анализ риска
Опишите все, что может пойти не так, и как вы планируете справляться с проблемами, которые могут возникнуть. Некоторый
общие риски, которые угрожают проектам,

Трудности с подбором персонала

Несвоевременная доставка консольных dev-kits

Опора на внешние источники для ключевых технологических компонентов

Изменения в установленной базе целевой платформы

Конкурентоспособные технологические разработки

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

Резюме
Целью разработки концепции является создание предложения игры и концептуального документа. Эти должны
подчеркивать ключевые моменты вашей игры и способность вашей команды предоставлять качественный продукт в срок
и по бюджету. В качестве тестировщика или руководителя тестирования предоставьте оценку графика, оцените затраты на испытательное оборудование.
для бюджета и определите тестовые риски для анализа рисков.
[1] Орр, Бонни. (2002). «Высокая концепция». СКРИНТАЛЬК. < http://www.screentalk.biz/art043.htm> (19

Январь 2005 г.).

Стр.91

Подготовка к выпуску (подтверждение концепции)


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

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

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

Документ игрового дизайна


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

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

https://translate.googleusercontent.com/translate_f 73/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Такой документ, если бы он был записан на бумаге, был бы размером с телефонный справочник, и его невозможно было бы записать.
поддерживаются, никем не читаются и почти мгновенно устаревают. Вместо этого поместите его во внутреннюю сеть как набор
веб-страниц. См. Www.openwiki.com, чтобы узнать о методологии, которая упрощает эту задачу.

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

План производства произведений искусства


Препродакшн - это когда вы устанавливаете «внешний вид» своей игры и решаете, как будет создаваться искусство.

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

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

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

Путь производства

Стр.92

Путь производства - это процесс перехода от идеи к реальности, от идеи в чьей-то


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

Активы, бюджеты, задачи и графики

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

Документ технического дизайна


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

Кроме того, TDD определяет

Какие основные инструменты будут использоваться для создания игры

Какие инструменты уже есть в наличии

Какие инструменты нужно купить или создать

Какое оборудование и программное обеспечение необходимо приобрести

Какие изменения необходимо внести в инфраструктуру вашей организации, например, в емкость хранилища,
возможности резервного копирования и скорость сети - для поддержки разработки

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

План рабочей силы


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

План ресурсов

https://translate.googleusercontent.com/translate_f 74/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
План ресурсов рассчитывает все внешние затраты проекта. Из технического плана требуется время
оборудование закупается для поддержки внутреннего персонала, и он оценивает, когда внешние затраты (голос,
музыка, видео и т. д.) будут понесены.

Документ по отслеживанию проекта

Здесь вы отслеживаете, соблюдаете ли вы график. Некоторые продюсеры используют управление проектами


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

Стр.93

доморощенные методы отслеживания проекта.

Бюджет
После применения множителей накладных расходов к плану трудовых ресурсов вы объедините эти числа с
ресурсный план для расчета ежемесячных потребностей в денежных средствах и общего бюджета игры.

P&L

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

График разработки

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

Определения вех

Вехи - это важные моменты в развитии, отмеченные завершением определенного объема работ (
результат ). Эти результаты должны быть конкретными и очень точными, с такими формулировками, как
«Эскизы пятнадцати персонажей спереди, сбоку и сзади» или «Оружие №1 смоделировано, снято со шкуры и
работает в игре со звуковым эффектом-заполнителем, но без анимации или визуальных эффектов ".

Избегайте нечетких результатов, таких как «Дизайн выполнен на 25%». Лучшие результаты - бинарные: они
либо завершены, либо нет, и между ними нет места для споров.

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

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

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

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

https://translate.googleusercontent.com/translate_f 75/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.94

Стр.95

Разработка
Развитие - это долгий путь.

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

https://translate.googleusercontent.com/translate_f 76/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
функции, превзойденные
эти проблемы илиперепроектирование
могут вызвать украденные другимиииграми, иличто,
переделку, увидеть, как
в свою технологии
очередь, перекрываются
приведет к задержкамдостижениями
в графике. аппаратного обеспечения. Любой из

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

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

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

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

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

Вот несколько нетехнических советов, как выжить на этапе разработки:

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

Поддерживайте хорошее общение в команде. Поддерживайте актуальность и доступность проектной документации


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

Отслеживайте свои фактические расходы по сравнению с вашим бюджетом.

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

Стр.96

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


а функции зарядят вашу команду энергией, когда у них будет плохое настроение.

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

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

Наконец, приготовьте несколько функций, которые помогут вам управлять прицелом.

https://translate.googleusercontent.com/translate_f 77/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.97

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

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

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

https://translate.googleusercontent.com/translate_f 78/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.98

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

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

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

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

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

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

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

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

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

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

https://translate.googleusercontent.com/translate_f 79/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. 99

все тонкости создания финального диска - это верный путь к катастрофе.

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

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

Стр. 100

Замораживание кода
Это не тот этап, когда вы выносите свой мастер-диск в Сиэтл в середине января. Скорее на
в конце бета-тестирования вы, вероятно, будете в замороженном состоянии , когда вся работа будет сделана и подготовка
кандидат в мастера дисков начинается. Каждый из этих дисков отправляется на тестирование. Единственные изменения, разрешенные в

https://translate.googleusercontent.com/translate_f 80/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
кодовая база - это те, которые специально обращаются к возникающим ошибкам showstopper.

Стр.101

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

https://translate.googleusercontent.com/translate_f 81/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.102

Патчи
Что касается ПК, то почти неизбежно, что игра получает исправления после ее выпуска.
Вопреки мнению, выраженному на досках сообщений в Интернете, это не обязательно потому, что
Разработчик поспешил выбросить плохо протестированный продукт. В мире, где буквально тысячи
Аппаратные комбинации существуют, проверить их все так же буквально невозможно. Когда покупатель находит
что его конкретная комбинация BIOS, видеокарты, звуковой карты, монитора, процессора, операционной системы,
клавиатура, мышь и джойстик вызывают проблемы в игре, большинство разработчиков будут работать с ним, чтобы понять
из источника проблемы. Если проблема достаточно распространена, разработчик выпускает патч.

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

https://translate.googleusercontent.com/translate_f 82/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.103

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

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

Многие компании, предлагающие многопользовательские игры, проводят для своих подписчиков сезонные или праздничные мероприятия, которые
может включать специальные ограниченные по времени миссии, варианты изготовления и / или выпадение предметов.

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

https://translate.googleusercontent.com/translate_f 83/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.104

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

Стр.105

Упражнения

https://translate.googleusercontent.com/translate_f 84/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
1. Нарисуйте линию, чтобы соединить каждое из названий игр слева с их "высокой концепцией" на
верно.

Звездные войны: Рыцари Старой Республики Скорострельные игры без правил

Гало Может ли один человек спасти вселенную?

Нереальный Турнир SimCity установлен в зоопарке

Зоопарк Магнат Mortal Kombat с оружием

Настоящее преступление: Улицы Лос-Анджелеса Обычный парень узнает, что он необычный

Wario Ware, Inc. Grand Theft Auto наоборот

2. На какой стадии проекта производится каждый из следующих результатов или мероприятий?

Библия искусства

Конкурентный анализ

Прототип игры

Новые карты

Анализ риска

Документ игрового дизайна

Контрольный провод на борту

Технический проектный документ

Код отправлен на проверку на соответствие

Праздновать

Концептуальный документ

Участвуют волонтеры-тестировщики

3. Для каждого из следующих результатов игрового проекта укажите, являются ли они относительно высокими.
или Низкая детализация:

Высокая концепция

Предполагаемый бюджет

История в концептуальном документе

Документ игрового дизайна

График разработки в плане проекта

Прототип игры

Бета-версия

План рабочей силы в плане проекта

Стр.106

Список активов в плане подготовки производства

4. Что из следующего необходимо поддерживать в актуальном состоянии на протяжении всего срока реализации проекта?
Документ игрового дизайна

Опытный образец

План проэкта

План художественного производства

Патчи

Ответы

1. Star Wars: Knights of the Old Republic - Обычный парень обнаруживает, что он необычный.

HALO - Может ли один человек спасти вселенную?

Unreal Tournament - Mortal Kombat с оружием

Zoo Tycoon - SimCity, действие которого происходит в зоопарке

https://translate.googleusercontent.com/translate_f 85/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Настоящее преступление: Улицы Лос-Анджелеса - Grand Theft Auto наоборот

Wario Ware, Inc. - Быстрые игры без правил

2. Художественная Библия - Подготовка

Конкурентный анализ - разработка концепции

Прототип игры - предварительная подготовка

Новые карты - обновления

Анализ рисков - разработка концепции

Документ по дизайну игры - подготовка

Ведущий тестировщик на борту - Разработка

Техническая проектная документация - подготовка производства

Код отправлен на тестирование на соответствие - бета

Празднуйте - выпуск в производство

Концептуальный документ - Разработка концепции

Участвуют добровольцы-тестировщики - бета

3. Высокая концепция - низкая детализация.

Ориентировочный бюджет - низкая детализация

История в концептуальном документе - низкая детализация

Документ по игровому дизайну - высокая детализация

График разработки в плане проекта - высокая детализация

Стр.107

Прототип игры - низкая детализация

Бета-версия - высокая детализация

План рабочей силы в плане проекта - высокая детализация

Список активов в предварительном плане - низкая детализация

4. Документ об игровом дизайне - да

Прототип - Нет

План проекта - да

План производства произведений искусства - Да

Патчи - Нет

https://translate.googleusercontent.com/translate_f 86/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.108

Часть III: Основы тестирования


Список глав

Глава 6: Качество программного обеспечения

Глава 7: Фазы тестирования

Глава 8: Процесс тестирования

Глава 9: Проверка цифрами

https://translate.googleusercontent.com/translate_f 87/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.109

Глава 6: Качество программного обеспечения


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

В своей книге « Качество - это бесплатно» Филип Кросби утверждает, что «Качество - это бесплатно». Это должен быть высокий
концепция (помните это из главы 5?) вашей программы качества. Если стоимость выполнения какого-то качества
не ожидается, что функция приведет к конечной экономии, найдите способ сделать это дешевле или лучше. Если не можешь,
тогда перестань это делать.

Факторы качества игры


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

Качество истории

Качество игровой механики

Качество (например, стиль, реализм) игровых звуковых и визуальных эффектов.

Красота визуального стиля

Использование юмора и преувеличения

«Человекоподобный» неигровой персонаж Искусственный интеллект (ИИ)

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

Еще одним фактором обеспечения качественного взаимодействия с пользователем является обеспечение того, чтобы код и ресурсы игры были
совместим с ограничениями памяти целевой платформы. Сюда входят доступные рабочие
объем памяти, необходимый для правильной работы игры, а также размер и количество целевых носителей, таких как
картриджи, CD-ROM или DVD, используемые для распространения игры.

Более высокие требования к памяти могут повлиять на производительность игры, поскольку время тратится на переключение игровых ресурсов в
и нехватка памяти во время игры. Каждый дополнительный диск или карта памяти большей емкости влияет на стоимость
производство и распространение игры. Повышение цены для компенсации дополнительных затрат на рекламу.
может повлиять на продажи. Добавление диска без увеличения цены уменьшит прибыль. Подавляющее большинство
консольные игры должны уместиться только на одном диске, но сложные компьютерные игры могут занимать где угодно
2–6 дисков. Память портативного устройства не подлежит обновлению, как ПК. Игры должны соответствовать
ограничения памяти встроенных микросхем памяти и поддерживаемых съемных запоминающих устройств.
Мобильные игры, как правило, наиболее ограничены с точки зрения доступной фиксированной и съемной памяти.

Любые попытки "взлома кода" становятся все дороже и дороже, чем позже они происходят в игре.
цикл разработки. Стоимость не только в работе по сокращению. Уменьшение кода игры или
переформатирование ресурсов для соответствия целевому носителю или объему памяти может привести к появлению новых труднообнаруживаемых ошибок с опозданием
в проекте. Это создает дополнительную нагрузку на разработку, управление проектами, отслеживание дефектов,

Стр. Решебника 110

контроль версий и тестирование.

https://translate.googleusercontent.com/translate_f 88/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. Решебника 111

Оценка качества игры


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

Тестирование считается оценочной деятельностью. Устанавливает, выполняет ли игровой код функции


для чего это было предназначено. Но тестирование - не самый экономичный способ найти дефекты игры; лучше всего
ловить проблемы в момент их появления.

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

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

https://translate.googleusercontent.com/translate_f 89/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
серьезно, когда звонят на твой номер.

Прохождение
Пошаговые руководства - это одна из форм экспертной оценки. Общая схема пошагового руководства выглядит следующим образом:
1. Руководитель (например, дизайнер) охраняет комнату и планирует прохождение

2. Руководитель начинает встречу с обзора работы, включая объем, цель и специальные


соображения

3. Лидер отображает и представляет текст и диаграммы документа

4. Участники задают вопросы и поднимают вопросы

5. Новые вопросы, поднятые во время пошагового руководства, записываются во время встречи.

Зал должен комфортно вместить количество присутствующих и иметь проектор для презентаций. А
доску или бумажный блокнот для мольберта ведущий или участники могут использовать для уточнения вопросов или
ответы. Ограничьте посещаемость максимум 6–8 человек. Это не должно превращаться в собрание команды. Включите только
представитель каждой роли в проекте, на которую может повлиять работа, которую вы выполняете. Для
Например, кто-то из команды художников не обязательно должен присутствовать в большинстве пошаговых руководств по разработке кода, но есть
при представлении проектов графических подсистем должен быть опытным игровым художником. Не надо
приглашайте ведущего к каждому прохождению, которое затрагивает команду тестирования. Если да, то игровые знания
и опыт прохождения не будет передан другим тестировщикам. Это также защищает тестовый провод от
тратить слишком много времени на пошаговые инструкции и мало времени на проведение тестов. Работайте с тестовым проводом, чтобы
найти других способных представителей в ее команде. Если вы - руководитель тестирования, пришлите кого-нибудь из своего
команда на вашем месте, когда вы можете.

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

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

Также неплохо использовать некоторые пошаговые руководства в качестве наставничества или возможностей роста для людей на вашем сайте.
команда. «Гости» должны ограничить свои вопросы и комментарии во время встречи материалом.
будут представлены и поговорите со своим "хозяином", чтобы обсудить любые другие вопросы о

Стр.112

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

Вот список представителей, которых можно пригласить для ознакомления с различными артефактами проекта:

TDD - технический руководитель, арт-директор, продюсер, руководитель проекта.

Раскадровка - продюсер, ведущий разработчик, художники

SQAP - руководитель проекта, продюсер, руководитель разработки, руководитель тестирования, руководитель отдела контроля качества и инженер (и)

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

Дизайн кода, прочее - ключевые разработчики, представитель тестирования

Код - ключевые разработчики, ключевые тестировщики

План тестирования - руководитель проекта, продюсер, руководитель разработки, ключевые тестировщики.

Тесты - разработчик функций, ключевые тестировщики

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

Возможные реализации

Взаимодействия

Соответствующий объем

Прослеживаемость к более ранним рабочим продуктам

Полнота

https://translate.googleusercontent.com/translate_f 90/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Вопросы, поднятые
осознать ошибку, во время
просто пошагового
рассказав о своейруководства, также записываются
работе. Прохождение во время
предоставляет выходвстречи. Иногда
для этого. Одинведущий
участник действует как регистратор, записывая вопросы и моменты презентации, которые необходимы для понимания
материал. Другие участники могут в конечном итоге использовать информацию для последующих действий, таких как
кодирование или тестирование. Руководитель несет ответственность за своевременное закрытие каждого вопроса и распространение встречи.
примечания для команды в течение одной недели после прохождения. Ожидается, что QA последует, проверив, что
вопросы действительно были закрыты до того, как была выполнена какая-либо работа на основе пройденного материала и
что записки были розданы участникам.

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

Ожидается, что рецензенты подготовят свои комментарии до совещания по обзору и представят их


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

Стр.113

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

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

Обзоры на основе контрольных списков


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

Инспекции
Проверки более структурированы, чем обзоры. Инспекции Фэгана - одна из конкретных инспекций
методология, из которой были получены многие другие. Они были определены Майклом Фаганом в
1970-е годы основаны на его работе в IBM, и теперь они являются частью Fagan Defect-Free Process. Вы можете узнать
больше о его процессе на www.mfagan.com .

Инспекция Фагана включает следующие шаги:


1. Планирование

2. Обзор

3. Подготовка

4. Встреча

5. Переделка

6. Следовать за

7. Причинно-следственный анализ

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

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

https://translate.googleusercontent.com/translate_f 91/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
для различных предметов, которые вы будете проверять. Как только критерии соблюдены, модератор планирует
обзорная встреча, а также «обзорная» сессия, которая проводится до обзора. Это для обсуждения
объем и цель проверки с участниками. У участников также могут быть вопросы, которые можно

Стр. Решебника 114

ответил здесь или вскоре после встречи. Обычно между


обзор и инспекционная встреча. Это необходимо для того, чтобы у рецензентов было достаточно времени на подготовку.

Каждому инспектору назначается своя роль на инспекционном совещании. Читатель должен


перефразировать исследуемый материал. Идея состоит в том, чтобы сообщить любую подразумеваемую информацию или поведение
что Читатель интерпретирует, чтобы увидеть, соответствует ли он намеченной функции Автор. Например, вот строка
кода для чтения:

LoadLevel (уровень [17], highRes, 0);

Вы можете просто сказать: «Вызовите LoadLevel с семнадцатым уровнем, высоким разрешением и нулевым». Лучшее чтение для
целью проверки было бы сказать: «Вызовите LoadLevel, не проверяя возвращаемое значение. Пройдите уровень.
информация, использующая постоянный индекс семнадцать, сохраненное значение highRes и жестко запрограммированный ноль ".
Это второе чтение поднимает следующие потенциальные проблемы:
1. Возвращаемое значение LoadLevel не проверяется. Должен ли он вернуть значение, указывающее на успех, или
номер уровня для проверки того, что уровень, который вы намеревались загрузить, действительно был загружен?

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

3. Значение 0 не объясняет его функцию или параметр, которому он назначается.

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

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

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

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

По окончании встречи модератор определяет, требуется ли доработка до начала встречи.


материал может быть принят. Он продолжает работать с автором, чтобы решать проблемы, пока они не будут устранены.
закрыто. В зависимости от объема или сложности изменений может потребоваться дополнительная проверка.

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

Стр.115

https://translate.googleusercontent.com/translate_f 92/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

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

Стандарты пользовательского интерфейса


Стандарты пользовательского интерфейса (UI) помогают игрокам отождествлять себя с названием вашей игры.

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

2. Сделайте все буквы одинакового размера.

3. Избегайте использования строчных букв. Вместо этого используйте уменьшенные версии заглавных букв.

4. По возможности используйте контур шрифта.

5. Экранная клавиатура должна напоминать внешний вид реальной клавиатуры.

6. На экранной клавиатуре буквы должны располагаться в алфавитном порядке. Не используйте QWERTY


расположение.

7. Разделите буквы алфавита, символов и акцентов на три отдельные экранные клавиатуры.

8. Общие функции, такие как Готово, Пробел, Backspace, Caps Lock и переключение между
наборы символов должны быть сопоставлены с доступными кнопками на игровом контроллере.

9. Назначьте клавиши пробела и возврата на левую и правую плечевые кнопки.

10. Каждое меню должно умещаться на одном экране.

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

12. Избегайте горизонтальных меню.

13. Вертикальное меню должно состоять не более чем из 6–8 пунктов, каждое со своей кнопкой.

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

15. Оставьте передышку для локализации текста. (Для некоторых языков, например, немецкого, может потребоваться больше
букв в слове, чем на родном языке вашей игры.)

16. Поместите значки кнопок рядом с их функциями вместо использования линий для подключения функций к
кнопки.

17. Наведите значки кнопок на их расположение на контроллере.

18. Отделите функции движения джойстика от функций кнопок.

Дополнительные стандарты могут применяться к последовательному назначению клавиатуры («F1 всегда должен быть справкой.
кнопка ") или гибкость опций игрового контроллера (" Всегда должна быть возможность включить или отключить
вибрация »).

Стр.116

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

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

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

https://translate.googleusercontent.com/translate_f 93/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Соглашения об именах файлов

Заголовочные файлы

Стили комментариев и отступов

Использование макросов и констант

Использование глобальных переменных

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

Даже в этом случае стандарты кодирования - это не только форматирование. Многие правила предназначены для решения
важные вопросы, такие как переносимость, ясность, модульность и возможность повторного использования. Важность этих
Стандарты увеличиваются в проекте, который распространяется по разным командам, сайтам и странам. Там
Есть несколько вещей менее увлекательных, чем отслеживание дефекта, вызванного тем, что одна команда определила УСПЕХ как 0 и
другая команда, определяющая УСПЕХ как 1.

Вот некоторые выдержки из стандартов C-кодирования для проекта Computer Associates Ingres®:
Не используйте константы для проверки машинно-зависимых диапазонов или значений. Используйте символику
вместо этого (например: UINT_MAX, а не 4294967295 ).

Константы должны быть правильно набраны, чтобы соответствовать их использованию. Например, константа 1, которая будет
переданный в процедуру, ожидающую long, должен быть определен как ((long) 1) .

Не используйте буквальный ноль в качестве значения указателя NULL .

Для объявления новых типов используйте TYPEDEF , а не #define .

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

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

Стр.117

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

https://translate.googleusercontent.com/translate_f 94/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. Решебника 118

Измерения качества игры


Насколько хорош «хороший» игровой софт? Безусловно, количество дефектов в коде имеет какое-то значение.
с добротой. Еще один фактор, который следует учитывать, - это способность команды находить дефекты в своем продукте. "Сигма"
уровень »устанавливает дефектность игрового кода относительно его размера, а« фазовое сдерживание »обеспечивает
показатель того, насколько успешно команда находит дефекты в их источнике, оставляя меньше, чтобы скрыться
ваши клиенты.

Программное обеспечение Six Sigma


«Уровень сигмы» - это один из способов установить цель исходящего качества вашей игры. Для программного обеспечения это
мера основана на количестве дефектов на миллион строк кода, исключая комментарии (также называемые «не-
закомментированные исходные строки »или« NCSL »). Мера« строк кода »часто нормализуется до Assembly-
эквивалентные строки кода (AELOC), чтобы сбалансировать разный уровень абстракции в разнообразии
используемые языки, такие как C, C ++, Java, Visual Basic и т. д. Уровень абстракции каждого
язык отражается в его множителе. Например, каждая строка кода C обычно рассматривается как
эквивалент трех-четырех AELOC, тогда как каждая строка кода Perl обрабатывается как примерно 15 AELOC. Это
лучше всего измерить этот коэффициент в зависимости от конкретной среды разработки и использовать его для любых
оценки или прогнозы, которые вам нужно сделать в будущем. Если вы используете разные языки для разных
части вашей игры, умножьте строки кода для каждой части на соответствующий языковой коэффициент.

На рисунке 6.1 показано количество дефектов, необходимое для достижения показателя качества программного обеспечения между
три и шесть сигм. Шесть сигм (всего 3,6 дефекта на миллион строк кода) обычно рассматриваются как
выдающийся результат, и попадание в диапазон 5,5 сигма очень хорошо.

https://translate.googleusercontent.com/translate_f 95/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. Решебника 119

Рисунок 6.1: Выдержка из сигма-таблицы для поставляемого программного обеспечения различных размеров.

Не обманывайте себя, измеряя свою сигму только на основе открытых дефектов, о которых вы знаете в
продукт. Это могло бы вознаградить плохое тестирование, которое не обнаружило много дефектов, которые все еще остались в игре, но
не будет отражать опыт ваших клиентов. Подсчитываемые дефекты должны включать как
известные вам игровые дефекты, которые не были исправлены, какие бы дефекты ни были у ваших клиентов.
уже обнаружены, и ваш прогноз дефектов, оставшихся в программном обеспечении, которые не были обнаружены
еще. Лучше подождать от 6 до 18 месяцев после отправки, чтобы рассчитать сигму. Если у вас все еще есть
хороший результат после этого, продолжайте управлять своими проектами аналогичным образом, повторяя то, что было
"правильно", но также исправить то, что пошло "не так". Если у вас плохие результаты, внимательно посмотрите, что вас изменит.
можно сделать, чтобы избежать повторения исполнения. Вы можете начать с просмотра списка несоответствий
что QA обнаружил во время проекта.

Фазовое сдерживание
Фазовое сдерживание - это способность обнаруживать неисправности на той стадии проекта, на которой они были внесены. Фаза
Эффективность сдерживания (PCE) - это показатель того, насколько хорошо это делается.

Неисправности, обнаруженные в той фазе, в которой они возникли, называются синфазными неисправностями или «ошибками».
Ошибки, которые не обнаруживаются на той же стадии, в которой они возникли, считаются устраненными и
становятся «дефектами». Принцип заключается в том, что если любая последующая работа будет производиться от неисправного элемента, то
возник дефект. Подумайте о 18-дюймовом Стоунхендже, спускающемся с потолка в фильме Spinal Tap .
Этого можно было бы избежать (но не так смешно ...), если бы кто-нибудь заметил, что размер был дан в дюймах.
вместо ног на рисунке, подаренном художнику.

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

Стр. Решебника 120

https://translate.googleusercontent.com/translate_f 96/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

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

PCE обычно отслеживается и сообщается, показывая неисправности, обнаруженные на каждом этапе разработки. Неисправности
организованы в столбцы для каждой фазы, в которой они могут быть обнаружены. Ошибка кодирования не может быть обнаружена
на этапе требований, потому что кода на этом этапе не существует. Рассчитайте PCE, разделив
количество синфазных замыканий на сумму сбоев, обнаруженных на всех фазах, чтобы придумать PCE для этого
фаза. Исходя из данных на рисунке 6.2, PCE на этапе проектирования рассчитывается путем деления количества неисправностей.
найдено на этапе кодирования, 93, суммой всех ошибок, внесенных кодированием, которая составляет 93 + 6 + 24 = 123.
Результат: 93/123 = 0,76. На рис. 6.3 показан график, обобщающий PCE кода для каждой фазы.

Рисунок 6.2: Данные о сдерживании фазы кода игры.

Рисунок 6.3: График сдерживания фазы кода игры.

В качестве альтернативы результаты испытаний можно разбить на отдельные категории, как показано на Рисунке 6.4. Эти
дополнительные категории не влияют на числа или графики PCE, но это может быть более удобно для данных
сбор, если для разных типов релизов используются разные системы или категории. Эти данные также помогают
команда понимает, будут ли дополнительные действия по тестированию, которые могут еще больше снизить PCE
числа по мере обнаружения большего количества дефектов. На рисунке 6.4 нет результатов бета-тестирования, которые можно было бы добавить к
Таблица. Таким образом, числа PCE для требований, дизайна и кодирования представляют только максимально возможные
значение. Новые дефекты, обнаруженные в бета-тестировании, будут связаны с этими фазами и уменьшат соответствующие
ПКП.

Рисунок 6.4: Данные о сдерживании фазы кода игры с расширенными категориями тестирования.

Если эта практика полезна для понимания того, насколько хорошо команда выявляет дефекты в коде игры, она
также должны применяться к работе, произведенной тестировщиками. На рисунке 6.5 показан пример данных PCE для
результаты тестирования, а на Рисунке 6.6 показан соответствующий график.

Стр. Решебника 121

Рисунок 6.5: Данные сдерживания фазы тестирования игры.

https://translate.googleusercontent.com/translate_f 97/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Рисунок 6.6: График сдерживания фазы игрового теста.

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

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

Как и в случае со значением сигмы, ищите способы улучшить свой PCE. Если бы у вас было 100% сдерживание во всех ваших
фазы, вам нужно будет запустить каждый тест только один раз, и все они пройдут. Ваши клиенты не найдут
никаких проблем, и вам никогда не придется выпускать патч. Подумайте о времени и деньгах, которые можно сэкономить! С
PCE является функцией произведенных неисправностей и неисправностей, вы можете атаковать низкий PCE на обоих концах.
Программисты могут улучшить свои способности по предотвращению появления ошибок. Тестировщики и QA могут улучшить
их способность обнаруживать неисправности.

В обоих случаях основными стратегиями решения проблем с низким уровнем PCE являются:

Повысьте уровень знаний по предмету и проведите соответствующее обучение.

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

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

Повышение соответствия существующим методам и стандартам.

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

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

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

Стр. Решебника 122

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

QA персонал

Стандарты, которые будут использоваться в продукте

Обзоры и аудиты, которые будут проводиться

Записи и отчеты QA, которые будут созданы

Отчетность о проблемах QA и корректирующие действия

Инструменты, методы и методы обеспечения качества

Метрики QA

Контроль поставщиков

Сбор, ведение и хранение записей контроля качества

Требуется обучение QA

Риски QA

Книги CD содержит ссылку на шаблон SQAP документа из TeraQuest ( www.teraquest.com ) , что


следует этому плану.

https://translate.googleusercontent.com/translate_f 98/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

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

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

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

Стандарты

Стр. 123

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

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

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

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

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

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

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

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

https://translate.googleusercontent.com/translate_f 99/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
и какимиобразом.
аудиты О вещах,
обзоры можно требующих через
резюмировать частого внимания,
более следует
длительные сообщать времени.
промежутки регулярно. Нечасто команда QA может произвести
Например,
еженедельные отчеты об аудитах результатов тестирования, но ежеквартальные отчеты по процедуре резервного копирования и восстановления
аудиты. Аудит результатов тестирования начнется вскоре после начала тестирования и продолжится до конца
проект. Аудит резервного копирования и восстановления можно начать раньше, когда начнется разработка.

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

Стр. Решебника 124

совещание по проверке качества.

Отчеты о проблемах и корректирующие действия


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

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

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

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

Инструменты, методы и методы


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

Некоторые статистические методы могут быть полезны для анализа качества результатов проекта и процесса. Многие из этих
методы поддерживаются инструментами. Такие инструменты и методы должны быть указаны в SQAP. Например,
Диаграммы Парето отображают список результатов в порядке убывания. Крайние слева полосы - это самые
часто встречающиеся предметы. Это те проблемы, на которые вы должны в первую очередь потратить время. Если ты успешен
при их исправлении числа уменьшатся, и другие проблемы заменят их в левой части диаграммы. Ты
можно бесконечно решать проблему, указанную в левой части диаграммы, потому что она всегда будет. Это
вроде как попытаться очистить свой гараж. В какой-то момент вы можете решить, что результаты "хорошие"
достаточно "и перейти к совершенно другому результату, который нужно улучшить.

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

https://translate.googleusercontent.com/translate_f 100/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Стр. Решебника 125

Рисунок 6.7: Диаграмма Парето дефектов на KLOC для каждой игровой подсистемы.

Еще один полезный метод обеспечения качества программного обеспечения - это построение контрольных диаграмм результатов продукта или процесса. Контроль
На диаграмме показан ожидаемый средний результат и граничные линии «контрольного предела» для набора предоставленных данных.
Любые элементы, выходящие за пределы контроля, выходят за пределы диапазона значений, которые указывают на то, что они получены из
тот же процесс, что и остальные данные. Это похоже на машину, которая штампует металлические квадраты
определенным образом, но время от времени одно выходит очень отличным от других. Если у тебя есть право
из любопытства, чтобы быть специалистом по контролю качества, вы хотели бы знать, почему квадрат выходит неправильно в некоторых из
время. То же самое и с результатами программного обеспечения, которые получаются «забавными». Контрольный график показывает результаты
которые следует исследовать, чтобы понять их причину. Это может быть просто результат того, что кто-то вошел в
неверные данные (дата, время, размер, дефекты и т. д.). На рисунке 6.8 показан пример контрольной диаграммы для новых линий.
изменений дельта-кода (добавленного или удаленного) в игре каждую неделю. Цифры указаны в KLOC.

Рисунок 6.8: Контрольный график еженедельного изменения кода в KLOC.

Сплошная линия, проходящая через середину диаграммы, представляет собой среднее значение для набора данных. Два разбитых
линии, обозначенные UCL и LCL, представляют верхний контрольный предел и нижний контрольный предел, соответственно.
Эти значения также рассчитываются из набора данных. Точка данных за неделю от 02.05.2004 находится выше
UCL. Это вопрос, который следует исследовать.

Примечание . Диаграмма Парето и контрольная диаграмма на рисунках 6.7 и 6.8 , соответственно, были созданы с использованием
SPC для Excel ( www.spcforexcel.com ). Ссылка на демонстрационную версию находится на компакт-диске книги.
ПЗУ.

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

Стр. Решебника 126

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

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

https://translate.googleusercontent.com/translate_f 101/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
промежуточное ПО, изображения и аудиофайлы.
В обоих этих случаях QA должен играть роль в определении того, что поставляемые элементы «пригодны для использования». Этот
можно сделать так же, как оцениваются внутренние результаты. Кроме того, команда QA может оценить
способность поставщика поставлять качественный продукт путем проведения выездных визитов для оценки
процессы. Когда вы идете в гастроном, приятно видеть, что еда красиво разложена в витрине. Ты
также цените тот факт, что инспектор по пищевым продуктам проверил растение, на котором производится еда.
убедитесь, что он не загрязнен и производится в чистой и здоровой окружающей среде. Тоже самое
должно относиться к программному обеспечению и материалам, связанным с играми, которые предоставляются вам другими компаниями.

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

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

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

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

Результаты проекта не синхронизируются с запланированными аудитами

Персонал QA переключился на другие виды деятельности, такие как тестирование

Отсутствие независимой структуры отчетности по обеспечению качества

Отсутствие у организации обязательства предпринимать корректирующие действия и / или закрывать вопросы, поднятые QA.

Недостаточное финансирование новых технологий обеспечения качества

Недостаточное финансирование обучения новым технологиям разработки и / или обеспечения качества

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

Стр. Решебника 127

сохраняется.

https://translate.googleusercontent.com/translate_f 102/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. Решебника 128

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

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

Примечание. Дополнительную информацию и ресурсы о качестве программного обеспечения можно найти на сайте Американского общества
Качественный веб-сайт www.asq.org .

https://translate.googleusercontent.com/translate_f 103/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. 129

Упражнения
1. Размер вашего игрового кода составляет 200 000 AELOC. У него было 35 дефектов, о которых вы знали, когда
выпустил его. Люди, купившие его, сообщили о еще 17. Какой уровень сигмы у вашего кода
в?

2. Опишите различия между ролью лидера в пошаговом руководстве и ролью модератора в


Инспекция Фэгэна.

3. Добавьте следующие дефекты, обнаруженные в ходе бета-тестирования, к данным на рисунке 6.4 : Требования - 5,
Дизайн — 4, Кодирование — 3. Каковы обновленные PCE кода для требований, дизайна и
этапы кодирования?

4. Используя демонстрацию SPC Tool, создайте контрольную диаграмму для следующих коэффициентов проверки тестовых случаев:
измеряется в страницах в час:

Обзор 1: 8.5

Обзор 2: 6.1

Обзор 3: 7.3

Обзор 4: 4.5

Обзор 5: 13.2

Обзор 6: 9.1

Какие отзывы, если таковые имеются, попадают выше или ниже контрольных лимитов? Опишите, какие "хорошие" и
которые являются «плохими». Как высокая или низкая оценка может повлиять на количество ошибок, обнаруженных в
те обзоры?

Ответы

1. Общее количество выявленных дефектов составляет 35 + 17 = 52. В таблице на рис. 6.1 есть столбец для 100 000, но
не для 200 000, поэтому удвойте количество дефектов в столбце 100 000. Количество дефектов 66
указывает уровень 4,9 сигма, а 48 - 5 сигма. Ваши 52 дефекта не достигают уровня 5 сигм, поэтому ваш
код игры - 4,9 сигма.

2. Модератор инспекции Фагана несет дополнительную ответственность за планирование и проведение


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

3. Новые PCE: требования = 0,69, конструкция = 0,73, код = 0,66.

4. Ваша контрольная диаграмма должна выглядеть, как на рисунке A.1 .

https://translate.googleusercontent.com/translate_f 104/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.130

Рисунок A.1: Контрольная диаграмма для оценки количества обзоров.

Значение для обзора 5 выходит за пределы верхнего контрольного предела (UCL). Этот показатель считается «завышенным».
Слишком быстрый просмотр материала может указывать на одно из следующего:

плохая подготовка

отсутствие участия и взаимодействия во время обзора

непонимание рецензируемого материала

давление в расписании, которое «побуждает» рецензентов не тратить «слишком много» времени на отзывы.

Какими бы ни были причины, потенциальное последствие высокой оценки количества отзывов - это упущенные ошибки.

С другой стороны, слишком медленное движение может быть результатом:

Слишком много споров по поводу разногласий во время обзора

Потратить время на обсуждение вопросов, не относящихся к обзорному материалу.

Непонимание рецензируемого материала

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

Стр. Решебника 131

Глава 7: Фазы тестирования


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

https://translate.googleusercontent.com/translate_f 105/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
следуйте той же базовой структуре:

1. Подготовка к производству

2. Подать мяч

3. Альфа

4. Бета

5. Золото

6. Релиз

7. Пост-релиз

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

Рисунок 7.1: Хронология консольной гоночной игры.

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

Стр. Решебника 132

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

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

Вы не можете проверить качество в игре. Качество игры определяется кодом, графикой и


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

Если в начале проекта вы получили по почте купон, в котором говорилось: «Отправьте этот купон, чтобы сохранить
20% или более в вашем проекте », вы бы отправили его? Когда вы сохраняете тестирование до конца проекта, это
например, иметь купон, но не отправлять его, потому что вы не хотите платить за пересылку по почте.

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

https://translate.googleusercontent.com/translate_f 106/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Определите объем тестирования проекта, который потребует

Проектный документ, TDD и график проекта проверяются менеджером по тестированию, чтобы сформулировать:
документ «Объем тестирования», в котором указывается, сколько ресурсов для тестирования, т. е. времени, людей и
деньги - ему или ей нужно будет тщательно протестировать игру перед выпуском (см. следующую боковую панель,
«Планы расширения»).

Планы расширения

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

МЕМОРАНДУМ

К: Исполнительный продюсер

От: Менеджер по обеспечению качества

RE: РЕЗЮМЕ ТЕСТИРОВАНИЯ РАСШИРЕНИЯ RTS

Резюме

Для тестирования этого пакета расширения потребуется 1760 часов, исходя из следующих предположений:

50-дневный производственный график,

Испытательная группа из четырех человек,

10% надбавка за сверхурочную работу, и

Нет тестирования после выпуска исправлений.

Стр. Решебника 133

Одиночная игра (900 часов)

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

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

Мультиплеер (650 часов)

Суть многопользовательского тестирования будет заключаться в следующем:

1. Обеспечить правильную реализацию новых юнитов и нового набора плиток,

2. Отладка новых карт,

3. Отладка «оптимизация интерфейса» (новая функциональность описана в проектной документации),

4. Размер игры стресс-теста,

5. Размер армии стресс-теста,

6. Продолжительность стресс-теста и (если позволяет время)

7. Проверка баланса.

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

Тестовые матрицы (210 часов)

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

Мы будем запускать в игре следующие стандартные матрицы:


1. Матрица установки / удаления (с упором на совместимость с предыдущим продуктом)

2. Матрица ошибок Windows

3. Матрица стандартов издателя

https://translate.googleusercontent.com/translate_f 107/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
4. Матрица многопользовательской связи
Мы также будем создавать и запускать единичную матрицу, разработанную при тестировании оригинальной игры на каждом новом
блок в пакете расширения.

Совместимость (0 часов)

Поскольку минимальные системные требования не изменятся по сравнению с оригинальной игрой, мы не


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

Сверхурочные (уточняется)

Стр. Решебника 134

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

Назначить ведущего тестировщика

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

Лидер, способный мотивировать команду тестировщиков и поддерживать их сосредоточенность и продуктивность.

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

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

Дипломат - способный управлять конфликтами по мере их возникновения (и они будут возникать).

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

Определите критерии приемлемости фазы

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

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

При планировании сертификации для каждого этапа тестирования требуются три элемента:

Критерии входа: набор тестов, которые должна пройти сборка перед входом в данную фазу тестирования. Игра
не будет считаться «в альфа-версии», например, пока код не пройдет тест Alpha Entry.

Критерии выхода: набор тестов, которые должна пройти сборка перед завершением фазы тестирования.

Целевая дата: дата, над которой команда разработчиков и тестировщиков работают на конкретном этапе.
запускать.

Участвуйте в обзорах игрового дизайна


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

Настройте базу данных отслеживания дефектов

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

https://translate.googleusercontent.com/translate_f 108/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. Решебника 135

«Неожиданный результат» слишком общий. Не все ли ошибки неожиданные?

Рисунок 7.2: Типичная запись в базе данных ошибок.

Ведущий тестировщик и менеджер проекта должны согласовать соответствующие разрешения, т. Е. Какие


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

Будет ли база данных ошибок размещаться на внутреннем сервере или быть доступной через Интернет, это
хорошая идея на данном этапе заполнить базу данных ошибок несколькими фиктивными записями и перепроверить все
пароли и разрешения, как локально, так и удаленно. Каждый человек, у которого будет доступ к ошибке
базе должен быть назначен индивидуальный пароль, и ведущий тестировщик может разрешить или заблокировать права редактирования для
отдельные поля в зависимости от роли, которую этот человек будет играть в команде проекта (см. следующую боковую панель,
«Слишком много поваров?»).

Проект плана испытаний и проектные испытания

Наличие актуальных и подробных знаний об игровом дизайне имеет решающее значение, поскольку ведущий тестировщик начинает составлять проект.
тестовые документы. Начните составлять общий план тестирования, определяющий, какие типы тестов будут проводиться и какие
отдельные наборы и матрицы будут выглядеть так (см. главу 8 , «Процесс тестирования»). В этом суть
проект, в котором вы можете эффективно использовать методы, описанные в части IV этой книги. Помнить:
Предварительное планирование предотвращает плохую работу.

План тестирования

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

Стр.136

Слишком много поваров?

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

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

https://translate.googleusercontent.com/translate_f 109/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
общаться друг с другом о конкретном дефекте с не менее важной необходимостью контролировать
поток информации для всех членов команды проекта. Программисты должны иметь возможность комментировать
или задать вопросы о дефекте в поле комментариев или примечаний разработчика, но они не могут быть разрешены
чтобы закрыть дефект произвольно, изменив поле «Статус» на «закрыто». Тестировщикам необходимо уметь
опишите ошибку в полях Краткое описание и Полное описание, но они могут не соответствовать требованиям
в поле «Кому назначено» определите, кому должна принадлежать ошибка.

Вот несколько рекомендаций:

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

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

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

Краткое / полное описание должно вводиться тестировщиками и редактироваться ведущим или основным тестировщиком.

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

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

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

Прецедент

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

Стр. Решебника 137

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

Тестирование

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

Тестирование перед началом тестирования


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

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

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

https://translate.googleusercontent.com/translate_f 110/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
прецедент. Тестирование истинных дефектов не начнется, пока игра не будет принята для альфа-тестирования.
Наконец, ведущий тестировщик должен начать набирать или нанимать дополнительных членов команды по мере необходимости в соответствии с
его или ее ресурсный план. Как только команда будет на месте, можно начинать стартовые испытания.

Стр. Решебника 138

Начало испытаний
Известно, что первые шаги положительно влияют на разработку программного обеспечения, улучшая процесс.
определение, лучшее решение проблем и сокращение времени цикла. В команде, в которой тестировщики имеют разные
уровней тестирования и опыта игровых проектов, индивидуальные потребности вряд ли будут удовлетворены на
запуск проекта. Команде выгодно начинать игру на следующем низком уровне: тестовое начало для каждого «теста».
который создается или выполняется отдельными тестировщиками. Начало теста иллюстрирует принцип, согласно которому
увеличение скорости организации является результатом итеративного процесса выявления препятствий, разработки
новый процесс, который их устраняет, и обеспечение реализации нового способа.

Начало тестирования разбито на две части: подготовка тестировщика и стартовое совещание, которое
проводится согласно стартовой программе. Шаги подготовки тестировщика и начальная повестка дня:
задокументировано в контрольном списке для начала теста, как показано на Рисунке 7.3.

Рисунок 7.3: Контрольный список для начала теста.

https://translate.googleusercontent.com/translate_f 111/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Из контрольного списка для начала теста тестировщик готовится следующим образом:
1. Читает требования и / или документацию для тестируемой функции игры.

2. Собирает оборудование, файлы и программы, необходимые для теста

3. Читает тесты

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

После того, как тестировщик завершит подготовительные мероприятия, проводится стартовое собрание. Эксперт по тестированию ведет

1.

Стр.139

стартовое собрание, выполнив следующие действия:


1. Предоставление обзора функции

2. Решение вопросов о функциях

3. Получение каких-либо специальных инструкций по тестированию

4. Выносить и запрашивать любые соответствующие предложения по улучшению тестирования

5. Решение любых вопросов или проблем, связанных с выполнением теста

6. Запись важных вопросов в стартовую форму и предоставление копии тестировщику после встречи
завершено

Следуя этапам подготовки, перечисленным в контрольном списке, и участвуя в интерактивной встрече в соответствии с
Тестирование преимуществ стартовой повестки дня следующими способами:

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

Знакомит тестировщика с ожидаемым поведением игры или модуля во время тестирования для повышения
осведомленность тестировщика о том, что правильно

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

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

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

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

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

Делайте меньше ошибок (уменьшайте потраченные впустую усилия)

Этапы запуска теста предназначены для того, чтобы гарантировать, что тестирование не начнется, пока тестер не будет оборудован для
test и понимает детали и цели тестирования. Помимо прочего, это приводит к более быстрому
и более точное измерение результатов.

Уменьшите циклические усилия (кратчайшее расстояние между двумя точками - линия)

В рамках подготовки тестировщик полностью проверяет тест и требования. Это снижает


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

Все усилия приводят к чему-то, что будет использовано

https://translate.googleusercontent.com/translate_f 112/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. Решебника 140

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

Правду приветствуют

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

Проводите конструктивные обсуждения, а не излишние усилия и дискуссии

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

Я понимаю, что встреча на самом деле сэкономит время - это чуждое понятие. Мне нужно было знать это для
я, когда стартовые тесты были просто «идеей». В проекте, над которым я работал в то время, я провел тестовую
начальные этапы для части тестов, в то время как остальные были выполнены без запуска. «Стартовые» испытания были
выполнено в 1,4 раза быстрее, чем тестирование «без зацепа». Другими словами, тестировщики, которые начали
прошли на 40% больше тестов, чем те, у кого не было начального этапа.

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

Рисунок 7.4: Контрольный список для начала создания теста.

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

Стр. Решебника 141

Альфа
Пора заняться. Менеджер проекта представляет вам альфа-кандидата. Вы подтверждаете это против Альфы

https://translate.googleusercontent.com/translate_f 113/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
критерии, которые вы установили на этапе планирования. Теперь можно начинать полнопроходные испытания.

В ходе альфа-тестирования дизайн игры дорабатывается. Функции тестируются и пересматриваются (или


слом). Недостающие активы интегрированы. Системы, разработанные разными программистами, связаны между собой
все вместе. Это захватывающее время.

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

В ходе альфа-тестирования все модули игры должны быть протестированы хотя бы один раз, и
должны быть установлены базовые показатели производительности (частота кадров, время загрузки и т. д.). Эти исходные данные будут
помочь команде разработчиков определить, как далеко они должны пойти, чтобы довести каждый стандарт производительности до
цель для выпуска. Например, частота кадров 30 (или даже 15) кадров видео в секунду (fps) может
быть приемлемым на ранних этапах разработки 3D-игры, но целью выпуска должна быть
стабильные 60 кадров в секунду без продолжительных провалов во время сцен с большим, чем обычно, количеством кадров
персонажи и спецэффекты на экране.

Критерии входа в альфа-фазу


Ниже приведены критерии входа в альфа-версию, типичные для консольной игры:

1. Все основные игровые функции существуют и могут быть протестированы. Некоторые все еще могут быть в отдельных модулях для
в целях тестирования.

2. Тестировщик может провести игру по некоторому пути от начала до конца. Это предполагает игру
является линейным или имеет некоторую линейную составляющую (например, режим карьеры в гоночной игре). Так как
многие игры нелинейны, ведущий тестировщик и руководитель проекта должны заранее согласовать
цель завершения контента для таких игр (например, три из 12 мини-игр).

3. Код проходит не менее 50% платформы TRC. Каждая консольная игра имеет набор стандартов
опубликовано и протестировано производителем этой платформы. Когда вы производите
Игра для PlayStation, команда Format QA в Sony Computer Entertainment America (SCEA) протестирует
это противоречит Контрольному списку технических требований PlayStation (TRC), чтобы убедиться, что игра
соответствует соглашениям о платформе. Эти требования очень строгие, например, указание
точный текст сообщений об ошибках, которые должна отображать игра, если игрок вытаскивает карту памяти
во время сохранения игры.

4. Базовый интерфейс завершен, предварительная документация доступна QA. Главный


меню, большинство подменю и игровой интерфейс (иногда называемый Heads-Up Display или
HUD) должен быть функциональным, если еще не доработан и визуально отполирован. Предварительная документация в
этот контекст означает любое объяснение новых функций, измененных карт контроллеров и мошенничества.
коды (если есть).

5. Игра совместима с большинством указанных конфигураций оборудования и программного обеспечения. Для


кроссплатформенная консольная игра, это означает, что игра будет работать на каждой целевой платформе
(Например, PlayStation 2 и Xbox). Для компьютерной игры этот критерий диктует, что игра должна
работать на множестве систем с различными характеристиками (диапазон скоростей процессора, диапазон оперативной памяти

Стр. Решебника 142

кеши и так далее).

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

7. Сторонние контроллеры и карты памяти работают. Каждый производитель платформы (SCEA, Microsoft,
Nintendo и т. Д.) Либо производит, либо лицензирует производство собственной линейки периферийных устройств.
Поскольку поддержка этих периферийных устройств первого производителя требуется для TRC платформы, и поскольку
большая часть тестирования будет проводиться с использованием периферийных устройств сторонних производителей, они должны поддерживаться Alpha.

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

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

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

https://translate.googleusercontent.com/translate_f 114/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

В ходе альфа-тестирования все модули игры должны быть протестированы хотя бы один раз, и
должны быть установлены базовые показатели производительности (например, частота кадров, время загрузки и т. д.). Эти
базовые показатели помогут команде разработчиков определить, как далеко им нужно зайти, чтобы добиться каждого результата.
стандарт до цели для выпуска. Например, частота кадров 30 (или даже 15) кадров видео на
второй (fps) может быть приемлемым на ранних этапах разработки 3D-игры, но выпуск
цель должна быть стабильной 60 кадров в секунду без продолжительных провалов во время сцен, когда есть больше, чем обычно
количество персонажей и спецэффекты на экране.

Стр. Решебника 143

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

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

Критерии входа в бета-фазу


Следующие критерии фазы бета-тестирования типичны для консольной игры:
1. Реализованы все функции и опции. В игре "функция завершена".

2. Код проходит не менее 100% платформы TRC. Ближе к концу бета-тестирования игра должна быть
готов к отправке "предварительной сертификации" производителю платформы. Этот процесс позволяет
команда QA производителя платформы, чтобы протестировать игру на соответствие последней версии TRC и предупредить о любых
потенциальные проблемы с соблюдением требований.

3. В игре можно перемещаться по всем путям. Любые ошибки, которые могли закрывать части
игры исключены.

4. Весь пользовательский интерфейс окончательный.

5. Игра совместима со всеми указанными конфигурациями оборудования и программного обеспечения.

6. Логика игры и ИИ окончательны. Программирование завершено на « геймплее » игры. В


игра знает свои правила. Все профили AI заполнены.

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

8. Завершено оформление. Не должно быть никаких картинок-заполнителей. Бета - это фаза


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

https://translate.googleusercontent.com/translate_f 115/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

9. Реализовано финальное аудио. Все звуковые файлы-заполнители заменены финальными активами


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

10. Все онлайн-режимы полны и доступны для тестирования.

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

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

Стр. Решебника 144

представил еще один дефект в другом месте игры.

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

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

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

С какими ошибками поставляться. Во многих отношениях это самое трудное решение - какие ошибки оставить.

Отпустить ошибки
Как игрок, вы могли столкнуться с дефектом в купленной игре. Ваша реакция может быть
был: "Интересно, как тестеры это пропустили?" Скорее всего, они его не пропустили.

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

Какой бы ни была причина, каждый проект должен иметь быстрый и упорядоченный процесс, чтобы определить, какие
будут устранены дефекты , то есть те, которые не будут исправлены командой разработчиков. Это обозначение
много разных имен. Ошибки, на которые не распространяется действие, могут быть обозначены как "как есть", ISV (в поставляемой версии), DWNF.
(Разработчик не исправит) или CBP (закрыт производителем). Худшее имя, которое я когда-либо встречал для
Отмененный статус является «избранным», что закрепляет циничную шутку: «Это не ошибка, это особенность». (Нет
Удивительно, но эта студия сейчас не существует, выпустив слишком много глючных игр.)

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

В идеале старшие члены команды проекта будут регулярно и часто встречаться для обсуждения тех ошибок, которые
команда разработчиков запросила отказ. Они могут быть помечены как "запрос на отказ" или
«запрос как есть» в полях «Статус» или «Статус разработчика» базы данных ошибок. Старшие члены
команда проекта (продюсер, исполнительный продюсер, ведущий тестировщик и QA-менеджер) может встретиться для оценки каждого
ошибка и обсудите положительные и отрицательные стороны ее исправления вместо того, чтобы оставлять ее в игре. Другие члены команды
например, программисты или тестировщики должны быть доступны для этих встреч по мере необходимости. Это принятие решения
орган иногда называют CCB (Change Control Board) или Комитетом по ошибкам.

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

Как только ошибка была устранена, важно напомнить как автору ошибки, так и команде тестирования в целом.

https://translate.googleusercontent.com/translate_f 116/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. Решебника 145

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

Стр. Решебника 146

https://translate.googleusercontent.com/translate_f 117/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Золотое тестирование
После завершения фазы бета-тестирования игра должна перейти в состояние, подобное следующему набору
типичные рекомендации по выпуску:
1. Исправлены все известные ошибки с уровнем серьезности 1 (сбои, зависания, сбои основных функций).

2. Исправлено более 90% всех известных ошибок с уровнем серьезности 2.

3. Исправлено более 85% всех известных ошибок с уровнем серьезности 3.

4. Для любых известных открытых проблем есть обходные пути, о которых было сообщено в службу технической поддержки (или
задокументировано в Файл README.TXT , в случае компьютерных игр).

5. Достигнута производительность на уровне релиза (частота кадров 60 кадров в секунду).

При выполнении ваших критериев выпуска игра объявляется «на кодовой блокировке». Краткий, напряженный период
проводится тестирование того, что все в команде надеется (но, вероятно, не будет) финальным
строить. Поскольку версия игры, которая отправляется на производство, известна как золотой мастер , окончательный
несколько протестированных версий известны как кандидаты в золотые мастера (GMC) или кандидаты на выпуск .

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

Дефекты в последнюю минуту


Поскольку заключительные этапы проекта настолько интенсивны и перегружены, люди негативно отреагируют на
showstoppers: «Почему мы [или вы] просто находим это сейчас? Тесты длились месяцами!» Этот
Воздержание часто слышно от истощенных руководителей. Лучше всего, чтобы испытательная команда взяла такой эмоциональный
комментируйте спокойно и помните несколько незыблемых истин разработки игр:

1. В любом проекте редко бывает достаточно времени, чтобы найти каждую ошибку.

2. Каждый раз, когда программист касается кода, могут появиться ошибки.

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

4. К концу проекта программисты гораздо более устают и склонны к ошибкам.

5. Тестировщики гораздо более устают и склонны упускать что-то ближе к концу проекта.

6. Ошибки случаются.

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

Стр. Решебника 147

Сертификация выпуска
Чистый GMC отправляется производителю платформы для окончательной сертификации после того, как команда проекта завершит работу.
Тестирование золота. Затем производитель платформы (например, Nintendo, SCEA или Microsoft) проводит свои
собственное интенсивное тестирование на GMC. Их тестирование состоит из двух этапов, которые могут проходить одновременно или
последовательно. На этапе стандартизации код проверяется на соответствие Контрольному списку технических требований. В
Фаза функциональности проверяет код на функциональность и стабильность. Релиз-тестеры всегда играют в игру
хотя бы один раз за отправку. Они часто находят собственные ошибки.

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

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

https://translate.googleusercontent.com/translate_f 118/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
После того, как игра была повторно отправлена ​и сертифицирована производителем платформы, она становится «Золотой». В
шампанское должно потечь. Но проект еще не закончен.

Стр. Решебника 148

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

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

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

https://translate.googleusercontent.com/translate_f 119/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. Решебника 149

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

https://translate.googleusercontent.com/translate_f 120/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр.150

Упражнения
1. Каковы основные обязанности ведущего тестировщика?

2. Какие поля в базе данных ошибок следует разрешить первичному тестировщику изменять?

3. Бета-версия - это версия, которая будет отправлена ​в производство. Правда или ложь?

4. Опишите, подходит ли каждая из следующих тем для обсуждения во время теста.


начало выполнения и почему:
а. Возможные противоречия в требованиях к функции

б. Идеи для новых тестов

c. Курсы акций компании

d. Идентичные тесты уже выполняются в других тестовых наборах

е. Насколько "глючной" эта функция была в предыдущем выпуске

f. Последние изменения в форматах файлов данных игры

грамм.
Недостаток деталей в документации тестового случая

5. Блокировка функций должна происходить в Alpha. Правда или ложь?

6. Возможности сетевой многопользовательской игры можно протестировать в альфа-версии. Правда или ложь?

7. Быть командным игроком не является важным критерием для ведущего тестировщика. Правда или ложь?

8. Все ошибки ДОЛЖНЫ быть исправлены до того, как игра будет сертифицирована как GMC. Правда или ложь?

9. Объясните разницу между планом тестирования и тестовым примером.

Ответы

Стр. Решебника 151

https://translate.googleusercontent.com/translate_f 121/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

1. Основные обязанности ведущего тестировщика: управление командой тестирования, разработка и внедрение


общий план тестирования проекта, «владеющий» базой данных ошибок.

2. Основному тестировщику должно быть разрешено изменять все поля в базе данных ошибок, кроме Приоритета,
Статус, Кому назначено и Комментарии разработчиков.

3. Неверно

4. а. уместно, так как это "вопрос функции", чтобы понять, как функция и ее тесты должны
действительно работает.

б. уместно в качестве предмета "улучшения тестирования".

c. не подходит.

d. уместно в качестве предмета "улучшения тестирования".

е. уместно, так как имеет дело с «недавней историей дефектов» функции.

f. уместно, поскольку относится к сбору «оборудования, файлов и программ, необходимых для тестирования».

грамм.
уместно в качестве предмета "улучшения тестирования".

5. Неверно

6. Верно

7. Неверно

8. Неверно

9. Короче говоря, план тестирования определяет общую структуру цикла тестирования. Тестовый пример - это один конкретный
вопрос или условие, по которому выполняется работа и оценка кода.

Стр. Решебника 152

Глава 8: Процесс тестирования


Программисты не тестируют полностью свои игры. У них нет времени, и даже если они и сделали, это не
отличная идея. Еще на заре эры видеоигр программист игры часто был ее художником,
дизайнер и тестировщик. Несмотря на то, что игры были очень маленькими - размером с электронную почту, - программист тратил
большую часть времени занимается дизайном и программированием. Мало его времени было потрачено на тестирование. Программист
Астросмаш , космический стрелок системы Intellivision, сделал предположение, когда проектировал
игра, в которой ни один игрок никогда не наберет 10 миллионов очков. В результате он не выписал чек на оценку
переполнен. Он перечитал свой собственный код, и - исходя из собственных предположений - он, похоже, работал нормально. Это
была забавной игрой - ее графика захватывала дух (в то время), и игра стала одной из
самые продаваемые игры на платформе Intellivision.

Однако через несколько недель после выхода игры несколько клиентов стали звонить с жалобами.
Когда они набирали более 9 999 999 баллов, в них отображались отрицательные числа, буквы и т. Д.
нечисловые символы. Это было после того, как в каталоге описывалась игра как имеющая «неограниченное количество очков.

https://translate.googleusercontent.com/translate_f 122/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
потенциал ». Проблема усугублялась тем фактом, что в консоли Intellivision была функция, которая
позволяет игрокам играть в игру в замедленном режиме, что значительно упрощает набор высоких результатов. Джон
Программист Сол усвоил тяжелый урок: пользователь всегда удивит вас .

Тестирование «черного ящика»


Практически все игровое тестирование - это тестирование черного ящика ; тестирование проводится вне приложения. Не знаю,
или доступ к исходному коду предоставляется тестировщику. Игровые тестеры обычно не находят дефекты, читая
код игры. Скорее, игровые тестеры пытаются найти дефекты, используя те же устройства ввода, что и
нормальный плеер. Тестирование черного ящика - самый экономичный способ протестировать чрезвычайно сложную сеть
системы и модули, которые представляет даже самая простая видеоигра.

На рисунке 8.1 показаны некоторые из различных входов, которые вы можете предоставить видеоигре, и выходы, которые вы можете
получить обратно. Самыми основными из входов являются позиционные и управляющие данные в виде нажатия кнопок и
движения курсора. Они могут поступать от различных устройств ввода: джойстиков, клавиатур, мышей и т. Д.
эзотерические устройства, такие как танцевальные площадки, контроллеры для ловли окуня, контроллеры maraca и контроллеры барабанов. Аудио
вход может поступать с микрофонов в гарнитурах или подключаться к игровому контроллеру. Видео вход может прийти
с USB-камер. Ввод от других пользователей может поступать от второго контроллера, локальной сети или
Интернет. Наконец, сохраненные данные, такие как сохраненные игры и настройки параметров, могут быть вызваны в качестве входных данных из
карты памяти или жесткий диск.

Рисунок 8.1: Тестирование черного ящика - планирование входных данных и проверка выходных данных.

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

Стр. Решебника 153

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

Рисунок 8.2: Цикл обратной связи игрока подстраивается под ввод игры и наоборот.

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

https://translate.googleusercontent.com/translate_f 123/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Стр. Решебника 154

Тестирование "белого ящика"


В отличие от тестирования черного ящика, тестирование белого ящика дает тестировщику возможность проверить исходный код.
кодируйте напрямую так, как никогда не мог бы конечный пользователь. Для тестировщика «белого ящика» может быть непросто прочитать
кусок игрового кода и предсказать каждый способ его взаимодействия с каждым другим битом кода,
и учтены ли в коде все возможные комбинации и порядок ввода. Тестирование игры
использование только методов белого ящика также чрезвычайно сложно, потому что почти невозможно учесть
сложность петли обратной связи игрока. Однако есть ситуации, в которых тестирование методом белого ящика более
практично и необходимо, чем тестирование черного ящика. К ним относятся следующие:

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

Тестирование модулей кода, которые станут частью многоразовой библиотеки в нескольких играх и / или
платформы

Тестирование методов или функций кода, которые являются важными частями игрового движка или промежуточного программного обеспечения.

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

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

При выполнении тестирования белого ящика вы выполняете определенные модули и различные пути, по которым код может
следуйте при использовании модуля различными способами. Тестовые входы определяются типами и значениями
данные, которые можно передать в код. Результаты проверяются путем изучения значений, возвращаемых модулем,
глобальные переменные, на которые влияет модуль, и локальные переменные по мере их обработки в
модуль. Чтобы почувствовать вкус тестирования белого ящика, рассмотрим процедуру TeamName из Castle Wolfenstein:
Вражеская территория :

const char * TeamName (int team) {


если (команда == TEAM_AXIS)
вернуть «КРАСНЫЙ»;
иначе, если (команда == КОМАНДА_ВСЕ)
вернуть "СИНИЙ";
иначе, если (команда == TEAM_SPECTATOR)
вернуть "ЗРИТЕЛЬ";
вернуть «БЕСПЛАТНО»;
}

Для этого модуля требуются четыре теста белого ящика для проверки правильного поведения каждой строки кода в пределах
модуль. Первым тестом будет вызов функции TeamName с параметром TEAM_AXIS, а затем
убедитесь, что возвращается строка «КРАСНЫЙ» . Во-вторых, передайте значение TEAM_ALLIES и убедитесь, что
"СИНИЙ" возвращается. В-третьих, передайте TEAM_SPECTATOR и убедитесь, что возвращается "SPECTATOR" . Ну наконец то,
передать другое значение, такое как TEAM_NONE , которое гарантирует возврат "FREE" . Вместе эти
тесты не только проверяют каждую строку кода хотя бы один раз, они также проверяют поведение как «истинного», так и
"ложные" ветви каждого оператора if .

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

https://translate.googleusercontent.com/translate_f 124/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
подход к тестированию черного ящика:
Тестирование черного ящика должно проверить все различные способы выбора тестового значения из
игра, например, различные меню и кнопки. Тестирование белого ящика требует, чтобы вы передали это значение в
подпрограмма в одной форме - ее фактическое символическое значение в коде.

Стр.155

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

Тестирование черного ящика основывается на согласованной конфигурации игры и ее операционной среды в


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

Стр. Решебника 156

https://translate.googleusercontent.com/translate_f 125/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Жизненный цикл сборки


Базовый процесс тестирования игры состоит из следующих этапов:

1. Спланируйте и разработайте тест. Хотя многое из этого делается на ранней стадии планирования, планирование и
дизайн следует пересматривать с каждой сборкой. Что изменилось в спецификации дизайна с момента последней сборки? Какие
добавлены дополнительные тестовые случаи? Какие новые конфигурации поддержит игра? Какие особенности есть
был вырезан? Объем тестирования должен гарантировать, что в процессе исправления ошибок не возникнет никаких новых проблем.
до этого выпуска.

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

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

4. Сообщите о результатах. Зарегистрируйте завершенный набор тестов и сообщайте обо всех обнаруженных вами дефектах.

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

6. Вернитесь к шагу 1 и повторите тест. С новыми ошибками и новыми результатами тестов приходит новая сборка.

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

Как показано на рис. 8.3, сам процесс тестирования представляет собой цикл обратной связи между тестировщиком и разработчиком. Тестер
планирует и выполняет тесты кода, а затем сообщает об ошибках разработчику, который исправляет их и компилирует новую сборку,
тестировщик планирует и выполняет тесты, и так далее.

Рисунок 8.3: Цикл обратной связи процесса тестирования.

Удобная шкала для изучения этого процесса находится на уровне тестирования отдельной сборки. Даже относительно
Небольшой игровой проект может состоять из десятков сборок за цикл разработки.

Стр. Решебника 157

Тестовые наборы и наборы тестов


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

В простейшей форме набор тестов представляет собой серию пошаговых шагов, которые тестер может выполнять последовательно. Последующий
в главах этой книги подробно обсуждается умелое проектирование тестовых примеров и наборов с помощью таких методов, как комбинаторный
таблицы и схемы испытаний. Для целей этого обсуждения рассмотрим небольшой набор тестов, который вы бы выполнили на
Minesweeper - простая игра, доступная в большинстве версий Microsoft Windows. Часть этого набора показана на
Рисунок 8.4. Вы найдете образец набора тестов в Приложении E.

https://translate.googleusercontent.com/translate_f 126/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

Рисунок 8.4: Часть набора тестов для Minesweeper .

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

Поскольку тестировщики неизбежно увидят результаты, которых разработчик тестов не планировал, поле «Примечания» позволяет
тестировщик, чтобы уточнить ответ Да / Нет, если необходимо. Ведущий или основной участник, получивший завершенный набор тестов, может
затем просканируйте поле «Примечания» и внесите необходимые изменения в набор тестов для следующей сборки.

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

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

Есть ли в тексте опечатки?

Проблема с этим вопросом в том, что пройденный тест (без опечаток) будет записан как «нет». Было бы очень легко торопиться
(или уставший) тестировщик ошибочно пометил столбец Fail. Гораздо лучше сформулировать вопрос так, чтобы ответ был положительным.
указывает на "пройденное" условие:

Нет ли в тексте опечаток?

Стр. Решебника 158

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

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

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

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

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

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

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

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

Контроль версий: не только для разработчиков

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

https://translate.googleusercontent.com/translate_f 127/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
предотвратимые) причины дефектов программного обеспечения. Процесс отслеживания сборок и обеспечение того, чтобы все участники
Команда разработчиков проверяет текущий код и активы в текущей версии, известной как контроль версий.

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

Правильный контроль версий для группы тестирования включает следующие шаги:

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

2. Архивируйте все документы. Сюда входят не только все примечания к сборке, полученные от команды разработчиков, но и
также любые завершенные тестовые наборы, старые планы тестирования, снимки экрана, сохраненные игры, заметки, .AVI и любые другие
материал, созданный в ходе тестирования сборки. Иногда бывает важно повторить шаги по
бумажный след, помогает ли выявить новый дефект или определить, в какой версии была старая ошибка
введен.

3. Перед копированием проверьте номер сборки у разработчика.

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

5. Измените нумерацию всех наборов тестов и любых других документов, относящихся к сборке, на текущий номер версии.

6.

Стр. Решебника 159

5.

6. Раздайте новую сборку для дымового тестирования.

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

Возможно, наиболее важным шагом в этой подготовке является устранение любых следов предыдущей сборки на оборудовании.
«Очистить» старую сборку на Nintendo GameCube просто, потому что единственным записываемым носителем для этой системы является
карта памяти. Все, что вам нужно сделать, это удалить и заархивировать сохраненную игру, которую вы создали с помощью старой сборки. Более тщательный тест
Лидеры попросят своих тестеров выполнить дополнительный шаг по переформатированию карты памяти, при котором карта полностью стирается, чтобы
убедитесь, что никакие следы данных старой сборки не будут перенесены во время тестирования новой сборки.
Кончик

Сохраните свои сейвы! Всегда архивируйте свои старые данные, созданные пользователями, включая сохранения игр, файлы опций, пользовательские символы и т. Д.
и настраиваемые уровни.

Неудивительно, что для компьютерных игр подготовка конфигурации может быть намного сложнее. Максимально чистое тестирование
конфигурация для игры на ПК

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

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

Последние версии любых «вспомогательных приложений» или промежуточного программного обеспечения, необходимых для запуска игры. Они могут варьироваться от Microsoft
Мультимедийные библиотеки DirectX для многопользовательского программного обеспечения для поиска матчей, такого как GameSpy Arcade.

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

«Боб» однажды вошел в лабораторию контроля качества, которая тестировала очень передовую 3D-игру для ПК. Тестирование игры упало
позади, и его отправили из штаб-квартиры компании для расследования. Боб прибыл поздно утром, и
в полдень он был потрясен, увидев, как тестировщики вышли из игры, которую они тестировали, и запустили электронную почту, IRC, веб-браузеры и
программы для обмена файлами - множество приложений, установленных на их тестовых компьютерах. Некоторые даже прыгнули в
игра Unreal Tournament . Боб спросил помощника менеджера по тестированию, почему, по его мнению, это хорошая идея для всех тестировщиков.
иметь эти посторонние программы в своих тестовых конфигурациях. «Он имитирует реальные условия», - пожал плечами он.
раздражен вопросом Боба.

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

https://translate.googleusercontent.com/translate_f 128/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Проблема была решена
затем с помощью путем переформатирования
программы-образа диска создайте каждого тестового ПК,системы.
файл восстановления новой установки операционной
С этого момента системы ипросто
тестировщикам последних драйверов,
нужно было а также
переформатируйте их жесткий диск и скопируйте файл восстановления системы с компакт-диска.

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

Дымовые испытания

Стр. Решебника 160

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

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

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

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

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

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

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

Тест "Вокруг" ошибки


Старая столярная поговорка гласит: «Дважды отмерь, один раз отрежь». Хорошие тестировщики тщательно исследуют дефект перед тем, как написать о нем.
вверх, предвосхищая любые вопросы, которые могут возникнуть у команды разработчиков.

Прежде чем приступить к составлению отчета о дефектах, задайте себе следующие вопросы:

1. Это единственное место или уровень, где возникает ошибка?

2. Возникает ли ошибка при использовании других персонажей?

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

4. Могу ли я устранить какие-либо шаги на пути к воспроизведению ошибки?

5.

https://translate.googleusercontent.com/translate_f 129/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я
Стр. Решебника 161

4.

5. Возникает ли ошибка на всех платформах (например, PlayStation2 и Xbox)?

6. Является ли ошибка конкретной машиной (например, возникает ли она только на ПК с определенной конфигурацией оборудования)?

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

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

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

Вопрос:

Сколько нужно программистов, чтобы вкрутить лампочку?

Ответы

А:

Нет - там, где они сидят, не темно.

Хорошее написание отчета об ошибке позволяет программистам «увидеть свет» ошибки. Но программисты - далеко не единственные
люди, которые прочитают вашу ошибку. Аудитория может включать

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

Менеджер проекта, который прочитает ошибку и назначит ее соответствующему члену команды проекта.

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

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

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

Другие тестировщики, которые будут воспроизводить шаги, если их попросят проверить исправление во время регрессионного тестирования.

Поскольку вы никогда не знаете, кто будет читать ваш отчет об ошибке, вы всегда должны писать четко, объективно и четко.
как можно более беспристрастным. Вы не можете предположить, что каждый, кто читает ваш отчет об ошибке, будет так же знаком с
игра, как вы. Тестировщики проводят больше времени в игре, исследуя каждый скрытый путь, внимательно исследуя каждый
актив - чем почти кто-либо другой в команде проекта. Хорошо написанная ошибка даст читателю, не знакомому с
игра хорошо понимает тип и серьезность дефекта, который она описывает.

Просто факты, мэм

Дело в том, что дефекты вызывают стресс у команд разработчиков, особенно в «критический момент». Каждая новая ошибка добавляется в
база данных означает, что еще предстоит проделать большую работу. В проекте среднего размера могут быть сотни или тысячи дефектов.
сообщается до его завершения. Разработчики могут чувствовать себя очень ошеломленными и, в свою очередь, станут очень враждебными, если почувствуют

Стр. Решебника 162

время тратится на легкомысленные или произвольные ошибки. Вот почему хорошее написание ошибок основано на фактах и ​беспристрастно.

Шляпа охранника должна быть синей.

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

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

ИИ слабый.

https://translate.googleusercontent.com/translate_f 130/424
15.07.2021 Game Testing All in One Чарльз П. Шульц, Роберт Брайант и Тим Лэнгделл Роли и обязанности тестировщика игр, это я

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

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

Краткое описание

Более крупные базы данных могут содержать два поля описания: краткое описание и полное описание. Поле Краткое описание
используется в качестве краткого справочника для определения ошибки. Это должно быть не симпатичное прозвище, а описание, состоящее из одного предложения.
позволяет членам команды выявлять и обсуждать дефекты, не читая каждый раз более подробное полное описание. Считать
краткого описания в качестве заголовка отчета о дефекте.

Вылет на рабочий стол.

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

Система спасения нарушена.

Это полное предложение, но недостаточно конкретное. Что испытал тестер? Игра не сохранялась? Сделал
сохраненная игра не загружается? Сохранение вызывает сбой?

Вылет на рабочий стол при выборе «Параметры» в главном меню.

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

Игра вылетела после того, как я убил всех охранников и дважды прошел уровень, чтобы получить
все пикапы и убили первого возродившегося охранника.

Это продолжительное предложение, в котором слишком много деталей. Хороший способ сварить это может быть

Игра вылетела после возрождения охранников.

Стр. Решебника 163

Телепрограммы в вашей газете могут стать отличными примерами краткого описания - они сводятся к целой половине
часовой ситком или двухчасовой фильм в одно или два предложения.
Кончик

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

Полное описание

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

1. Запускаем игру.
2. Посмотрите анимированные логотипы. Не нажимайте ESC, чтобы пропустить их.
-> Обратите внимание на плохой стробирующий эффект в конце логотипа разработчика.

Чем меньше шагов, тем лучше, и чем меньше слов, тем лучше. Помните предупреждение Брэда Питта Мэтту Дэймону в фильме «Оушен».
Одиннадцать : «Не используйте семь слов, если достаточно четырех». Точно так же не используйте семь шагов, когда д