Тест-кейс (он же контрольный пример в ГОСТе, он же тестовый случай и т. д.) – это алгоритм действий для получения ожидаемого результата, включающий начальные условия и входные данные для проверки.
Проектирование тест-кейсов – это процесс создания набора шагов, необходимых для проведения тестирования конкретного функционального элемента игрового продукта. При проектировании тест-кейсов нужно убедиться, что они охватывают все возможные сценарии использования продукта, а также что они являются достаточно гибкими для тестирования вариантов использования, которые могут возникнуть в будущем.
Во время этапа проектирования условия тестирования преобразуются в тест-кейсы и наборы тест-кейсов (тест-суитов). Таким образом, анализ и планирование отвечают на вопрос «Что тестировать?», а проектирование – «Как тестировать?».
Проектирование базово включает в себя:
• проектирование и приоритизацию тест-кейсов и наборов тест-кейсов;
• проектирование тестового окружения и определение необходимой инфраструктуры и инструментов.
3.2.1. Чек-листы
На этапе проектирования и в последующем тестировании в качестве самостоятельного инструмента могут быть использованы чек-листы.
Чек-лист в тестировании – это список задач или критериев, которые должны быть выполнены в процессе тестирования продукта. Он может включать в себя различные элементы, такие как функциональные требования, тест-кейсы, тестовые данные, ожидаемые результаты и т. д.
Чек-листы используются для упрощения и структурирования процесса тестирования, а также для того, чтобы ни один аспект тестирования не был пропущен. Они могут быть разработаны для различных типов тестирования: функциональное, регрессионное, тестирование совместимости, тестирование безопасности и т. д.
Чек-листы могут быть разработаны как вручную, так и автоматически. Вручную разработанные чек-листы могут быть более гибкими и адаптивными, в то время как автоматические обычно используются для проверки конкретных аспектов продукта, таких как удобство использования, безопасность или производительность.
Чек-листы – важный инструмент для тестировщиков, который помогает им более эффективно проверять продукт на соответствие требованиям и выявлять ошибки и недочеты, что улучшает качество продукта.
Чек-лист может включать в себя широкий диапазон пунктов для проверки: функциональность, производительность, безопасность, пользовательский интерфейс и т. д. В процессе тестирования тестировщик использует чек-лист для проверки каждого пункта, отмечая, был ли он выполнен успешно или нет.
Преимущества использования чек-листов при тестированиимогут быть следующими.
Объективность. Используя чек-лист, тестировщик имеет точные критерии для оценки продукта. Это уменьшает вероятность субъективного восприятия и позволяет проводить более объективные оценки.
Систематизация. Использование чек-листа обеспечивает структурирование процесса тестирования и упорядочивает проверку каждого пункта.
Улучшение качества продукта. Чек-листы позволяют заметить мелкие ошибки, которые могут быть упущены при ручном тестировании. Это улучшает качество продукта.
При разработке тест-кейсов чек-листы могут использоваться для определения того, какие функции и возможности продукта должны быть протестированы в рамках конкретного тест-кейса.
Однако следует помнить, что чек-листы не могут заменить профессионального тестировщика и полноценное тестирование продукта. Они могут использоваться лишь как вспомогательный инструмент для улучшения процесса тестирования.
Кроме того, большой минус чек-листов – их тенденция разрастаться и из удобного инструмента превращаться в огромного монстра, который становится неудобно актуализировать.
3.2.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], особенно если без скриншота непонятно, как этот тест-кейс проходить.
5. Подробно прописывай шаги и ожидаемый результат после выполняемых действий.
6. Тест-кейсы должны быть простыми для понимания, см. п. 3. Тест-кейс, написанный тобой, может выполнять новый сотрудник на проекте, поэтому тест-кейсы должны быть легко читаемыми и понятными для любого тестировщика.
7. Выработай привычку пересмотра своих тест-кейсов кем-то из твоих коллег или начальников. Пусть их посмотрит лид, руководитель отдела тестирования или разработчик. Это поможет добиться понятности и лаконичности, а тебе станет понятно, что другие специалисты ждут от подобных документов.
8. Пиши тест-кейсы так, чтобы их можно было использовать повторно в другом проекте. Ты сэкономишь кучу времени, если будешь использовать готовые кейсы, например для проверки движения персонажа в FPS, вместо того, чтобы каждый раз писать их с нуля.
3.2.3. Тест-дизайн
При проектировании тест-кейсов необходимо подумать о возможности и необходимости применения техник тест-дизайна – методик оптимизации ресурсов при проведении тестовых активностей. Своевременное и уместное применение техник тест-дизайна помогает серьезно сократить трудозатраты и время на само тестирование.
То есть тест-дизайн – это процесс, который позволяет создать оптимальное тестовое покрытие объекта при минимально возможных трудозатратах, используя определенные техники. Давай разберем некоторые из них.
Предугадывание ошибок (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 (ближайшее вне класса).
Как видно из примера выше, некоторые значения совпадают, а значит, не стоит проводить одни и те же тесты. Проверяем:
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. Проверка перехода из меню паузы обратно в игровой процесс или в главное меню.
• Нажать кнопку «Продолжить» или «Выйти в главное меню» в меню паузы.
• Проверить, что игровой процесс возобновляется или игра возвращается в главное меню.
Ожидаемый результат
После применения таблицы перехода состояний и выполнения тестовых случаев все переходы между экранами меню в игре происходят корректно.
Всегда ли необходимо применять техники тест-дизайна? Кто-то из тестировщиков скажет, что нет. Но они точно необходимы, когда:
• процесс тестирования предполагает множество однотипных действий;
• мы стремимся разработать тесты, которые помогут найти наиболее серьезные ошибки;
• мы хотим минимизировать количество необходимых тестов для проверки продукта при сохранении оптимального тестового покрытия;
• мы хотим избежать лишних трат времени и денег (то есть всегда!).
3.2.4. Наборы тест-кейсов (тест-суиты)
После того как возможные тест-кейсы созданы, следующий шаг – объединить их в наборы на основе некоторой логики для проведения тестирования в оптимальном режиме. Объединение тест-кейсов в логические наборы называют тест-суитами (или наборами тест-кейсов). Это комплекты тест-кейсов для исследуемого компонента или системы, в котором обычно постусловие одного теста используется в качестве предусловия для последующего.
Организация тест-кейсов в наборы используется в следующих случаях.
1. Структурирование проверок. Последовательность выполнения тест-кейсов помогает нам проверить, например, работу приложения от его запуска до закрытия, покрывая тестами работу всего ключевого функционала.
2. Проведение одновременных проверок. Мы можем организовать параллельную проверку различных модулей игры или ее функционала разными командами или тестировщиками. Например, один тестировщик тестирует всех персонажей, другой – все оружие, третий – пользовательский интерфейс и т. д. Так мы экономим время команды тестирования и оптимизируем работу.
3. Мониторинг и контроль прогресса выполнения работ. При выполнении тестирования мы можем ясно видеть прогресс и проблемы, возникающие при реализации проекта.
4. Подключение к проекту новых сотрудников. Провести тестирование по готовому набору тест-кейсов может любой сотрудник, не знакомый с продуктом и его функциональностью.
5. Сохранение информации для дальнейшего использования. Спустя некоторое время на аналогичном проекте мы сможем использовать готовые тестовые наборы или слегка модифицировать их, что также экономит много времени.
Тест-суиты могут быть составлены по-разному: по типу проверок, по приоритету и т. д. Мы можем объединять тест-кейсы для проведения регрессионного тестирования или проверки основных пользовательских сценариев, а можем иметь разные тестовые наборы для разных этапов проверки. Можем по результатам проверок оценить, в каком из модулей у нас наибольшее количество проблем и чему стоит уделить больше времени на этапе регрессионного тестирования.
Еще один способ комбинирования тест-кейсов – сценарий тестирования. Это последовательные тесты, при прохождении которых можно проверить внушительный набор функций. Сценарий тестирования может (и в идеале должен) ссылаться на остальные тест-кейсы, написанные для всех функций через поле Reference. Сценарий тестирования не получится сделать, просто накидав тест-кейсов из разных категорий: почти нереально подобрать из готовых тест-кейсов последовательность так, чтобы результат прохождения одного тест-кейса становился условиями (preconditions) для прохождения следующего.
Проектирование сценариев тестирования и их объединение в тестовые наборы может происходить разными способами, но тестировщики традиционно используют для этого специализированное ПО.
3.2.5. Как проектировать эффективные проверки
В основе проектирования проверки качества игрового продукта всегда лежит понимание того, что качество – ценность для конечного пользователя. И эта ценность определяется только стоимостью игры, которая может быть довольно высокой. Человек, запустивший игру, имеет полное право ожидать получение удовольствия от процесса, которое зависит в том числе от стабильной работы продукта.
В связи с этим, проектируя проверку качества игры, тестировщик должен держать в голове мысль о том, что соответствие спецификации и требованиям безусловно важно. Но также важно, насколько то, что игрок видит на экране, соответствует его ожиданиям.
Игры любого жанра, как и любое другое ПО, обладают ключевым, дополнительным и второстепенным функционалом. Понимая, что у тебя не будет времени для супертщательной и многократной проверки всех функциональных и нефункциональных областей конкретной игры, ты должен сфокусировать усилия на тех областях, которые критически важны для всех игроков.
Для этого, приступая к проектированию проверки, ты должен задать себе следующие вопросы.
1. Что за продукт ты собираешься тестировать? К какому жанру он принадлежит? Это позволит тебе определиться с главными областями функциональных и нефункциональных проверок.
2. Какая у него целевая аудитория? Что эти люди ожидают от игры? Это позволит понять, что ждут от продукта разные игроки в соответствии со своим игровым опытом.
3. Как собираются в него играть разные типы игроков? Это позволит сразу придумать некоторое количество характерных сценариев использования с набором тест-кейсов для каждого из них.
4. Как продукт может работать неверно в проверяемых областях? Это поможет создать наборы негативных тест-кейсов.
Ответы на эти вопросы помогут тебе спроектировать проверку и создать такие тест-кейсы, чтобы найти максимум важных ошибок за отведенное время.
Теорий, описывающих психотипы игроков, немало, и они продолжают развиваться в настоящее время. Например, Барт Стюарт выделял следующие психотипы.
С учетом этого тебе может быть легче понять, что конкретно будут ценить в игре разные люди.