[Разработка мобильных приложений, Разработка под Android, Тестирование мобильных приложений] Автотесты на Android. Картина целиком

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

Автор

Сообщение

news_bot ^®

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

news_bot ^® написал(а)
20-Авг-2020 12:37

Цитировать

Всем привет!
Автотесты под Android — это непросто. Чтобы выстроить процесс автотестирования, надо запланировать и решить множество задач. Но самая большая беда заключается в том, что нигде нет полного описания, что вообще включает в себя автотестирование под Android, каковы его основные стадии. Отсутствует цельная картина. Этой статьей мы хотим восполнить пробел.
Она также выступит в роли схематичной дорожной карты работы Avokado Project. Мы верим в то, что в скором времени разворачивание автотестирования будет занимать куда меньше времени, чем сейчас. И активно работаем в этом направлении.

Зачем нужны автотесты?
Есть мнение, что UI-тесты не нужны, если у вас достаточное количество юнит- и интеграционных тестов. Но от следующей метафоры никуда не деться. Представьте, что вы собираете велосипед. У вас есть два хорошо протестированных колеса, протестированная рама вместе с седлом, протестированная система педалей с цепью и рулем. То есть мы с вами имеем хороший набор интеграционных и юнит-тестов. А велосипед-то в итоге поедет? Чтобы это проверить, вы нанимаете ручных тестировщиков, которые перед каждым релизом должны убедиться, что безупречные детали корректно взаимодействуют друг с другом, и велосипед будет ездить и доставлять пользователю удовольствие.
Так же и с любым программным обеспечением для мобилок. К сожалению, в мобильном мире мы не можем откатить неудачные изменения быстро, ведь все обновления идут через Google Play Store и App Store, что сразу накладывает ограничения в виде долгой раскатки в сравнении с веб- и backend-аналогами, обязательной совместимости версий и зависимости от решения пользователя обновляться или нет. Поэтому нам критически важно всегда убеждаться перед релизом, что основные пользовательские сценарии приложения работают именно так, как ожидается.
При этом, когда релизный цикл у вас длиной в несколько месяцев, вполне достаточно работы ручных тестировщиков и некоторого покрытия кода юнит- и интеграционными тестами. Однако во времена, когда релизный цикл стремительно сокращается до одной-двух недель (а то и еще меньше), сил ручных тестировщиков зачастую уже не хватает, что вынуждает или жертвовать качеством проверки, или нанимать больше специалистов.
Все это естественным образом подводит к необходимости автоматизации проверки пользовательских сценариев, то есть написания end-to-end- или автотестов. У «Авито» есть рассказ о том, как автотесты помогают и сколько они стоят (2019 год). Однако большинство команд такой метод отпугивает своей сложностью и необходимостью вкладывать существенные ресурсы, чтобы выстроить процесс. Это возвращает нас к цели данной статьи и вообще к одной из целей Avokado Project — стандартизировать процесс автотестирования в Android и существенно уменьшить его стоимость.
Картина целиком
Итак, обещанная картина целиком.

оригинал
Если вы чего-то не понимаете, не переживайте. Мы сейчас пройдемся подробно по всем пунктам.
Процесс написания тестов
На первом шаге давайте попробуем написать тесты у себя на машине и запустить их локально.
Выбор инструментов для написания автотестов
Стоит сразу определиться со стеком технологий, который мы будем использовать для написания тестов.
Первая развилка — это выбор между кроссплатформенным решением (Appium и т. д.) и нативным решением (Espresso, UI Automator). Много копий сломано в этих спорах. Рекомендуем посмотреть выступление наших коллег, полное драматизма и накала страстей.
Спойлер — мы за нативные решения. По нашему опыту, они:

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

Кроме того, Google поддерживает Espresso и UI Automator.
Больше почитать про сравнение вы можете в статьях:

На чистом Espresso и UIAutomator нынче редко кто пишет. Разработчики сделали различные удобные обертки, которые решают их проблемы. Сейчас у нас готовится статья об этих инструментах с классификацией и сравнением. Если кратко, то фреймворк, на который мы делаем ставку, это Kaspresso.
Kaspresso
Kaspresso — это фреймворк, который:

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

Вы можете прочитать о Kaspresso на GitHub и Habr.
Test runner
Вы написали несколько тестов. Теперь их нужно запустить. За этот этап отвечает Test Runner, или просто раннер.
Что нам предлагает Google? Утилиту AndroidJUnitRunner и ее специальный режим — Orchestrator. AndroidJUnitRunner делает то, что от него и требуется — просто запускает тесты, позволяя еще и параллелить их выполнение. Orchestrator позволяет продолжить выполнение тестов, даже если некоторые из них упали, и дает возможность минимизировать общее состояние между тестами. Так достигается изоляция исполнения каждого теста.
Но со временем требований к раннеру становится все больше. Вот некоторые из них:

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

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

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

Кроме того, мы считаем, что раннер должен быть проприетарным, то есть либо для Android, либо для iOS. Это обусловлено уникальной спецификой каждой ОС и вытекающей отсюда сложностью внесения изменений в раннер.
Поэтому прямо сейчас мы работаем над Avito Runner, в котором хотим собрать все лучшие и зарекомендовавшие себя наработки и идеи. Ждите будущих анонсов!
На чем запускать тесты
Параллельно с вопросом о том, какой раннер выбрать для тестов, перед вами встает другой: а на чем лучше запускать тесты? Есть три опции:

Настоящий девайс.
Плюсы. Покажет проблемы, специфичные для конкретных устройств и прошивок. Многие производители меняют Android под себя — как UI, так и логику работы ОС. И бывает полезно проверить, что ваше приложение корректно работает в таком окружении.
Минусы. Необходимо где-то добыть ферму устройств, организовать специальное помещение под них — необходима низкая температура, нежелательно попадание прямых солнечных лучей и т. д. Кроме того, аккумуляторы имеют свойство вздуваться и выходить из строя. А еще сами тесты могут менять состояние устройства, и вы не можете просто взять и откатиться на какой-то стабильный снепшот.
Чистый эмулятор.
Под «чистым» мы подразумеваем, что вы запускаете эмулятор у себя или где-то на машине, используя установленный на эту машину AVD Manager.
Плюсы. Быстрее, удобнее и стабильнее настоящего устройства. Создание нового эмулятора занимает считаные минуты. Никаких проблем с отдельным помещением, аккумуляторами и прочим.
Минусы. Отсутствие упомянутых выше device specifics. Однако зачастую количество тестовых сценариев, завязанных на специфику устройства, ничтожно мало, и они не высокоприоритетные. Но самый главный минус — это плохая масштабируемость. Простая задача залить новую версию эмулятора на все хосты превращается в мучение.
Docker-образ Android-эмулятора.
Docker решает недостатки чистых эмуляторов.
Плюсы. Docker и соответствующая обвязка в виде подготовки и раскатки образа эмулятора — это полноценное масштабируемое решение, позволяющее быстро и качественно готовить эмуляторы и раскатывать их на все хосты, обеспечивая их достаточную изолированность.
Минусы. Более высокий входной порог.

Мы делаем ставку на Docker.
В сети есть разные Docker-образы Android-эмуляторов, мы рекомендуем обратить внимание на следующие:

Как уже было упомянуто выше, подготовка образа требует некоторой сноровки. Плюс зачастую есть желание эмулятор преднастроить: выключить анимацию, залогиниться в аккаунт Google, выключить Google Play Protect и многое другое. Все эти вещи непросто организовать. Поэтому в скором времени мы хотим выкатить подробную документацию о том, как готовить и использовать образы быстро.
Инфраструктура
Вы написали сотни UI-тестов. Часть из них вы хотите запускать в рамках PR, а значит, весь тестовый набор должен проходить в максимально короткие сроки, например, до 20 минут. Вот тут наступает настоящее масштабирование.
Однако эта область — темный лес для части Android-разработчиков и автоматизаторов. Оно и немудрено, ведь инфраструктура требует знаний железа, конфигурирования серверов, DevOps-практик и прочего. Поэтому обязательно наладьте контакты с людьми, которые во всем этом разбираются, у себя в компании или вовне, ведь они сильно помогут и уберегут вас от ошибок.
Итак, что вам примерно предстоит:

Выбор между облачным решением, локальным решением с нуля и локальным решением на базе чего-то, если в компании есть своя инфраструктура по запуску тестов других платформ.
Самое трудоемкое — это развертывание внутренней инфраструктуры с нуля. В этом случае необходимо подобрать железо, которое будет максимально использоваться автотестами. Придется измерять нагрузку на CPU/GPU/Memory/Disk, а еще пробовать разное количество одновременно запущенных эмуляторов и смотреть за стабильностью тестов. Это большая тема, по которой мы хотим провести современные замеры и поделиться с вами своими рекомендациями.
Дальнейшая накатка необходимого ПО, встраивание в сети и прочее — это все за DevOps-инженерами.
На выходе должен быть какой-то сервис, единая точка, которая отдает вам эмуляторы. Это может быть Kubernetes, может быть облачный сервис типа Google Cloud Engine или какое-то кастомное решение.
В его настройке опять-таки помогают DevOps-инженеры.
Связка полученного сервиса с Test Runner.
Одна из задач AvitoRunner — сделать такую связку максимально простой и прозрачной, а также предоставить точки расширения, которые помогут вам легко внедрить свой кастомный сервис.

В ближайшее время мы планируем выпустить AvitoRunner и статьи, которые помогут настроить инфраструктуру.
Остальное
Не забывайте про такие немаловажные моменты, как:

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

Про все это мы еще обязательно поговорим.
Заключение
Мы постарались описать основные части становления автотестирования под Android. Надеемся, что теперь у вас в головах сложится тот самый пазл, который позволит видеть картину целиком.
Следите за анонсами на нашем сайте и в телеграм-канале.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_razrabotka_mobilnyh_prilozhenij (Разработка мобильных приложений), #_razrabotka_pod_android (Разработка под Android), #_testirovanie_mobilnyh_prilozhenij (Тестирование мобильных приложений), #_android_development, #_testing, #_testing_tools, #_infrastructure, #_infrastructure_as_code, #_infrastructure_testing, #_tools, #_mobile_development, #_ci/cd, #_impact_analysis, #_avito, #_kaspersky, #_runner, #_test_automation, [url=https://torrents-local.xyz/search.php?nm=%23_blog_kompanii_«laboratorija_kasperskogo»&to=0&allw=0&o=1&s=0&f%5B%5D=820&f%5B%5D=959&f%5B%5D=958&f%5B%5D=872&f%5B%5D=967&f%5B%5D=954&f%5B%5D=885&f%5B%5D=882&f%5B%5D=863&f%5B%5D=881&f%5B%5D=860&f%5B%5D=884&f%5B%5D=865&f%5B%5D=873&f%5B%5D=861&f%5B%5D=864&f%5B%5D=883&f%5B%5D=957&f%5B%5D=859&f%5B%5D=966&f%5B%5D=956&f%5B%5D=955]#_blog_kompanii_«laboratorija_kasperskogo» (
Блог компании «Лаборатория Касперского»
)[/url], #_blog_kompanii_avito (
Блог компании Авито
), #_razrabotka_mobilnyh_prilozhenij (
Разработка мобильных приложений
), #_razrabotka_pod_android (
Разработка под Android
), #_testirovanie_mobilnyh_prilozhenij (
Тестирование мобильных приложений
)

Профиль ЛС

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

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

Текущее время: 22-Ноя 23:21
Часовой пояс: UTC + 5