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

По сравнению технических характеристик мы видим, что 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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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