Осознанная автоматизация тестирования в геймдеве

🛠 🤖 🛠

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

Для начала стоит кратко обозначить, о чем пойдет речь:

Начнем по порядку с тем попроще и плавно будем спускаться в «подвал» к нашим велосипедам.

War Robots — флагман Pixonic, которому уже почти девять лет. А это значит, что в нем бездонная яма мета-механик (речь идет о различных механиках менеджмента роботов и их обвесах, разных социальных фичей вроде кланов и лиг и всего такого прочего) и интерфейсов. Плюс, все это полируется сверху весьма глубоким core-геймплеем (то есть всем, что происходит в бою: стрельба, передвижение, захваты маяков, уникальные способности роботов и прочее) с приличным количеством механик. И еще сверху разнообразный контент (роботы, пилоты, пушки, модули и много-много другого), который постоянно добавляется в игру. Все это генерирует очень много работы для QA отдела — лет на сто вперед. И глядя на это, можно придти к мысли, что автоматизация тестирования здесь не просто нужна, а необходима.

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

И еще немного о вещах, справедливых в большей степени только для геймдева:

Если подвести промежуточный итог, то проект в модели GaaS (Game as a Service) — наш идеальный кандидат. Это означает, что проект будет поддерживать и развивать долгое время, и заводить в него автотесты — хорошая идея.

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

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

И еще немного мыслей и советов, набитых на личном опыте:

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

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

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

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

Что касается утечек памяти, то там сценарий достаточно простой. Запускаем игровую сцену — например, ангар. Из этого ангара переходим в бой — это уже другая сцена. Проверяем, остались ли у нас какие-то атласы, материалы или еще что-то, не уничтоженное после этого перехода. Остались? Значит, мы течем по памяти. Берем список того, что не уничтожается, идем в клиент, говорим «А-та-та».

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

Да, были такие проблемы, что проседало время загрузки, мы начали это трекать и смотреть. На графике — сумасшедшие времена, потому что девайсы попроще, и мы в какой-то момент прикрутили delivery-систему (закачка бандлов на старте), которая растянула время холодной загрузки на время скачивания бандлов с ресурсами.

Также мы трекаем время переходов между экранами. В чем суть? Например, в рамках приложения, когда ты переходишь, условно говоря, из экрана, в котором ты создаешь клан, в экран Лиг, происходит загрузка. И иногда эти загрузки могут «подтекать», так что мы решили все эти вещи замерять.

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

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

В чем суть? Пишем видео, где воспроизводим какой-то эффект. Качеством этого видео мы можем управлять: можно записать максимально возможное доступное качество, либо супершакальное — что захочется. Список контента прогоняем, а на выходе получаем пачку роликов. QA-специалист пришел, отсмотрел, завел баги — разработчик починил, билд пересобрал. Цикл повторился, если есть на то необходимость.

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

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

А теперь наконец-то давайте посмотрим код.

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

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

Что мы делаем, чтобы так было? Пару простых банальностей. Для людей, которые читали чистый код — это прописные истины.

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

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

Это же касается и движка, в нашем случае — Unity. Мы в него всё равно стучимся, да и в клиент тоже стучимся — соответственно, такие вещи тоже прописываем. Конкретно в данном случае это хелпер, который может пройтись по иерархии отрисованных на сцене объектов и вытащить нужный нам объект по имени, спрятанный в иерархии, для взаимодействия с ним. А мы потом вольны с ним сделать все, что угодно: кликнуть по нему, вытащить из него текст, посмотреть заполнение, если это слайдер, к примеру.

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

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

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

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

А теперь поговорим про эффективность тестов и то, как мы выжимаем из них максимум.

Первый инструмент, который мы прикрутили для этого дела, — это так называемые списки блокирующих объектов. Это коллекция из объектов сцены, которую мы передаем в клиент при каждой команде, с которой мы обращаемся в рамках теста к клиенту. Например, всякие экраны переходов, при которых надо немного подождать. И в рамках теста, при появлении такого объекта на сцене, срабатывает следующая логика: «Ага, здесь появился вот этот fade-in экран с загрузкой, мне надо пару секунд подождать». Или это какие-то кликабельные вещи вроде поп-апов.

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

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

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

Следующий инструмент — кастомные перезапуски тестов.

В чем суть: это небольшая надстройка над стандартным атрибутом [Retry()] из NUnit’а. В нашем случае она позволяет в рамках идущего прогона тестов перезапустить конкретный падающий тест столько раз, сколько мы указали в настройках, либо пока он не пройдет.

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

Резюмируя, CustomRetry помогает нам в следующем :

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

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

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

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

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

А теперь наглядно: есть тест, проверяющий специальное умение робота, находящегося в самом конце списка роботов в магазине (а у нас их, на минуточку, больше 60). Если запустить этот сценарий с полноценной покупкой через интерфейс магазина, то на это уйдет примерно 5 минут 21 секунда; он просто идет в магазин и покупает робота в конце списка, при этом листая до него. А если же покупка робота будет совершена через API, то экономия по времени будет почти двукратная: 2 минуты 52 секунды

Таким образом, обращение из тестов по API к игровому серверу позволяет «мгновенно» выполнять ряд типовых предусловий и настраивать игровую среду для тестов:

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

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

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

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

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

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

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

Собираем во время прохождения сценария вообще все, что можем себе позволить:

Все это собранное добро мы формируем в приятный и информативный Allure-отчет, уже ставший классическим решением для отчетности автотестов. Получаются следующие преимущества:

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

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

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

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

#опыт #warrobots #pixonic #лонг #блогикомпаний