1. Дальнейшее чтение на SmashingMag:
2. Google Nexus
3. Любой телефон для разработчиков
4. Дешевые китайские телефоны с процессором MTK
5. Подготовка телефона к работе
6. Настройка тестовой машины
7. Создание контейнера для телефона
8. Заключение

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

Команда myMail в настоящее время использует около 60 устройств для регрессионного тестирования. В среднем мы тестируем около 20 сборок в день. Приблизительно 600 тестов пользовательского интерфейса и более 3500 юнит-тестов выполняются в каждой сборке. Автоматизированные тесты доступны круглосуточно и позволяют нашим тестерам сэкономить массу времени, помогая нам создавать высококачественные приложения. Без них нам потребовалось бы 36 часов (включая время ожидания) для тестирования каждого устройства, или примерно 13 часов без ожидания. Для запуска автоматического теста требуется около 1,5 часов, включая установку и обновление переводов. Это сокращает недели тестерской работы каждый день.

Если вы пишете автоматизированные тесты и не имеете дела с инфраструктурой, мы пройдем этот процесс с самого начала, от покупки телефона и переустановки прошивки до создания контейнеров Docker с автоматическим тестовым телефоном внутри. Смотреть видео чтобы увидеть результат.

Дальнейшее чтение на SmashingMag:

Какие телефоны лучше всего подходят для автоматизированных тестов Android?

Когда Android только начинал набирать популярность, разработчики тестов должны были выбрать меньшее из двух зол: купить дорогой набор телефонов или работать с медленными и глючными виртуальными устройствами. Сегодня все намного проще, потому что доступны виртуальные машины, такие как Android x86 и HAXM.

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

Рекомендуемое чтение: Где находятся лучшие в мире лаборатории открытых устройств?

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

( Посмотреть большую версию )

Прежде всего, я должен предупредить вас, что мы будем выбирать модель телефона для регрессионных тестов, а не тестов конфигурации. Давайте предположим, что у нас есть много тестов, например от 500 до 1000 тестов приложений, которые занимают 10 часов, и что нам нужно несколько телефонов, чтобы выполнить их за 15 минут. Это звучит немного нелогично - почему бы просто не купить 10-20 разных моделей телефонов? Ответ заключается в трудозатратах на код автоматизации тестирования. В итоге вы бы написали один и тот же тест для разных телефонных интерфейсов. При работе с 20 различными моделями написание хотя бы одного простого теста займет много времени. Но наша нынешняя цель - ускорить выполнение автоматизированных тестов без увеличения трудозатрат программиста, пишущего тесты.

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

• Есть способ получить права root.
• Есть способ разблокировать загрузчик телефона.
• В телефоне имеется Android-версия, близкая к стоковой, либо есть возможность установить ближайшую версию. Это означает, что вам не придется пробовать кучу разных тестов для разных интерфейсов.
• Память телефона составляет не менее 1 ГБ. Вы можете работать с меньшими затратами, но различные проверки отображения больших объектов займут много времени, даже при наличии последовательно написанных тестов.
• В идеале телефон имеет долгосрочную поддержку производителя. Если это так, у нас есть шанс продлить его жизнь с новыми версиями ОС.

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

Например, привилегии root позволяют вам использовать командную строку, чтобы легко изменять время на телефоне, переключаться между сетями Wi-Fi, а также включать и отключать системные программы для имитации работы с ними и без них. Разблокированный загрузочный сектор позволяет пользователям обновлять операционную систему и добавлять пользовательские прошивки, которые продлевают срок службы телефона, даже если производитель прекращает поддержку (что, к сожалению, имеет место в большинстве телефонов, которые у нас сейчас). Было бы грустно, если бы пользователи, работающие на Android 4.4 или Android 6, столкнулись с ошибкой, но ваши телефоны с автоматическими тестами работают на Android 5, поэтому ничего нельзя изменить.

К сожалению, вы не можете спросить продавца о большинстве этих критериев на момент покупки. Вот почему мы должны сначала пойти в Форумы разработчиков XDA а также Форумы 4PDA чтобы найти все детали, которые мы должны знать о модели. Если модель была выпущена некоторое время, обратите внимание на информацию о дефектах, памяти и сроке службы батареи - ваше устройство будет практически бесполезно без них. Не отвлекайтесь на экраны, кнопки, чехлы, динамики и другие функции, обычно важные для пользователя. Телефон будет отлично работать независимо (хотя это зависит от специфики вашего проекта).

Рекомендуемое чтение: The Thumb Zone: проектирование для мобильных пользователей

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

• Модель телефона с большим количеством локальных подтипов. Это проблема, если вы можете получить только привилегии root или разблокировать загрузчик только для некоторых из них. Трудно найти сертифицированный российский телефон в неофициальных магазинах, потому что поддельные и аутентичные телефоны выглядят одинаково. Кроме того, многие продавцы или их поставщики обновляют названия моделей, спецификации оборудования, регионы и даже версии ОС. Вполне возможно увидеть одну модель в настройках Android, другую модель в загрузчике и третью модель в оболочке с использованием getprop и get-ID. Проблема в том, что телефон прошел через несколько рук и регионов, прежде чем добраться до вас. Его первым владельцем был какой-то абонент Verizon из Южной Дакоты. Он возвращает его, и теперь восстановленное устройство каким-то образом оказывается у какого-то продавца в Тель-Авиве, который неумело устанавливает свою локальную версию ОС на аппаратном обеспечении. Затем продавец из Москвы покупает его и снова продает как новый телефон. Курьер доставит его вам, и вы получите ваше новое восстанавливаемое российское устройство с восемью ядрами, не имея ни малейшего представления о том, что вы на самом деле держите устройство с шестью ядрами, привязанное к определенной области, первоначально от клиента сотовой связи США. Информация на изображении выше для дорогого телефона с «текущим» программным обеспечением, которое, согласно его спецификациям, на самом деле является более старой моделью AT & T, которая была обновлена. ( Посмотреть большую версию )
• Идентичные серийные номера Здесь легче идентифицировать проблему, но, к сожалению, это распространено даже среди официальных дилеров. Отсутствие серийного номера является проблемой, связанной со многими недорогими устройствами. Если в ваших автоматических тестах используется Android Debug Bridge (ADB) и к компьютеру подключено несколько устройств, вам нужно либо переписать код ADB (потому что он будет видеть только одно устройство), либо, если покупка была сделана в соответствии с к ранее упомянутым критериям, вручную введите уникальный серийный номер. Типичные серийные номера для недорогих телефонов
• Псевдослучайный MAC-адрес от модуля Wi-Fi после перезапуска телефона. Это была довольно серьезная проблема, потому что мы обнаружили ее только после того, как я был уверен, что «все в порядке» - то есть телефон соответствует нашим требованиям, поэтому мы заказали еще 20. Во время наших автоматических тестов телефоны иногда перезагружались. Через некоторое время тесты начали проваливаться из-за отсутствия подключения к Wi-Fi, хотя казалось, что все работает нормально. Было подключение к сети, и все работало правильно после выключения и включения модуля Wi-Fi. Проблема заключалась в том, что в какой-то момент после перезагрузки пара телефонов в конечном итоге имела одинаковый MAC-адрес, но точка доступа Wi-Fi предоставляла доступ только к последнему. К сожалению, я не смог найти, где на телефонах генерируется MAC-адрес, поэтому мне пришлось поместить скрипт в загрузчик, чтобы принудительно установить уникальный MAC-адрес. Демонстрация подмены из коробки ( Посмотреть большую версию )

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

Итак, какие телефоны вы должны получить, чтобы создать собственную ферму автоматизации тестирования?

Google Nexus

Если у вас есть ресурсы, чтобы купить последние работающие модели Google Nexus (в настоящее время это такие устройства, как Nexus 5X-6P), приобретите их, не задумываясь. На них можно установить практически любую операционную систему, они имеют «чистую» базу Android, и разработчики также склонны использовать их для тестирования своих приложений.

Любой телефон для разработчиков

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

Дешевые китайские телефоны с процессором MTK

Многие телефоны с процессорами MediaTek (MTK) могут быть идеально перепрошиты, и их основным преимуществом является низкая стоимость. Вам нужно будет найти конкретные модели на местном рынке в вашей стране, потому что телефоны, как правило, доступны под разными торговыми марками, в зависимости от местоположения. Настоящими производителями обычно являются крупные компании, такие как Gionee, Lenovo, Inventec, Tinno Mobile, Longcheer и Techain. Эти компании перепродают свои телефоны в западных странах под фирменными знаками, включая Fly, Zopo, Wiko, Micromax, MyPhone, Blu, Walton, Allview и другие. Но не все телефоны подходят: всегда оценивайте их по критериям, перечисленным выше. Фермы с такими телефонами часто могут быть дешевле, чем серверы с виртуальными машинами Android, поэтому здесь есть значительный шанс сэкономить.

В дополнение к телефонам вам понадобятся компьютер и USB-концентраторы для запуска автоматических тестов . Есть некоторые другие вещи, которые следует рассмотреть на данном этапе. Например, постоянно работающим телефонам нужен хороший источник питания (не менее 0,5 А на устройство; чем больше, тем лучше). Большинство концентраторов на рынке поставляются со слабыми адаптерами, не предназначенными для подключения постоянно работающего телефона к каждому порту. Ситуация еще сложнее, когда дело касается планшетов: 9-дюймовые планшеты быстро умирают при непрерывной работе из-за большого энергопотребления экрана, поэтому нам приходится выбирать среди 7-дюймовых устройств. По нашему опыту, к адаптеру 4А можно подключить от шести до семи телефонов (в зависимости от их рабочей нагрузки). Следовательно, большинство многопортовых концентраторов с «адаптером 3A и 20 портами USB», мягко говоря, бесполезны. Кремом урожая являются серверные решения, но они безумно дороги. Итак, нам придется ограничиться потребительским рынком. Чтобы телефон работал, вы должны получить концентраторы на 3 порта с четырьмя портами или концентраторы на четыре порта с шестью портами. Если концентратор имеет хороший источник питания и большое количество портов, некоторые порты могут просто не использоваться.

Подготовка телефона к работе

Давайте рассмотрим одну модель телефона в качестве примера. Мы решим проблему с ОС, а затем попробуем собрать несколько устройств на одном простом стенде для автоматизации тестирования. Сам телефон недорогой и приличного качества, но не без собственных недостатков (описано выше). Например, эти телефоны имеют одинаковую iSerial, поэтому ADB видит только одно устройство, даже если подключено несколько устройств. Мы не будем менять его везде на телефоне, но мы дадим возможность АБР различать телефоны.

Для этого нам необходимо перепрошить загрузчик телефона и установить на телефоне пользовательский раздел восстановления. Это для того, чтобы защитить себя от любых неудачных экспериментов. Инструкции по прошивке вашей конкретной модели телефона можно найти в Форумы разработчиков XDA , На наших телефонах установлен MT6580, который является процессором MTK, поэтому мы можем использовать SP Flash Tool, а также recovery.img и устройства с файлами разброса файлов. Их можно найти в сети практически для любого устройства в XDA Developers и 4PDA, но при желании можно скомпилировать восстановление для вашего устройства. используя TWRP в качестве основы и создавая скаттер файл самостоятельно , В любом случае, мы просто возьмем наши файлы и переустановим их:

( Посмотреть большую версию )

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

Чтобы жестко закодировать ваш iSerial, вам необходимо распаковать образ загрузчика телефона. Это можно сделать через Android Image Kitchen , Запустите unpackimg.sh и получите распакованный образ в папке ramdisk:

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

Давайте найдем файл с серийным номером $ {ro.serialno и заменим его собственным номером - например, 999222333019:

find ramdisk / -maxdepth 1 -name «init.mt *» -exec sed -i 's / $ {ro.serialno} / 999222333019 / g' {} +

Теперь давайте запакуем образ обратно с помощью repacking.sh, перенесем его на телефон и установим с помощью кастомного рекавери. Теперь АБР может различать устройства. Все, что нам нужно сделать сейчас, это включить режим разработчика на телефоне и включить отладку в меню разработчика. Любые подобные проблемы могут быть решены точно так же. Практически все на телефоне может быть переустановлено, если этого требуют тесты.

Настройка тестовой машины

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

Для этого для каждого телефона рекомендуется создать изолированную виртуальную среду, которую мы можем изменить в случае необходимости (например, установить другие версии Java Development Kit или настроить мониторинг), не изменяя среды других телефонов. В результате наша машина будет разделена на несколько сред, каждая из которых доступна через один телефон (или группу телефонов, в зависимости от ваших требований). Мы можем создать эти среды, создав несколько виртуальных машин на хосте (это можно сделать в любой операционной системе). Или вы можете делать то, что мне нравится: делить телефоны с помощью контейнеров Docker, которые лучше всего работают в Linux. Мы будем использовать обычный рабочий стол с Ubuntu в качестве примера хоста для нашего стенда.

При заказе или сборке машин, к которым будут подключены телефоны, необходимо учитывать некоторые особенности. Помимо стандартных характеристик жесткого диска, ОЗУ и ЦП, обратите внимание на количество контроллеров USB на материнской плате и поддерживаемый протокол USB. Телефоны, использующие USB 3.0 (xHCI), могут значительно ограничить максимальное количество устройств, подключенных к машине (обычно 8 на контроллер или 16 устройств для машины с 2 контроллерами), поэтому стоит проверить, можно ли отключить его и использовать только EHCI. Вы найдете эти опции в BIOS или ОС. Лучше всего принудительно отключить xHCI в BIOS, если вам не нужны высокоскоростные устройства.

Создание контейнера для телефона

Как я писал ранее, мы хотим, чтобы slave-agent системы интеграции работал с конкретным телефоном и видел только этот телефон. Таким образом, тесты не будут случайно запускаться на других телефонах и выдают ложные результаты или ошибки. Чтобы достичь этого, мы должны разделить их. Когда агент системы интеграции запускается в контейнере Docker, каждый агент имеет доступ только к одному устройству, поэтому мы можем разделить задачи в системе интеграции по конкретным моделям телефонов, версиям операционной системы, размерам экрана и другим характеристикам (например, контейнер с планшет может выполнять тесты, требующие широкого экрана, а контейнер с телефоном может выполнять тесты, требующие возможности получать текстовые сообщения).

Давайте рассмотрим пример установки и настройки системы в Ubuntu. Вот установка самого Docker:

sudo apt-key adv --keyserver hkp: //p80.pool.sks-keyservers.net: 80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D echo 'deb https://apt.Dockerproject.org/repo main' >> / etc / apt / sources.list.d / Docker.list sudo apt-get update sudo apt-get установить Docker-engine

Мы собираемся использовать OverlayFS в качестве драйвера хранилища (это относительно быстро и надежно). Вы можете прочитать о различия между различными драйверами хранилища на официальном сайте Docker.

echo 'DOCKER_OPTS = "- оверлей s" ">> / etc / default / Docker

Затем мы создадим Dockerfile, который является инструкцией для Docker по установке минимально необходимого программного обеспечения для виртуальной среды, где мобильное устройство будет изолировано. Мы создадим изображения из этой инструкции. Давайте добавим Android SDK в Dockerfile:

ИЗ ubuntu: trusty # Обновите список репозиториев и добавьте репозиторий webupd8team, из которого мы установим Java RUN apt-get update -y && \ apt-get install -y software-properties-common && \ add-apt-repository ppa : webupd8team / java -y && \ apt-get update -y && \ echo oracle-java8-installer расшарен / принят-оракул-лицензия-v1-1 выбрать true | / usr / bin / debconf-set-selections && \ apt-get install -y oracle-java8-installer && \ apt-get удалить общие свойства программного обеспечения -y && \ apt-get autoremove -y && \ apt-get clean # Установить переменные окружения для Java и желаемой версии Ant ENV JAVA_HOME / usr / lib / jvm / java-8-oracle ENV ANT_VERSION 1.9.4 # Установить версию Ant, указанную выше, RUN cd && \ wget -q http: // archive .apache.org / dist / ant / binaries / apache-ant - $ {ANT_VERSION} -bin.tar.gz && \ tar -xzf apache-ant - $ {ANT_VERSION} -bin.tar.gz && \ mv apache-ant - $ {ANT_VERSION} / opt / ant && \ rm apache-ant - $ {ANT_VERSION} -bin.tar.gz # Установить переменную среды для Ant ENV ANT_HOME / opt / ant ENV PATH $ {PATH}: / opt / ant / bin # Установить инструменты сборки Android и требуемую версию Android SDK # Вы можете создать несколько версий Dockerfile, если вам нужно протестировать #several версии ENV ANDROID_SDK_VERSION r24.4.1 ENV ANDROID_BUILD_TOOLS_VERSION 23.0.3 RUN dpkg --add-архитектура i386 && \ apt-get update -y && \ apt-get install -y libc6: i386 li bncurses5: i386 libstdc ++ 6: i386 lib32z1 && \ rm -rf / var / lib / apt / lists / * && \ apt-get autoremove -y && \ apt-get clean ENV ANDROID_SDK_FILENAME android-sdk _ $ {ANDROID_SDK_VERS} .tgz ENV ANDROID_SDK_URL http://dl.google.com/android/$ndomANDROID_SDK_FILENAME} ENV ANDROID_API_LEVELS android-15, android-16, android-17, android-18, android-19, android-20, android-21, android-22, android-23 ENV ANDROID_HOME / opt / android-sdk-linux ENV PATH $ {PATH}: $ {ANDROID_HOME} / tools: $ {ANDROID_HOME} / инструменты платформы RUN cd / opt && \ wget -q $ { ANDROID_SDK_URL} && \ tar -xzf $ {ANDROID_SDK_FILENAME} && \ rm $ {ANDROID_SDK_FILENAME} && \ echo y | android update sdk --no-ui -a --фильтровать инструменты, инструменты платформы, $ {ANDROID_API_LEVELS}, инструменты сборки - $ {ANDROID_BUILD_TOOLS_VERSION} ### Теперь добавьте системный файл интеграции. Это может быть раб Дженкинс, агент Бамбук и т. Д., В зависимости от того, с чем вы работаете. ДОБАВИТЬ moyagent.sh / agentCI /

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

Докер сборка.

Теперь у нас есть работающий образ докера; однако контейнер, который мы из него породили, не будет видеть никаких устройств (или, наоборот, контейнер будет видеть все USB-устройства, если мы запустим его в привилегированном режиме). Нам это нужно, чтобы видеть только те устройства, которые мы хотим, чтобы это видели. Итак, мы указываем символическую ссылку (или символическую ссылку) на нашем хосте, которую мы передадим в контейнер Docker, созданный из образа. Символическая ссылка использует udev:

echo '"SUBSYSTEM ==" usb ", ATTRS {serial} ==" $ DEVICE_SERIAL ", SYMLINK + =" androidDevice1 "' >> /etc/udev/rules.d/90-usb-symlink-phones.rules

Вместо $ DEVICE_SERIAL мы вводим наш недавно установленный серийный номер и перезагружаем определения правил устройства:

управление udevadm - перезагрузить триггер udevadm

Теперь, когда телефон подключен через USB, у нас будет символическая ссылка устройства на путь / dev / androidDevice1 с серийным номером $ DEVICE_SERIAL. Все, что нам осталось сделать, это перенести его в контейнер при запуске:

Docker запускает -i -t --rm --device = / dev / androidDevice1: / dev / bus / usb / 001/1 android-Docker-image: последние устройства adb

Это означает, что мы хотим создать контейнер из образа Android Docker, который должен иметь доступ к устройству по символической ссылке / dev / androidDevice1. Мы также хотим запустить команду ADB devices в самом контейнере, который покажет нам список доступных устройств.

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

Docker запускает -i -t --rm --device = / dev / androidDevice1: / dev / bus / usb / 001/1 android-Docker-образ: последний / bin / sh /agentCI/moyagent.sh

Теперь мы запустили контейнер, в котором работает агент системной интеграции. Теперь агент имеет доступ к устройству по символической ссылке / dev / androidDevice1 и к виртуальной среде, в которой установлены все программы, указанные в Dockerfile (Android SDK и дополнительные зависимости).

Кстати, до недавнего времени опция командной строки –device начала работать с символическими ссылками (см. GitHub мастер ветка ). Ранее нам приходилось генерировать реальный путь из символических ссылок с помощью скрипта и передавать его в Docker. Итак, если вам не удается подключить устройство, добавьте следующий скрипт в параметр udev RUN + = (если подключенный телефон находится в / dev / bus / usb / 010/1):

realpath / dev / androidDevice1 | xargs -I linkpath linkpath link / dev / bus / usb / 010/1

Это позволит вам использовать старые версии Docker для запуска контейнера, который может получить доступ к телефону:

Запуск Docker --privileged -v / dev / bus / usb / 010 /: / dev / bus / usb / 100 / -i -t android-Docker-image: последние устройства adb

Вот и все. Теперь вы можете подключить подчиненное устройство к системе интеграции и работать с ней.

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

docker run -i -t --rm --device = / dev / androidDevice1: / dev / bus / usb / 001/1 android-docker-image: последние / bin / sh /agentCI/moyagent.sh

Теперь мы запустили наш контейнер с агентом системной интеграции, запущенным в нем. Устройство доступно для агента через символическую ссылку / dev / androidDevice1, а также через виртуальную среду, в которую вы установили программы из нашего Dockerfile (Android SDK и другие зависимости). Запущенный агент должен подключиться к вашему серверу (например, Bamboo или Jenkins), с которого вы можете дать ему команды для выполнения автоматических тестов.

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

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

Заключение

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

Подумайте о преимуществах и посмотрите, что будет лучше для вас - в вашей автоматизированной системе тестирования почти наверняка есть место для физических устройств. Желаю всем вам меньше ошибок и больше тестового покрытия! Реальные устройства имеют как преимущества, так и недостатки. Было бы здорово, если бы вы поделились своим мнением и опытом и сказали нам, что лучше использовать: реальные устройства или виртуальные машины. Ждем ваших комментариев!

Похожие

Комментарии