Автотесты На Android. Вся Картина

Всем привет! Автотесты для Android — дело непростое.

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

Но самая большая проблема в том, что нигде нет полного описания того, что вообще включает в себя автотестирование для Android, каковы его основные этапы.

Вся картина отсутствует. Этой статьей мы хотим восполнить этот пробел.

Он также будет служить схематическим планом работы.

Проект Авокадо .

Мы считаем, что в ближайшем будущем внедрение автоматизированного тестирования будет занимать гораздо меньше времени, чем сейчас.

И мы активно работаем в этом направлении.

Зачем нужны автотесты?

Но никуда не деться от следующей метафоры.

Представьте, что вы собираете велосипед. У вас есть два проверенных колеса, проверенная рама с седлом, проверенная педальная система с цепью и рулем.

То есть у нас есть хороший набор интеграционных и модульных тестов.

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

То же самое и с любым программным обеспечением для мобильных телефонов.

К сожалению, в мобильном мире мы не можем быстро откатить неудачные изменения, потому что все обновления производятся через Google Play Store и App Store, что сразу накладывает ограничения в виде долгого развертывания по сравнению с веб- и бэкенд-аналогами, обязательной совместимости версий.

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

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

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

Все это естественным образом приводит к необходимости автоматизации тестирования пользовательских скриптов, то есть написания сквозных или автотестов.

На Авито есть история о том, как Автотесты помогают и сколько они стоят (2019) .

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

Это возвращает нас к цели данной статьи и в целом к одной из целей Проекта Авокадо — стандартизировать процесс автотестирования в Android и существенно снизить его стоимость.

Вся картина

Если вы чего-то не понимаете, не волнуйтесь.

Сейчас мы подробно разберем все пункты.

Процесс написания теста

Выбор инструментов для написания автотестов

Первый форк — это выбор между кроссплатформенным решением (Appium и т. д.) и нативным решением (Espresso, UI Automator).

В этих спорах было сломано много копий.

Рекомендуем посмотреть выступление наших коллег , полный драмы и страсти.

Спойлер: мы за нативные решения.

По нашему опыту, это:

• более стабильный;
• Быстрее;
• лучше интегрируется в IDE;
• не содержат слоев, которые вносят нестабильность и заставляют обладать сверхширокими экспертными знаниями.

• Аппиум против эспрессо: ключевые различия .

• Appium или Espresso: какой фреймворк использовать для автоматического тестирования Android .

• Appium против Espresso: самая популярная среда автоматизации тестирования в 2019 году .

Сейчас мы готовим статью об этих инструментах с классификацией и сравнением.

Короче говоря, платформа, на которую мы полагаемся, — это Kaspresso.

Каспрессо

• предоставляет DSL, который значительно упрощает написание автоматических тестов;
• обеспечивает встроенную многоуровневую защиту от флек-тестов;
• ускоряет работу UI Automator;
• предоставляет полные логи о том, что происходит в тесте;
• дает возможность запускать любые команды ADB внутри тестов;
• предоставляет механизм перехвата для перехвата всех действий и проверок.

  Этот механизм используется для логирования и защиты от нестабильных тестов;

• описывает лучшие практики (основанные на нашем опыте) написания автоматических тестов.

Тестовый бегун

Теперь их нужно запустить.

За этот этап отвечает Test Runner, или просто бегун.

Что нам предлагает Google? Утилита AndroidJUnitRunner и ее специальный режим — Orchestrator. AndroidJUnitRunner делает то, что от него требуется — он просто запускает тесты, позволяя им выполняться параллельно.

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

Это обеспечивает изоляцию выполнения каждого теста.

Но со временем требований к бегуну становится все больше.

Вот некоторые из них:

• запускать отдельные группы тестов;
• запускать тесты только на определенных устройствах;
• перезапустить проваленные тесты (вторая волна защиты от последствий нестабильных тестов после Kaspresso);
• эффективно распределять тесты между устройствами, учитывая историю запусков и успешность предыдущих запусков;
• готовить отчеты о пробегах в различных форматах;
• отображение результатов пробежки (желательно на базе Allure);
• сохранять историю запусков для дальнейшего анализа;
• легко интегрируется с вашей инфраструктурой.

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

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

В частности, он не содержит:

• Простая и нативная интеграция раннера с инфраструктурой, производящей эмуляторы.

  Еще лучше — возможность сразу запускать тесты в облаке.

  Однако это проблема не только Марафона — к сожалению, ни один известный нам бегун не берет на себя ответственность за получение эмуляторов; это всегда ложится на плечи разработчиков.

• Тесная интеграция с такими фреймворками, как Kaspresso, для получения максимальной, точной и корректной информации о тесте.

Поэтому прямо сейчас мы работаем над Avito Runner, в котором хотим собрать все самые лучшие и проверенные разработки и идеи.

Следите за будущими объявлениями!

На чем проводить тесты

1. Настоящее устройство.

   плюсы .

   Покажет проблемы, характерные для конкретных устройств и прошивок.

   Многие производители меняют Android под себя — как пользовательский интерфейс, так и логику работы ОС.

   И может быть полезно проверить, корректно ли работает ваше приложение в такой среде.

   Минусы .

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

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

2. Чистый эмулятор.

   Под «чистым» мы подразумеваем, что вы запускаете эмулятор самостоятельно или где-то на машине с помощью AVD Manager, установленного на этой машине.

   плюсы .

   Быстрее, удобнее и стабильнее, чем настоящее устройство.

   Создание нового эмулятора занимает всего несколько минут. Никаких проблем с отдельной комнатой, батареями и т.д. Минусы .

   Отсутствие вышеперечисленных особенностей устройства.

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

   Но главный недостаток — плохая масштабируемость.

   Простая задача загрузить на все хосты новую версию эмулятора превращается в пытку.

3. Docker-образ эмулятора Android. Docker решает недостатки чистых эмуляторов.

   плюсы .

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

   Минусы .

   Более высокий порог входа.

• Docker-образ с Авито ;
• Docker-образ от Google ;
• Изображение Docker от Agoda .

Плюс часто возникает желание предварительно настроить эмулятор: отключить анимацию, войти в свой аккаунт Google, отключить Google Play Protect и многое другое.

Все эти вещи непросто организовать.

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

Инфраструктура

Некоторые из них вы хотите запустить в рамках PR, а это значит, что весь набор тестов должен быть выполнен за максимально короткое время, например, до 20 минут. Вот тут-то и происходит настоящее масштабирование.

Однако эта область — темный лес для некоторых разработчиков Android и инженеров по автоматизации.

Это неудивительно, ведь инфраструктура требует знаний об оборудовании, конфигурации серверов, методах DevOps и т. д. Поэтому обязательно наладьте контакты с людьми, которые во всем этом разбираются, в вашей компании или за ее пределами, ведь они вам очень помогут и защитят от ошибок.

Итак, примерно то, что вы имеете перед собой:

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

• Самая трудоемкая часть — развертывание внутренней инфраструктуры с нуля.

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

  Вам придется измерять нагрузку на CPU/GPU/Память/Диск, а также пробовать разное количество одновременно работающих эмуляторов и следить за стабильностью тестов.

  Это большая тема, по которой мы хотим провести современные замеры и поделиться с вами своими рекомендациями.

  Дальнейшая разработка необходимого программного обеспечения, интеграция в сети и т. д. — это все зависит от DevOps-инженеров.

• На выходе должен быть какой-то сервис, единая точка, предоставляющая вам эмуляторы.

  Это может быть Kubernetes, облачный сервис, такой как Google Cloud Engine, или какое-то специальное решение.

  DevOps-инженеры снова помогают в настройке.

• Связывание полученного сервиса с Test Runner. Одна из целей Avito Runner — сделать такое подключение максимально простым и прозрачным, а также предоставить точки расширения, которые помогут вам легко реализовать свой индивидуальный сервис.

Отдых

• вывод отчета о тестовом запуске (Allure);
• внедрение/синхронизация с TMS;
• интеграция в CI/CD;
• обучение разработчиков и тестировщиков;
• процессы - кто пишет, когда, сколько и какие автотесты.

Заключение

Следите за объявлениями на нашем сайте И в телеграм-канале .

Теги: #Разработка для Android #Разработка мобильных приложений #Тестирование мобильных приложений #тестирование #ci/cd #разработка для Android #инструменты тестирования #avito #автоматизация тестирования #инфраструктура #инфраструктура как код #разработка мобильных устройств #анализ воздействия #инструменты #kaspersky #тестирование инфраструктуры # бегун

• Сертификация Microsoft: Ваша Карьера Ждет!

  19 Oct, 24

• Онлайн-Опросы За Деньги: Как Найти И Заполнить Лучшие Опросы

  19 Oct, 24

• Мы Создаем Динамические Веб-Сайты С Использованием Php, Mysql, Javascript, Css И Html5. 3-Е Изд.

  19 Oct, 24

• Как Выбрать 1 Миллион Записей Из Базы Данных, Записать Их В Excel И Не Вылететь С Outofmemoryerror

  19 Oct, 24

• Второй День Sef В Минске

  19 Oct, 24

• Recaller — Программа Для Тех, Кто Много Перезванивает

  19 Oct, 24

• Сравнение Производительности C++ И C#

  19 Oct, 24

• До Свидания, Хабр

  19 Oct, 24

• У Нас Не Было Денег, Поэтому Нам Пришлось Подумать

  19 Oct, 24

• Социальные Сети Превращают Работников Порталов В Журналистов

  19 Oct, 24