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

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

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

4.3.1. Тестирование пользовательского интерфейса

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

• Интерфейс пользователя (GUI)

• Head-Up Display (HUD, проекционный дисплей), который может включать следующее.

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

· Мини-карта для лучшей ориентации игрока на уровне.

· Текстурные наложения: указатель прицела, пиктограммы оружия, радар и т. д.

· Компас или направление к цели.

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

• Индикатор урона (Damage indicator), который показывает направление и силу получения урона персонажем.

• Агония (Pain Effect) – это дополнение к индикатору здоровья. Проявляется покраснением экрана, дрожанием экрана и другими эффектами, в том числе звуковыми для индикации того, что персонаж находится в критическом состоянии и ему срочно требуется пополнить здоровье.

• Подсказка (Hint) – это элемент графического интерфейса. Используется как дополнительное средство для предоставления информации пользователю во время обучения. Могут быть двух видов.

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

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

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

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

• GUI правильно масштабируется при разном разрешении экрана.

• Текст не содержит ошибок и отформатирован.

• Текст читаем на фоне.

• Дизайн унифицирован (цвет, шрифт, размер элементов).

• В интерфейсе отсутствуют пустые участки.

• Элементы интерфейса не накладываются друг на друга.

• При выделении и/или наведении курсора на элементы (кнопки, надписи, поля и т. д.) они меняют внешний вид.

• Элементы анимированы, и анимация не «притормаживает».

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

• Дублированные формы имеют одинаковые названия.

• Если элемент недоступен или отключен (disabled), есть пояснение, почему.

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

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

• Работают все «горячие» клавиши и ярлыки.

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

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

• Текстовое поле (Text field)

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

· Работает выделение текста с помощью Ctrl+A / Shift+стрелка.

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

· Невозможно использовать пустое поле или меньше символов, чем указано.

· Отсекаются пробелы в начале, конце (а иногда и в середине).

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

· При ошибке валидации поле выделяется и выводится текст, поясняющий ошибку.

· При вводе пароля в соответствующее поле вводимые символы меняются на звездочки (*).

• Радиокнопка/Переключатель (Radio button)

· Расположен рядом с соответствующим текстом.

· Одновременно может быть выбран только один элемент.

• Флажок (Check box)

· Расположен рядом с соответствующим текстом.

· Одновременно может быть выбрано несколько элементов.

· При большом количестве элементов может быть специальный элемент для отметки/снятия выделения всех.

• Кнопка (Button)

· Имеет состояния: наведение курсора, нажатие, недоступна.

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

• Выпадающий список (Drop-down list)

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

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

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

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

· При наборе букв на клавиатуре подбираются подходящие значения.

• Подсказка (Tooltip)

· Не должна выходить за рамки экрана.

· Не нуждается в прокрутке.

· Может быть пропущена или обязательна к просмотру.

• Прокрутка (Scroll)

· Не появляется, если содержимое не выходит за рамки экрана.

· Работает при перетаскивании ползунка мышью, прокручиванием колеса мыши, клавишами стрелок «Вверх» и «Вниз» или отклонением стика на геймпаде.

· Крайнее верхнее и крайнее нижнее положения должны быть достижимы.

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

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

4.3.2. Тестирование совместимости

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

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

1. Тестирование совместимости с аппаратной частью (hardware)

2. Тестирование совместимости с OС и сторонним ПО

3. Тестирование совместимости с программно-аппаратным комплексом

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

1. Тестирование приложения на разных разрешениях экрана

2. Тестирование приложения с различными подключаемыми устройствами (наушники, карта памяти, контроллеры и т. д.)

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

4. Тестирование приложения на разных конфигурациях (оперативная память + процессор)

5. Тестирование управления приложением посредством свойств экрана (тач, свайп, мультитач)

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

Для игровых консолей проверка совместимости проводится с различными видами контроллеров. Кроме того, могут проводиться проверки совместимости игр с приставками предыдущих и последующих поколений, а также разными версиями устройств внутри одного поколения (например, PlayStation 4 и PlayStation Pro).

Другое направление тестирования – тестирование совместимости с OС и другим ПО. Среди такого ПО можно назвать:

• антивирусы;

• мессенджеры;

• программы для снятия скриншотов;

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

Иногда при появлении уведомлений из некоторых популярных мессенджеров игровое приложение сворачивается в трей[33] или «зависает». Другими примерами дефектов могут быть:

• возникновение отказов (см. ниже) при использовании некоторых видеокарт (например, относящимся к минимальным требованиям или, наоборот, только появившимся на рынке);

• несовместимость контроллеров некоторых производителей;

• несовместимость игры с конкретной OС;

• нарушенный режим воспроизведения звуков в разных устройствах;

• нарушенный режим воспроизведения графического контента из-за несовместимости с драйверами устройств.

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

4.3.3. Тестирование производительности

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

Зависание, фриз (Freeze)

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

Заедание, статтер (Stutter)

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

Чтобы лучше понять проблему «заедания» в играх, нужно немного углубиться в историю развития геймдева. Раньше разработчики создавали игры, учитывая частоту кадров, с которой работал дисплей. Скорость передвижения объектов измерялась не в пикселях в секунду, а в пикселях «в кадр»: например, скорость персонажа в Sonic The Hedgehog для Sega была 16 пикселей на один кадр.

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

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

Если разработчик не знает (а он не знает), с какой частотой кадров работает игровая платформа, ему потребуется измерить текущую частоту кадров и адаптировать скорость анимации под нее, чтобы на экране игровой объект передвигался плавно с одной видимой скоростью. Например, если один кадр занимает 1/60 секунды (при 60 FPS), или 16,67 миллисекунды, а скорость объекта на экране 10 метров в секунду, то в каждом кадре расстояние, на которое он перемещается, будет равно 1/6 метра. Но если FPS «упадет» в два раза (до 30 кадров в секунду), то объект должен будет перемещаться уже на 1/3 метра в каждом кадре, то есть в два раза быстрее, чтобы пользователь наблюдал одну и ту же скорость объекта.

Скорость рендеринга кадров совпадает с частотой монитора, поэтому объект двигается плавно и с постоянной скоростью

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

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

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

Рендеринг кадра 3 у ГП занимает слишком много времени, поэтому кадр 2 повторяется в третий раз

Частота кадров, фреймрейт (Frame Rate)

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

На показатель частоты кадров непосредственное влияние оказывают:

• быстродействие оперативной памяти;

• монитор с высоким коэффициентом обновления кадров;

• графический адаптер (видеокарта), мощность которого обеспечивает скорость вычислительных процессов при рендере сцен;

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

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

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

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

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

• отсутствие текстур на поверхностях объектов на сцене;

• разрывы экрана;

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

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

• невозможность запустить игру на платформе с минимальными требованиями.

4.3.4. Тестирование стабильности

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

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

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

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

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

Длительная работа приложения

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

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

Пример. Ежеминутно в оперативную память записывается блок размером 4 Мб. Чтобы заполнить, например, объем 4 Гб, понадобится чуть больше 1000 минут. Нельзя забывать, что ОС и другие фоновые приложения также потребляют память. И давай представим, что этот объем будет равен 1,5 Гб. Игровое приложение тоже потребляет память: те же 1,5 Гб. Получается, что свободным остается 1 Гб, который будет заполнен за 256 минут, то есть чуть больше 4 часов. А это уже реальное время, которое может быть потрачено пользователем на игру.

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

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

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

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

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

Пиковые нагрузки

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

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

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

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

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

Отказ, падение, краш (Crash)

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

• Попытки чтения или записи памяти, которая не предназначена для чтения или записи этим приложением.

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

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

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

Реакция на отказ (краш)

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

Чтобы ответить на эти вопросы, мы должны искусственно вызвать зависание или отказ приложения. Мы не будем использовать многочасовой сценарий, при котором приложение будет работать с перегрузкой. Это состояние системы мы будем форсировать, намеренно увеличивая величину пиковой нагрузки или продолжительность такого пика. Например, если в нормальных условиях приложение должно пережить пик в 200 % от расчетной нагрузки длительностью 1 минуту, то здесь пик будет 800 % и 15 минут.

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

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

4.3.5. Нагрузочное тестирование

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

Нагрузочное тестирование может проводиться по-разному:

1. с применением автоматизированного тестирования и дополнительного программного обеспечения;

2. в рамках плейтестов большой группой тестировщиков;

3. в рамках бета-тестирования большой группой пользователей.

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

Ключевыми метриками в игровом тестировании называют:

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

• потребление ресурсов (например, загрузка процессора, памяти, пропускная способность сети, сетевая задержка, доступное место на диске, интенсивность подсистемы ввода-вывода);

• время обработки пакетных операций (например, время ожидания, время обработки, время полного выполнения операций, время ответа базы данных);

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

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

Методы, используемые при анализе, могут включать:

• сравнение результатов с заявленными требованиями;

• определение тенденций в результатах;

• выявление ошибок;

• сравнение ожидаемого и полученного результатов;

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

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

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

4.3.6. Тестирование локализации

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

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

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

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

2. Перерисовка графических файлов: изображения, символика, текстуры.

3. Подбор актеров, дублирование и запись звуковых файлов.

4. Поддержка технических требований.

5. Поддержка правовых требований региона.

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

В Steam указывается, какие локализации поддерживает игра

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

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

Перевод текстов

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

Цель проводимого тестирования перевода – проверка контента игры (включая интерфейса игры, субтитров, реплик персонажей и т. д.) на наличие ошибок перевода.

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

• Ошибки формата чисел, денежных единиц, календаря, дат

• Ошибки, связанные с адресами, телефонами

• Некорректное использование и конвертация единиц измерения или валют

Другими словами, сообщение в игре «Вы движетесь со скоростью 62 мили в час» может вызвать непонимание у игрока из России, а сообщение «Вы движетесь со скоростью 100 километров в час» приведет в ступор игрока из США. В таких случаях необходимо изменять не только цифру, но и формулу расчета в зависимости от локализации.

• Отображение числовой информации

• Ошибки перевода имен собственных

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

То же касается:

• названий исторических событий;

• праздников;

• реалий;

• пословиц и поговорок;

• топонимов (географических названий);

• просторечной и ненормативной лексики;

• аббревиатур.

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

• торговая марка;

• логотип;

• сокращение;

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

• Искажение или игнорирование особых символов (например, неправильное отображение диакритических знаков во французском, иврите, арабском)

• Несоответствие перевода ситуации

Ситуация, когда перевод выглядит смешно или чужеродно, обычно возникает из-за того, что переводчикам приходится работать, не понимая контекста, в котором произносится та или иная фраза. Отсюда и возникают легендарное «Потрачено!»[35] как перевод «Wasted» и масса других, которые неизбежно становятся мемами.

• Использование фраз или слов, которые могут восприниматься как оскорбление

Иногда даже не сами слова, а их употребление в неуместном контексте может спровоцировать большой скандал. В файтинге Kakuto Chojin разработчики назвали одного из героев Асад. Он проводит бои на ринге, оформленном в арабском стиле, а в музыкальный трек вставлено пение муллы, в котором явно слышна фраза «Allah Akbar». При попытке выйти на ближневосточный рынок локализаторы решили, что эта фраза привлечет игроков. Эффект оказался прямо противоположным: исламское общество посчитало оскорблением использование священной фразы в такой ситуации. Во всех исламских странах игра была запрещена.

А игра Devotion была запрещена в Китае после того, как проверяющие увидели в ней оскорбительные послания в адрес Председателя Компартии КНР. На одной из карт были размещены иероглифы с именем Си Цзиньпина и с Винни-Пухом, с которым его ассоциируют.

Перерисовка графических файлов: изображения, символика, текстуры

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

Подбор актеров, дублирование и запись звуковых файлов

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

• Неестественно звучащая речь

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

• Неподходящие голоса актеров озвучки

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

• Национальные и индивидуальные особенности речи персонажей

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

Поддержка технических требований локализации

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

• Искаженные символы (Mojibake, Garbage characters)

Речь идет о появлении искаженного текста в результате выбора неправильной кодировки символов. Он выглядит как набор символов из другой системы письма, как правило, совершенно нечитаемые. Например, фраза «База захвачена!» с исходной кодировкой Windows-1251 при декодировании в ISO 8859-1 будет выглядеть как «Áàçà çàõâà÷åíà!»

• Локализованный текст не помещается в отведенные границы (обрезается, появляется скроллинг)

Нередко перевод слова с английского языка требует большее количество символов из-за того, что слова в английском существенно короче, чем во многих других языках. Например, английское «Reload now» содержит в себе 10 символов, а на русском соответствующий этому «Перезагрузите сейчас» – 20 символов, в два раза больше. И если на кнопке нет достаточно места для 20 символов, то строка не может уместиться целиком.

• Смещение/искажение текста и элементов интерфейса

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

• Перекрытие/наложение

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

• Неверный шрифт/размер

В разных регионах используются разные шрифты и размеры по умолчанию. Например, в азиатских странах обычно используют шрифт размера 9 по умолчанию, а в США – шрифт размера 8.

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

• Неправильное направление текста

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

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

• Неправильные «горячие» клавиши

Проблемы с «горячими» клавишами могут быть следующими:

· потерянная «горячая» клавиша (при локализации забыли назначить «горячую» клавишу, и в локализованной игре отсутствует возможность использовать этот функционал);

· дубликат «горячей» клавиши (используются две «горячих» клавиши для выполнения одного и того же действия);

· «горячая» клавиша не работает.

• Переменные в тексте и их особенности

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

Одна из наиболее распространенных ошибок разработчиков – делить на части предложения, содержащие переменные. Например, используется переменная для генерации боевых сообщений вида «You take X hit points». Если поместить части предложения («You take» и «X hit points») в разных местах кода, не предупредив об их взаимосвязанности, после перевода можно легко получить следующий текст: «Вы берете 2 единицы урона» вместо «Вы получаете 2 единицы урона».

Существует понятие «грамматический строй целевого языка», и это едва ли не главный краеугольный камень локализации. Зачастую при добавлении переменных разработчики не учитывают, что в ряде языков их значение может менять построение фразы. Речь идет не только об окончаниях в русском языке (1 единица, 3 единицы, 10 единиц), но и, скажем, об артиклях в немецком.

Когда переменных несколько, иногда нельзя поменять их местами (хотя обычно это признак не очень хорошо написанного продукта). Но переводчикам эта возможность нужна, поскольку в разных языках различные правила построения предложений: если в оригинале сначала стоит переменная X, а потом Y, то в иностранном порядок может быть иной – Y и затем X. Рассмотрим пример с теми же боевыми сообщениями: «You take 10 hit points, 3 points blocked». Красивый перевод будет иметь вид «Вы заблокировали 3 единицы урона, получив 10 единиц». Но если возможности менять переменные местами нет, то смысл фразы меняется в корне.

• Рассинхронизация звукового ряда оригинала и перевода

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

Обратный случай: в русской локализации The Witcher 3: The Wild Hunt длина фраз в диалогах зачастую сильно отличается от оригинала. Компенсируется такая разница технически: реплики персонажей ускоряются или замедляются.

• Несовпадение звучащей речи и субтитров

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

• Отсутствие/порча файлов перевода в папках назначения

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

Поддержка требований производителей аппаратной части

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

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

Поддержка правовых требований региона

Во время тестирования локализации необходимо учитывать правовые требования, касающиеся возраста игроков, различных стран и регионов. Например, в России совершеннолетие наступает в 18 лет, в США в зависимости от штата этот возраст варьируется от 18 до 21 года, а в Японии молодые люди считаются совершеннолетними с 20 лет. И это важно учитывать.

Таблица возрастных ограничений в зависимости от контента игры

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

1. ACB (Австралия): M

2. РСВР (Россия): 18+

3. PEGI: 12+

4. ESRB: T – для подростков

5. USK (Германия): 6+

В России игре присвоен самый суровый рейтинг. По всей видимости, причина столь жесткого суждения в том, что цензоры увидели в ней нарушение следующего пункта закона о защите детей: «К информации, запрещенной для распространения среди детей, относится информация, отрицающая семейные ценности, пропагандирующая нетрадиционные сексуальные отношения и формирующая неуважение к родителям и/или другим членам семьи»[36].

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

• Изображение крови (неважно какого цвета)

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

• Изображение женоподобных мужчин

• Порнографические сцены

• Название игры совпадает с названием ранее изданной игры

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

• Азартные игры

• Предрассудки и предсказания будущего

• Ограничения на ежедневное использование «коробок добычи» (loot-box, лутбоксы) и др.

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

К другим ограничениям законодательного порядка можно отнести следующие.

• Изображение нацистской символики и пропаганду нацизма

• Изображение символики различных международных организаций (например, Красный Крест)

• Расовая дискриминация

• Неуважение к религии

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

• Реклама запрещенных напитков и продуктов (например, энергетиков)

• Порнография

• Информация об изготовлении оружия, взрывчатых веществ

• Информация о различных способах суицида

• Информация, содержащую описание или изображение сексуального насилия

• Лимит времени для нахождения в игре несовершеннолетних

• Лимит суммы денег на покупку внутриигрового контента

• Наличие системы родительского контроля и т. д.

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

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

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

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

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

Известно настороженное отношение некоторых народов к цифре 13 как символу неудачи. А в Китае и Южной Корее такая участь постигла цифру 4, произношение которой созвучно со словом «смерть». В Японии люди стараются избегать цифры 9, которая произносится так же как «страдание». Для христиан число 666 традиционно ассоциируется с Антихристом и злом в целом. Одним словом, иррациональный страх перед некоторыми цифрами есть у многих народов, и это необходимо учитывать при локализации игры для конкретного рынка и ее последующего тестирования.

Все народы относятся с уважением к собственной истории. Часто некоторые исторические события, особенно военные конфликты, могут интерпретироваться разными народами по-разному. Известна история с неудачной попыткой Age of Empires выйти на южнокорейский рынок с эпизодом, когда японское вторжение в Корею закончилось захватом страны практически без сопротивления. Несмотря на достоверность этих событий, корейцы считают этот исторический эпизод постыдным, и игра была допущена на рынок только после того, как разработчики переделали эту часть, добавив героическое сопротивление корейцев. В России вызовут возмущение игры, основанные на событиях Второй мировой войны, где Берлин захватывают американцы, которые также «героически» приписывают себе и освобождение концлагеря Освенцим.

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

1. Юмор

2. Религия, включая оккультизм

3. Отношение к инвалидам, сексуальным меньшинствам, животным, детям и т. д.

4. Сексуальные отношения

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

6. Терроризм

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

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

4.4. Прочие виды функционального/нефункционального тестирования

Предыдущая Стр. 14 из 26 Следующая