Введение

В данной статье я постараюсь описать пример инфраструктуры для автотестов Android приложений (mobile automation), а именно, среду для проведения тестранов UI автотестов на эмуляторе Android девайса в виртуальной среде.

Требования:

Для Android эмулятора нужна поддержка Intel Virtualization Technology или AMD Virtualization. Поэтому часто тестировщик сталкивается с необходимостью запуска тестранов только в нативной среде ПК с прямым доступом к центральному процессору.

В этом случае схема получается такая:

Трудности:

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

  2. Среда не создаётся перед проведением тестирования, и после проведения не удаляется, поэтому среда может влиять на тестируемое приложение.

  3. Починка и настройка среды занимает много времени.

Предлагаемое решение в данной статье:

  1. Создать VM с использованием возможностей nested virtualization VirtualBox (более подробное описание технологии в этой статье).

  2. Пробросить поддержку Intel-VT или KVM внутрь созданной виртуальной машины.

  3. Изнутри VM создать и запустить Android эмулятор девайса.

  4. Провести тестран UI тестов приложения.

  5. После проведения тестирования уничтожить VM.

В этом случае схема получится такая:

Предполагаемые преимущества:

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

  2. Уменьшится время поддержки среды и управляющего ПО, так как не нужно каждый раз руками ничего устанавливать и чинить неисправности инвайронмента.

В настоящей статье будет использоваться оборудование:

  • процеcсор: Intel i5-1035G1

  • память: 12Gb

  • в BIOS включена поддержка виртуализации процессора

  • OC: Ubuntu 20.4

Шаг 1: Установка ПО на нативную OS

Отдельно обращу внимание на управление машиной. Будем использовать протокол VNC для создания удобного удаленного рабочего стола. Протокол универсальный, для Linux, Windows, Mac и т.д.

x11vnc сервер

Установка:

sudo apt-get update #обновляем пакеты
sudo apt install x11vnc #устанавливаем x11vnc
sudo x11vnc -storepasswd <вводим пароль сервера> /etc/x11vnc.pass #создаём пароль в файлике
sudo chmod ugo+r /etc/x11vnc.pass #разрешаем использовать файлик с паролем

Запуск с параметрами:

x11vnc -nevershared -forever -dontdisconnect -many -noxfixes -rfbauth /etc/x11vnc.pass

Установка VirtualBox

Вводим в командной строке:

sudo apt-get update
sudo apt install gcc make linux-headers-$(uname -r) dkms
wget -q https://www.virtualbox.org/download/oracle_vbox_2016.asc -O- | sudo apt-key add -
wget -q https://www.virtualbox.org/download/oracle_vbox.asc -O- | sudo apt-key add -
sudo sh -c 'echo "deb http://download.virtualbox.org/virtualbox/debian $(lsb_release -sc) contrib" >> /etc/apt/sources.list.d/virtualbox.list'
sudo apt update #обновляем репозиторий
sudo apt install virtualbox-6.1

Создание VM

Мы пойдем по самому простому пути и создадим VM из интерфейса VirtualBox с такими характеристиками. В дальнейшем создание VM будет code-first

  • Количество CPU - не больше половины имеющихся на Вашем процессоре (в идеале половина)

  • Оперативная память - будет достаточно 4Gb

Nested Virtualization можно также включить из командной строки:

VBoxManage modifyvm <Имя VM> --nested-hw-virt on

Далее переходим в саму VM.

Шаг 2: Установка ПО на VM

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

Устанавливаем последний образ Ubuntu с официального сайта.

Установка KVM

egrep -c '(vmx|svm)' /proc/cpuinfo #Если в результате будет возвращено 0 - значит Ваш процессор не поддерживает аппаратной виртуализации, если 1 или больше - то вы можете использовать KVM на своей машине
sudo apt-get update #Обновляем пакеты
sudo apt install qemu qemu-kvm libvirt-daemon libvirt-clients bridge-utils virt-manager #Установка KVM и сопроводительные либы
sudo usermod -G libvirt -a ubuntu #Добавление пользователя ubuntu в группу libvirt
sudo systemctl status libvirtd #Проверка запуска сервиса libvirt
sudo kvm-ok #Проверка статуса KVM

Установка Android command line tools

sudo apt-get update #обновляем пакеты
yes | sudo apt install android-sdk #устанавливаем Android SDK
sudo apt install unzip #Устанавливаем unzip для распаковки архивов
cd ~/Downloads #переходим в каталог Downloads
wget https://dl.google.com/android/repository/commandlinetools-linux-6858069_latest.zip #скачиваем архив с command line tools с официального сайта Google
sudo unzip commandlinetools-linux-6858069_latest.zip -d /usr/lib/android-sdk/cmdline-tools/ #распаковываем
sudo mv /usr/lib/android-sdk/cmdline-tools/cmdline-tools /usr/lib/android-sdk/cmdline-tools/tools #переименовываем каталог с тулами. Сейчас странная ситуация, Google раздаёт тулу с одним каталогом, а SDK ищет его в другом каталоге
export ANDROID_SDK_ROOT=/usr/lib/android-sdk #регистируем переменную
export PATH=$PATH:$ANDROID_SDK_ROOT/cmdline-tools/latest/bin:$ANDROID_SDK_ROOT/cmdline-tools/tools/bin #регистрируем новый Path
export PATH=$PATH:$ANDROID_SDK_ROOT/emulator #регистируем новый Path

Проверяем, что sdkmanager работает и Android SDK доступен:

sdkmanager --version

Устанавливаем Android tools

yes | sdkmanager --licenses #принимаем лицензии
sudo chown $USER:$USER $ANDROID_SDK_ROOT -R #Ставим для текущего юзера право менять содержимое папки с ANDROID_SDK_ROOT
yes | sdkmanager "cmdline-tools;latest" #устанавливаем cmdline-tools
sdkmanager "build-tools;30.0.3" #Устанавливаем build-tools
sdkmanager "platform-tools" #Устанавливаем platform-tools
sdkmanager "platforms;android-30"
sdkmanager "sources;android-30"
sdkmanager "emulator" #Устанавливаем AVD manager
emulator -accel-check #Проверяем, есть ли поддержка виртуализации
yes | sdkmanager "system-images;android-23;google_apis;x86_64" #Устанавливаем образ для эмулятора
sdkmanager --list #Выводим список установленных пакетов. Обычно для CI оставляю.
no | avdmanager create avd -n android-23_google_apis_x86_64 -k "system-images;android-23;google_apis;x86_64" #создаём эмулятор из образа
emulator -list-avds #проверяем наличие созданного эмулятора

Устанавливаем Git и клонируем проект

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

sudo apt update #обновляем пакеты
yes | sudo apt install git #установка Git
git --version #проверка установки
mkdir ~/workspace #создаём каталог для проектов
cd ~/workspace #переходим в каталог для проектов
git clone https://github.com/panarik/AndroidClearApp.git #клонируем проект на локал
cd ~/workspace/AndroidClearApp #переходим в каталог проекта

Шаг 3: Проведение тестирования проекта на созданном Android эмуляторе

./gradlew assembleDebug --no-daemon #билдим APK
emulator -avd android-23_google_apis_x86_64 -no-audio -no-window -verbose -gpu off -accel off #запускаем эмулятор из ранее созданных
sleep 240 #аналог будильника, ждём четыре минуты пока загрузится эмулятор
adb get-state #проверяем, видит ли ADB запущенный эмулятор. Если нет, то ждем еще

ADB видит подключенный к нему эмулятор:

Запускаем тестран:

./gradlew connectedAndroidTest --no-daemon

Ура! Тест пройден!

Негативный тест

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

Подготовка:

  • Переустановка VirtualBox на родительской машине (чтобы избежать ошибочное сохранение конфигов)

sudo apt purge virtualbox-6.1

  • VM мы создаём без проброса виртуализации и с одним CPU:

  • В созданной VM мы не устанавливаем:

    • VBoxClient

    • KVM

Остальные шаги аналогичны шагу №2 с установкой ПО. Попробуем еще раз наш тестран. Обратите внимание, что ADB также видит эмулятор:

Ура! Тест не пройден! Никогда еще так не радовался проваленному тестрану:

Падает PackageManager, как и обычно при запуске из виртуальной среды без аппаратной поддержки процессора:

Заключение

Мы сделали первый этап построения инфраструктуры для проведения автотестов Android приложений. Следующим этапом должно стать упаковка описанного выше сценария в Packer (ссылка на официальный сайт) который умеет работать с образами VirtualBox. Затем весь сценарий мы попробуем запустить из CI Jenkins. Если учесть, что плагин для него уже порядком устарел, то будет очень интересно.

Все результаты опубликую, как пополнения к этой статье.

В идеале, у нас должна получится code-first инфраструктура для тестрана UI и интеграционных автотестов для Android приложений, которую можно поднять на любом современном офисном ПК, которая работает автономно, билдит тесты на родных Android эмуляторах и есть не просит.

Спасибо большое за внимание!

П.С.

Можно Вас в комментариях попросить привести пример Вашей инфраструктуры с использованием Android эмулятора? К примеру, эмуляторы в докер-контейнерах (https://github.com/budtmo/docker-android) может быть еще какие-нибудь интересные примеры.