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

Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет Бизнеса и Менеджмента

Выпускная квалификационная работа - БАКАЛАВРСКАЯ РАБОТА

по направлению подготовки Бизнес-Информатики

образовательная программа «Бизнес-Информатика»

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

Сакунова Анастасия Юрьевна

Научный руководитель

к. т. н. Ефремов. С. Г.

Москва, 2019



Введение

Актуальность

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

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

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

Цель исследования

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

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

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

Исследовать предметную область и задачи, ставящиеся в ней

Проанализировать современные практики автоматизированного тестирования для мобильных приложений в разных компаниях и выявить самые эффективные из них

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

Методы

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

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



Глава 1. Основные понятия

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

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

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

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

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

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

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

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

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

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

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

Системноетестирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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



1.2 Этапы тестирования

Принятой практикой разработки программного обеспечения является как можно более раннее привлечение тестировщиков к работе над продуктом. Общий цикл тестирования можно представить следующим образом [7]:

Анализ требований

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

Разработка стратегии тестирования и планирование процедур контроля качества

Работа с требованиями

Создание тестовой документации

На этом этапе уточняются требования к тестированию и создаются основные документы: тест-план, тест-кейсы.

Тестирование прототипа

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

Основное тестирование

Тестирование уже законченного продукта и регрессионное тестирование для уже существующих продуктов.

Стабилизация

Исправление багов и тестирование их исправления.

8. Эксплуатация

Основные наборы тест-кейсов

Как правило составляются следующие наборы тест-кейсов для разных видов тестирования:

Дымовое тестирование (SmokeTesting, BVT - buildverificationtest) --оченьмаленький набор тестов, направленный на проверку того, что приложение способно выполнять самые основные функции. Этот вид тестирования нужен, чтобы понять отдавать ли сборку в дальнейшее тестирование или нет.

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

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

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

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

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

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

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

Автоматизация тестирования на мобильных устройствах

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

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

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

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

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

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

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

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

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

Специфика операционных систем

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

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

Проблемы, возникающие при автоматизации

В качестве основных проблем, возникающих при автоматизации тестирования, хотелось бы отметить следующие [3, 20]:

Нестабильность тестовой инфраструктуры и самих тестов

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

Негибкость тестов

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

Небольшие/неважные баги

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

Долгая обратнаясвязь

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

Недостаточная подготовка тестировщиков

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

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



Глава 2. Общий алгоритм тестирования

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

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

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

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

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

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

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

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



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

Источник: https://habr.com

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



2.1 Популярные тестовые фреймворки

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

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

Источник: https://bitbar.com

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

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

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

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

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

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

Источник: https://bitbar.com



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

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

В трендах по автоматизации 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.2 Сравнение фреймворков для Android

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

В исследовании сравнивают 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.3 Сравнение фреймворков для 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.



2.4 Проблемы тестовых фреймворков

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

Работа с ОС вне тестируемого приложения

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

Скорость

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

Flaky-safety

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

Отсутствие готовых решений по архитектуре

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

Тяжело читаемый код

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

Рисунок 2.4. Пример тестового кода на Espresso

Источник: https://proandroiddev.com/

Для решения этой проблемы зачастую используются различные синтаксические обертки, например, Kakaoдля Espesso.

2.5 Модульные тесты (Unit)

Ранее речь шла в основном о end-to-endтестировании - когда тестируется весь продукт целиком, как если бы он использовался конечным пользователем. В этом разделе мы обсудим модульное тестирование, которое должно тестировать отдельные классы приложения.

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

Цель модульных тестов - изолировать каждую отдельную часть программы и показать, что эта отдельная часть работает корректно [16].

Выгода от использования модульных тестов

Нахождение дефектов на ранних этапах разработки

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

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

Повышение качества кода

Существует хороший подход, помогающий при проектировании кода. Подход заключается в следующем: прежде чем написать код, реализующий какую-либо функциональность, лучше написать сначала клиентский код, который будет использовать эту функциональность [24, 25]. Такой подход подталкивает к созданию хороших интерфейсов. Это одна из причин, по которой TDD позволяет писать более качественный код: сначала тест (клиентский код), потом пишется функциональность.

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

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

1. Привести этот компонент к нужному начальному состоянию.

2. Проверить корректность состояния после взаимодействия с компонентом.

Поощрение изменений

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

Документирование кода

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

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

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

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

1. Происходит завязка на особенности конкретной реализации, что замедляет рефакторинг в будущем.

Как правило, необходимость исправлять тест должна возникать редко при рефакторинге кода.

2. Тестирование особенностей конкретной реализации редко повышает уверенность в работоспособности приложения.

Интеграционные и end-to-end тесты

Остаётся вопрос: а что, если сценарий затрагивает более чем один модуль/класс/метод, или изменения вносились во всю кодовую базу? Модульные тесты всё равно дают некоторую степень уверенности в отдельных частях программы, но, неизбежно, чтобы получить более высокую степень уверенности в работоспособности программы, нужно не забывать про существование интеграционных и endtoend (далее E2E) тестов [28].

Рисунок 2.5. Пирамида тестирования

Источник: https://testing.googleblog.com/



Чем выше в данной пирамиде тест, тем больше уверенности он даёт.

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

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

Рассмотрим простую и очевидную таблицу:

Таблица 2.4. Польза тестов для пользователя

Этап	Тест провалился	Баг на дефект открыт	Дефект исправлен
Польза конечному пользователю	Нет	Нет	Да

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

Идеальная обратная связь напрямую связана со следующими свойствами тестов:

Скорость выполнения. Чем быстрее скорость выполнения, тем быстрее можно узнать о возможных дефектах и тем быстрее их можно поправить.

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

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

Возвращаясь к вопросу использования только E2E тестов, легко заметить, что, по определению, эти тесты будут по сравнению с юнит тестами[19]:

Выполняться значительно медленнее, так как они охватывают множество фундаментально “медленных” частей приложения (взаимодействие с UI, обращение к базам данных и удалённым ресурсам).

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

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

То есть, E2E тесты сильно проигрывают юнит тестам с точки зрения обратной связи.

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

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

Быстрые

Независимые

Зависимости не должны полагаться на внешние факторы в окружении.

Надежные

Каждый запуск должен приводить к получению одного и того же результата выполнения.

Самодостаточные

Не должно быть необходимости осуществлять дополнительные ручные проверки чтобы понять прошёл тест или нет.

Например, для AndroidGoogle рекомендуетследующее распределение тестов: 70% юнит тестов, 20% интеграционных и 10% UI тестов [13].

Непрерывнаяинтеграция(ContinuousIntegration)

Непрерывнаяинтеграция (CI, англ. ContinuousIntegration) -- этопрактикаразработки программного обеспечения, включающая слияние всех частей проекта в одну общую систему, частые сборки проекта, выполнение автоматизированных тестов до или после сборок продукта. Целью такой разработки является поддержание постоянно работоспособной ветки разработки, в которую достаточно часто попадают мелкие изменения и тестируются на выполнение своих функций и правильную интеграцию с другими частями продукта [12, 15].

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

Крупные компании с большим количеством поддерживаемого кода и продуктов отмечают значимую выгоду от использования систем непрерывной интеграции. Например, Яндекс работает над созданием монолитного репозитория с плотной интеграцией каждого pull-request'а с автоматическими тестами и другими связанными компонентами [5].

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



Рисунок 2.6. Проверки коммитов в системе непрерывной интеграции

Источник: https://habr.com/

Для тестирования мобильных приложений также активно применяются системы непрерывной интеграции. И для них важно правильно выбрать набор тестов, который будет запущен после каждой сборки/каждый день/каждый релиз. В докладе Яндекса для своего backendотмечается, что после каждого изменения запускаются легкие тесты, а пользователь может выбрать запускать ли более тяжелые наборы тестов или нет. Для мобильных приложений это тоже актуально, после каждой сборки запускать быстрые Unit-тесты или интеграционные espresso-тесты, которые не занимают много времени.

Долгиежеend-to-endтестымогут быть запущены позже, например, раз в суткиили перед релизом, а не после каждой сборки, если, например, это большой набор регрессионных тестов.

Также от систем непрерывной интеграции ожидается, что всегда можно будет обнаружить, какой коммит «сломал» тест (привел к ошибочному выполнению).

Для того, чтобы не возникало такой ситуации:



Рисунок 2.7. Результаты автоматического теста

Источник: https://habr.com/

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

Рисунок 2.8.Diff-тесты

Источник: https://habr.com/

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

Устройства для автоматизации

Даже после настройки систем непрерывной интеграции остается вопрос какие устройства использовать для тестов. Модульные тесты исполняются на компьютере/сервере с CI-системой, а интеграционные и end2endтесты должны выполняться непосредственно на мобильном устройстве. Здесь имеются разные варианты:

Использовать реальные устройства на ферме, собранной внутри компании. Использование физических реальных устройств, подключенных к ферме, внутри компании, например, с помощью openstf[23]

Использовать эмуляторы

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

Использовать внешние фермы устройств

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

Поэтому обычно выбор делается между первыми двумя вариантами.

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



Глава 3. Необходимость автоматизации

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

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

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

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

Продукт существует долго и накоплено большое количество тестов, ручная проверка которых требует большого количества ресурсов

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

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