Файл: Критерии выбора средств разработки мобильных приложений (Теоретические аспекты выбора средств для разработки мобильных приложений).pdf

ВВЕДЕНИЕ

Начавшаяся в начале XXI века тенденция к мобилизации всех устройств, только набирает обороты. Сейчас, практически любую задачу в области информационных технологий пользователь может выполнять с помощью мобильных устройств [11, 22]. Каждая компания, предоставляющая продукты пользователям, заботится о наличии мобильной версии или мобильного приложения.Рынок мобильных приложений растет ежегодно. В данной работе будет идти речь о приложениях Android и iOS, как о самых распространенных платформах.

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

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

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

Целью настоящей работы является выявление критерийв автоматизации тестировании мобильных приложений и разработка рекомендаций по организации данного процесса.

Задачи исследования

Для достижения данной цели необходимо выполнить следующие задачи:

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

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

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

Глава 1. Теоретические аспекты выбора средств для разработки мобильных приложений

1.1 Виды разработок по уровню тестирования

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

Все эти этапы проходят через уровни тестирования программного обеспечения. Есть четыре основных уровня тестирования[17]:

1. Модульное тестирование
2. Интеграционное тестирование
3. Системноетестирование
4. Приемочное тестирование

Рисунок 1.1.Уровни тестирования

Каждый из этих уровней тестирования имеет определенную цель. Эти уровни тестирования обеспечивают ценность жизненного цикла разработки программного обеспечения[26].

1. Модульное тестирование:

Модуль — это наименьшая тестируемая часть системы или приложения, которую можно скомпилировать, загрузить и выполнить. Этот вид тестирования помогает тестировать каждый модуль отдельно.

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

1. Интеграционное тестирование:

Интеграция — это объединение. На этом этапе тестирования различные программные модули объединяются и тестируются вместе, чтобы убедиться, что интегрированная система готова к системномутестированию.

Интегрированное тестирование проверяет поток данных от одного модуля к другим модулям. Этот вид тестирования выполняется тестировщиками.

3) Системное тестирование:

Системное тестирование выполняется на полностью интегрированной системе. Этот вид тестирования позволяет проверить соответствие системы требованиям. Оно проверяет общее взаимодействие компонентов. Оновключает проверку нагрузки, производительности, надежности и тестирование безопасности.

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

Это обычно тестирование методом «черного ящика», где тестирование проводится полностью со стороны пользователя.

4) Приемочное тестирование:

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

1.2 Специфика тестирования мобильных приложений

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

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

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

Если разнообразие телефонов и других устройств на iOs сравнительно небольшое и допустимо протестировать приложения на всех актуальных девайсах, то на системе Android благодаря большому количеству компаний, выпускающих устройство, разнообразие телефоновогромно. Даже большая компания не может позволить себе иметь модели за пределами самых распространенных. Поэтому для тестирования могут использоваться фермы мобильных устройств. Это сервисыпредоставляющие смартфоны для «удаленной аренды», где можно воспользоваться ими на какое-то время и протестировать работу своего продукта.

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

1. Выделение и согласование тест-кейсов для автоматизации

Команда тестирования определяет какие тесты можно автоматизировать, а какие нельзя. И какие наборы тестов являются самыми приоритетными для автоматизации.

1. Создание и развертывание тестовой инфраструктуры

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

1. Написание скриптов для прохождения тест-кейсов

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

1. Поддержка автоматизированных тестов

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

Говоря об основных операционных системах для мобильных устройств, главное, что стоит выделить —это намного большая закрытость операционной системы iOsпо сравнению с Android.В некотором смысле тестировать и разрабатывать под iOsлегче, так как количество возможных конфигураций, размеров экрана и устройств сравнительно небольшое.Однако Androidпредоставляет большое количество инструментов для разработки и, в частности тестирования, доступных на любых десктоп операционных системах.В то время как, например, запуск эмуляторов и разработка на iOsвозможна только на MacOs.

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

Глава 2. Сравнительный анализ средств разработки мобильных приложений

2.1 Общий алгоритм разработки

Теперь перейдем от теории к реальным кейсам людей из компаний. Компания TouchInstinctописывает свой алгоритм тестирования мобильных приложений [6]:

Тестирование требований

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

Если тестирование закончилось успешно, то специалист по тестированию составляет smokeи функциональные тесты. Они разделяются по конфигурациям и платформам.

Далее проект отдается в разработку.

Сборка на build-сервере

Потом на сборочном конвейере собирается продукт и менеджер проекта (такая система действует в компании TouchInstinct) может отдать ее в тестирование, поставив соответствующий флажок.

Рисунок 2.1. Настройки сборочного сервера

Если менеджер, ставит такую галочку, то тестировщики получают уведомление о том, что готова сборка для тестирования с таким номером.

Само тестирование при этом подразделяется на быстрое и полное. Быстрое выполняется для тех сборок, которые не собираются отправляться в релиз, сразу после окончания разработки. Быстрое включает в себя дымовое тестирование, проверку работоспособности касательно багов, которые должны были быть исправлены и функциональные тесты на ту часть, которая разрабатывалась в данной итерации. Для Androidустройств также запускаются Monkeyтесты [7].

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