Что такое мобильная ферма

AWS Device Farm

AWS Device Farm – это сервис для тестирования приложений, который позволяет повысить производительность мобильных и веб-приложений. Для этого используются различные браузеры для настольных компьютеров и реальные мобильные устройства, поэтому вам не требуется создавать собственную инфраструктуру для тестов. Сервис позволяет проводить тесты одновременно в нескольких браузерах для настольных компьютеров или использовать для этого реальные мобильные устройства. Это ускоряет процесс тестирования, во время которого также создаются видео и журналы для быстрого выявления ошибок в работе вашего приложения.

Удаленный доступ

Управляйте устройствами с помощью касаний и жестов в режиме реального времени прямо из веб-браузера.

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

Запускайте тесты Selenium одновременно в разных версиях браузеров Chrome, Internet Explorer и Firefox, которые размещаются в облаке AWS.

Преимущества тестирования с помощью реальных устройств в AWS Device Farm

Тестирование на устройствах, с которыми работают ваши пользователи

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

Воспроизведение и быстрое устранение ошибок

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

Моделирование реальных условий

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

Выбор подходящих тестов

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

Интеграция с рабочим процессом разработки

Воспользуйтесь подключаемыми модулями и API сервиса для автоматической инициации тестов и получения результатов из интегрированных сред разработки и сред непрерывной интеграции, таких как Android Studio или Jenkins.

Настройте собственную лабораторию частных устройств в облаке

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

Преимущества тестирования в браузерах для настольных компьютеров в AWS Device Farm

Запуск тестов на нескольких инстансах для браузеров одновременно

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

Быстрое выявление и исправление ошибок

Чтобы быстро обнаружить, проанализировать и исправить ошибки в работе приложения, можно использовать видео, журналы консоли, журналы операций и журналы веб-драйверов, которые создает Device Farm.

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

Запускайте тесты в нескольких браузерах для настольных компьютеров, включая Chrome, Firefox и Internet Explorer, чтобы обеспечить правильную работу приложений в разных браузерах.

Применение ферм девайсов в тестировании мобильных приложений

Мы в Open Solutions максимально автоматизируем процесс тестирования в наших проектах. Это позволяет заказчику сэкономить деньги, а нам — помогает максимально полно проверить функционал разрабатываемого нами продукта. В случае с мобильными приложениями, мы пришли к выбору сервиса автоматизации после того, как выстраивали систему на базе локальных ресурсов. Но со временем это стало неудобно из-за необходимости поддерживать актуальный парк устройств и заниматься их администрированием. Поэтому мы перешли на облачные фермы мобильных устройств и выбирали между Firebase Test Lab и Microsoft App Center. Об этом выборе мы и хотим рассказать в данной статье.

Что такое удаленные фермы устройств и зачем они нужны?

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

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

Какие преимущества дают удаленные фермы:

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

Но без недостатков тоже не обойтись:

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

Почему именно Firebase Test Lab и Microsoft App Center?

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

• Firebase Test Lab. Потому что мы уже работаем в Firebase. Мы загружаем наши тестовые сборки приложений и собираем статистику. Удобно держать результаты автотестов в той же консоли. Достаточно зайти в одну систему и ты получишь полную информацию о своем приложении.
• Microsoft App Center. Наша фирма является сертифицированным партнером Microsoft. Благодаря этому, нам доступна существенная скидка на использование всех сервисов, в том числе и App Center. А самый главный плюс — это большой выбор физических устройств.

Firebase Test Lab

Данный сервис предоставляется 11 виртуальных и 139 физических устройств для тестирования. Firebase дает возможность руками запускать 10 тестов на виртуальных и 5 тестов на физических устройствах в день совершенно бесплатно. За запуски через CI или увеличение доступных запусков в день придется платить.

Помимо запуска рукописных тестов, о них поговорим чуть позже, Test Lab умеет делать Robo-тесты. По сути это некое подобие monkey-тестов. Только здесь есть возможность задать тестовое окружение и, как говорится в документации, на одних и тех же данных тест будет выполнять одни и те же действия, что позволит проверить исправление ошибок.

К автотестам Firebase предъявляет ряд требований. Такие тесты должны быть написаны с использованием следующих фреймворков:

• Grandle + JUnit + UIAutomator или Espresso для Android. UIAutomator используется для тестирования методом черного ящика. Espresso — белого.
• XCUITests для iOS.

Основные сравнительные эксперименты мы проводили в части тестов на Android приложениях. Тестирование МП реализовывали методом черного ящика, поэтому выбрали следующий набор технологий: Grandle + JUnit + UIAutomator. До этого мы не были знакомы с UIAutomator независимо от Appium. Но разобраться получилось довольно быстро. Написание простенького теста на авторизацию с использованием PageObjects и отладка запусков в Firebase заняло около 3 дней.

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

• Список сценариев, которые выполнялись во время прогона.

Как создать мобильную ферму, или Вжух! И ты мобильный фермер

Привет, «Хабр»! Мы — Даня и Ксюша, разработчик и тестировщик команды мобильных приложений в компании ATI.SU. Сегодня хотим рассказать удивительную историю о том, как наши системные администраторы помогли нам развернуть мобильную ферму Android-девайсов, и с чем мы столкнулись. Опишем технические детали, чтобы вы могли повторить наш опыт. Однажды и ваша команда сможет отлаживать и тестировать удалённо на большом парке девайсов.

Ситуация: мы переходим на удалёнку

Когда мы перешли на удалённый режим работы из-за пандемии, у нас появились проблемы с тестовыми девайсами:

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

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

Мы столкнулись с первым выбором: стоит ли использовать какую-то готовую облачную ферму или разворачивать что-то свое. Вот наиболее популярные решения, которые мы рассматривали:

• Ферма Samsung: исключительно с устройствами от Samsung.
• Ферма Google: с небольшим парком устройств, выбранных Google. Данная ферма имеет ограничение: на ней можно запускать только автоматизированные тесты, но не тестировать вручную.
• Ферма Huawei: схожа ферма с фермой от Samsung, но представлены только телефоны от Huawei.

В облачных фермах мы обнаружили ряд проблем, а именно:

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

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

Этап 1. Выбираем и настраиваем софт

В качестве ПО для фермы мы выбрали STF — инструмент для удалённого тестирования и отладки прямо на странице браузера.

От мобильной фермы мы ожидали следующих возможностей:

• проводить ручное тестирование приложений без установки на компьютер дополнительного ПО;
• отлаживать код приложения через стандартные средства (подключение через adb);
• отлаживать WebView в приложении через Chrome Dev Tools;
• снимать логи с устройства.

С учетом запрашиваемого перечня возможностей STF оказался для нас единственным вариантом. Дополнительно мы получили еще ряд приятных бонусов:

• упрощенная отправка deeplink;
• упрощенная отправка shell-команд;
• контроль за файловой системой;
• просмотр детальной информации о состоянии батареи, интернета, SIM и процессора.

STF реализует свои возможности через 2 канала управления устройствами:

• STF должен быть развернут на машине на которой уже запущен ADB сервер и которая имеет доступ к желаемым телефонам.
• STF устанавливает собственное приложение STFService.apk, работающее в состоянии foreground-service, на подключенные устройства. Приложение взаимодействует с бекендом STF через сокеты и существенно расширяет возможности по управлению устройствами.

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

После выбора ПО основной задачей для нас был выбор железа. Решить эту задачу нам помогли наши отважные системные администраторы.

Первой идей стало заказать USB-концентратор, который управляется при помощи usbip. Данное решение нам показалось надежнее и красивее, чем обычный ПК и набор хабов. Однако красота красотой, а решение нужно было протестировать.

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

Общая инфраструктура выглядела в этом случае следующим образом:

• в нашем офисе в Санкт-Петербурге стоит сервер с развернутым STF;
• в Москве у производителя стоит концентратор, к которому подключены 10 наших девайсов;
• на концентраторе запущен сервер usbip, к которому подключается клиент usbip, запущенный на нашем сервере;
• далее usbip производит bind портов, и нашему серверу с STF начинает «казаться», что в его USB-порты подключены девайсы;
• девайсы отображаются в STF.

При тестировании, как и ожидалось, мы столкнулись с набором проблем. Первая проблема была в лимите портов usb_over_ip. В Ubuntu этот лимит равен 8, чего явно недостаточно для нашей фермы. Исследовав проблему, мы выяснили, что в debian этот лимит выше. Также был вариант пересобрать ядро и увеличить лимит.

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

После этого мы продолжили изучать темы доступных концентраторов, которые работают по иным протоколам или имеют более мощную конфигурацию железа. Мы нашли еще несколько вариантов в США и от ORICO. У данных лотов была долгая доставка и отсутствовала возможность протестировать железо до покупки, поэтому мы решили не брать «кота в мешке».

Этап 3. Продолжаем выбирать железо и тестируем софт

Потерпев неудачу в тестировании концентратора, мы с системными администраторами остановились на обычном ПК с процессором i7 и 32 Гб оперативной памяти. В качестве ОС использовали Ubuntu.

Для установки и настройки STF нам пригодилась инструкция из GitHub. Мы хотели глубже разобраться, как устроен STF изнутри, поэтому решили обойтись без использования готового Docker-контейнера.

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

Ещё из полезных функций нам пригодился таймаут — это время, через которое девайс освобождается от текущего пользователя, если девайс не используется ( –group-timeout ). В таком случае девайс может быть занят новым пользователем.

Этап 4. Покупаем стойку и хабы

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

Для подключения девайсов к системному блоку мы закупили хабы TP-Link. Для нас были очень важны характеристики хабов: количество портов, наличие usb 3.0 и силы тока больше 1 А, так как современным девайсам недостаточно 0,5 А.

У хабов есть разъемы USB 3.0 с разной силой тока:

• по 1,5 А — 3 штуки;
• по 0,5 А — 4 штуки.

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

Этап 5. Настраиваем фермерские девайсы

Большинство девайсов удалось настроить для работы в ферме следующим способом:

1. Включить на девайсе настройки разработчика.
2. Включить отладку и установку по USB в настройках разработчика.

1. Подключить девайс к хабу по USB-кабелю.
2. Выбрать тип подключения «Передача файлов».

1. Дождаться, когда девайс покажет диалог про разрешение отладки. Разрешить отладку.

1. При подключении к ферме на девайс автоматически устанавливается приложение Open STF. В настройках девайса необходимо дать ему все разрешения (Permissions)

Некоторые девайсы отключают сервис приложения Open STF, когда он работает в фоновом режиме. Это объясняется Doze mode — режимом глубокого сна девайса, в который он переходит, если не используется длительное время (по нашему опыту, от часа и больше в зависимости от девайса). Чтоб избежать отключения сервиса, мы настроили девайсы по инструкции с сайта Don’t kill my app!.

Помимо проблем с сервисом в приложении, существует отдельная проблема поддержки конкретного устройства в minicap. Через Minicap производится стриминг экрана устройства, что позволяет дублировать экран телефона в web-интерфейсе STF. Однако Minicap построен на внутренних API Android, которые могут отличаться от прошивки к прошивке и часть девайсов может не работать, так например долгое время были проблемы с устройствами от Xiaomi. Все существующие проблемы вы можете найти в issue к проекту, а также в случае проблем, возникающих у вас, вы можете заводить там новые issue.

Этап 6. Приручаем строптивых: Huawei и Xiaomi

При попытке разблокировать девайсы Huawei STF отображает чёрный экран, поэтому для них мы сделали дополнительные настройки:

• в настройках экрана выбрали пункт «Включать спящий режим — никогда»;
• в настройках разработчика выбрали пункт «Не выключать экран» или «Оставлять активным» (название отличается на разных девайсах).

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

Для подключения к ферме и отладки смартфоны Xiaomi также потребовали дополнительных настроек:

• включить режим разработчика на девайсе (7 тапов по версии билда MIUI);
• перейти в настройки разработчика, включить следующие пункты: отладка по USB, установка через USB, отладка по USB (раздел «Настройки безопасности»);
• подключить Mi-аккаунт;
• вставить SIM-карту, активировать ее не понадобилось;
• перезагрузить девайс.

Этап 7. Отлаживаем и тестируем

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

Страница работы с STF выглядит так:

Для установки приложения на фермерский девайс достаточно перетащить APK-файл. Для сбора логов в STF есть меню, аналогичное Logcat в Android Studio. В нём нужно нажать Get для старта логирования.

Логи можно сохранять в форматах json и log.

Для выполнения команд adb используется Shell — командная строка.

Кроме того, в STF можно использовать debug-режим. Для этого на вашем компьютере должен быть установлен Android Debug Bridge. Алгоритм подключения debug:

1. В разделе remote-debug лежит команда для удаленного подключения к отладке девайса.

1. Необходимо выполнить команду в терминале вашего компьютера

1. При первом выполнении команды подключиться не получится. Терминал выдаст такое сообщение: failed to authenticate to
2. На странице фермы в браузере появится диалог с предложением верифицировать ключ вашего компьютера на ферме, нажимаем Add Key. Далее нужно перейти в Settings — Keys и проверить, что добавился публичный ключ.

1. Далее нужно перейти в Settings — Keys и проверить, что добавился публичный ключ

1. Выполнить команду из раздела remote-debug повторно, и терминал ответит: already connected to .

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

1. Также будет возможна отладка WebView на странице chrome://inspect.

Этап 8. Отладка WebView

Следующей задачей, связанной с фермой, стало предоставление возможности отладки WebView посредством Chrome Dev Tools без установки adb.

У нас возникла необходимость предоставлять средства для отладки Google Chrome другим командам. Часто у них не было adb, а его установка и использование усложняли им жизнь, поэтому мы решили оптимизировать этот момент.

WebView предоставляет возможности для отладки веб страниц. Это работает благодаря тому, что при включении опции setWebContentsDebuggingEnabled WebView открывает unix domain socket на девайсе, который работает по протоколу Chrome DevTools Protocol.

Данный сокет запущен на устройстве, порты которого недоступны извне, и Google Chrome, запущенный на локальном компьютере, отображает только те девайсы, которые подключены к ADB (через USB/через remote connect).

У нас возникло несколько идей, как сделать отладку WebView доступной без установки adb. И мы их проработали более подробно. И вот наши результаты.

Идея 1. Можно запустить виртуальный Сhrome на ферме (на той же машине, где запущен STF) с открытым портом для дебага, предварительно поставив x-server.

google-chrome --disable-gpu --no-sandbox --user-data-dir=/tmp/chr --remote-debugging-port=9222 

Далее дать доступ к порту 9222 извне и подключиться к этому порту со своего локального Сhrome.

Таким образом вы будете отлаживать Chrome, который в свою очередь отлаживает WebView на девайсе. Схема оказалось нерабочей из-за того, что при запуске отладки WebView (Inspect) запускается новое окно, которое недоступно для отладки через chrome-dev-tools.

Идея 2. Вместо отладки виртуального хрома на ферме, можно подключиться к нему через x-server и работать через GUI-виртуального хрома. Этот вариант оказался чуть более эффективным и даже окно для отладки WebView открывалось, но фрагмент предпоказа страницы на девайсе был недоступен из этой страницы. Также не любой терминал позволяет работать x-server, что понижает эффективность данного решения.

Рабочая идея. Мы решили обратиться к истокам и выяснить, каким образом Google Chrome подключается к портам внутри девайсов и какие средства ADB он использует.

При изучении был обнаружен следующий исходный файл dev_tools_adb_bridge. Оказалось, что Chrome проверяет все unix domain socket на девайсе по магическому фильтру const char kDevToolsChannelNameFormat[] = «%s_devtools_remote» . Далее, найдя необходимые сокеты для отладки, пробрасывает эти сокеты наружу для доступа к ним.

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

• находить девайс по его идентификатору deviceId ;
• искать сокеты по фильтру, специфичному для WebView webview_devtools_remote ;
• пробрасывать сокет с девайса в tcp порт сервера, который доступен для доступа portToForward .

Скрипт на TypeScript, построенный на базе библиотеки, которая также используется внутри STF adbkit, будет выглядеть следующим образом:

import * as adb from "@devicefarmer/adbkit"; export const client = adb.Adb.createClient(< host: "localhost", >); export const forwardDevicePortToAnother = async ( deviceId: string, portToForward: string, ) => < const deviceClient = client.getDevice(deviceId); const shellResult = await deviceClient.shell( "cat /proc/net/unix | grep webview_devtools_remote", ); const shellOutput = (await adb.Adb.util.readAll(shellResult)) .toString() .trim(); if (shellOutput.length === 0) return; const webviewRemotePort = shellOutput.split("@")[1]; const forwardResult = await deviceClient.forward( `tcp:$`, `localabstract:$`, ); return forwardResult; >;

Соответственно, если наша ферма развёрнута по адресу x.x.x.x и на этой машине у нас есть открытый порт 2222, то выполнив данный скрипт для некоторого девайса, на котором запущен WebView, мы получим доступный порт для отладки WebView: x.x.x.x:2222. Этот порт мы можем вставить в Сhrome на нашей локальной машине, и она найдет девайс.

Дописав несколько вспомогательных методов для получения списка устройств и отключения проброса портов, а также небольшой фронт на Flutter-web, мы получили следующий инструмент.

1. Запускаем WebView на девайсе в ферме.
2. Переходим в инструмент для проброса портов и находим нужный девайс.

1. Запускаем проброс портов.

1. Прописываем полученный адрес в chrome://inspect/#devices.

1. Запускаем отладку WebView.

Если кому-то будет полезен данный инструмент, мы с удовольствием приведём код сервиса в порядок и опубликуем его в нашем GitHub.

Этап 9. Светлое будущее фермеров

В будущем мы планируем развивать ферму и видим 3 основных направления:

1. Пожарная безопасность фермы. Сейчас основная проблема девайсов — это аккумуляторы, которые иногда выходят из строя и могут загореться или взорваться. Мы уже регулярно осматриваем ферму, чтобы обнаружить такие аккумуляторы вовремя, а также мы используем приложение, которое показывает состояние аккумулятора. Также мы уже заказали встроенный шкаф для девайсов с металлическим покрытием и отдельными ячейками для каждого девайса. Вдобавок, мы изучаем направления по избавлению девайсов от аккумуляторов вовсе, то есть попытаться изменить электросхему девайса, чтобы он питался от сети напрямую.
2. iOS. В нашем парке девайсов помимо Android-устройств также есть и iOS-устройства, которые используются нативной командой iOS-разработки и командой Flutter-разработки. STF имеет средства для поддержки iOS-устройств, но пока мы не успели протестировать этот способ в работе. Также мы будем исследовать варианты расширения нашего микросервиса для отладки WebView и на iOS.
3. Решение проблем на части девайсов. В нашем парке девайсов все еще есть ряд девайсов, которые либо имеют проблемы с Minicap, либо убивают сервис STF. А некоторые девайсы имеют баги другого рода, что мы выявили по логам STF. Например, на них возникают бесконечные цикличные коннекты-дисконнекты. Для каждого девайса мы планируем провести индивидуальную работу, чтобы максимально расширить наш парк.

Заключение

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

А также хотим поблагодарить наших системных администраторов, которые помогали нам с выбором железа и софта для фермы, с настройкой и тестированием STF и проделали огромный объём работы для фермы!

Мы очень надеемся, что статья поможет и вам в решении проблем с девайсами при удалённой работе.

• мобильные приложения
• тестирование мобильных приложений
• ферма
• андроид
• девайсы
• android
• разработка мобильных приложений
• mobile development
• mobile testing
• удалёнка

Ферма мобильных устройств — новый способ тестирования Android-приложений

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

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

Многие энтузиасты пытаются найти «серебряную пулю», чтобы после проверки приложения можно было заявить, что оно работает на любом устройстве — вне зависимости от характеристик и производительности. И хоть написать приложение под все телефоны в мире невозможно, мы в Selectel нашли способ, как к этому приблизиться.

Классические способы тестирования

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

1. «Покупаешь телефоны, загружаешь свое приложение и тестируешь». Это самый простой подход, но сильно затратный для бюджета. Например, чтобы проверить мобильное приложение дополненной реальности, нужно закупить десятки телефонов с разными камерами и драйверами. И все равно может потом всплыть версия, на которой все «валится». Кроме того, эти устройства нужно утилизировать — об этом мы подробнее рассказали в отдельной статье.
2. «Зачем вообще реальные устройства? Установил эмулятор — и в бой!» Это хороший способ, если нужно быстро протестировать базовый функционал и найти явные «мобильные баги». Разработчику не нужны большие средства на покупку телефонов. Кажется, что это оптимальный путь тестирования, но все ли так просто?

Что нужно учитывать

Не для всех тестов релевантны эмуляторы. Когда речь заходит о тестах на производительность, UI на взаимодействие с «реальным железом» — будь то камера или антенна — лучше вернуться к модели «на столе». Но что делать, если телефонов 5, 10, 15 или еще больше? Если команда находится на разных концах города или даже страны, передача устройств может сильно затянуться.

Кроме того, часто бывают ситуации, когда performance critical-код необходимо писать на C/C++ — или другом компилируемом языке — и подключить к основному JVM-based приложению нативную библиотеку. Или пересобрать существующую под аппаратную платформу смартфона. В таких случаях без нативного кода не обойтись.

«Есть два типа людей. Первые — используют вставки из нативного кода или пишут приложения полностью на нем. Вторые — обходят его стороной». Однозначно можно сказать, что нативный код используют и будут использовать, притом достаточно часто. Хороший пример — мобильные игры, которые сложно представить без нативного кода. Там он нужен, например, чтобы подключать библиотеки на C/C++ для обработки 3D-графики.

Решение — ферма мобильных устройств

Сегодня для сборки и прогона unit-тестов нативного кода используют эмуляторы целевой архитектуры — например, QEMU. Но они накладывают некоторые ограничения, в том числе из-за скорости трансляции кода под необходимую архитектуру.

Мы решили объединить лучшие практики из классических способов тестирования и создали ферму мобильных устройств. Теперь у клиентов есть возможность тестировать свои приложения на реальном железе и использовать наши инстансы на ARM-процессорах.

Ферма мобильных устройств — это инфраструктурное решение для удаленного тестирования и сборки приложений под Android. Имея доступ к большой базе смартфонов с различными параметрами (версиями OS Android, процессорами, диагоналями, производительностью и оболочкой), пользователь может проводить широкий набор тестов. Тем самым ускорить обнаружение багов и деплой в продакшен. Входящий в этот бандл ARM-сервер значительно упрощает работу с нативным кодом. По нашим предположениям, мобильные приложения быстрее проходят unit-тестирования именно на целевой архитектуре.

Функциональность фермы мобильных устройств

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

На данный момент ферма работает именно с устройствами на Android 4.0 и выше. Реализацию IOS-фермы с телефонами Apple мы решили пока не трогать, у них есть свои особенности и ограничения.

Как устроена ферма мобильных устройств

Схема фермы проста: специальный USB-хаб и «устройство-прослойка» объединяют телефоны в пул и подключают к ARM-серверу через выделенные свитчи. Весь трафик перетекает в рамках локальной сети.

В качестве «прослойки» мы используем специальный софт на Raspberry Pi, который объединяет мобильные телефоны в пулы, локальные парки и позволяет управлять ими прямо через браузер.

Рассмотрим схему фермы мобильных устройств подробнее.

Устройства объединены с помощью USB-хаба

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

В итоге мы взяли HARPER HUB-10MB, и сейчас эта железка справляется со своей задачей. Она также позволяет легко выводить устройства из бандла. Для этого предусмотрен интерфейс для управления питанием отдельных портов.

Ферма расположена в отдельном помещении

Не просто так размещение аккумуляторных батарей в серверных запрещено. И так как мы не можем разместить телефоны в общих серверных и сделать прямое подключение к ARM-серверу, нужно было придумать «финт ушами».

Самое очевидное решение проблемы — выделить отдельное изолированное помещение под мобильную часть фермы и подготовить его к нештатным ситуациям с аккумуляторами.

Так мы и сделали: подготовили отдельное помещение и разместили в нем мобильные устройства, а для соединения с ARM-сервером поставили роутер. Через него простирается локальная сеть до машины в серверной.

В серверной — машина на ARM

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

В наших дата-центрах можно арендовать выделенный ARM-сервер с 128-ядерным процессором Ampere Altra. Мы его уже полностью протестировали, машина готова к работе. Но если вам нужен сервер на x86 — можем подобрать другую конфигурацию.

Кому полезны фермы мобильных устройств

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

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

• Хотите тестировать приложения на реальных устройствах без затрат на обслуживание. Вам не нужно приобретать телефоны для единоразового тестирования — достаточно на время арендовать ферму. Это избавляет от лишних затрат на администрирование и проблем с утилизацией ненужных устройств.

• Ваше приложение использует библиотеки C/C++. Софт на базе C++ — это один большой и много маленьких бинарников для решения узких бизнес-задач, которые нужно портировать по отдельности. И gcc —arch=aarch64 работает тут почти никогда, поэтому особенно важно протестировать свое приложение на целевой архитектуре, если оно содержит нативный код. С этим поможет ферма мобильных устройств, в основе которой — ARM.

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