на каком языке написан вот блиц
Движок игры
На каком языке в основном написан Клиент?
На каком языке в основном написан Сервер?
Какие программы вы используете на сервере игры?
Какие языки вы использовали при написании Сервера/Клиента?
Интересно что вы ответите
Do you know the way
Победителям Великой Отечественной:
Спасибо Вам за тишину, за наше небо голубое.
За то, что в страшную войну,
Сумели Мир Прикрыть Собою.
Xiaomi Mi Max 6.44″ . G o o g l e Android 6, Miui 8.
«На старте проекта было всего 10 программистов и 5 художников»: разработчики рассказали о создании World of Tanks Blitz
Этим летом мобильной онлайн-игре World of Tanks Blitz исполнилось 6 лет. Сотрудники Wargaming рассказали УНИАН о том с каким трудностями пришлось столкнуться в процессе разработки игры и своих планах по развитию проекта. О создании одной из самых популярных мобильных игр в Украине читайте в нашем свежем материале.
В честь шестилетия игры УНИАН разыграл среди читателей 5 кодов на 6 месяцев премиум-аккаунта в World of Tanks Blitz. Совместно с разработчиками мы выбрали победителей. Их имена можно узнать в конце статьи.
Сейчас большими многопользовательскими играми на смартфонах никого не удивишь. Помимо World of Tanks Blitz есть Fortnite, Call of Duty Mobile, PUBG Mobile и много других популярных проектов.
Однако всего 6-7 лет назад ситуация была совершенно другой. Сложно было даже представить, что можно будет играть на телефоне в динамичную игру с десятками реальных пользователей в онлайне. Да и делать большую мультиплеерную игру для смартфонов было рискованно. Экраны телефонов были меньше, мобильный интернет хуже, а сами устройства не могли похвастаться хорошей производительностью. Но разработчики World of Tanks поняли, что в их игре есть потенциал для экспансии на другие платформы, и приняли решение зайти на рынок мобильных игр, хоть и не все в компании поддерживали эту идею.
«World of Tanks – это медленный шутер, реакция и координация в нем не так важны, как тактическая составляющая и понимание механики пробития. Такой геймплей хорошо ложится на мобильные устройства – в силу особенностей тач-управления там не так хорошо играются традиционные шутеры с необходимостью быстро и точно целиться. Сказать по правде, не все в компании верили, что довольно сложный тактический шутер может сыскать успех на мобильном рынке, где преобладают казуальные игры. Это было задолго до PUBG и Fortnite», – вспоминает Павел Бусько, Tech Lead World of Tanks Blitz.
Просто так перенести игру с больших платформ на смартфоны было нельзя. Мобильные устройства накладывали слишком много ограничений на разработчиков. А самым сложным в работе над мобильной версией World of Tanks было реализовать удобное управление.
«В процессе разработки мы перепробовали множество типов touch-контролов, а также вариаций механик прицеливания. Много работы пошло на выброс, чтобы в итоге управление стало действительно удобным.
Кроме того, нужно было адаптировать геймплей, чтобы сделать игровые сессии короче. Отсюда уменьшенные локации и меньшее количество танков на арене. Это также позволило сделать итоговую картинку лучше: в мобильных устройствах слабые GPU, и имея очень ограниченный бюджет на количество треугольников в кадре, гораздо лучшего результата можно добиться, распределив этот бюджет на меньшее число объектов.
Технологически между клиентом WoT и WoT Blitz вообще мало общего, только сетевые библиотеки. Движки абсолютно разные – движок WoT Blitz писался параллельно с разработкой самой игры и во многом заточен именно под мобильные устройства», – говорит Павел Бусько.
Работа предстояла огромная. Это сейчас над World of Tanks Blitz трудится около двух сотен человек. А на старте проекта количество сотрудников было куда меньше.
«На старте проекта было около десяти программистов и пять художников, несколько гейм-дизайнеров и QA-специалистов. К моменту релиза команда была гораздо больше, около ста специалистов. Точно вспомнить уже тяжело», – отмечает Павел Бусько.
И хоть работа кипела, сотрудники студии постоянно сталкивались с подводными камнями. К тому же разработчики рисковали – ведь на маленьком экране смартфона ощущения от игры могли быть хуже. Нужно было серьезно переработать интерфейс.
«В бою каждый элемент интерфейса – результат многих и многих итераций. Джойстик, мини-карта, контрол выбора снарядов – все это делалось, плейтестилось, переделывалось, снова плейтестилось, пока мы не понимали, что получилось классно. Даже такая, казалось бы, простая штука, как кнопка стрельбы – ну что может быть проще кнопки? Но на самом деле кнопка работает хитро: если коснуться ее и отпустить палец без смещения, произойдет выстрел, а если коснуться и повести в сторону – произойдет поворот камеры. Это защищает игрока от случайного выстрела в ситуации, когда он, доворачивая камеру при прицеливании, попадает пальцем на область, где находится кнопка», – рассказывает Бусько.
Международный релиз World of Tanks Blitz состоялся 26 июня 2014. Тогда игра вышла только на iOS. В Украине презентация игры прошла в одном из киевских торговых центров, где посетителям давали возможность посидеть в холле на креслах и сыграть на планшетах в мобильную версию World of Tanks.
«Наше решение оказалось верным – игра нашла свою аудиторию сразу после релиза и продолжает расти уже шесть лет», – говорит Павел Бусько.
В декабре того же года World of Tanks Blitz заняла оставшуюся часть мобильного рынка и вышла на Android. За шесть лет Blitz превратился из достаточно рискованного проекта в популярную мобильную игру с огромной аудиторией – более 137 миллионов пользователей. А сама игра поддерживается на 27 тысячах моделей устройств. Более того World of Tanks Blitz является одной из самых популярных мобильных игр в Украине. Ее скачали 7,3 миллиона раз – это третий показатель среди всех стран мира. Кроме того, пользователь, сыгравший самое больше количество боев в Blitz – игрок из Украины. На его счету более 158 тысяч сражений.
«За шесть лет произошло много изменений. Появилось огромное количество контента. Сейчас у нас суммарно 29 уникальных арен (30-я на подходе!) и более 400 танков. Не многие мобильные игры могут похвастаться таким разнообразием. Из самых крупных фичей выделил бы турниры, которые дают игрокам возможность посоревноваться командами и игровые режимы вроде MAD GAMES, где в игру вводятся совершенно новые механики, кардинально меняющие геймплей. Еще за последний год мы переделали большую часть интерфейса в лобби, сделав его красивее, удобнее и современнее. Ну а в обновлении 7.0, приуроченном к дню рождения игры, появилось довольно много графических улучшений, главное из которых – следы попаданий по танкам», – отмечает Павел Бусько.
Команда, работающая над WoT Blitz показала впечатляющие успехи, но останавливаться на этом разработчики не планируют. Ведь у них перед глазами пример ПК-версии World of Tanks, которой в этом году исполняется уже 10 лет.
«На самом деле шесть лет – это и много, и мало одновременно. Старшему брату нашей игры (имею в виду ПК-версию World of Tanks), в этом году стукнет 10. Планов на развитие у нас много – они касаются как геймплея, так и технической составляющей игры (визуал, оптимизация). Ну и конечно мы будем продолжать радовать игроков новыми танками и новыми картами», – резюмирует Павел Бусько, Tech Lead World of Tanks Blitz.
Итоги конкурса:
В начале недели УНИАН запустил конкурс, в котором просил читателей написать о том, что нового они хотели бы увидеть в World of Tanks Blitz. Совместно с разработчиками мы выбрали самые интересные ответы и определили победителей.
Коды на 6 месяцев премиум-аккаунта в World of Tanks Blitz получат:
Победители конкурса получат свои призы в ближайшее время.
Я из Wargaming: что значит быть программистом?
Иван Петроченко, глава отдела разработки движка World of Tanks Blitz
Как начинали?
Делать игры мечтал с детства. По образованию я эколог. До этого была школа с экологическим уклоном.
В индустрии я уже больше десяти лет. Попал в нее относительно легко: разместил резюме, через день позвонили и позвали «разрабатывать под мобилки» в небольшую, известную в узких кругах компанию Incubus. Ничего удивительного — в 2004 году в Минске игроделов можно было по пальцам пересчитать и отечественный геймдев был в зачаточном состоянии. Со временем, конечно, ситуация поменялась.
Вторым местом работы стала TikGames. По меркам того времени это был уже игрок покрупнее и гораздо известнее — в компании успела поработать приличная часть моих нынешних коллег 😉
Затем была Dava Consulting, которая впоследствии вошла в состав «Гейм Стрим». Так в моей жизни появился World of Tanks Blitz.
Мне всегда нравилось делать игры. К этому лежит душа. Писать код для скучных приложений, наверное, не смог бы.
С чем работаете?
Платформа у нас не одна. Это и iOS, и Android, и Windows 10. Недавно добавилась Mac OS. Что касается языка, то это классика геймдева — всеми любимый C++. Это основа основ и 95% всей работы. Конечно, есть и другие скрипты, которые используются для автоматизации (Python и так далее).
Софт — Visual Studio для Windows, Xcode для Mac и iOS. C Android уже сложнее. Капризная платформа диктует свои правила. Используем то, что удобнее всего, однако идеальный софт еще не нашли.
А какое образование нужно?
Я, наверное, в очередной раз повторю то, что все и так знают. Чтобы создавать первоклассные игры, необязательно иметь три диплома и курсы разработчика за плечами. У нас работают как самоучки, превратившие сырой талант в блестящие результаты, так и те, кто целенаправленно планировал идти в индустрию еще на этапе получения образования.
Хороший геймдев-разработчик должен быть экспертом во многих областях. Современные игры даже среднего уровня основываются на большом количестве технологий (если не брать в счет проекты на высокоуровневых движках, например, на Unity). Нужно хорошо владеть теоретической частью (структура данных, алгоритмы), разбираться в трехмерной графике, знать особенности операционных систем (в случае World of Tanks Blitz их много, так как игра кросс-платформенная).
Это как с иностранными языками — чем больше ты языков знаешь, тем легче тебе даются новые. Если ты освоил 10 технологий, вероятнее всего, с 11-й сложностей не будет.
Известны случаи, когда в программирование приходили прямиком из строителей. Да, и такое бывает. Однако отмечу, что лучше начинать до 30 лет. Чем раньше, тем лучше. Слишком много специфики и нюансов, которые надо охватить. На это нужно время.
Что важно?
Если программист умеет быстро разбираться с незнакомыми технологиями, то он хороший специалист. В этой сфере очень высоко ценится способность адаптироваться. Это архиважно. Безусловно, основа (С++) постоянна. Однако нюансы меняются из года в год. Появляются новые стандарты, что хорошо видно на выставках и конференциях, где демонстрируются достижения мировой IT-индустрии.
Как только ты перестал развиваться, ты дрейфуешь где-то на среднем уровне, несмотря на наличие опыта. Консервация — это плохо. Необязательно посещать все специализированные мероприятия и не пропускать ни одной конференции. Это нужно, скорее, чтобы прочувствовать атмосферу и вдохновиться. Своеобразная моральная подпитка. Учиться и углублять знания можно не выходя из дома. Есть интернет с огромным количеством литературы, технических блогов, лекций.
Сейчас на самом деле передовое время. Та теория, которая была разработана 30–40 лет назад, находит отклик в аппаратных возможностях современных технологий. Появилась возможность реализовать то, что было придумано на бумаге.
Английский?
Без английского в программировании никуда. Вся полезная литература, весь «свежак», новейшие материалы выходят, к сожалению, не на русском. Но никто не говорит, что нужен продвинутый уровень владения языком. Достаточно понимать. Мне сложно представить программиста, не знающего хотя бы азов английского. Разве что специалисты по 1С, где нужно писать кириллицей.
Это скучно?
Нет. Программист — это не тот человек, который сидит и тихонько пишет код. Он придумывает. Особенно если мы говорим об игровой индустрии. Другое дело —проект какой-нибудь банковской системы: когда человек приходит на работу, ему дают программу, которую до него писали десять лет, и он продолжает над ней трудиться, минимально меняя код. Это беспощадная рутина. То же самое и с бухгалтерией — здесь по большому счету нечего изобретать.
В геймдеве динамика намного выше. Во-первых, редко когда игра существует в первозданном виде пять или более лет. Те же «Танки» постоянно обновляются.
А как в Беларуси?
Можно выучиться на гейм-дизайнера в университете (БГУИР) или закончить курсы, которых появляется все больше и больше. Однако огромную роль играет самообразование: интернета хватит с лихвой, надо просто захотеть. Когда приходят резюме, я даже не смотрю на пункт «Образование». Диплом есть почти у всех, ценится опыт и собственные проекты. Недавно на собеседование приходил кандидат, недавний выпускник, который написал свой игровой движок. Он показал, как все работает, объяснил механику. Вижу ли я в нем достойного специалиста в будущем? Конечно. Сразу понятно, что человек интересовался этим с детства, получил хорошие знания в интернете и будет развиваться.
Кого берете?
Людей с техническим складом ума, которые умеют решать новые задачи. Человека, который пришел с опытом работы в геймдеве, видно за версту — диалог выстраивается сам собой и идет по накатанной. Новичка в индустрии разговорить уже сложнее.
«Джуниору» к нам попасть сложно. Команда уже сформирована, необходимости в расширении у нас нет. Нужны люди, которые смогут углубить экспертизу.
Бывает, что в резюме написано одно, а при личной встрече оказывается, что это неправда. Преувеличено, присвоено и так далее. Это всегда узнается.
С чего начать?
Тому, кто очень хочет не только в программирование, но в IT в принципе, лучше начинать с техподдержки. А еще лучше — с QA (знаю реальные примеры). Это бывает, когда есть желание и соответствующий склад ума, но не хватает технической подкованности. Два-три года работы в индустрии в поддержке или тестировании обычно устраняют пробелы.
Совет молодым?
Посоветую никогда не забрасывать профессиональное развитие. Инструментов для поддержания хорошей формы хватает. Для ленивых: существуют сайты, где все представлено в легкой и увлекательной форме. Допустим, есть игра, к которой нужно написать искусственный интеллект. Результатом можно очень сильно вдохновиться.
Язык программирования WoT
Сервер написан на С++ (из вакансии)
Клиент на питоне(он ругался по питоньи при запуске в линуксе)
ну и на плюсах, следуя из цитаты.
возможно использовались и другие ЯП при написании клиента и сервера.
Сервер написан на С++ (из вакансии)
Клиент на питоне(он ругался по питоньи при запуске в линуксе)
ну и на плюсах, следуя из цитаты.
возможно использовались и другие ЯП при написании клиента и сервера.
А вот про сервер ничего сказать не могу. Не видел.
Клиент на питоне(он ругался по питоньи при запуске в линуксе)
Мобильные танки и тесты: интервью о тестировании World of Tanks Blitz
У всех есть какое-то представление о франшизе World of Tanks. Но, как правило, оно «снаружи» (пользовательское) и общее. А что, если посмотреть изнутри, и рассмотреть какие-то очень конкретные вопросы? Скажем, на каком языке пишут тесты для мобильной World of Tanks Blitz, и по каким причинам выбрали его?
Студия разработки мобильных «танков» MS-1 компании Wargaming присутствовала на нашей конференции Heisenbug, и там мы позадавали такие вопросы Дмитрию Сычеву — Lead QA Automation в World of Tanks Blitz. А теперь решили для Хабра сделать и текстовую версию этого небольшого разговора.
— Дмитрий, привет! Ты работаешь над проектом World of Tanks Blitz — для начала расскажи, что это.
Дмитрий: Наша студия разработки MS-1 занимается производством мобильных игр. Я работаю над World of Tanks Blitz, в июне этому проекту исполнилось 6 лет. Он представляет собой кроссплатформенный мультиплеерный танковый шутер. Сердцем игры является сервер. Там происходит вся бизнес-логика, расчет очередей, расчет урона и т.д. Клиент игры написан на C++ и использует in-house движок.
— Мобильные игры запускают на куче разных устройств, у них совершенно разные процессоры (в том числе и старые), и так далее. Весь этот зоопарк надо тестировать — как вы это делали и делаете?
Дмитрий: При разработке игры остро встал вопрос о тестах производительности. Нам нужно было точно знать, помещаемся ли мы в ограниченные бюджеты по памяти и можем ли выдать играбельный FPS.
На тот момент вопрос был решен таким образом:
Teamcity (CI)
Основная цель использования TeamCity – формирование очереди тестов, установка и запуск их на соответствующих устройствах, сбор тестовых данных, формирование и рассылка отчётов всем заинтересованным. За очередь отвечает сама CI, а все остальные задачи лежат на скриптах, написанных на Python, и вспомогательном софте, запускаемом этими скриптами.
MongoDB
Тесты, собирающие какие-то метрики, во время выполнения сохраняют данные в базе, на основе которых в последующем формируются отчёты.
Все тесты были написаны на Lua, движок которой работал прямо в игре. Для связи скриптов на Lua с кодом игры использовалась прослойка SWIG. Код тестов интегрировался в сам архив с игрой, и при наличии определённого файла конфигурации в документах запускалось исполнение определённого сценария. По окончании выполнения сценария, либо при возникновении ошибки, приложение закрывалось и инициировался сбор тестовых данных.
У этого подхода были как плюсы, так и минусы. Явным плюсом было то, что Lua — один из самых легковесных и быстрых языков по сравнению с тем же Python или JavaScript. Однако при его использовании выявилось несколько недостатков.
Про один из них я могу рассказать историю. Когда я только пришел работать в команду, на языке Lua еще не работал, как и многие — он далеко не самый популярный. Но я подумал, что это интересный вызов. Одним из моих первых заданий было написать несколько тестов на Lua. Я сделал это, дальше нужно было протестировать их на устройствах, посмотреть, все ли правильно работает. Нашел несколько проблем, и мне надо было их продебажить. Спросил у своих коллег, как мне это сделать, и тут оказалось, что отладка в Lua — больной вопрос. Обычно все обкладывают логами и смотрят, что и где пошло не так.
Кроме этого, язык Lua влияет на потребление памяти. Это приходилось учитывать в результатах автотестов производительности.
А отдельного упоминания заслуживает непосредственно написание кода на Lua. Многое тут зависит от писателя, однако есть ограничение для все: нативно не предоставлена возможность писать классы. Наиболее ярко это проявлялось при написании мультиплеерных тестов — это боль.
Можно подумать, что не все так плохо, но вот, что под капотом.
Поэтому людей, желающих обучаться писать на этом языке, было, мягко говоря, немного.
В итоге мы пришли к тому, что надо что-то менять. Улучшать нашу систему.
Вначале мы пошли по неправильному пути. Сначала мы решили все отрефакторить, вынести фреймворк отдельно, тесты отдельно, ввести объекты (пытаться их писать), но это оказалось тоже не очень удобно. И было принято решение полностью пересмотреть концепцию. Когда мы поставили перед собой такую цель, у нас было поставлено три основных задачи.
Первая — тесты должны писаться быстро, легко и удобно, и они должны быть на языке, который люди хотят изучать.
Вторая — удобное написание мультиплеерных тестов.
Третья — универсальность нашего фреймворка. При разработке игры используется много дополнительных инструментов, которые помогают художникам, артистам, рендеру быстро разрабатывать свои фичи. Эти инструменты тоже развиваются и их тоже надо тестировать. И начал подниматься вопрос, что автоматизировать их тоже было бы неплохо.
Мы ставили перед собой три этих задачи.
И языком был выбран Python: сам фреймворк у нас написан на Python, в целом в проекте Python используется достаточно широко, и те же мануальные тестировщики были с ним уже более-менее знакомы.
В качестве ядра нашего фреймворка сначала мы рассматривали вариант использовать REST API, то есть использовать в качестве сервера наш клиент игры, а в качестве клиента наши тесты. Однако в этом решении был один большой минус. Нам не хватало динамики. Мы хотели получать ивенты с игры, чтобы нам не приходилось на каждый необходимый ивент слать запрос и получать ответы.
Мы нашли другое решение, которое нам понравилось. Мы решили использовать websocket. Это тоже по сути сервер-клиент, сервер поднимается в движке игры при старте клиента, а клиентом являются тесты. И там мы можем как делать запросы, так и подписываться на ивенты, и ждать каких-то ивентов от игры. Мы написали прототип, попробовали, и нам все понравилось. Поэтому мы решили использовать такую схему.
Получился следующий вариант:
Многие могут задать вопрос: а как вообще произвести переход между решениями? У вас есть тесты на Lua, вы хотите их сделать на Python и использовать websocket. А автоматизированное тестирование — это такая штука, которая нужна каждый день, каждую версию. Тесты должны быть непрерывными и постоянными.
Мы нашли следующее решение: написали на первое время обертку, которая вызывала Lua-тест, как питоновский. Со временем, когда тесты переводились на Python, Lua уходил, и на данный момент мы полностью избавились от него. Больше мы его не используем. Сейчас я могу рассказать, какие преимущества мы получили.
— Хорошо. Как я понял, вы сейчас полностью перешли на websocket и полностью перешли с Lua на Python, который у вас де-факто стандарт, в том числе в QA Automation в компании. Какие результаты вы в итоге получили? Если сравнивать старые и новые решения, что стало лучше, а что хуже?
Дмитрий: На данный момент все тесты пишутся на Python. Мы смогли написать достаточно удобный фреймворк, который позволяет человеку с минимальным знанием Python писать тесты. Вот пример того же мультиплеерного теста:
Появилась возможность параметризировать тесты для быстрого изменения запуска (например, при дебаге):
При написании теста есть подсказки, некоторые вещи прописывать не нужно, так как они автоматизированы. Как пример: у нас есть такая сущность как Screen Manager. SM — это класс, который разруливает простейшие переходы между экранами, чтобы эти переходы не приходилось постоянно писать самому. Внутри SM определены зависимости между экранами, те прописано как можно перейти с одного экрана на другой. Когда в тесте мы обращаемся к экрану, который указан в зависимостях, SM определяет, на каком экране сейчас находимся и как можно перейти на экран, к которому мы обратились.
Появилась возможность запускать несколько клиентов игры на одном устройстве и тестировать мультиплеерные тесты быстрее. Также можно эмулировать запуск мобильных устройств на десктопе, что помогает при разработке UI тестов, зависящих от разрешения экрана.
В конце концов, сейчас тесты можно дебажить, причем это можно делать как локально, так и прямо на устройстве, при желании можно работать даже через браузер.
— Насколько я понимаю, у вас довольно развесистая инфраструктура, и в Wargaming десятки самых разных проектов. Существует ли какая-то стандартизация на уровне всей компании? Для автотестов в основном используется Python — это характерно, наверное, не только для вашей команды, а в целом практика для всей компании?
Наверняка есть команда, которая занимается инфраструктурами тестирования, и у них есть очень много разных наработок (мониторинги, биндинги, логи и все, что угодно). Удалось ли с помощью перехода на Python получить все эти плюшки, или вы довольно независимо все это делаете?
Дмитрий: В Wargaming много проектов, но они действуют достаточно распределенно. Потому что на разных проектах — разные требования. Я могу провести такую аналогию: для нашего проекта, когда заводились автотесты, изначально одним из важных условий было то, что это должны были быть UI-автотесты. То есть мы должны делать действия так же, как и юзеры, используя UI-элементы.
А в «больших» World of Tanks используется другой принцип: там проверяется главная логика игры, используется botnet. То есть внутри игры находятся танки, они делают какие-то действия, и проверяются их взаимодействия. Насколько я знаю, это происходит даже без визуализации игры. То есть сам клиент в полномасштабном режиме не запускается.
Проекты достаточно специфичны, у каждого свои требования. Поэтому нет стандартизации в этом плане. Хотя и у нас тесты написаны на Python, и на «больших» танках тесты написаны на Python, но сама концепция абсолютно разная. С другой стороны, как я говорил, мы закладывали универсальность нашей схемы, и предполагается, что мы будем использовать наш фреймворк для автоматизации других проектов нашей мобильной студии. На данный момент у нас разрабатывается игра на движке Unreal 4, и сейчас мы изучаем вопрос по интеграции нашего фреймворка для автотестов этой игры. В World of Tanks Blitz у нас используется in-house движок, который написан полностью с нуля в нашей студии, а в той игре используется Unreal Engine. То есть это два абсолютно разных движка, но мы будем использовать наши автотесты и там, и там.
— На Heisenbug было много людей, которые занимаются автоматизацией тестирования. Далеко не все из них занимаются автоматизацией тестирования в области мобильных устройств и, тем более, мобильных игр. В чем самая главная специфика QA Automation человека в вашей области и вообще в мобилках и конкретно в мобильных играх?
Дмитрий: Я считаю, что основная специфика автоматизированного тестирования в разработке мобильных игр — это кроссплатформенность. При разработке фреймворка нужно учитывать, что работать нужно с несколькими платформами, которые могут очень сильно отличаться.
И второе — это производительность. Тестирование производительности. Для мобильных девайсов очень важно, чтобы ваша игра шла без лагов, без затупов и прочего. Нужно сразу учитывать, как вы будете тестировать производительность. Это два основных момента, на которые нужно железобетонно обращать внимание, потому что без них я не представляю себе надежное автотестирование.
— Дмитрий, мы с тобой поговорили про тестирование клиентской части, а как у вас обстоят дела с бэкендом, с нагрузочным тестированием вашего сервера?
Дмитрий: Мы сделали такую штуку как Cloud Client. Это клиент игры, но без визуализации. И в качестве нагрузочного тестирования мы можем создавать до 500000 клиентов игры и заходить ими на сервер. Таким образом мы «ранним» сервер при большом количестве клиентов какое-то время, а далее анализируем логи с сервера на наличие проблем.
— Это, наверное, требует создания некоторой инфраструктуры?
Дмитрий: Естественно. Этот вопрос у нас уже сейчас решается. На данный момент у нас запуск всех автотестов идет с помощью CI-инструмента Team City. Он устанавливает игры на девайс, запускает тесты, регулирует очереди, потом собирает тестовые данные и отправляет заинтересованным людям. Но так как наши тесты подразумевают очень много разных конфигураций запуска, ими пользуются очень много людей, как оказалось, не для всех просто этим пользоваться. Поэтому мы сейчас работаем над тем, что делаем наш портал, на котором будет очень много интересных вещей. Будет реализован запуск тестов в удобном виде. То есть любой человек сможет выбрать то, что он хочет запустить, и это будет запущено на девайсах. Мы туда переводим все отчеты.
На данный момент мы просто формируем html-страницы с графиками, с результатами, со статусами тестов и рассылаем их. А сейчас вся эта информация будет на портале в динамическом виде. Можно будет не только посмотреть текущий запуск, а отсортировать это по дате или по типу или пулу устройств. Это будет удобно для отображения. Если говорить о нагрузочном тестировании, то на портале будет отдельная вкладка для нагрузочного тестирования, где в удобном виде можно будет все посмотреть. Это будет наш кастомный инструмент. Потому что задач ставится перед ним много, и каким-то одним инструментом решить их не получится. Поэтому мы будем развивать свой портал.
— Есть системы (JIRA, TeamCity, Allure), которые позволяют с помощью разных плагинов добиваться примерно того, о чем ты рассказываешь. Почему Allure не подходит для решения такой задачи?
Дмитрий: Allure используется именно для красивого отображения данных. Однако TeamCity это уже CI-инструмент, который используется для запуска тестов, у него стоят абсолютно другие цели. Нам необходимо поддерживать и работу с Allure, и работу с TeamCity, причем как-то сделать удобной работу с TeamCity.
Но это подразумевает поддержку и развитие нескольких инструментов одновременно. А мы можем в одном месте сделать все, так как мы хотим. Ничто не мешает нам на портале прикрутить библиотеки для построения графиков в Allure или еще чем-то другом. В зависимости от того, что нам требуется, мы можем использовать разные вещи. Для отображения больших массивов данных по профайлингу нашей игры (мы используем профайлинг перед тестированием производительности и собираем большое количество данных) удобно работать в BigQuery в Data Studio. Мы будем это использовать, данные уже туда отсылаются. Мы можем в нужном виде их представить, а на портале просто предоставить удобный переход для отображения этих данных. Это не мешает использовать тот же Allure или что-то другое. Просто это все будет сосредоточено в одном месте, удобном для пользователя.
— Дмитрий, спасибо большое за интервью!