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

НачалоПочему не подошли другие решенияКак создавали своё решениеКакие проблемы возниклиПланы на будущее

По статистике SlickJamp, 90% интернет-трафика в России идёт через приложения в смартфонах и мобильные веб-версии сайтов. Чтобы онлайн-сервисы работали стабильно, нужно постоянно тестировать их на десятках мобильных устройств — это сложно, долго и дорого.

Руководитель направления в Digital Platform в Сбере Владимир Коржев рассказал, как они собрали свою ферму для тестирования мобильных приложений.

У нас в Сбере больше 13 офисов разработки и свыше 50 мобильных приложений в работе. Мы посчитали, что для тестирования нам нужно больше сотни разных смартфонов, а средняя цена одной модели — 40 000 рублей. К расходам на покупку прибавляются траты на логистику, если команда работает в распределённом режиме или на удалёнке.

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

Рассматривали два основных варианта:

  • SaaS от зарубежных вендоров: AWS Device Farm и BrowserStack. Продукты не подошли из-за условий безопасности или недоступности тестового окружения.
  • Проекты в Open Source: Open STF и Device Farmer (Fork). Полноценно перейти на это решение также не удалось. Device Farmer работает только для Android, а нам нужно тестировать приложения в том числе для iOS. Кроме того, для нас важно устанавливать подписанные тестовые приложения. По сути, Device Farmer — это монорепозиторий и монодистрибутив, на запуск которого влияет огромное количество параметров. А нам был нужен продукт с гибкой сервисной архитектурой.

Стало понятно, что надежды на SaaS и Open Source не оправдались. Поэтому решили разработать своё решение.

Сначала расскажу о том, что нам понадобилось, чтобы собрать собственное решение.

  1. Команда. Разработчики, а также специалисты техподдержки, которые могут устранить физическую поломку. Мы работаем с консумерскими устройствами, которые изначально не рассчитаны на продакшен-нагрузку. Поэтому важно, чтобы специалист мог подстраховать и минимизировать возможные технические сбои.
  2. Железо. Компьютеры Mac, мобильные телефоны, кабели, различные USB-хабы с отдельным питанием, бесперебойники, стойки, сменные аккумуляторы. Для Android подойдёт компьютер на Linux. И инструменты, чтобы со всем этим работать.
  3. Open Source проекты. Нам понадобились Appium, Libimobiledevice и ffmpeg. Appium отвечает за автоматизацию устройств, Libimobiledevice — это вспомогательная утилита, а ffmpeg — для работы с видеопотоком.
  4. Вендорские решения. Для работы с iPhone — Xcode, для Android — ADB из Android Studio.
  5. Инструменты разработки. Наше приложение написано на Node.js и TypeScript, на фронтенде — React.js, в качестве баз данных — PostgreSQL, интерактив и real-time — за счёт Server Sent Events. Всё это упаковано в Docker и K8s/OpenShift.
  6. Помещение. Важно обеспечить электропитание достаточной мощности, чтобы не выбивало пробки, а ещё систему вентиляции: смартфоны не должны перегреваться. Следить за пожаробезопасностью тоже обязательно.
  7. Сеть. Нужна стабильная связь между физическими устройствами и облачным решением. Понадобится Ethernet или Wi-Fi для Mac, а также доступ через Wi-Fi для телефонов.

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

  • Аккумуляторы выходят из строя. Из-за интенсивной работы они нагреваются, вздуваются и деформируют устройство. Приходится менять аккумуляторы, чтобы продолжать тестировать приложения на всех устройствах.
  • Экраны выгорают. Смартфоны работают 24/7, поэтому на матрице остаются следы от интерфейса. Этот дефект не влияет на качество трансляции.
  • Неэффективный кабель-менеджмент. Чтобы собрать на одной стойке несколько десятков смартфонов, пришлось потратить время на аккуратную прокладку всех кабелей — это упрощает обслуживание и замену устройств.
  • Много времени уходит на настройку. У каждого телефона нужно включать режимы разработчика или автоматизацию интерфейса. Такие издержки кажутся незначительными, но в масштабе всего парка устройств тратится достаточное количество времени. Это тоже нужно учитывать.

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

В планах работа над подключением через ADB к удалённым устройствам для дебага и подключением Chrome DevTools для Android, если нужно исправить фронтенд на мобильном устройстве. Также попробуем WebRTC для трансляции экрана. В дальнейшем интегрируем эти фичи в CI/CD-разработку.

Поделитесь увиденным

Скопировать ссылку
ТелеграмВКонтакте