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

Содержание:

ВВЕДЕНИЕ

Начавшаяся в начале 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 устройствах и тестирование обновлений. Для мобильных приложений важно проверять сценарий обновления со старой версии на новую, так как пользователи в большинстве случаев не удаляют приложение, а устанавливают обновление, что может привести к неполному применению всех исправлений, которые сделали разработчики или утере пользовательских данных, которые они сохранили раньше. Кроме того, пользователи могут не обновляться довольно долго и потом скачать новую версию приложения, пропустив много промежуточных.

2.2 Современные тестовые фреймворки

По данным Bitbar (компании, предоставляющей платформу и инструменты для автоматизированного тестирования) [9]:

Рисунок 2.2. Фреймворки тестирования

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

На Android очень популярны также Espresso и UIAutomator. И есть также веские причины, по которым люди используют эти фреймворки. Espresso обеспечивает очень быстрое выполнение тестов, а UIAutomatorпредоставляет легкий API, который легко адаптировать и использовать ваши собственные приложения. Обе эти платформы, однако, несколько ограничены только нативными приложениями. Опять же, большинство разработчиков игр используют либо Appium, либо какую-то внутреннюю среду разработки.

Appiumпредоставляет инструмент для End-to-endтестирования на устройствах, которое выполняется со скоростью немногим быстрее, чем если бы пользователь взаимодействовал с элементами интерфейса. Это избавляет от рутинного труда, их сравнительно несложно поддерживать, и они не зависят от того нативное приложение или нет, однако для автотестирования длительность исполнения может быть слишком большой, особенно на большом наборе тестов.Espresso, например, может использоваться для интеграционных тестов, которые могут исполняться очень быстро.

На iOSпопулярными фреймворками были Appium и Calabash, оба из которых являются кроссплатформенными средами.

Еще одной широко используемой платформой для iOS была UI Automation.

Но теперь, поскольку Appleобъявила UI Automationустаревшей, Bitbarожидает рост популярности XCTest и XCUITest в автоматизации под IOS. Тем не менее, изменение Apple ударило по Appium (для данной платформы), поскольку в его основе лежал UI Automation.

Рисунок 2.3. Прогнозы популярности фреймворков тестирования

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

В трендах по автоматизации AndroidBitbarне ожидает серьезных изменений. Appium, Calabash и Espresso определенно будут активно использоваться и, вероятно, даже станут популярнее, поскольку Google склоняется в пользу Espresso, а также есть много поклонников Appium. Calabash не предоставил много новых возможностей для своей экосистемы в последнее время, но одна из его сильных сторон заключается в достаточной легкости написания тестов.

Другая компания, специализирующаяся на мобильной разработке, Intuz [21] отмечает также и другие популярные фреймворки:

Robotium

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

MonkeyRunner

MonkeyRunner специально разработан для тестирования устройств и приложений на базовом/функциональном уровне. Инструмент содержит функции, такие как управление несколькими устройствами, регрессионное тестирование, расширяемая автоматизация и функциональное тестирование для тестирования приложений и оборудования Android. Тесты MonkeyRunnerпишутся на Python. Разработчикам не нужно вносить изменения в исходный код для автоматизации тестирования.

Selendroid

Являясь одним из ведущих инструментов автоматизации тестирования, Selendroid тестирует пользовательский интерфейс гибридных и нативных приложений на базе Android и мобильного Интернета. Тесты клиентского API пишутся с использованием Selendroid 2. Инструмент поддерживает физическое подключение устройств. Кроме того, он обладает возможностями взаимодействия с несколькими устройствами Android одновременно. Selendorid хорошо совместим с протоколом JSON.

MonkeyTalk

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

Testdroid

Это облачная программа для тестирования мобильных приложений, которая помогает разработчикам экономить затраты на разработку, устранять непредсказуемые эксплуатационные расходы и сокращать время выхода на рынок. Это платформа для тестирования устройств на iOS и Android с разными разрешениями экрана, версиями ОС и аппаратными платформами. Testdroid— это инструмент, который снижает риск при тестировании виртуальных и реальных устройств.

Frank

Frank позволяет тестировать только приложения и программное обеспечение iOS. Фреймворк сочетает в себе JSON и Cucumber. Инструмент содержит инспектор приложений «Symbioate», который позволяет разработчикам получать подробную информацию о запущенном приложении. Этот инструмент более всего подходит для веб-приложений и эмуляторов. Его можно интегрировать с CI системами и запускать тесты на устройствах и симуляторах.

SeeTest

SeeTestAutomation— это кроссплатформенное решение. Это позволяет запускать одни и те же скрипты на разных устройствах. Он позволяет разработчикам запускать тест на нескольких устройствах параллельно. Являясь мощным средством автоматизации тестирования, он способен тестировать веб-сайты или мобильные приложения. Он поддерживает iOS, Android, Symbian, Blackberry и WindowsPhone. Наиболее важные функции этого инструмента - тестирование телефона, тестирование батареи, браузера и т. д.

2.3 Критерия для Android

Для Androidкак более распространённой системы существует больше исследований и сравнений фреймворков, обратимся к сравнению фреймворков для тестирования GUI[8].

В исследовании сравнивают 4 фреймворка для Android: Espresso, UI Automator, Appium и Calabash. Для сравнения фреймворков исследователи используют две основных группы критериев: общий обзор фреймворков и технические критерии, связанные с жизненным циклом Activityи основных компонентов графического интерфейса Android.

Общие критериивключают следующие пункты:

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

• Поддержка логирования.

• Поддержка захвата/воспроизведениядействий на устройстве.

• Документация. Хорошая документация может помочь разработчику сократить время вхождения в контекст фремворка.

• Автоматическая генерация событий (monkeytesting)

• Поддержка эмуляторов и реальных устройств

• Поддержка версий. Эта версия поддержки указывает, сколько версийAndroid API поддерживается тестированием.

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

Технические критерии включают доступность следующего:

• Возобновление приложения: возобновление приложения используется для проверки метода OnRestart() в жизненном цикле Android.

• ПриостановлениеActivity: приостановка приложения используется для проверки метода OnStop() в жизненном цикле Android.

• Завершениеработы/уничтожение Activity: «Завершение» используется для проверки метода OnDestroy() в жизненном цикле Android.

• Изменение настроек устройства: изменение настроек, таких как ориентацияэкрана, также поможет протестировать жизненный цикл Activity.

• Прокруткаэкрана (scroll).

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

• Поддержка задержки для действий

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

• Ввод текста

• Нажатие кнопок

• Поддержка переключателей (radiobutton)

• Поддержка флажков (checkbox)

• Выбрать дату/время (picker)

• Работа с выпадающими списками (spinner)

• Пролистывание (Swiping)

• Переходы по вкладкам

Сравнение по общим критериям отражено в таблице:

Таблица 2.1 Общие критерии сравнения фреймворков для Android

Общий критерий	Espresso	UI Automator	Appium	Calabash
API	Очень простой	Простой	Простой	Очень простой
Логирование	Хорошее	Плохое	Хорошее	Хорошее
Захват/ воспроизведение	Да	Нет	Нет	Нет
Документация	Хорошая	Хорошая	Хорошая	Хорошая
Автоматическая генерация событий	Нет	Нет	Нет	Нет
Поддержка эмуляторов/ реальных устройств	Оба	Оба	Оба	Оба
Доступные версии Android	API 8+	API 18+	API 18+	API 8+
Поддерживаемые IDE	Eclipse, Android Studio	Eclipse, Android Studio	Eclipse, Android Studio	Eclipse, Android Studio

Сравнение общих критериев показало, что Espresso является рекомендуемой платформой для тестирования Android, поддерживается довольно простым API, хорошей системой логирования, которая позволяет тестировщику легко обнаружить, если в приложениипроизошла ошибка. Также у Espressoхорошая структурированная документация, которая поможет в обучении, возможно запускать процесс тестирования как на эмуляторе, так и на реальном устройстве, поддерживается обратная совместимость, начиная с API 8 (Froyo), может использоваться в наиболее известных Android IDE (Eclipse и AndroidStudio) и Espresso также поддерживает метод захвата/воспроизведения для тестирования, позволяющий запускать тест без необходимостипрограммировать.

Таблица 2.2 Технические критерии сравнения фреймворков для Android

Технический критерий	Espresso	UI Automator	Appium	Calabash
Возобновление приложения	Нет	Да	Нет	Нет
Приостановление Activity	Нет	Да	Да	Да
Уничтожение Activity	Да	Да	Да	Да
Изменение настроек устройства	Нет	Нет	Да	Нет
Прокрутка	Да	Да	Да	Да
Одновременные нажатия	Нет	Нет	Да	Нет
Задержки для действий	Автоматически	Да	Да	Да
Условное тестирование	Да	Да	Да	Да
Ввод текста	Да	Да	Да	Да
Нажатие кнопок	Да	Да	Да	Да
Поддержка переключателей	Да	Да	Да	Да
Поддержка флажков	Да	Да	Да	Да
Выбор даты/времени	Да	Да	Да	Да
Выпадающие списки	Да	Да	Да	Да
Пролистывание	Да	Да	Да	Да
Переходы по вкладкам	Да	Да	Да	Да

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

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

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

2.4 Критерии для IOS

Для этой работы также проведем сравнение самых популярных фреймворков и инструментов для автоматизации тестирования на IOS [2, 8].

В качестве сравнимых фреймворков были выбраны самые популярные фреймворки:

XCTestфреймворк для iOS. Это фреймворк для тестирования пользовательского интерфейса iOS. Эта программа была создана при поддержке Apple и может быть легко интегрирована в среду разработки для написания и запуска тестов. Фреймворк отслеживает все изменения Xcode и полностью совместим с Objective-C и Swift. Система предоставляет не только модульные (unit), но и UI-тесты и тесты производительности. Также присутствуют функции записи и воспроизведения, которые помогают тестировщикам писать тесты.

Appium— это кроссплатформенный инструмент, который уже упоминался ранее несколько раз.

Calabash. Также кроссплатформенный инструмент, который позволяет писать и запускать тесты для Android и iOSприложений. Эта система использует BehaviorDrivenDevelopment (BDD). Это тот тип разработки, когда код пишется после того, как определены внешние приложения. Calabash использует Cucumber для описания сценария с помощью BDD. И это огромный бонус для тестировщиков, поскольку он делает данные понятными и с которыми легко работать.

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

Таблица 2.3. Сравнение фреймворков для тестирования IOS

	XCTest	Appium	Calabash	EarlGrey
Производитель	Apple	Open Source	Open Source	Google/Open Source
Доступ к исходному коду приложения	Нет	Нет	Да	Да
Более 1го приложения	Нет	Да	Нет	Да
Реальные устройства	Да	Да	Да	Да
Запись/Воспроизведение	Да	Нет	Нет	Нет

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

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

Функция же запись/воспроизведение доступна только для нативного, производимого Apple, XCTest.

Глава 3.Разбор вариантов стратегий автоматизации тестирования

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

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

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

Автоматизация будет полезна в следующих случаях:

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

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

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

1. Для решения одной из самых актуальных проблем – скорости выполнения тестов необходимо активно использовать распараллеливание выполнения тестов на разные устройства и писать как можно больше модульных тестов (unit) на отдельные классы, так как они выполняются очень быстро и быстрее любых других вариантов тестов.
2. Стоит следовать рекомендациям по соотношению тестов, где каждый более низкий уровень тестирования покрыт большим количеством автоматизированных тестовых сценариев.
3. Автоматизация должна двигаться командой разработки самого продукта, ее не должны полностью нести на своих плечах тестировщики или изолированная команда автоматизации. Это поможет избежать проблем с тем, что тесты могут писаться неподготовленными людьми или без учета всех особенностей продукта.
4. Для систематизации обратной связи и уведомления всех заинтересованных сторон о текущей ситуации стоит использовать системы непрерывной интеграции. Это поможет тестировать именно те сборки, которые необходимо и не тратить усилия на какие-то другие сборки. Также всегда будет доступна история по каждому тесту, и можно будет эффективнее искать, какой коммит прекратил корректное выполнение какой-либо функции.
5. В большинстве случае для прогона автотестов достаточно использовать эмуляторы, как более быстрый и дешевый вариант. ОС и девайс специфичные баги могут быть обнаружены и на ручном тестировании.
6. Невозможно покрыть автоматизированными тестами все 100% вариантов использования продукта на всех конфигурациях. Ручное тестирование все равно будет использоваться.
7. Но кроме всего вышесказанного необходимо отметить, что для каждой ситуации выбор фреймворка и стратегии тестирования может быть индивидуальным.

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

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

«Стартап» — это компания, которая либо недавно создала этот продукт и еще неизвестно сколько планирует его поддерживать. Либо это ситуация, когда мобильное приложение не является основным продуктом компании. В данном случае мобильное приложение может быть не основным приоритетом само по себе, и автоматизация его тестирования может быть даже не столь необходима для компании как направление вложения ресурсов.

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

В данном случае можно выделить 2 разных подхода.

Для «стартапа» могут быть актуальны следующие опции:

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

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

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

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

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

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

Для «корпорации» же актуальны большая часть общих рекомендаций:

1. Покрытие модульными (unit) тестами необходимо для сокращения времени тестирования.

Потому что в противном случае тестирование может выполняться много часов.

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Автоматизация тестирования iOS-приложений с применением Calabash и Cucumber[Электронный ресурс] / Habr – Коллективный блог. – URL: https://habr.com/ru/company/mailru/blog/244807/.
2. Батыров А. Путеводитель по инструментам автотестирования мобильных приложений [Электронный ресурс] / Habr – Коллективный блог. – URL: https://habr.com/ru/company/badoo/blog/347986/.
3. Бындю А. Тестирование: Ручное или Автоматизированное? [Электронный ресурс] / Habr – Коллективный блог. – URL: https://habr.com/ru/post/145974/.
4. Каща А. Модульное тестирование: 2+2 = 4? [Электронный ресурс] / RSDN – URL: http://rsdn.org/article/testing/UnitTesting.xml
5. Круглов А. Continuousintegration в Яндексе [Электронный ресурс] / Habr–URL:https://habr.com/ru/company/yandex/blog/428972/.
6. Ларин А. Процесс тестирования мобильных приложений [Электронный ресусрс] / Habr–URL: https://habr.com/ru/company/touchinstinct/blog/197060/.
7. Мищевский Г. Тестирование. Фундаментальная теория [Электронный ресурс] / Habr–URL: https://habr.com/ru/post/279535/.
8. 7BestiOSTestingFrameworks: ComparisonGuide[Электронныйресурс] / ApplikeySolutions – URL: https://applikeysolutions.com/blog/7-best-ios-testing-frameworks-comparison-guide/.
9. Abdallah S.A., Moawad R., Fawzy E.E. An optimization approach for automated unit test generation tools using multi-objective evolutionary algorithms // Future Computing and Informatics Journal. 2018. Vol. 3, Issue 2, P. 178-190.
10. Askmeanything. Avito. Android[Электронныйресурс] / Habr – URL: https://habr.com/ru/company/avito/blog/348622/.
11. Braun S.,Elberzhager F., Holl K.Automation Support for Mobile App Quality Assurance – A Tool Landscape //Procedia Computer Science.2017.Vol. 110, P. 117-124
12. FowlerM.ContinuousIntegration[Электронныйресурс] / MartinFowler –URL: https://martinfowler.com/articles/continuousIntegration.html.
13. Fundamentals of Testing[Электронныйресурс] / AndroidDevelopers – URL:https://developer.android.com/training/testing/fundamentals/.
14. Gojare S., Joshi R., Gaigaware D. Analysis and Design of Selenium WebDriver Automation Testing Framework. // Procedia Computer Science. 2015. Vol. 50, P. 341-346
15. Hamdan S., Alramouni S. A Quality Framework for Software Continuous Integration. // Procedia Manufacturing. 2015. Vol. 3, P. 2019-2025f
16. Kolodiy S.Unit Tests, How to Write Testable Code and Why it Matters[Электронныйресурс] /Toptal–URL: https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters/.
17. Levels of Testing in Software Testing [Электронныйресурс] / Guru99 –URL: https://www.guru99.com/levels-of-testing.html/. (Датаобращения: 07.05.19).
18. Meiliana, Septian. I., Aliantoa. R. I., Daniel. Comparison Analysis of Android GUI Testing Frameworks by Using an Experimental Study. // Procedia Computer Science. 2018. Vol. 135, P. 736-748
19. Onyaem C. Separate Unit, Integration, and Functional Tests for Continuous Delivery [Электронныйресурс] / Medium – URL: https://medium.com/pacroy/separate-unit-integration-and-functional-tests-for-continuous-delivery-f4dc240d8f2f/.
20. Rauf E.M.A., Reddy E.M.Software Test Automation: An Algorithm for Solving System Management Automation Problems. //Procedia Computer Science. 2015Vol.46, P. 949-956
21. Rupareliya P. Top 10 Automated Testing Tools for Mobile Apps[Электронныйресурс] / Medium – URL: https://medium.com/intuz/top-10-automated-testing-tools-for-mobile-apps-8d9380e1757f/. (Датаобращения: 09.05.19).
22. Singh A.Kr., Prajapati A.Kr., Kumar V., Mishra S. Usage Analysis of Mobile Devices. // Procedia Computer Science. 2017. Vol. 122, P. 657-662
23. SmartphoneTestFarm[Электронныйресурс] / OpenSTF – URL: https://openstf.io/.
24. TDD > The Principle of Single Responsibility[Электронныйресурс] /Philosophical Hacker – URL: https://www.philosophicalhacker.com/post/tdd-is-greater-than-the-principle-of-single-responsibility/.
25. Test Early and Often [Электронныйресурс] / Microsoft Documentation – URL: https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2012/ee330950(v=vs.110). (Датаобращения: 09.05.19).
26. Testing Mobile Apps: A Primer [Электронныйресурс] / Medium – URL: https://medium.com/@FizzyInTheHall/testing-mobile-apps-a-primer-889f62a85e40/.
27. UI/ApplicationExerciserMonkey[Электронныйресурс] / AndroidDevelopers – URL: https://developer.android.com/studio/test/monkey/.
28. Wacker M. Just Say No to More End-to-End Tests [Электронныйресурс] / Google Testing Blog – URL: https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html. (Датаобращения: 09.05.19).
29. What'sTrendingwithMobileTestAutomationFrameworks[Электронныйресурс] / Bitbar– URL: https://bitbar.com/blog/whats-trending-with-mobile-test-automation-frameworks/.