Home

Автор: Виталий Никоноров
Оригинальная публикация

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

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

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

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

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

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

Структура проекта, программное обеспечение и тесты для него должны быть неотъемлемой частью стратегии тестирования. Глобально, стратегия тестирования — это принятая в организации схема, описывающая подход к тестированию цикла разработки программного обеспечения. Цель такой схемы состоит в том, чтобы преобразовать высокоуровневые требования организации (заказчика) в набор конкретных подходов и процедур, которые позволят достичь требуемого уровня качества сервиса.

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

Важной частью тестовой стратегии являются автотесты.

Существует большое разнообразие тестов и способов их классификации. Для мобильных разработчиков, наиболее применимые способы включают в себя классификации по:

1. Предмету (объекту) тестирования:

   • Функциональное тестирование;

   • Тестирование производительности;

   • Тестирование корректности поддержки специальных возможностей (accessibility);

   • Тестирование совместимости;

2. По масштабу/рамкам (scope)

   • Модульное (unit) тестирование;

   • Интеграционное тестирование;

   • Сквозное (e2e) тестирование;

3. По среде выполнения тестов

   • Локальные тесты;

   • Инструментальные тесты.

Остановимся подробнее на классификации по скоупу тестирования. Наверняка каждый знаком и не раз встречался с пирамидой автоматизированного тестирования.

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

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

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