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

1. – 1 (проверяем Класс 3);

2. 0 (проверяем Класс 2 и Класс 3);

3. 1–17 (проверяем Класс 2 и Класс 3);

4. 18 (проверяем Класс 1 и Класс 2);

5. 19 (проверяем Класс 1);

6. буквы, спецсимволы и т. д. (проверяем Класс 4).

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

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

Для Класса 1:

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

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

Для Класса 2:

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

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

Для Класса 3:

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

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

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

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

При проверке условия, при котором х ≥ 18, где х – возраст пользователя с использованием двухточечного анализа, мы проверим значения 17 (негативный тест) и 18 (позитивный тест). Представь, что разработчик по ошибке поставил вместо знака ≥ просто =. Проверка в случае использования двухточечного анализа не выявила бы этой ошибки, потому что при проверке с 17 обнаружилась бы ошибка, а тест с 18 завершился бы успехом. А вот использование трехточечного анализа, при котором проверялось бы еще значение 19, эту ошибку выявил бы, потому что проверка закончилась бы ошибкой, а ее быть не должно.

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

Допустим, мы тестируем компьютерную игру с большим количеством уровней или миссий. Одна из техник тест-дизайна, которую мы можем применить, – метод граничных значений (Boundary Value Analysis, BVA). Давай рассмотрим пример применения этой техники для тестирования функции здоровья персонажа в игре.

Задача. Протестировать функцию здоровья персонажа в компьютерной игре.

В игре здоровье персонажа может иметь пределы, например от 0 до 100 единиц.

Граничные значения: 0 (минимальное значение), 1 (меньше минимального), 50 (среднее значение), 99 (больше минимального), 100 (максимальное значение), 101 (больше максимального).

Создание тест-кейсов

Тест 1. Проверка, что здоровье персонажа уменьшается правильно при получении урона до 0.

Тест 2. Проверка, что персонаж умирает, когда его здоровье достигает 0.

Тест 3. Проверка, что персонаж не может иметь отрицательное здоровье.

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

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

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

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

Попарное тестирование (Pairwise Testing)

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

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

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

Видеокарта (GPU)

1. AMD Radeon HD6570

2. NVidia GeForce RTX 2070

3. NVidia GeForce GTX 1060

Оперативная память (RAM)

1. 8 МB

2. 16 MB

3. 32 MB

Процессор (CPU)

1. Intel i7 4790

2. Intel Core i5-3330

3. AMD A10 7890K

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

Количество конфигураций = 3 х 3 х 3 = 27.

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

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

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

• Выбираем параметр с самым большим количеством значений.

• Составляем уникальные пары со следующим параметром.

• Сравниваем остальные параметры с последним.

• Удаляем лишние пары.

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

Но в большинстве случаев нет необходимости вручную комбинировать каждую такую пару. Можно использовать готовые программные решения, в которых нам нужно указать только параметры и значения, а дальше приложение рассчитает все само. В числе таких приложений можно назвать PICT (Pairwise Independent Combinatorial Tool) от Microsoft.

Используя их, мы получаем 9 комбинаций для проверки вместо 27. Неплохо!

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

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

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

Пример использования техники тест-дизайна (Pairwise Testing) для системы управления в компьютерной игре:

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

Входные данные

• Движение клавиш (WASD)

• Нажатие клавиш для атаки (левая кнопка мыши)

• Нажатие клавиши для прыжка (пробел)

• Действия мыши (вращение камеры, направление атаки и т. д.)

Применение техники тест-дизайна

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

Пример комбинаций

• Нажатие клавиши W (движение вперед) + Нажатие клавиши D (движение вправо) + Нажатие левой кнопки мыши (атака)

• Нажатие клавиши S (движение назад) + Нажатие клавиши A (движение влево) + Пробел (прыжок)

• Нажатие клавиши W (движение вперед) + Нажатие клавиши D (движение вправо) + Движение мыши влево (вращение камеры)

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

Тестирование на основе сценариев использования (Use Case Testing)

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

При этом тестовое покрытие мы определяем как процент протестированных вариантов поведения к общему числу вариантов.

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

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

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

Действующие лица

Пользователь, Система регистрации и авторизаци

Цель

Пользователь: зарегистрироваться в системе и начать работать

Система: внести пользователя в базу данных и идентифицировать его права доступа

Предусловие

Пользователь не имеет учетной записи в системе

Успешный сценарий:

1. Пользователь запускает систему в первый раз. Система открывает сессию пользователя и предлагает зарегистрироваться.

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

3. Система проверяет, есть ли данные пользователя в базе данных.

4. Если данные о пользователе в БД не дублируются, система высылает письмо на указанную электронную почту и просит подтвердить регистрацию через e-mail. При дублировании данных система предлагает вспомнить старую учетную запись.

5. После подтверждения регистрации система создает запись в истории авторизаций (IP-адрес пользователя, логин, дата, рабочая станция) и присваивает права в соответствии с должностью.

6. Система выдает пользователю сообщение по поводу успешной регистрации (ссылка на сообщение).

7. Пользователь заходит в систему, ему доступны разделы, соответствующие его правам.

Результат

Учетная запись пользователя была создана, права соответствуют должности. Информация о пользователе появилась в БД

На этой основе создаются тестовые сценарии.

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

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

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

Сценарии использования

I. Сценарий: начало боя с одним противником

Шаги

1. Встретить одного противника на локации.

2. Начать бой с противником.

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

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

5. Проверить, что противник реагирует на действия игрока.

II. Сценарий: бой с несколькими противниками

Шаги

1. Встретить группу противников на локации.

2. Начать бой с группой противников.

3. Использовать тактические приемы, такие как фокусировка на одном противнике или использование специальных атак.

4. Проверить, что игровая механика управления несколькими противниками работает корректно.

5. Проверить, что ИИ противников работает адекватно при бое в группе.

III. Сценарий: бой с боссом

Шаги

1. Достичь конца уровня, где находится босс-противник.

2. Начать бой с боссом.

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

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

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

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

Диаграмма перехода состояний (State & Transition Diagram)

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

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

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

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

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

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

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

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

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

Таблица перехода состояний

Описание переходов

1. Пользователь может перейти из главного меню на экран выбора уровня, нажав кнопку «Играть».

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

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

4. Из меню паузы пользователь может выбрать продолжение игры или выход в главное меню.

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

Проверка перехода с главного меню на экран выбора уровня.

1. Нажать кнопку «Играть» в главном меню.

• Проверить, что появляется экран выбора уровня.

• Проверка перехода от экрана выбора уровня к началу игрового уровня.

2. Выбрать уровень и нажать кнопку «Старт».

• Проверить, что игровой уровень начинается.

• Проверка перехода в меню паузы во время игры.

3. Начать игровой уровень.

• Нажать кнопку «Пауза» во время игры.

• Проверить, что появляется меню паузы

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

• Нажать кнопку «Продолжить» или «Выйти в главное меню» в меню паузы.

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

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

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

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

• процесс тестирования предполагает множество однотипных действий;

• мы стремимся разработать тесты, которые помогут найти наиболее серьезные ошибки;

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

• мы хотим избежать лишних трат времени и денег (то есть всегда!).

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

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

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

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

3. Мониторинг и контроль прогресса выполнения работ. При выполнении тестирования мы можем ясно видеть прогресс и проблемы, возникающие при реализации проекта.

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

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

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

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

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

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

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

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

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

1. Что за продукт ты собираешься тестировать? К какому жанру он принадлежит? Это позволит тебе определиться с главными областями функциональных и нефункциональных проверок.

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

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

4. Как продукт может работать неверно в проверяемых областях? Это поможет создать наборы негативных тест-кейсов.

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

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

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