Текст книги "Тестирование видеоигр, или Легкий способ попасть в геймдев"

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

Финансовые ресурсы

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

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

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

Вероятность – это степень возможности наступления некоторого события, зависящая от разных факторов, к которым можно отнести:

• сложность технологии и команд;

• личностные проблемы и проблемы подготовки среди членов команд;

• конфликт внутри команды;

• слабое управленческое или техническое руководство;

• время, ресурсы, бюджет и давление менеджмента;

• отсутствие мероприятий по обеспечению качества;

• высокие темпы изменений;

• высокий темп выявления ранних дефектов.

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

• частоту использования затронутой функции;

• критичность функции для достижения целей;

• ущерб репутации;

• потенциальные финансовые потери;

• отсутствие разумных обходных путей и др.

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

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

Идентификация рисков

Цель этого этапа – выявить некоторое количество неизвестных рисков проекта. Часто в управлении рисками вероятность возникновения и критичность риска рассматривается с точки зрения «причина – риск – эффект».

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

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

Анализ рисков

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

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

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

Карта рисков

Должна быть определена граница для критичности рисков. В примере выше эта граница определена как 6 баллов и выше. То есть риски, оцененные выше 6 баллов, рассматриваются как значительные.

Планирование рисков

Цель этого этапа – создание стратегии управления риском, которая устранит или уменьшит его последствия. Есть три основные стратегии.

1. Перенести ответственность за последствия риска на третью сторону (заказчика, компанию партнера, страховую компанию и т. д.). Стратегия используется, если нельзя повлиять на существующий риск.

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

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

Мониторинг и контроль рисков

Мониторинг и контроль рисков – это постоянный процесс поддержания информации о рисках в актуальном состоянии, который в упрощенном виде выглядит как:

• выполнение ревизии списка рисков, обновление их оценки и обновление устаревших планов;

• выявление случившихся рисков, принятие решения о внедрении запасных планов и обновление плана тестирования.

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

Определите потенциальный риск, связанный с коммуникацией между командами разработчиков и тестировщиков, с точки зрения «причина – риск – эффект» и предложите план управления риском (основной и запасной).

3.2. Проектирование тест-кейсов

Тест-кейс (он же контрольный пример в ГОСТе, он же тестовый случай и т. д.) – это алгоритм действий для получения ожидаемого результата, включающий начальные условия и входные данные для проверки.

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

Во время этапа проектирования условия тестирования преобразуются в тест-кейсы и наборы тест-кейсов (тест-суитов). Таким образом, анализ и планирование отвечают на вопрос «Что тестировать?», а проектирование – «Как тестировать?».

Проектирование базово включает в себя:

• проектирование и приоритизацию тест-кейсов и наборов тест-кейсов;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как и остальные документы тестирования, тест-кейсы имеют свою структуру и основные атрибуты.

• Идентификатор (ID) – номер кейса.

• Приоритет (Priority) – степень необходимости прохождения тест-кейса. Может варьироваться от «Умри, но выполни» до «Забей», потому что на каждом проекте названия и важность этого атрибута будут определяться индивидуально. Приоритет тест-кейсов помогает оценить жизнеспособность продукта. Например, три непройденных тест-кейса при проверке элементов интерфейса, имеющих низкий приоритет, не так критичны, как один тест-кейс, проверяющий загрузку клиента игры.

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

• Предусловия (Precondition) – состояние игры, необходимое для начала проведения проверок. Например, необходимо быть залогиненным под определенным аккаунтом на сервере и должен быть выбран определенный персонаж или включен графический режим Ultra.

• Шаги (Steps). Действия, выполняемые в процессе проверок, которые должны привести к «Ожидаемому результату». То есть в буквальном смысле – Выбрать персонажа 1, перейти в окно выбора оружия, выбрать оружие 1.

• Ожидаемый результат (Expected Result). Состояние игровой системы, в которое она должна перейти. Например, при нажатии клавиши W персонаж идет вперед и т. д.

• Статус (Status) – результат проверки. Он содержит в себе обозначения вроде Passed, Failed, In Progress, Blocked, Untested.

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

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

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

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

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

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

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

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

Тест-кейсы бывают двух типов – позитивные и негативные.

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

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

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

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

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

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

Разберем написание тест-кейса на примере перехода игрока между лигами в игровой рейтинговой системе. Важно: игроки не могут «перескакивать» через несколько лиг за раз, перемещение происходит последовательно.

Все игроки начинают игру с нулевым рейтингом. Для определения стартовой лиги используются отборочные матчи. Выиграв 3 матча, игрок попадает в золотую лигу, 2 победных матча – в серебряную, 1 или менее побед – в бронзовую.

Напишем тест-кейс о переходе игрока в бронзовую лигу.

• ID: BL01

• Priority: Must Do

• Summary: переход игрока в бронзовую лигу при поражении.

• Precondition: запущенный режим лиг на сервере.

• Steps:

1. перейти в рейтинговые бои;

2. сыграть три отборочных матча, проиграв каждый из них;

3. открыть интерфейс рейтинговых боев

• Expected Result: Игрок помещен в бронзовую лигу.

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

1. Passed – фактический результат равен ожидаемому.

2. Failed – фактический результат не равен ожидаемому. Найдена ошибка.

3. Blocked – выполнение теста блокировано, если после одного из шагов продолжение теста невозможно. Найдена ошибка. Или функционал не реализован и не может быть протестирован.

Пример структуры проекта (ее части)

Хорошо составленный тест-кейс можно использовать при описании бага. Конечно, его нужно будет дополнить фактическим результатом, подробным описанием и прочими атрибутами дефекта типа критичности, но шаги (STR) и ожидаемый результат (Expected Result) у вас уже готовы.

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

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

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

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

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

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

4. Обязательно прикладывай необходимые аттачи[21]21
  Аттачи (от англ. attachments) – дополнительные материалы.


[Закрыть], особенно если без скриншота непонятно, как этот тест-кейс проходить.

5. Подробно прописывай шаги и ожидаемый результат после выполняемых действий.

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

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

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

При проектировании тест-кейсов необходимо подумать о возможности и необходимости применения техник тест-дизайна – методик оптимизации ресурсов при проведении тестовых активностей. Своевременное и уместное применение техник тест-дизайна помогает серьезно сократить трудозатраты и время на само тестирование.

То есть тест-дизайн – это процесс, который позволяет создать оптимальное тестовое покрытие объекта при минимально возможных трудозатратах, используя определенные техники. Давай разберем некоторые из них.

Предугадывание ошибок (Error Guessing)

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

• знание того, как приложение работало в прошлом;

• знание того, какие типы и виды дефектов традиционно допускаются во время разработки;

• знание дефектов, которые были найдены в похожих приложениях.

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

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

Техника предугадывания ошибок (Error Guessing) в тестировании компьютерных игр предполагает использование опыта и интуиции тестировщика для предвидения потенциальных ошибок или проблем, которые могут возникнуть в процессе использования игры. Вот пример использования этой техники.

Пример. Тестирование многопользовательского режима в компьютерной стратегической игре.

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

Шаги тестирования

1. Предположение: проблемы синхронизации игрового состояния.

• Предположим, что сетевая синхронизация игрового состояния между игроками может привести к несоответствиям или задержкам в игровом процессе.

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

2. Предположение: ошибки в балансе игровых персонажей.

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

• Проверить балансировку уровня и силы игровых единиц в различных сценариях игры.

3. Предположение: проблемы совместимости между версиями клиента и сервера.

• Предположим, что изменения в клиентской или серверной части могут привести к несовместимости версий.

• Проверить, что клиент и сервер работают корректно после обновлений или патчей.

4. Предположение: проблемы с обработкой большого количества одновременных действий.

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

• Провести тестирование с максимально возможным количеством игроков и действий на экране.

5. Предположение: нарушения правил игрового процесса.

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

• Провести проверку наличия и эффективности античитовых механизмов.

Ожидаемый результат

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

Причина-следствие (Cause/Effect)

Метод предполагает проверку того, что ввод комбинаций условий (причин) приводит к получению определенного ответа от системы (следствие).

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

Каждый столбец этой таблицы – по сути, готовый тест-кейс.

Техника «причина-следствие» (Cause-Effect Testing) в тестировании компьютерных игр позволяет идентифицировать и проверять причины и следствия определенных событий или действий в игре. Рассмотрим пример использования этой техники на практике.

Пример. Тестирование эффектов падения здоровья персонажа в компьютерной игре.

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

Шаги тестирования

1. Падение здоровья от атаки противника.

• Провести тест, в ходе которого персонаж будет атакован противником.

• Проверить, что здоровье персонажа уменьшается при успешной атаке противника.

2. Проверка визуального отображения уменьшения здоровья.

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

3. Падение здоровья от повреждений окружающей среды.

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

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

4. Восстановление здоровья от лечения.

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

• Проверить, что здоровье персонажа восстанавливается после использования лечебных средств.

5. Проверка смерти персонажа при полном исчерпании здоровья.

• Провести тест, в ходе которого здоровье персонажа будет снижено до нуля.

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

Ожидаемый результат

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

Эквивалентное разбиение (Equivalence Partitioning)

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

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

Пример. Тестирование управления автомобилем в компьютерной игре.

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

Эквивалентные классы

1. Тип контроллера

• Клавиатура

• Геймпад

• Руль с педалями

2. Тип управления

• Управление направлением (повороты)

• Управление скоростью (газ, тормоз)

• Управление специальными функциями (нитро, ручной тормоз)

Тест-кейсы

1. Тестирование управления направлением.

• Для каждого типа контроллера провести тестирование управления поворотами автомобиля вправо и влево.

• Проверить, что автомобиль поворачивает корректно и плавно при использовании каждого типа контроллера.

2. Тестирование управления скоростью.

• Для каждого типа контроллера провести тестирование управления газом и тормозом.

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

3. Тестирование специальных функций.

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

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

Ожидаемый результат

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

Граничные значения (Boundary Value Analysis)

Техника граничных значений основана на том предположении, что много ошибок возникает на границах эквивалентных классов. Она связана с техникой эквивалентного разбиения и поэтому часто используется с ней в паре. Часто проблемы возникают, когда возрастные категории указаны «внахлест» (например, 0–18, 18 и старше). Например, игра содержит платный контент, и игрок может приобрести внутриигровую валюту или игровые предметы за реальные деньги. При этом оплату могут произвести игроки в возрасте от 18 лет. Тестировщику будет необходимо проверить, как система обработает запрос от совершеннолетнего игрока. То есть при использовании позитивных тест-кейсов нужно проверить: «пустое» значение, значение в диапазоне 1–17 (для несовершеннолетних игроков), 18 и любое значение больше 18 для совершеннолетних. То есть граничными значениями будут 0, 1, 18, 19. Графически решение этой задачи можно изобразить так:

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

Давай рассмотрим пример с проверкой поля ввода возраста пользователя.

В этом случае мы рассматриваем следующие классы эквивалентности.

1. Класс 1 – валидные значения от 18 и больше

2. Класс 2 – невалидные значения от 1 до 17

3. Класс 3 – невалидные значения от ∞ до 0

4. Класс 4 – невалидные данные (не числа)

Все эти классы делятся на три типа.

1. Класс, который имеет только нижнюю границу (Класс 1)

2. Класс, который имеет нижнюю и верхнюю границы (Класс 2)

3. Класс, который имеет только верхнюю границу (Класс 3)

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

Для Класса 1:

• верхней границы нет;

• нижние значения – 18 (внутри класса) и 17 (ближайшее вне класса).

Для Класса 2:

• верхние значения – 17 (внутри класса) и 18 (ближайшее вне класса);

• нижние значения – 1 (внутри класса) и 0 (ближайшее вне класса).

Для Класса 3:

• нижней границы нет;

• верхние значения – 0 (внутри класса) и 1 (ближайшее вне класса).

Как видно из примера выше, некоторые значения совпадают, а значит, не стоит проводить одни и те же тесты. Проверяем: