Всем привет! В этой статье расскажу, как можно стабильно и многопоточно тестировать клиентские приложения на последних версиях Android с помощью Selenoid – если у вас уже есть Appium-автотесты, или они ещё только планируются. Подсвечу важные моменты и нюансы, которые смогут сэкономить вам, как минимум, несколько рабочих дней – а вы больше не будете переживать, что ваши тесты будут падать из-за тестовой инфраструктуры.
Вам же нужен Selenoid?
Сначала разберёмся, для кого Selenoid может подойти в рамках тестирования мобильных приложений Android.
Пункт первый – используете Appium
Вам точно подойдёт Selenoid, если вы используете или планируете использовать в своих тестах Appium, а не нативные тесты.
У всех есть свои причины так делать – у нас, например, в Android-тестах используется Appium в связке с pytest, поскольку мы тесно интегрированы с автотестами на Backend, которые тоже написаны на Python. Преимущество такого подхода в том, что мы можем "нативно" рулить бэком, подготавливая любые предусловия для тестов без использования внешних адаптеров. Об этом, кстати, была написана отдельная статья.
Плюсом к этому, нам близок подход, когда автотесты для всех клиентских платформ у нас однообразны, универсальны и легки в поддержке – поэтому для Android / AndroidTV / iOS / Web тесты у нас написаны с использованием Appium и Selenium соответственно.
Пункт второй – есть на чём попробовать
Чтобы дальнейший материал имел практический смысл, ваши DevOps должны быть готовы выделить вам некие инфраструктурные мощности, которые как правило, находятся на архитектуре х86. Либо у вас в наличии уже есть такой ресурс. Можно начать свой путь с пары машин, а так как система хорошо масштабируется, попозже запросить расширение парка.
Пункт третий – вам нужна многопоточность
Не важно, начали вы уже писать тесты или только планируете это делать. Главное, что вы, скорее всего, уже догадываетесь, что их вскоре или уже сейчас нужно будет параллелить, чтобы сохранить адекватные временные рамки тестовых сессий.
Сразу о плохих альтернативах
Если DevOps предлагают вам VM
Давным-давно, когда инфраструктура наших автотестов ещё была только в проекте, DevOps предложили выделить нам пул виртуальных машин. Нюанс в том, что при ещё одном дополнительном слое виртуализации мы будем иметь чудовищно низкую производительность. Ведь на вашей машине будет крутиться ещё и Docker, в контейнере которого лежит родительская ОС, в которой в свою очередь, уже лежит долгожданный Android-эмулятор.
А как дополнительный бонус, вы получите нерабочие снапшоты – в нашем случае, из-за особенностей работы KVM на виртуальных машинах, Android SDK просто откажется вам их сохранять. Так что как только на горизонте появилась возможность переехать на настоящее железо – мы сразу это сделали, и предлагаем вам на эти же грабли не наступать.
Физические мобильные фермы
Можно пойти по другому пути – и подумать в сторону мобильных ферм. Это, конечно, совершенно другая лига и другие бюджеты, если мы говорим про локальные варианты. Например, у нас поднята небольшая ферма на опен-сорс решении STF, и по факту она сейчас используется только ручным тестированием, когда нужно подключиться к какому-нибудь девайсу руками и что-то потыкать.
Из выявленных проблем – это отвалы авторизации по ADB, постоянные нюансы с доступами из-за разношерстности парка (особенно на Xiaomi и чем-то подобном). В общем, нюансы имеются. И вместе с этим, здесь нужно в первую очередь хорошо посчитать аппаратную стоимость такой фермы, поскольку количество потоков в ваших тестах ограничено только тем, какое у вас сейчас под рукой количество реальных устройств.
BrowserStack
Если говорить про Browserstack, то в первую очередь нам не понравилась скорость и стабильность выполнения тестов. Да, по идее на бумаге всё круто: ты просто оплачиваешь подписку и тебе из коробки уже доступна заветная многопоточность. Да, там есть красивые дашборды, где можно смотреть результаты тестов, если лень настраивать какие-нибудь Allure-отчёты. Но задержки там большие, тесты часто падают на динамических проверках – например, где какой-то элемент доступен лишь несколько секунд.
И есть еще такой скользкий момент – если ваша компания большая, а времена нынче неспокойные – у вас будет отдельная головная боль, как согласовать с безопасниками выгрузку ваших дебажных версий приложений куда-нибудь в Индию.
Вдобавок конкретно нам важно было запускать автотесты на Android TV, а Browserstack сейчас не может предложить те реальные устройства, которые распространены в СНГ. А недавно такой функционал в принципе находился в альфа-стадии, так что рассчитывать на стабильность тестов там тоже не стоит.
Selenoid 101 – ставим на "побаловаться"
И так, с альтернативами разобрались. Теперь я расскажу самые базовые вещи о том, что такое Selenoid, какие проблемы он решает, и самое главное – как вы можете в пару кликов попробовать поставить его себе на "посмотреть". Понятное дело, что этой информацией мы не ограничимся – у нас с вами дальше много интересного. Но погружаться в дебри будем уже имея первоначальное представление, с чем же мы работаем.
Что такое Selenoid
Selenoid - это инструмент, который призван решить проблему многопоточности Selenium и соответственно, Appium тестов. Он написан на Go, занимает в памяти при работе около 50 мегабайт, и из-за этого имеет потрясающее быстродействие.
Ближайшим аналогом Selenoid’а можно считать Selenium Grid, который примерно решает те же задачи, но написан на Java, более требователен к ресурсам и менее поворотлив. Раньше на него также жаловались по стабильности, но как и любой популярный продукт, он постепенно развивается, и сейчас общее количество нареканий на него снизилось.
Как работает Selenoid
И так, давайте разбираться, как работает Selenoid, и как он готов из коробки лишить вас головной боли насчёт многопоточных тестов.
Когда вы инициализируйте драйвер в ваших автотестах, то вы стучитесь, как правило, на локально поднятый Appium Server – примерно по такому адресу, как на картинке. Всё что вам требуется сделать, это поменять адрес на адрес инстанса поднятого Selenoid’а, а дальше всю работу он берёт на себя. Сперва он поднимает один или несколько docker-контейнеров с Android и Appium-сервером внутри контейнера, и далее полностью занимается маршрутизацией HTTP-запросов от ваших тестов до конечного поднятого контейнера, и понятное дело, делает это в многопоточном режиме. Вот, собственно, почти и вся наука.
Приятным бонусом является то, что он также следит за очередью тестов, и при правильной настройке не допустит перегрузки железа по ресурсам, если у нас превышена доступная квота – а поставит тесты в очередь. А также прибьёт больше не нужные нам контейнеры в конце тестовой сессии.
Другими словами – весь менеджмент контейнеров также будет лежать на нём.
Как поиграться с Selenoid
У тех, кто еще не пробовал данный инструмент, наверняка после предыдущего слайда уже зачесались руки проверить всё в деле. И здесь разработчикам можно выразить огромный респект, поскольку быстрый старт еще никогда не был так быстр.
Всё что вам нужно, это установленный на машине Docker. Его установка различается для разных операционных систем, но я рекомендую использовать вам что-то в стиле Ubuntu Server или аналогичной серверной ОС. Тем не менее, держите ссылку на официальную инструкцию по установке Docker’а на любую систему.
Selenoid имеет специальную утилиту для быстрого запуска и конфигурации – она называется как ни странно, Configuration Manager. Она лежит и ждёт вас на Github-страничке Selenoid’а. Вашей задачей будет скачать её и запустить вот таким образом:
./cm selenoid start --vnc --force --browsers "android:10.0" Утилита сама скачает вам с docker-репозитория образ последней официально поддерживаемой системы Android – десятой. Для наших демо-целей этого пока что более чем достаточно.
Для тех, кто любит наблюдать за тем, как выполняются тесты, можно через тот же Configuration manager запустить и UI Selenoid’а. Он даст вам возможность не только смотреть, но и управлять устройствами, а также смотреть логи с Appium. Команда запуска выглядит так:
./cm selenoid-ui startТеперь чтобы перевести ваши тесты на Selenoid, осталось прописать в ваших тестах дополнительный Capabilities для Appium:
"deviceName": "android"Таким образом мы сообщаем Selenoid’у, что нам нужен не условный Google Chrome, а именно Android.
Всё, можно запускать тесты!
Как правильно настроить Selenoid под Android
Системные требования
Не секрет, что все наши Android-устройства работают на ARM-архитектуре – там всё работает плавно, быстро и здорово. У нас же в распоряжении есть x86, и если DevOps выделили вам железо, которое еще вчера крутило джобы в каком-нибудь Jenkins, то в 95% случаях это будет х86 и самое главное - там не будет GPU.
Давайте посчитаем, сколько ресурсов в таком случае нам потребуется под один эмулятор, но сначала – маленькое напоминание. Как уже было озвучено в первом разделе статьи – постарайтесь строить инфраструктуру именно на физических серверах, а не на виртуалках. Если представить, что вам не нужны снапшоты (а от них грех отказываться!) то с VM даже на железе уровня Xeon Gold 62xx у вас не будет стабильно работать Android новее 11-й версии. И это с учётом образа, в котором отсутствуют Google Play сервисы! Проверено.
Открываем калькулятор
С расчётами же всё довольно просто – чтобы понять, сколько потоков мы с вами сможем потянуть, будем ориентироваться на высчитанные и выстраданные цифры из таблицы на слайде. Обратите внимание, что мы говорим не о физических ядрах процессора, а именно о потоках.
Предположим, если у нас есть типичная двухпроцессорная сборка на недорогих 10-ядерных Xeon Silver, то мы сможем эмулировать на нём сразу шесть устройств одновременно. На более мощном CPU, соответственно, цифры будут отличаться в большую сторону.
У Android есть несколько вариантов дистрибутивов, в этой таблице указано потребление варианта с Google API, без Google Play сервисов. По возможности – выбирайте вариант не с Google Play, а с Google API, если вам не принципиально обратное, например, тестирование In-App-покупок, которое в России сейчас не очень актуально. Образы с Google API работают стабильнее и быстрее, а также едят меньше памяти.
Если же вам принципиален Google Play, то желательно будет докинуть пару гигабайт к результатам нашей таблицы с требованиями.
А если я всё-таки поставлю GPU?
А теперь – вопрос со звёздочкой. Если у вас стоит вопрос, оснащать ли сервер GPU, то отвечу просто – Selenoid не поддерживает проброс GPU в контейнер из коробки. Так что можно со спокойной душой переходить дальше.
Но я, конечно, решил попробовать пойти путём костылей, и в целом замерил прирост производительности Android-образа с использованием GPU и без – в отрыве от Selenoid'a. И вот, что было замечено при тестах:
Конечно, был отмечен двойной прирост в скорости загрузки эмулятора на холодную – то есть, без использования снимка системы. Спойлер: с использованием снимка – отрыв будет гораздо скромнее.
Также по понятным причинам GPU-вариант в целом визуально работает гораздо плавнее и приятнее. Но фактически это не сделает ваши автотесты быстрее – им будет достаточно производительности CPU-варианта для большинства задач. А самое интересное, что используя GPU, мы практически не сможем сэкономить на потоках процессора, хотя казалось бы, что это могло бы сработать. В момент снятия данных эмулятор был максимально нагружен нашем приложением, и итоговые отличия оказались несущественны, что и видно в таблице.
А если у меня уже есть GPU?
Но ваше приложение может вести себя с GPU и по-другому. Например, если мы говорим про сферу Gamedev, или про очень ресурсоёмкие приложения. Поэтому я покажу вам ссылку на инструкцию от NVIDIA, по которой вы можете установить на машину нужные драйвера и саму оснастку, которая позволит прокидывать всё это в контейнер, а затем поэкспериментировать и посмотреть, как ведёт себя образ с поддержкой GPU в отрыве от Selenoid’a.
И если ваши цифры после этого будут явно не похожи на те, что были на предыдущем скриншоте с таблицей, то вы можете попробовать пропатчить Selenoid для поддержки флага GPU. Для этого необходимо немножко шарить в языке Go, а инструкция по билду собственной версии Selenoid’а есть в официальной документации на сайте aerokube.com. Так что если ваши сравнительные результаты будут отличаться от наших – пробуйте. Благо, что задача (по крайней мере со стороны) выглядит весьма тривиальной.
Собираем образ Android
Окей, с ресурсами определились, настало время собрать образы. Изначально всё сделано достаточно просто – скрипт для сборки Docker-образа также лежит в github-репозитории авторов Selenoid – aerokube/images.
Но к сожалению, в последнее время у Google приоритет тестирования образов явно ушел в сторону ARM, и чтобы новые образы под X86 работали из коробки и были стабильными на любой конфигурации, необходимы некоторые ухищрения.
Было замечено, что образы, собранные с поддержкой Vulkan API, который стал принудительно включённым в Emulator SDK примерно с год назад, нестабильно работал на наших машинах вне зависимости от выбора типа аппаратного ускорения. Сколько бы ресурсов мы не дали образу, запущенный эмулятор постоянно сбоил, системный UI крашился – а автотесты, естественно, валились.
Было испробовано множество вещей, но решение проблемы оказалось простое – взять бинарники годовалой давности, и всё пошло как по маслу. Отмечу, что эти версии актуальны именно для работы с Selenoid, на условном домашнем компьютере с GPU сносно будет работать и более новые версии. В конце статьи я прикреплю ссылку на Dockerfile, который поможет собрать вам нужные образы и не переживать по данному поводу.
Также в нашем Dockerfile есть весьма полезная штука, которую можно смело рекомендовать к применению – вынос файла Entrypoint из образа. Entrypoint – это shell-скрипт, к которому обращается Docker, когда запускает образ. И то что вы видите сейчас на скриншоте выше, это, безусловно, неканоничный вариант использования. Но эта штука позволяет конфигурировать эмулятор на лету без необходимости пересобирать образ. Это несколько раз нас здорово выручало – например, когда у нас вводили SSL-bumping, или вдруг понадобилось поменять разрешение дисплея у планшета. Подсвечу два интересных момента.
Первый момент – это использование команды ls перед непосредственным запуском файла. Нужен он для повышения стабильности монтирования папки, как бы это сейчас странно не звучало. Дело в том, что при запуске образа иногда появляется эффект volume’а шредингера – том вроде и примонтировался, но при запуске shell-скрипта, терминал может вам написать, что скрипт не был найден. Эта команда как раз и поправляет такое нестабильное поведение.
Второй момент – мы используем разные entrypoint’ы для каждого из образов для их более гибкой конфигурации. В каждом из них можно настроить индивидуальные параметры запуска эмулятора. А в конце каждого уникального Entrypoint после старта эмулятора запускается уже общий shell-скрипт, где удобно конфигурируются общие параметры. Например, настройки прокси.
Если вы захотите сделать такую же систему, не забудьте указать в browsers.json, что вы хотите смонтировать такую папку в образ. Мы, кстати, таким же образом монтируем и папку, которая называется builds – туда кладутся, к примеру сторонние приложения, которые нужно установить на эмулятор для успешного прохождения тестов. Например браузер с подписями минцифры для успешной авторизации через российские сервисы.
После того, как мы сконфигурировали наши браузеры-андроиды – поговорим о том, как сделать, чтобы всё это работало как часы.
Как мы с вами уже видели, Selenoid имеет приятную утилиту под названием Configuration Manager, но обычно DevOps не любят, когда на машинах крутятся процессы, о которых они не знают. Поэтому мы будем настраивать запуск Selenoid через docker-compose, а бонусом получим автоматический перезапуск Selenoid’а прямо из Docker’а в случае его падения. Пример готового конфига я положу также внизу статьи, а сейчас обращу внимание на вещи, которые в этом конфиге уже присутствуют, но требуют некоторого пояснения.
Например, параметр conf, который передаёт аргументы для запуска Selenoid. Суть такова – Selenoid позволяет устанавливать явные лимиты по использованию процессора и памяти для каждого контейнера, но в случае с Android нам важно положить туда ограничение по CPU, но не указывать ограничение по памяти. Всё дело в том, что из-за особенностей работы с памятью, Android честно старается укладываться в свой указанный лимит, но может кратковременно за него выходить. И вот в этот момент наш Docker может быстренько убить контейнер с ошибкой OutOfMemory, и если сразу не залезть в системные логи, то можно потратить много времени на поиск причин внезапной остановки этого самого контейнера.
Можно, конечно, отключить такой механизм, но делать так лучше не стоит, если ваши ресурсы распределены с не очень большим запасом. Гораздо стабильнее будет выставить ограничение по памяти в самом эмуляторе, добавив в параметры запуска ключ -memory.
Кстати, не лишним будет упомянуть, что при планировании аппетитов эмулятора, нужно будет оставить хотя бы пару гигабайт оперативки под работу родительской операционной системы, иначе в один прекрасный момент память у вас кончится, и в качестве вишенки на торте отвалится SSH, и не факт, что при спаде нагрузки он поднимется обратно.
После того, как вы всё сконфигурировали и проверили, что образ стартует через UI Selenoid’а и ничего теперь не падает, давайте попробуем сократить время запуска образа, на цифрах – примерно раза в четыре. Это довольно простая процедура и мы сейчас с вами её выполним:
Сперва вам потребуется ещё раз запустить образ. Для тех, кто ещё не нагуглил, как можно конфигурировать эмулятор под свои задачи с помощью adb-команд, но очень хочет это сделать – можно попробовать сделать это через режим VNC в Selenoid’e сейчас, на этом этапе. А в материалах внизу я оставлю файлик-шпаргалку, с помощью которой вы впоследствии сможете делать это автоматически.
docker exec –lt $(docker ps -lq) adb emu avd snapshot save fastboot Как только вы всё готово, то вам понадобится на машине, где крутится Selenoid, выполнить команду из второго пункта – запустить внутри последнего запущенного контейнера команду на сохранение состояния эмулятора с названием fastboot - имя выбрано для примера. Сохранение состояния в целом занимает в районе 5-10 секунд, и после этого можно смело сохранять текущие изменения в новый образ:
docker commit <new image name>Далее, как и в случае с ключом -memory с предыдущего слайда, допишите в параметры запуска эмулятора ключ –snapshot, чтобы эмулятор сразу грузился именно с него. Поменяйте или добавьте новый образ рядом с текущим в browsers.json, перезагрузите Selenoid, и можно проверять. Если всё успешно, переходим дальше. И помните, что выполнив эти шаги, вы только что сделали тесты инфраструктурно стабильнее. Потому что вы теперь всегда знаете, в каком состоянии у вас будет находиться эмулятор перед запуском тестов – всегда ровно в том, в котором вы закоммитили образ.
Бонус: корневые SSL-сертификаты
Этот подраздел будет не для всех, но есть ненулевая вероятность, что рано или поздно вы тоже с этим столкнётесь :)
У нас немножко всё обезопасили, и чтобы тесты могли добраться до всего, к чему нужно – нам потребовалось внедрить SSL-сертификаты прямо в эмулятор. Все нужные скрипты я, как обычно, оставлю внизу, а здесь оглашу тезисно, что нужно делать в похожей ситуации. Сначала – про очевидные решения.
Первое – установка сертификатов в родительскую систему вам ничего не даст, так как эмулятор их попросту не увидит. Можно попробовать установить ваши сертификаты в раздел пользовательских, но скорее всего они у вас будут корневые – а значит, что они будут работать, например, в браузере Chrome, но не в вашем приложении – так что этот вариант тоже отпадает. Для того, чтобы прокинуть сертификаты в системные, нужно провернуть пару фокусов, куда же без них.
Справедливости ради отмечу, что эта операция без проблем срабатывает на образах с Google API, так как образы с Google Play даже на эмуляторах ведут себя как обычные нерутованные телефоны с изначально заблокированными правами супер-пользователя, и эти образы дополнительно придётся ещё и рутануть. Оставлю так же ссылочку, как это делается, для тех, кому захочется и кто выбрал себе сложный путь.
А для остальных внизу оставлю shell-скрипт, который будет необходимо положить в after_init.sh. Теперь настало время разобраться, что он делает:
Запускаем эмулятор с ключом -writable-system, чтобы он разрешил надругательства над системным разделом. Убирать этот флаг позже – не нужно
Далее мы получаем права суперпользователя и отключаем модуль верификации AVB
Перезагружаемся и выполняем команду перемонтирования разделов
ℹ️ На этом шаге у нас срабатывает прикольная штука – поскольку из-за алгоритмов защиты файловой системы Android мы всё еще не можем просто скопировать файлы прямо в раздел /system, для нас специально создаётся новый overlay-слой системы, который фактически и монтируется сверху основной. Именно поэтому нельзя убирать флаг из первого пункта, иначе при загрузке система просто проигнорирует этот слойКопируем наши сертификаты в специально предназначенную для этого директорию, но перед этим нужно их правильно назвать
ℹ️ Дело в том, что Android смотрит, как именно у нас называются файлы сертификатов, и если их не назвать так, как показано на скриншоте, они будут проигнорированы. Для упрощения вычисления названия можно выполнить команду со этого же скриншота внизу, и к получившемуся результату приписать расширение .0:И в конце не забудьте выдать права на новые сертификаты.
После этого можно либо закоммитить образ, либо перезагрузиться еще раз – и всё будет работать как надо.
Почему VNC можно, а видео – нельзя
Напоследок расскажу ещё об одной штуке. Люди, начинающие работать с Selenoid, иногда изучают официальную документацию (и это прекрасно!), и замечают там на первый взгляд классные штуки – например, как VNC, который позволяет смотреть за ходом тестов при отладке, да и еще и девайсом управлять. А ещё Selenoid может записывать для вас видео тестовых сессий, которые мы можем потом использовать в отчётах. Звучит круто, но разберемся с этими двумя фичами чуть глубже.
Дело в том, что VNC – это супер-полезная фишка, которую можно применять в различных сценариях, о которых я расскажу в следующем разделе. Из приятного – её включение увеличивает потребление памяти образом в среднем всего на 50 мегабайт, которыми в целом, можно пренебречь.
А вот если вы захотите писать видео тестовых сессий в Selenoid, то во-первых, на каждый контейнер эмулятора у вас будет подниматься аналогичный второй, но для записи видео, а во-вторых, ест эта штука уже приличное количество памяти – более гигабайта на один поднятый контейнер. Так что гораздо экономичнее и проще будет писать видео через Appium Driver – тем более, что в случае с Android, поднимать контейнер для каждого нового теста это довольно дорого по времени, а с Selenoid-решением по записи видео у вас по-умолчанию будет писаться вся тестовая сессия, которую еще нужно будет придумать как нарезать по отчётам. В случае же с Appium-вариантом, просто прикрепите захваченный видеофайл в ваш тестовый отчёт, и дело в шляпе.
Итоги подведём
Выбираем физический сервер вместо VM
6 CPU / 6 RAM = 1 девайс, без GPU
Собираем образ по докерфайлу из материалов статьи внизу
Преднастраиваем образ и ускоряем загрузку (docker commit)
Обязательно укладываем эмулятор в квоты
VNC – можно, видеозапись от Selenoid – не рекомендуется
Что ещё может предложить Selenoid?
Помимо всего, что мы обсудили ранее, можно превратить Selenoid в универсальный инструмент для вашей компании, помимо непосредственно автотестов. Начнём с того, что работает прямо из коробки.
Отлаживаем тесты прямо из IDE
Почему бы нам не использовать возможность отлаживать автотесты на инфраструктуре без необходимости поднимать локальный Appium и эмуляторы? Это довольно прикольная штука, и она просто работает уже сейчас. Указав адрес Selenoid вместо локального, вы можете дебажить тесты в реальном времени именно на том окружении, на котором будут гоняться тесты, просто открыв рядышком Selenoid UI. Это, на самом деле, дорогого стоит – поскольку редко, но всё же иногда поведение приложения на х86 немного отличается от ARM, и к этому вы уже заранее будете готовы.
И точно также можно подключиться к запущенной сессии через Appium Inspector, чтобы смотреть какие элементы у нас сейчас отображаются в приложении – для этого просто подключитесь к запущенной сессии Selenoid с помощью вкладки Attach to Session, после чего вы также сможете работать с инспектором, будто делаете у себя это на локальном компьютере.
Кайф? Да ещё какой!
Selenoid – для ручного тестирования
А вот ещё одна идея. У нас Selenoid использует даже ручное тестирование – как при разборе автотестов, так и бывает, даже демкают новый функционал, если под рукой нет устройства, а показать нужно быстро. Как же это сделано? На самом деле, очень просто.
Для этого была сделана небольшая страничка, реализованную на Flask, на которой можно указать, какой конкретно эмулятор вы хотите поднять, какое приложение на нём запустить, и на какое время вам нужна сессия. Под капотом там всё ровно как в автотестах – Appium-драйвер стучится в Selenoid, и просто возвращает URL сессии, на который мы в итоге и перекидываем пользователя. То есть QA нажимает кнопку запуска, и уже через минуту начинает работать с эмулятором. Также в дополнение я завернул в окно сессии логи приложения и покрасил их согласно приоритетам, поэтому отлаживаться ручным тестировщикам здесь стало даже проще, чем в Android Studio.
Что имеем в итоге
Давайте глобально подведём итоги всей нашей статьи.
Во-первых, сегодня мы с вами убедились, что Selenoid, как инструмент для многопоточных Appium-тестов всё еще хорош даже спустя года. Он быстро работает, ест мало памяти, и изначально очень прост в интеграции с тестами.
Во-вторых, теперь мы знаем, как затащить в Selenoid последние версии Android, и произведя небольшие и простые доработки, мы можем настроить эффективную и стабильную работу автотестов.
Ну и третий пункт, как приятный бонус – теперь мы можем не только отлаживать наши тесты прямо из IDE на конечной инфраструктуре благодаря Selenoid’у, но и использовать его функционал как прикладной инструмент для ручного тестирования, дав возможность ему гонять ваши приложения на эмуляторах, чтобы не поднимать их у себя локально.
Очень надеюсь, что статья вам пригодится, и вы сможете миновать все шероховатости и ямы на дороге к многопоточной автоматизации Appium-тестов :)
