Home

Автор: Евгений Мацюк

Всем привет!

Меня зовут Женя, и я люблю автотесты. Причем люблю так сильно, что даже стал соавтором Kaspresso, OpenSource библиотеки для написания автотестов под Android, и автором ряда докладов и статей про тесты (Kaspresso: фреймворк для автотестирования, который вы ждали, Автотесты на Android. Картина целиком, Kaspresso tutorials. Часть 1. Запуск первого теста, Дмитрий Мовчан, Евгений Мацюк — Как начать писать автотесты и не сойти с ума). Также со мной полюбил автотесты и мой товарищ, Сергей Ярцев, который является CTO в HintEd, и также вынужден трогать автотесты, причем под разные платформы.

В одной из своих статей (Автотесты на Android. Картина целиком) я описывал, что вообще в себя включают Автотесты под Android. Если кратко, то я выделял 4 большие области: Процесс написания автотестов, Runner, Инфраструктура и Остальное, которое включало в себя отчеты, интеграцию с CI/CD и тд. В свое время (2019-2020) когда мы делали Kaspresso, мы закрывали боль с написанием автотестов. Теперь разработчики и тестировщики могут писать красивый и понятный DSL и не думать про проблемы с флаканием, логами, скоростью и тд. По другим же областям были некоторые решения, но команды, выстраивающие весь процесс, должны были сами со всем этим разбираться и все это стыковать. Особенно больно было с Инфраструктурой, где приходится нырять в дивный мир DevOps и частично даже Highload.

Недавно мне стало интересно, а как сейчас обстоят дела у разных команд с автотестами. Для этого мы с Сергеем провели ряд интервью с более, чем 30 разными командами. Да, это далеко не вся выборка, и данное исследование точно не претендует на абсолютную истину. Но 30 больше, чем 1 или 2 или 5, и поэтому исследование точно может наводить на кое-какие мысли.

Исследование

Итак, что за команды мы опрашивали. Большая часть команд находится в России, но мы также охватили команды из Европы, США и Австралии. Мы пообщались с такими компаниями, как Spotify, Revolut, Badoo, Авто.ру, Sber, HH и другие. У всех есть UI тесты в том или ином виде. Причем количество тестов достаточно сильно варьируется:

Только у 1/3 UI тестов больше 1000. Рекордсмены - 11000 тестов.

Интересно было понять, кто как соблюдает пирамиду тестирования. Напомним, что пирамида здорового человека - это когда Unit-тестов примерно 80% от общего количества, а E2E (они же UI обычно) - около 5%:

У 75% наших респондентов пирамида правильная или почти правильная. У 25% что-то пошло не совсем так (количество E2E превышает количество Unit тестов), но называть мы их, конечно же, не будем, это будет наш маленький секрет.

Следующим вопросом было, на какой наиболее ранней стадии команды запускают UI тесты. Причем тесты могут быть не все (какой-то определенный набор или набор после impact анализа) и могут быть на замокированных данных. Картина следующая:

Более половины делает это на PR, еще четверть на регулярных ночных билдах. Как мы видим, практика запуска тестов только перед релизом, по сути, ушла в прошлое. Также хотим отметить, что более половины всех респондентов использует замокированные данные. По опыту, обеспечить стабильность тестов, тем более на PR, без мокирования практически нереально.

Как обстоят дела со средним временем прогона UI тестов на PR? Предлагаем взглянуть на график ниже:

Я не раз встречал утверждение, что разработчики готовы ждать результатов прогона не более 15 минут. В противном случае они переключаются на другие задачи, и текущий PR подвисает. К сожалению, у меня нет каких-то исследований на этот счет. Но если отталкиваться от цифры 15 минут, то многим командам есть еще куда расти. Масштабируемость инфраструктуры - наше все. Стоит также отметить, что время прогона тестов не на PR (ночные прогоны, прогоны после вливания ветки) уже не так критично, и там встречаются цифры 2-3 и более часов.

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

Более половины респондентов ограничиваются только 5 эмуляторами. Добавлю, что практически все, у кого в параллель запускается 1 тест, не гоняют тесты на PR. Ну, оно и понятно, тут все упирается в инфраструктуру.

Далее мы поспрашивали команды про используемые технологии (в ответах команды могли выбирать несколько пунктов, поэтому сумма процентов легко может быть 146%):

Как мы видим из опросов, православный набор инструментов православного разработчика - это Kaspresso (почти на первом месте) + Marathon + Allure. Высокий процент использования Espresso и UI Automator скорее объясняется периодической необходимостью что-то “докрутить” под себя плюс некоторым процентов кастомных решений, базирующихся на нативных инструментах (Espresso и UI Automator).

Кто как организовывает инфраструктуру? Тут результаты довольно интересны:

Почти четверть респондентов используют одну локальную машину. Также в лидерах Local Service (несколько серверов, которые оркестрируются Kubernetes или чем-то подобным) и Firebase TestLab. Также люди используют AWS, Google Cloud, OpenStf, билд-агенты и тд.

Далее, хотелось немного посмотреть на процессы, а именно, кто отвечает за “написание и поддержку тестов” и “инфраструктуру тестов”:

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

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

И одним из последних вопросов было, что команды используют или хотели бы использовать для улучшения автотестов (перфоманс, возможности, удобство и тд.). Далее привожу список, отсортированный по популярности:

• Test Validity Gate. Это когда новый тест прогоняется 5-10, а может и больше раз для определения того, является он флекающим или нет. В случае, если все прогоны зеленые, то тест принимается в сьют.

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

• Network mock/proxy. Мокирование или проксирование запросов в сеть для приложения или вообще для девайса полностью. Сюда также относятся вопросы корректной записи моков и их обновления. К данному разделу относятся такие технологии, как MockWebServer, MitmProxy, Charles и тд.

• Screenshot diff. Дифф успешного и зафейленного теста. Позволяет сразу понять, что именно отличается в UI.

• Hot Docker images. “Прогретые” докер-образы эмуляторов. Позволяют существенно экономить время на старте. Кстати “прогретым” может быть и приложение (пройденный логин или еще что-то).

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

Выводы

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

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

90% опрошенных нами команд используют нативные тесты. Однако, мы не можем утверждать, есть ли тенденция к бОльшему использованию нативных тестов в сравнении с кроссплатформенными решениями.

Те, кто только начинает выстраивать автотесты у себя, очень довольны Kaspresso, так как Kaspresso позволяет избегать много боли. Это абсолютно честное мнение без какой-либо доли предвзятости с моей стороны =). Команды же, которые вложили много ресурсов в свои решения, базирующиеся на Espresso и UI Automator, в конечном счете, или доводили свои решения до какого-то приемлемого вида, или постепенно переезжали на другие решения типа Kaspresso, но с оставлением части тестов, написанных на Espresso и UI Automator.

Runner + Отчеты

Нативные решения типа AndroidJUnitRunner и Orchestrator по-прежнему популярны. Но если вы хотите что-то лучше, то весь выбор сводится по сути только к одному инструменту - Marathon, который активно развивается и по сей день. Единственный “минус” или особенность Marathon - это то, что он никак не покрывает инфраструктурную часть в отличии от, например, Flank, который умеет работать с Firebase TestLab (правда, только с ним и умеет).

По отчетам русскоязычная аудитория почти повсеместно использует Allure. Что-то лучше Allure на рынке, честно говоря, не видно.

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

Команды, которые давно в деле, выстроили кастомную систему на основе своих серверов, самостоятельно их оркестрируя и поддерживая.

Но в остальном, ситуация с инфраструктурой остается довольно грустной. На рынке так и не наблюдается простого, кастомизируемого и масштабируемого решения. Этим объясняется, что 23% опрошенных гоняют тесты на одной локальной машине. Да, есть Firebase TestLab, но он хорошо подходит для малого количества относительно простых тестов. Когда же тестов становится много, то хочется иметь репорты качественнее, параллелизацию из коробки, просмотр истории с аналитикой, возможность кастомизировать докер-образы (настроить прокси, например) и многое другое. Все это придется как-то настраивать самому. Слышал еще про вот такое решение - emulator.wtf, но ничего не знаю про успешное применение.

Из интересного хочу отметить появление TestWise, который мы с Сергеем консультируем. В следующей статье мы хотим провести сравнение всех этих сервисов.

Процессы

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

Заключение

На этом мы бы хотели попрощаться. Пишите в комментарии ваши вопросы и мысли, с удовольствием подискутируем!

Обсудить в форуме