SavePearlHarbor

Selenoid: Запускаем Appium UI-тесты на iOS. Часть 2

—

от автора

admin

В первой части статьи мы рассказали, как легко и быстро построить инфраструктуру для запуска UI-тестов на Android с помощью Appium и Selenoid. Продолжаем историю и рассказываем, как внедрили в схему запуск UI-тестов на iOS.

Масштабируемся с GGR

Максимальное количество параллельных потоков в пределах хоста ограничено его ресурсами. Поэтому нам понадобился инструмент для объединения нескольких хостов в один кластер. Для этого мы используем Go Grid Router (GGR) от ребят из Aerokube. Согласно описанию из документации, GGR — балансировщик нагрузки, используемый для создания масштабируемых и высокодоступных кластеров Selenium.

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

Развернуть GGR и GGR UI несложно:

  • Устанавливаем Docker.

  • Создаём каталог для файлов конфигурации GGR mkdir -p /etc/grid-router/quota.

  • Создаём файл users.htpasswd $ htpasswd -bc /etc/grid-router/users.htpasswd test test-password.

  • Создаём файл с квотами, где в качестве хоста указываем адрес развёрнутого Selenoid:

$ cat /etc/grid-router/quota/test.xml <qa:browsers xmlns:qa="urn:config.gridrouter.qatools.ru"> <browser name="android" defaultVersion="10.0" defaultPlatform="android">   <version number="10.0">     <region name="1">       <host name="0.0.0.0" port="4444" count="1"/>     </region>   </version> </browser> </qa:browsers>

  • Запускаем контейнер с GGR:

docker run -d \   --name ggr \   -v /etc/grid-router/:/etc/grid-router:ro \   --net host aerokube/ggr:latest-release \   -listen=:4445 -guests-allowed

  • В проекте тестов меняем порт Appium на порт запущенного GGR:

val driver = AndroidDriver(URL("http://localhost:4445/wd/hub"), capabilities)

  • Запускаем контейнер с GGR UI:

docker run -d \   --name ggr_ui \   -p 8888:8888 \   -v /etc/grid-router/quota:/etc/grid-router/quota:ro \   aerokube/ggr-ui:latest-release

  • Запускаем контейнер с Selenoid UI, где вselenoid-uri передаём порт GGR UI:

docker run -d \   --name selenoid-ui \   -p 4446:4446 \   --link selenoid:selenoid \   aerokube/selenoid-ui:1.10.4 \   --selenoid-uri "<http://ggr-ui:8888>"

Теперь наш Selenoid UI должен отображать состояние всех Selenoid-кластеров, подключенных к GGR.

Приступаем к запуску тестов на iOS

Для запуска UI-тестов на iOS мы используем собственную ферму Mac mini. Таким же образом ферму можно собрать из списанных рабочих макбуков или взять их в аренду. На каждый хост необходимо установить:

  • Appium (для работы с iOS≥16 необходимо использовать Appium 2.x).

  • Xcode.

Первые проблемы

Мы не могли повторить структуру, используемую при запуске Android-тестов, так как не нашли способ запускать iOS-симуляторы в Docker-контейнерах. Рассматривали вариант запуска Docker-OSX, но возникли сомнения по легальности его использования для целей, не связанных с OS X Security Research. Мы решили пойти другим путём.

Итерация 1: GGR→Appium

Добавили Appium (порт 4723) в качестве хоста Selenoid для iOS-тестов в ранее созданный конфиг GGR:

<qa:browsers xmlns:qa="urn:config.gridrouter.qatools.ru"> <browser name="android" defaultVersion="10.0" defaultPlatform="android">   <version number="10.0">     <region name="1">       <host name="0.0.0.0" port="4444" count="1"/>     </region>   </version> </browser> <browser name="iPhone 14" defaultVersion="16.2" defaultPlatform="iOS">   <version number="16.2">     <region name="1">       <host name="0.0.0.0" port="4723" count="1"/>     </region>   </version> </browser> </qa:browsers>

Схема iOS-части в таком случае выглядит следующим образом:

Используемая в итерации структура работоспособна. Проблема в том, что в данном случае мы можем запускать тесты только в одном потоке на каждом Mac mini, что расточительно. Также кластер не будет отображаться в Selenoid UI.

Итерация 2: GGR→Selenoid→Appium

Selenoid позволяет работать не только с контейнерами. В связи с вышеуказанными проблемами мы решили использовать Selenoid и с iOS-тестами, но в виде исполняемого файла:

  • Скачиваем Selenoid (amd64/arm64).

  • Создаём файл конфигурации browsers.json.

  • В конфигурации указываем Appium и параметры запуска:

{   "iPhone 14": {     "default": "16.2",     "versions": {       "16.2": {         "image": ["appium", "--log-timestamp", "--log-no-colors", ...]       }     }   } }

  • Предоставим разрешение на исполнение файла Selenoid. В нашем случае мы использовали chmod 755.

  • Запускаем Selenoid через терминал. Мы использовали следующие параметры: selenoid -conf ~/browsers.json -disable-docker -capture-driver-logs -service-startup-timeout 4m -session-attempt-timeout 4m -timeout 6m -limit 2.

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

    • Параметром -limit установили максимальное количество запускаемых симуляторов. На это значение в дальнейшем будет опираться GGR. При выставлении параметра опираемся на производительность хоста.

    • Подробнее о параметрах запуска можно почитать в документации Selenoid.

  • При необходимости на каждом Mac mini можно создать PLIST-файл для автозагрузки Selenoid на случай внезапного перезапуска системы.

Схема работы кластера теперь выглядит так:

При таком подходе мы частично получаем функциональность Selenoid UI и возможность запускать тесты в несколько потоков на одном хосте.

Недостатком является то, что на каждом Mac mini надо вручную проделывать много рутинных манипуляций по созданию симулятора и привязыванию его к Appium через указание UUID и назначение портов. Это может стать проблемой, когда в дальнейшем появится необходимость перехода на новую версию iOS.

Итерация 3: GGR→Selenoid→Bash→Appium

У нас крупная ферма Mac mini, которая будет продолжать расти. Поэтому мы искали способ облегчить масштабирование, чтобы не создавать руками симуляторы и прибивать их к Appium. В прошлой схеме у Appium и симуляторов было бы длительное время жизни, что могло повлечь непредсказуемые последствия.

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

{   "iPhone 14": {     "default": "16.2",     "versions": {       "16.2": {         "image": ["~/bin/config/start_appium.sh", "iPhone 14"]       }     }   } }

Так он выглядит у нас:

#!/bin/bash  set -ex  DEVICE_NAME=$1 APPIUM_PORT=$(echo $2 | cut -d '=' -f 2)  function clean() {   if [ -n "$APPIUM_PID" ]; then       kill -TERM "$APPIUM_PID"   fi   if [ -n "$DEVICE_UDID" ]; then       xcrun simctl delete $DEVICE_UDID   fi }  trap clean SIGINT SIGTERM  # Каждый симулятор имеет udid, поэтому чтобы запустить одинаковые устройства параллельно - клонируем и запускаем # только клоны. Нельзя клонировать запущенное устройство. После закрытия сессии удаляем клон. cloned_device_name="[APPIUM] ${DEVICE_NAME} ($(date +%Y%m%d%H%M%S))" DEVICE_UDID=$(xcrun simctl clone "$DEVICE_NAME" "$cloned_device_name")  # https://github.com/appium/appium-xcuitest-driver#important-simulator-capabilities WDA_LOCAL_PORT=$(($APPIUM_PORT+1000)) MJPEG_SERVER_PORT=$(($WDA_LOCAL_PORT+1000)) DEFAULT_CAPABILITIES='"appium:udid":"'$DEVICE_UDID'","appium:automationName":"'XCUITest'","appium:wdaLocalPort":"'$WDA_LOCAL_PORT'","appium:mjpegServerPort":"'$MJPEG_SERVER_PORT'"'  appium --base-path=/wd/hub --port=$APPIUM_PORT --log-timestamp --log-no-colors --allow-insecure=get_server_logs,adb_shell \        --allow-cors --log-timestamp --log {choose_directory_for_logs} \        --default-capabilities "{$DEFAULT_CAPABILITIES}" & APPIUM_PID=$!  wait

В случае использования скрипта обратите внимание на объявленные capabilities и параметры запуска Appium. Здесь они указаны с учётом запуска Appium 2.x — для Appium 1.x не требуется указание вендора в capabilities и нет возможности указать —base-pat.

Скрипт решает проблемы параллельного запуска симуляторов:

  • Когда мы напрямую подключаем к GGR несколько аппиумов с одного Mac mini, возникает проблема с эмуляторами — нельзя запустить один и тот же эмулятор с одинаковыми UDID. Надо каждый раз вручную дублировать и зашивать/хардкодить UDID. Например, в случае необходимости изменения версии iOS или модели симулятора.

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

Использование Selenoid позволяет упростить это до одного скрипта, который не создаёт конфликтов между несколькими парами Appium + Simulator в пределах одного хоста. Он запускает Appium и убивает его при получении соответствующего сигнала от Selenoid, а также динамически клонирует симуляторы при запуске и удаляет их после завершения сессии.

Получили такую схему:

Далее добавляем адреса Selenoid каждого Mac mini в файл конфигурации развёрнутого GGR, объединяя Android- и iOS-структуры:

Итог

Собранная инфраструктура позволяет прогонять на 36 потоках около 500 UI-тестов в час суммарно на обеих платформах. Добавление нового хоста для Android-тестов полностью автоматизировано с помощью воркфлоу на GitHub Actions и занимает около двух минут. В ближайших планах автоматизировать развёртывание Selenoid-кластера и на Mac mini.

В дальнейшем хочется попробовать запускать контейнеры Docker-OSX на Mac mini с Linux, чтобы унифицировать все процессы и облегчить развертывание на них, не нарушая при этом правила использования macOS. Возможно, у вас есть такой опыт — будем рады, если вы поделитесь им в комментариях.


ссылка на оригинал статьи https://habr.com/ru/articles/732226/

Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *