СТРУКТУРА АВТОМАТИЗИРОВАННОГО ТЕСТИРОВАНИЯ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ

AUTOMATED TESTING STRUCTURE FOR MOBILE APPLICATION

Artyom Vinokurov

student, Voronezh Institute of High Technologies,

Russia, Voronezh

АННОТАЦИЯ

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

ABSTRACT

The article observes popular technologies of automated testing mobile apps, suggests the comprehensive way to automated tests categorization.

Ключевые слова: автоматическое тестирование; мобильное приложение.

Keywords: automated testing; mobile app.

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

Традиционно тесты мобильных приложений принято разделять по способу выполнения на локальные (local tests, app tests – терминология у каждой платформы своя) и инструментальные (instrumented tests, library tests) [1, 4]. Локальные тесты выполняются при сборке проекта, тогда как инструментальные требуют наличия эмулятора или подключённого устройства, на котором будет произведён запуск тестовой сборки приложения и выполнение тестов.

Локальные тесты android-приложений представляют собой обычные unit-тесты языков Java и Kotlin с использованием фреймворка JUnit. Для iOs-приложений такие тесты пишутся соответственно с помощью OCUnit для языка Objective-C или XCTest - для Swift. Тогда как инструментальные тесты используют отдельные программные интерфейсы тестирования из SDK и специфические библиотеки, позволяющие работать с объектами пользовательского интерфейса приложения при запуске теста на эмуляторе или устройстве.

Несмотря на то, что такая классификация заложена в структуру проекта и описана в документации Android SDK или Apple SDK, а её компоненты доступны «из коробки», её сложно назвать однозначной и исчерпывающей. Прежде всего, выполнение инструментальных тестов на эмуляторах и физических устройствах — это не характерная особенность, а характерный недостаток данной группы тестов, поскольку выполняется медленно и задействует избыточное количество ресурсов системы. В целях оптимизации тестирования и выполнения инструментальных тестов Android как локальных компанией PivotalLabs в 2010 году был разработан фреймворк Robolectric, позволяющий запускать инструментальные тесты на локальной виртуальной машине Java без установки приложения, а также без использования эмуляторов или внешних подключённых устройств. Начиная с версии 4.0, данный инструмент интегрирован с AndroidX Test Framework и используется повсеместно. Соответственно, то самое «фундаментальное» различие двух категорий тестов для Android-приложения в значительной мере сгладилось в ходе дальнейшего развития платформы. Для iOs, которая не относится к JVM-системам, проблема была решена иначе – там раздельно существуют Library tests и тесты пользовательского интерфейса с помощью библиотеки UIAutomation [4]. Тем не менее, для обеих платформ очевиден недостаток такой классификации – фокус внимания смещается с цели тестирования на особенности реализации конкретных тестов.

Более значимой представляется группировка тестов по объекту тестирования и по целям тестирования:

- unit-тесты;

- ui-тесты;

- интеграционные тесты;

- функциональные тесты;

- тесты обработки внешних событий;

- тесты безопасности;

- тесты производительности;

- тесты локализации;

и др.

Самыми распространёнными и востребованными являются первые четыре группы тестов, их можно встретить практически в любом мобильном приложении.

Если с unit-тестами и UI-тестами ситуация более-менее понятна, то их отграничение от интеграционных тестов и технологии разработки последних вызывают вопросы. Согласно приводимому М. Фаулером и ставшему классическим определению: «Интеграционные тесты проверяют, функционируют ли корректно независимо разработанные части приложения, когда они подключены друг к другу» [2].

Можно выделить определённые признаки, наличие любого из которых показывает, что мы имеем дело с интеграционным тестом:

- тестирование производится методом «белого ящика» и использует абстракции интерфейсов межкомпонентного или пользовательского взаимодействия;

- в тестировании участвует не менее двух компонентов, взаимодействие которых проверяется;

- тесты запускаются по расписанию под управлением среды непрерывной интеграции;

- тесты требуют выполнения затратных операций без использования «заглушек» (mock-ов);

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

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

Вместе с тем, ошибочным является мнение некоторых авторов, что для написания «интеграционного теста» достаточно просто в unit-тесте заменить mock-объекты реальными экземплярами классов с примерами реальных данных [3]. Подобные тесты останутся модульными тестами, просто с нарушенной методологией тестирования. Интеграционными тестами они от этого не станут, поскольку отличие этих групп тестов заключается в целях и в соответствующих этим целям тестовых сценариях, и не сводится к использованию или неиспользованию «заглушек» вместо реальных классов.

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

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

Нельзя не упомянуть в связи с рассматриваемой проблематикой и о такой специфической особенности процесса разработки мобильных приложений, как особая роль платформ-агрегаторов (Google Play Market, AppStore, Windows Store) в распространении приложений. Размещаемые на указанных платформах приложения проходят проверку, которая часто включает автоматическое тестирование определённого набора кейсов.

Так в случае Google Play Market целями такого тестирования являются: проверка соответствия заявленных разработчиком характеристик приложения загруженному файлу apk или App Bundle, выявление некоторых дефектов производительности, которые разработчику следует оптимизировать, проверка соответствия интерфейса приложения некоторым требованиям гайдлайнов Material Design, изучение пригодности приложения для запуска на разных моделях и типах устройств, соответствие размера загруженного приложения его доступному функционалу (наличие неиспользуемых ресурсов и недостижимых классов), а также проверка пригодности приложения для использования лицами с ограниченными возможностями. Успешное прохождение такого тестирования и устранение разработчиком выявленных дефектов является необходимым условием для дальнейшего опубликования приложения в открытом доступе [5].

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

Отдельно следует сказать и о роли т. н. фреймворков автоматического тестирования. На сегодняшний день существует целый ряд программных решений (Robotium, Appium и Calabash), позволяющих выполнять инструментальные тесты мобильного приложения на наборе реальных или виртуальных устройств, объединённых в кластер Selenium Grid Hub или облачный кластер, например, BrowserStack или SauceLabs.

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

1) Локальные юнит-тесты, которые будут выполняться при каждой сборке приложения, и которые проверяют корректность кода отдельных классов и методов;

2) Инструментальные UI-тесты, а также интеграционные тесты внешних ресурсов и контрактов, которые не требуют имитации действий пользователя с приложением, которые не должны выполняться при каждой сборке (доступность базы данных не зависит от сборки приложения, например), но которые может быть целесообразно запускать по расписанию в системе непрерывной интеграции;

3) Интеграционные и функциональные тесты приложения с помощью Appium или его аналогов, выполняемые в кластере Selenium Grid Hub, запущенном в системе непрерывной интеграции, либо в облачном кластере, и имитирующие реальную активность пользователей в приложении;

4) Тестирование приложения оператором площадки-агрегатора при его опубликовании (набор выполняемых тестов индивидуален для каждой площадки);

5) Автоматические нагрузочные тесты и иные специфические методы тестирования, которые должны выполняться отдельно и зависят от конкретных задач проекта.

Список литературы:

1. Build effective unit tests [Электронный ресурс]. – Режим доступа: https://developer.android.com/training/testing/unit-testing?hl=ru (дата обращения: 22.11.2020)
2. Fowler M. IntegrationTest [Электронный ресурс]. – Режим доступа: https://martinfowler.com/bliki/IntegrationTest.html (дата обращения: 22.11.2020)
3. Jarad N. How to do TDD in Android? Part 3 — Mocking & Integration testing [Электронный ресурс]. – Режим доступа: https://medium.com/mobility/how-to-do-tdd-in-android-part-3-mocking-integration-testing-60b057840db6 (дата обращения 22.11.2020).
4. Testing Basics [Электронный ресурс]. – Режим доступа: https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/03-testing_basics.html (дата обращения: 22.11.2020)
5. Upload your app to Play Console [Электронный ресурс]. – Режим доступа: https://developer.android.com/studio/publish/upload-bundle (дата обращения: 22.11.2020)