Создание автотестов на Android – дело сложное. Дабы правильно построить процесс автотестирования, необходимо планировать и анализировать множество задач.
Но наибольшая сложность заключается в том, что в сети пока нет детализированного описания того, что конкретно включает в себя процесс автотестирования под систему Android, какие его базовые стадии и прочее. Цельной картины просто нет.
Но, перед тем как проанализировать имеющееся ПО и методики его применения, необходимо разобраться, зачем вообще нужны автотесты?
В чем актуальность автотестов?
Бытует мнение, что UI-тесты уже не актуальны, если на проекте достаточная сумма юнит-тестов и интеграционных проверок. Но вот от следующей метафоры никак уйти не получится.
Давайте вообразим, что мы – конструкторы велосипеда. Мы имеем 2 прекрасно протестированных колеса, качественно проверенную раму, седло и руль. Если говорить терминологией QA, у нас есть набор юнит-тестов и группа интеграционных проверок.
Вопрос, а поедет ли теперь наш велосипед? Чтобы ответить на этот вопрос, нам необходимо привлечь группу мануальных тестировщиков. Перед каждым следующим релизом они должны самостоятельно убедиться в том, что идеальные детали качественно взаимодействуют друг с другом, и наш велосипед будет двигаться корректно, доставляя владельцу истинное удовольствие.
Что-то подобное можно наблюдать и в плане программного обеспечения для тестирования мобильных приложений. Очень жаль, но в современном мобильном мире уже нет возможности быстро отменить неудачное редактирование, так как все версии идут через платформы App Store / Google Play.
Следовательно, это сразу же автоматически накладывает определенные ограничения в виде длительной раскатки по сравнению с десктопными веб-продуктами. Поэтому очень важно всегда перед финальными релизами мобильного ПО убеждаться в том, что базовые пользовательские сценарии функционируют именно так, как было оговорено изначально.
Правильный подбор инструментов для написания мобильных автотестов
Необходимо изначально определить единственно верный стек технологий, которые нужно использовать для создания группы автотестов.
Первая развилка – выбор между кроссплатформенными решениями и нативными. На просторах Интернета уже много раз люди спорили, что нужно выбирать, а что уже не дает необходимого результата. Но мы склоняемся более к нативным решениям, ведь они:
- Более стабильные;
- Быстрые;
- Качественно интегрированы в IDE;
- Не содержат слоев, которые могут вносить нестабильности, и заставляют содержать широкие технические знания.
Кроме того, Google поддерживает Espresso и UI Automator. Только на Espresso сейчас мало кто пишет тесты. Программисты за последнее время разработали массу удобных решений, которые могут решать насущные задачи.
Как итог, сегодня в сети можно встретить массу полезных фреймворков и программ, которые делают мобильное тестирование на Android простым и понятным. К ним и обратимся.
Логотип Kaspresso
Kaspresso
Данный фреймворк полезем тем, что:
- С его помощью можно оперировать DSL, который существенным образом облегчает создание автотестов;
- Он предоставляет многоуровневую защиту от нестабильных тестов (англ. flaky test);
- Существенным образом ускоряет функционирование UI Automator;
- Предоставляет пользователю полные логи того, что конкретно происходит при выполнении определенного теста;
- Дает возможность пользователю запускать любые ADB-команды внутри теста;
- Предоставляет описание лучших практик по созданию автотестов.
Test Runner
Итак, допустим у нас есть несколько тестов. Теперь появляется задача по их запуску. За данную стадию отвечает система выполнения тестов (англ. test runner).
Ищем решения в Google. Можно воспользоваться утилитой AndroidJUnitRunner и ее особым режимом – Orchestrator. Утилита просто делает то, что от нее требуется: запускает набор автотестов, позволяя выполнять проверки на параллельной основе.
С помощью Orchestrator можно продолжить выполнение тестов, даже если в части из них произошел сбой. Также этот режим дает возможность свести к минимуму общее техническое состояние между стартовавшими тестами. Подобным образом достигается общая изоляция выполнения каждого теста.
Спустя некоторое время, к системе выполнения тестов выдвигается все больше и больше требований. Например:
- Выполнять запуск отдельных групп тестов;
- Запускать автотесты на определенных мобильных платформах или устройствах;
- Показывать итоги выполнения теста;
- Сохранять историю тестирований для будущего анализа;
- Интегрировать тесты с определенной локальной инфраструктурой.
Сейчас в сети есть много систем выполнения тестов. Среди всех наиболее востребованным в последнее время считается Marathon, который способен максимально удовлетворить часть расписанных выше требований. К примеру, данный инструмент может поддерживать распараллеливание проверок и подготовку итогов прогона в форме, которую можно отобразить в Allure.
Но, к сожалению, Marathon не обладает такими качествами, как:
- Простая интеграция раннера с технической инфраструктурой, которая может выдавать эмуляторы;
- Плотная интеграция с фреймворками (к примеру, Kaspresso) для получения максимально точных данных касательно теста.
Более того, бытует мнение, что система выполнения тестов должна быть платформенной, как под Android, так и под iOS.
Подобное обусловлено оригинальной спецификой каждой мобильной операционной системы, а также вытекающей отсюда критичностью внесения изменений внутрь системы выполнения тестов.
Чем запускать автотесты?
Ответ на данный вопрос можно разделить на три составные части:
- Реальные устройства. С плюсов можно отметить тот факт, что использование настоящих устройств позволит найти проблемы, специфичные для конкретных гаджетов и прошивки. Порой бывает очень полезно проверить, что разрабатываемое приложение корректно работает на том устройстве, где вы его просматриваете.
Из минусов – постоянно нужно находить где-то множество устройств, создавать особые помещения под них. Кроме того, некоторые тесты могут изменить состояние устройства, а быстро вернуться от сломанной до последней стабильной версии не всегда получится. - Чистый эмулятор. Он быстрее и гораздо стабильнее реального устройства. Разработка нового эмулятора занимает не более пары минут.
Из негативного можно отметить ограниченное количество тестовых сценариев, которые будут завязаны на специфику конкретного устройства, и не все из них будут высокоприоритетными.
Но самый большой минус – это низкий процент масштабируемости. Банальная задача, загрузить новую версию эмулятора на определенный хост, является сама по себе проблемной. - Docker-версия Android-эмулятора. Docker и раскатка образа эмулятора — это отличное полноценное масштабируемое решение, с помощью которого можно быстро создавать эмуляторы и раскатывать их на хосты, достигая достаточной изолированности. Однако, здесь есть и один недостаток – максимально высокий входной порог.
Взаимодействие с инфраструктурой
Представим, что мы создали несколько сотен UI-тестов. Это большое количество, но они должны проходить очень быстро (допустим, максимум за 20 минут). Вот тут дело доходит до реального масштабирования.
Данная сфера – незнакомая область для некоторой части Android-разработчиков и для сообщества автоматизаторов. Это неудивительно, учитывая тот факт, что подобная инфраструктура требует первоклассных знаний оборудования, конфигурации функционирования серверов, а также DevOps-практик. А значит, обязательно нужно настроить правильные контакты с людьми, которые в этом сильны. Это могут быть как привлеченные специалисты извне, так и специально обученные сотрудники внутри вашего офиса.
Если вкратце, вот что вам предстоит сделать:
- Выбрать между облачными и локальными решениями, при условии, что в компании есть персонализированная инфраструктура по старту тестов для разных платформ.
- Развернуть всю внутреннюю инфраструктуру с самого начала. При такой работе нужно заручиться качественным и проверенным оборудованием, которое будет выдерживать максимально допустимое количество включаемых вами автотестов. Придется анализировать работу нескольких одновременно запущенных эмуляторов и следить за стабильностью тестов.
- В конце нужно обязательно оперировать каким-то сервисом, который отдает вам эмуляторы. Это может быть, к примеру, Kubemetes – облачное решение по типу Google Cloud Engine, либо же кастомное решение.
- Союз полученного сервиса с Test Runner.
Краткий итог
В завершении хотим отметить, что не стоит забывать о:
- Выводе отчета после выполнения тестов;
- Выполнении синхронизации с TMS;
- Интегрировании в CI/CD;
- Обучении программистов и тестировщиков методикам создания и проверки таких автотестов;
- Фиксации процессов создания, изменения и использования мобильных автотестов.
Во всем вышеизложенном мы попытались максимально полно описать базовые стадии становления процесса автотестирования под мобильную платформу Android. Очень сильно верим в то, что после прочтения данного материала у читателя сложится исключительно корректное представление данной ситуации в целом.
Оставить комментарий