как протестировать мобильное приложение при отсутствии мобильного устройства

Тестирование для мобильных устройств: эмуляторы, симуляторы и удалённая отладка

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

При отсутствии инструментов отладки приходилось полагаться на разные хаки. В целом они сводились к попыткам воспроизвести баг в десктопном браузере и затем отловить его при помощи Chrome Developer Tools или где-то ещё. К примеру, можно было уменьшить размер окна браузера или поменять user agent.

Грубо говоря, эти хаки не работали. Если ты правишь баг на десктопе, ты не уверен, что он исправлен на мобильном устройстве (МУ). Поэтому приходилось постоянно метаться между устройством и десктопом.

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

В этой статье мы разберём несколько эмуляторов и симуляторов, которые позволяют быстро и легко тестировать сайты и приложения. Затем посмотрим на инструменты для удалённой отладки, позволяющие подключаться к МУ.

Эмуляторы и симуляторы

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

Симулятор iOS

Для тестирования яблочных устройств, айфонов и айпадов, есть несколько вариантов. Первый среди них – официальный Apple iOS Simulator, входящий в поставку Xcode. Позволяет тестировать разные комбинации софта и железа – но только на Mac.

Установите и запустите Xcode. Потом ПКМ и выберите «Show Package Contents». Затем пройдите “Contents” → “Applications” → “iPhone Simulator.”

Хотя найти его нелегко, использовать симулятор просто. Откройте Safari в симуляторе и тестируйте свой сайт. Можно переключаться между разными устройствами iPhone и iPad, менять версию iOS, поворачивать устройство и т.п.

Если у вас нету Mac’а, придётся заморачиваться. Можно взять iPadian, симулятор iPad для Windows. Кроме него существует ещё несколько вариантов, в частности онлайновые. Но, честно говоря, они не особенно хороши.

Эмулятор Android

У андроида эмулятор кросс-платформенный. К сожалению, он сложен в настройке.

Для начала, скачайте подборку, включающую Android Development Tools (ADT) для Eclipse и Android software development kit (SDK). Затем следуйте инструкциям по установке, не забудьте кроме настроек по-умолчанию установить и “Intel x86 Emulator Accelerator (HAXM installer)”. Также вам понадобится установить HAXM (IntelHaxm.dmg на Маке и IntelHaxm.exe на PC).

Затем создайте Android virtual device (AVD) для тестируемого устройства. В менеджере AVD есть список готовых устройств в “Device Definitions”. Для начала выберите одно из них и нажмите “Create AVD”

Выберите любой CPU, и поставьте “No skin“ и “Use host GPU”. Теперь можно запускать виртуальное устройство и использовать браузер Android для тестирования.

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

Как альтернативу, можно использовать Manymo – эмулятор, встраиваемый в браузер. Его даже можно встроить в страницу.

Другие симуляторы и эмуляторы:

Удалённое тестирование

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

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

Для тестирования устройств от Samsung, таких, как Galaxy S5, можно бесплатно воспользоваться услугами Samsung Remote Test Lab – они предоставляют для тестирования большой выбор своих устройств.

Также можно пользоваться ресурсами Keynote Mobile Testing. Они недёшевы, но количество доступных устройств поражает, и некоторыми можно пользоваться бесплатно.

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

Удалённая отладка

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

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

С выходом 6-й версии Apple представила инструмент для отладки МУ через Safari Web Inspector.

Для начала надо разрешить удалённую отладку на устройстве. “Settings” → “Safari” → “Advanced” и разрешить “Web Inspector”

Затем подключите устройство к компьютеру через USB. Потом откройте Safari (версии не ниже 6) и в “Preferences” → “Advanced” выберите “Show Develop menu in menu bar”.

В этом меню вы увидите ваше устройство и несколько страниц с настройками.

На каждой из страниц представлено много инструментов, DOM Inspector и подобные.

Кроме DOM Inspector, iOS’ вы можете использовать:

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

Как и в случае с симулятором iOS, удалённой отладкой можно заниматься только с Мака.

Android

В случае с Андроидом инструменты удалённой отладки позволяют работать с десктопа при помощи Chrome’s Developer Tools. Кроме того, инструменты эти опять-таки кросс-платформенные.

Сначала, на телефоне пройдите в “Settings” → “About Phone” (для Android 4.4+), или “Settings” → “About Tablet”. Затем нужно нажать на “Build Number” семь раз. Кроме шуток. После этого вы увидите сообщение насчёт разработчика.

Затем обратно в основных настройках “Developer Options” нужен пункт “USB debugging”.

В адресной строке браузера Chrome наберите about:inspect. Разрешите “Discover USB devices”, и вы увидите в меню своё МУ.

Также вы должны увидеть открытые закладки в мобильном браузере. Выберите нужную, и вам будут доступны:

DOM Inspector,
Сетевая панель с внешними ресурсами
Панель исходного кода, для отладки JavaScript
Консоль JavaScript

Подробности можно найти в тьюториале “Introduction to Chrome Developer Tools, Part One.”

Также можно заниматься удалённой отладкой в эмуляторе Андроида.

Weinre

Если вам приходится отлаживать устройство с iOS на Windows, или Linux, или отлаживать устройство, работающее под Windows Phone или BlackBerry – попробуйте Weinre (web inspector remote). Работает везде.

Настройка weinre сложновата, т.к. его надо устанавливать и на сервере, и на странице. Сначала вам понадобится установить Node, а затем установить модуль Weinre:

npm install –g weinre

Затем запустите сервер отладки (подставляем ip-адрес компьютера):

Наконец, кликните на ссылке вверху user interface for debugging clients (http://localhost:8080/client/#anonymous). Теперь, когда вы откроете страницу на устройстве, её можно будет увидеть в списке целей (targets).

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

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

Ещё один вариант удалённого тестирования называется Ghostlab.

Заключение

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

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

Что ещё почитать перед сном:

“Mobile Emulators and Simulators: The Ultimate Guide,” Maximiliano Firtman
“Introduction to Chrome Developer Tools, Part One,” Seth Ladd, HTML5 Rocks
“About Safari Web Inspector,” Safari Developer Library, Apple
“Enable Remote Debugging With Safari Web Inspector in iOS 6” Dave Ackerman, Modus Create
“Remote Debugging on Android With Chrome,” Chrome Developer Tools
“Weinre as Remote Debugger,” Mozilla Developer Network

Источник

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

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

Существует несколько вариантов обеспечения тестировщиков необходимыми устройствами.

Симуляторы и эмуляторы

Для начала поймем, что такое симуляторы и эмуляторы.

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

• Симуляторы – имитируют оболочку, ограничиваются только ресурсами самой машины. Обычно данные инструменты поставляются вместе со средами разработки, такими как XCode и Android Studio. Эти инструменты позволяют имитировать поведение устройства, чаще всего ими пользуются разработчики для отладки создаваемых приложений.

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

● Могут использоваться в работе с автотестами.

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

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

Облачные фермы

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

Решение от одноименной компании позволяет протестировать ваше приложение на линейке устройств Samsung. Имеется возможность бронировать устройства на 30 минут и на 1 час.

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

Из основных минусов: девайсы общие, после тестирования устройство не сбрасывается, постоянно захламлено. В линейке только устройства компании Samsung.

Решение от компании Google. Позволяет протестировать ваше приложение более чем на 450 устройствах, чего должно хватить практически любому. Работать можно как с iOS-, так и с Android-устройствами. Есть возможность смотреть логи, настроить автоматизацию как обычные манки-тесты и как более осмысленные.

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

Visual Studio App Center (ранее Xamarin Test Cloud)

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

И это только малая часть списка, облачных ферм много.
Как и у любого решения, облачные фермы имеют как плюсы, так и минусы.

● Нет необходимости покупать большое количество реальных девайсов.

● Можно найти устройство практически для любой ситуации.

● Нет затрат на поддержку и ремонт тестовых устройств.

● Сетевая задержка, не позволяющая корректно отображать анимации.

● Работать как с полноценной заменой физических устройств тоже проблематично из-за отсутствия тачскрина.

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

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

● Цена иногда может быть достаточно высокой.

Локальные фермы

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

● Возможность глубокой кастомизации.

● Отсутствие внешней зависимости от вендора.

● Повышенный уровень безопасности: все данные находятся не где-то на чужих серверах, а у вас.

● Высокая стоимость поддержки.

● Необходимость высокого уровня компетенций специалистов.

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

Старые добрые устройства

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

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

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

● Самые честные тесты по сравнению со всеми способами тестирования.

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

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

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

Итого

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

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

В каких ситуациях применять тот или иной инструмент – решать только вам.

Источник

Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA

Онлайн-тренинги

Что пишут в блогах (EN)

Blogposts:

Разделы портала

Про инструменты

И вот настало то время, когда нашим нуждам тестирования стало тесно на рабочем столе тестировщика. Душа попросилась в облака. На самом деле нет. Не совсем.

Наши цели и задачи

(спешащий читатель, можешь мотать до следующего раздела)

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

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

При этом самым простым и очевидным решением является использование эмуляторов для Android и симуляторов для iOS устройств в нашем DevOps конвеере. Однако, что сравнительно легко реализуется на рабочем компьютере разработчика, для использования в облаке становится сложной и дорогой задачей. Для быстрой работы того же эмулятора Android требуется x86 сервер с поддержкой HAXVM, а для симулятора iOS — только MacOS устройство с xcode. Но, к сожалению, даже решив такую задачу остаётся вопрос с разрывом между поведением программного обеспечения на эмуляторах и реальных устройствах. Например каждый второй релиз мы ловим странные баги на Samsung устройствах, которые не воспроизводятся на эмуляторах. Ну, и, конечно редкие экзотические «китайцы» «радуют» уникальным и багами, которые тоже хотелось бы ловить ещё на этапе разработки.

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

Наши тесты написаны на Python 3.7 (далее это будет важно), как стек мы используем tox + pytest + Selenium + Appium, ну и небольшой набор полезных питонячих библиотек. Мы обязательно тестируем машины на Windows и MacOS с браузерами Edge, Firefox, Chrome, Safari, а так же устройства на Android и iOS — с браузерами и приложением. Тестов у нас на каждое устройство не сильно много (меньше тысячи), но при тестировании в один поток на устройствах полный набор выполняется пару часов. Поэтому критерием выбора сервиса для нас будет:

Желательно, но не обязательно:

Результаты исследования рынка

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

На Хабре я нашёл статью за 2017 год посвящённую этой же теме, но с тех пор появились и новые сервисы, да и наша задача чуть строже. Так, например, «вкусные» сервисы вроде Samsung Remote Test Lab, Firebase Test Lab, Xamarin Test Cloud нам, увы, не подходят.

Вне игры

Samsung Remote Test Lab

Сервис бесплатно предоставляет возможность попробовать поработать с различными устройствами Samsung, в том числе с самыми новыми, включая телевизоры или умные часы на Tizen (ограничение — максимум 10 часов в день, за день сервис бесплатно выдаёт 10 кредитов, что равно 2,5 часам в день, минимальная сессия — полчаса (2 кредита)). Это очень неплохо для отладки и поиска корневых причин возникновения ошибок на определённых устройствах, сервис даже предоставляет доступ к удалённой отладке (remote debug bridge, доступ к консоли и системным логам), но, к сожалению, сервис не предоставляет API-доступ к устройствам. Единственная возможность «автоматизировать» — это записать пользовательские действия и затем их воспроизвести в местном средстве автоматизации.

Firebase Test Lab

Visual Studio App Center

Сервисы на выбор

AWS Device Farm

Пожалуй, самая мощная ферма для тестирования на виртуальных и реальных устройствах на сегодняшний день (более 2500 устройств). Для нас это был приоритетный сервис, так как наши сервисы как раз развёрнуты в облаке AWS, кроме того, цены за минуту времени устройства начинаются от 17 центов. AWS позволяет работать как с нативными фреймворками, так и с Appium, Calabash, и другими фреймворками автоматизированного тестирования. Помимо автоматизированного тестирования, сервис предоставляет возможность ручной отладки. Ну и 1000 минут «на попробовать» — это очень заманчиво. Однако, дьявол как водится, кроется в деталях. С точки зрения тестирования у AWS есть несколько особенностей.

Мы, как я уже упомянул, используем Python 3.7, однако AWS Device Farm до сих пор работает с Python 2.7.6 (см. мануал здесь). И из коробки ничего не знает про tox. Для нас это означает отсутствие ряда возможностей и необходимость переработки части тестов для обеспечения обратной совместимости, так и создания окружения в обход tox. Кроме того, достаточно странный механизм загрузки тестового пакета (архив) подразумевает так же и загрузку приложения для тестирования. В нашем случае, если мы будем тестировать наш сервис через мобильный браузер, то загрузка приложения — лишний шаг. Впрочем, приложение можно заменить «заглушкой», а в окружении Python 2.7 создать venv с Python 3.7, и тогда в нём создать окружение с tox, который…

Amazon не был бы Amazon, если бы всё упиралось в старые версии. В качестве альтернативы (и ни у какого сервиса ниже такой возможности не будет) AWS предлагает использовать AWS Device Farm через AWS CLI (command line interface) (см. мануал здесь). То есть, мы можем подключить устройство из облака как реальное устройство к нашему компьютеру в режиме удалённой отладки (remote debug), правда, предварительно заменив adb на патченое (в списке бинарника под linux нет, но уверен, в природе он существует). То есть, настроив AWS CLI, для тестирования нам потребуется выполнить буквально несколько команд (ведь мы не собираемся использовать GUI в виде AWS Device Farm App).

Если мы хотим тестировать приложение, его так же можно загрузить через AWS SDK.

Но я не рассказал ключевой нюанс здесь. Мы снова натыкаемся на дьявола в деталях. Дело в том, что опция удалённой отладки доступна только если для AWS мы используем Private Devices план. Во-первых, данная возможность доступна только под запрос (нужно написать письмо в Amazon), во-вторых опция доступна для региона us-west-2, а в-третьих, фактически эта опция нас возвращает к сценарию, когда у нас есть сервер для тестирования с набором (или хотя бы одним) устройств подключенных к нему. Плюсы очевидны — мы это устройство можем использовать монопольно, что очевидно безопаснее и быстрее, с другой стороны лишаемся главного преимущества — выбора и разнообразия устройств.

Сервис мне в целом понравился, но для нашей команды, увы, в нём слишком много «но».

Bitbar

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

Kobiton

Настройка так же очень проста, в отличие от bitbar’a почти что оригинальный Appium.

BrowserStack

Пример кода для приложения

Experitest

SauceLabs

Perfecto

По всем критериям выбора сервисы весьма схожи, разница между сервисами в их производительности и цене (если нет особенностей, например, как в случае AWS). Поэтому сведём данные исследования в таблицу, посмотрим на скорость сервисов (с учётом подключения через US VPN), а так же на цену, для удобства сравнивая среднее месячное время тестирования на устройствах (5 релизов в месяц, по 2 часа тестирования на Android и iOS устройстве = 20 часов). В качестве референсных значений я использую данные со своего локального компьютера с эмулятором, опять-таки подключаясь к нему для чистоты эксперимента через VPN в США).

Выводы

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

Вариант А: Если вам важна быстрота проверки, и нужны проверки сразу на десятках разных устройств — ваш выбор — Bitbar.

Вариант Б: Если у вас в приоритете результаты с референсных устройств, а конфигурационное тестирование вторично (но необходимо) — ваш выбор — BrowserStack. Это как раз наш кейс, так как статистически — 90% всех ошибок — это ошибки с референсных платформ и устройств (чаще всего баги общие для всех референсных платформ сразу). Оставшиеся 8% — это ошибки MS IE, с отказом от поддержки IE — 2% ошибки MS Edge, а 0,5% ошибки на специфичных конфигурациях.

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

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

Источник