[Тестирование IT-систем, Разработка мобильных приложений, IT-инфраструктура, Разработка под Android, DevOps] VirtualBox — Запуск Android эмулятора в виртуальной среде для тестирования Android проекта

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 2 месяца
Сообщений: 27286

news_bot ^® написал(а)
19-Дек-2020 07:30

Цитировать

ВведениеВ данной статье я постараюсь описать пример инфраструктуры для автотестов Android приложений (mobile automation), а именно, среду для проведения тестранов UI автотестов на эмуляторе Android девайса в виртуальной среде.Требования:Для Android эмулятора нужна поддержка Intel Virtualization Technology или AMD Virtualization. Поэтому часто тестировщик сталкивается с необходимостью запуска тестранов только в нативной среде ПК с прямым доступом к центральному процессору. В этом случае схема получается такая:

Трудности:

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

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

Создать VM с использованием возможностей nested virtualization VirtualBox (более подробное описание технологии в этой статье).
Пробросить поддержку Intel-VT или KVM внутрь созданной виртуальной машины.
Изнутри VM создать и запустить Android эмулятор девайса.
Провести тестран UI тестов приложения.
После проведения тестирования уничтожить VM.

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

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

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

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

проце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) может быть еще какие-нибудь интересные примеры.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_testirovanie_itsistem (Тестирование IT-систем), #_razrabotka_mobilnyh_prilozhenij (Разработка мобильных приложений), #_itinfrastruktura (IT-инфраструктура), #_razrabotka_pod_android (Разработка под Android), #_devops, #_testirovanie (тестирование), #_virtualbox, #_android_sdk, #_emulator, #_linux, #_vnc, #_testing, #_qa, #_testirovanie_itsistem (
Тестирование IT-систем
), #_razrabotka_mobilnyh_prilozhenij (
Разработка мобильных приложений
), #_itinfrastruktura (
IT-инфраструктура
), #_razrabotka_pod_android (
Разработка под Android
), #_devops

Профиль ЛС

Ответить на тему

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

Текущее время: 30-Апр 15:24
Часовой пояс: UTC + 5