11 инструментов для тестирования мобильных приложений


Оглавление (нажмите, чтобы открыть):

Инструменты для автоматизированного тестирования мобильных приложений от A до Z

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

Appium

Кросс – платформенное средство автоматизированного тестирования, работает на многих языках программирования. Единственное требование – должен быть создан HTTP запрос. Обладает лёгким процессом настройки и запуска тестов. Код приложения не должен как-либо изменяться, чтобы тестирование стало возможным. Работает для iOS и Android, на реальных устройствах и эмуляторах. Обладает открытым исходным кодом.

Calabash

Разработан Xamarin и совместим с Cucumber. Обладает двумя библиотеками: для iOS и для Android. Также позволяет тестировать как нативные так и гибридные приложения. Хорошо совместим с Ruby, Java, .NET, Flex и другими языками программирования. Бесплатная open-source тула.

Eggplant

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

Frank for iOS

Это тестовый фреймворк только для iOS, объединяющий в себе Cucumber и JSON. Как и многие другие тулы является open-source и не требует модификации кода. Статически связанный сервер внутри приложения интерпретирует и выполняет UISpec и JSON команды. Больше подходит для эмуляторов и web-приложений.

iOS Driver

Использует Selenium и WebDriver API для тестирования мобильных приложений на iOS. Основной акцент сделан на работу на эмуляторах, где выполнение тестов более быстрое и масштабируемое. Не требует никаких манипуляций с кодом приложения. iOS Driver разработан для использования в качестве ноды Selenium Grid, что позволяет увеличить скорость тестов и предоставляет возможность параллельного тестирования. Распространяется свободно.

Keynote

Разработан компанией Dynatrace, один из лидеров в автоматизированном тестировании мобильных приложений. Keynote являет облачным решением, которое облегчает процесс тестирования. Возможная тесная интеграция с Agile. Уменьшает цикл разработки автотестов. Данный инструмент платный.

KIF расшифровывается, как Keep It Functional. Предназначен для тестирования под iOS. Использует API встроенное в iOS, чтобы моделировать реальное взаимодействие с пользователем. Тесты пишутся на Objective C, который уже знаком разработчикам под iOS. Распространяется свободно.

MonkeyTalk

Очень мощный инструмент, который позволяет тестировать начиная от smoke – тесто и заканчивая сложными взаимодействиями используя различные источники данных. Может использоваться как разработчиками, так и тестировщиками. MonkeyTalk состоит из IDE, в которой пишутся тесты, Agent, который является инструментальной тестовой библиотекой и Scripts, использующий простой синтаксис для выполнения тестов. Тесты могут принимать входные данные из таблиц с использованием формата CSV. Подходит для Android и iOS.

NativeDriver

Это разработка Google и является реализацией WebDriver API, который взаимодействует с UI приложения. Поддерживает тестирование на различных платформах и браузерах.

Ranorex

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

Основные этапы тестирования мобильных приложений

Ваш пошаговый алгоритм тестирования мобильных приложений

Обеспечение качества (QA, от английского — Quality Assurance) является неотъемлемой частью жизненного цикла разработки любых приложений, включая мобильные. К сожалению, многие упускают из виду критические особенности тестирования мобильных приложений, которые часто приводят к сбоям, ошибкам в работе приложения и плохому качеству обслуживания клиентов.

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

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

Давайте рассмотрим особенности тестирования мобильных приложений.

Цикл жизни спринтов

Этап 1: Планирование

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

Вы должны определить следующее:

  • Взаимодействует ли ваше приложение с другими приложениями?
  • Насколько функциональны все возможности приложения?
  • Является ли тестируемое мобильное приложение нативным, Mobile-web или гибридным?
  • Ограничена ли задача тестирования приложения тестированием только внешнего интерфейса?
  • Стоят ли задачи на тестирование бэкенда?
  • Какова должна быть совместимость с различными беспроводными сетями?
  • Как сильно данные приложения и свободное пространство, занимаемое им, зависят от особенностей использования приложения?
  • Насколько быстро загружается ваше приложение, насколько быстро происходит серфинг по меню приложения и его функциям?
  • Как будет обрабатываться возможное увеличение нагрузки на приложение?
  • Влияют ли различные изменения в статусе и состоянии телефона на работу мобильного приложения?

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

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

Этап 2. Определение необходимых типов тестирования мобильных приложений

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

Определите, на какие целевые устройства направлено данное приложение, и какие требования к функционалу следует проверить.

Вы также должны определить, какие целевые устройства нужно включить в список тестирования.

Вы можете сделать это следующим образом:

• Выяснить, какие устройства будет поддерживать приложение;
• Определить, какая версия операционной системы будет самой ранней из тех, что поддерживаются приложением;

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

Этап 3: Тестовые случаи и разработка сценариев тестирования приложения


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

В дополнение к функциональным тестовым случаям, также должны быть охвачены некоторые отдельные моменты (кейсы):

• Особенность использование батареи;
• Скорость работы приложения;
• Требования к данным;
• Объем используемой памяти.

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

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

Этап 4: Ручное и автоматическое тестирование

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

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

Этап 5: Тестирование юзабилити и бета-тестирование

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

Пример матрицы поддержки разных версий платформы iOs

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

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

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

Тестирование пользовательского интерфейса

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

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

Тестирование пунктов меню, кнопок, закладок, истории, настроек и навигации по приложению.

Тестирование внешних факторов

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

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

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

Этап 6: Тестирование производительности

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

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

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

Функциональное тестирование

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

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

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

В рамках функционального тестирования, вам следует выполнить следующие тесты:

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

Этап 7: Аттестационное тестирование и тестирование безопасности приложения

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

Убедитесь, что тестируемое приложение надежно защищено. Выполните проверку на возможность внедрения SQL инъекций, на возможность перехвата сеансов, анализа дампов данных, анализа пакетов и SSL трафика.

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

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

• Есть ли у приложения сертификаты безопасности?
• Использует ли приложение безопасные сетевые протоколы?
• Существуют ли какие-либо ограничения, например количество попыток входа в систему до блокировки пользователей?

Этап 8: Тестирование устройства

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

Этап 9: контрольный этап и резюме

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

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


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

Итоговый отчет о тестировании

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

Этот отчет должен включать:

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

Следует также указать в отчете, что:

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

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

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

В данной статье мы рассмотрели особенности тестирования мобильных приложений. Рассмотренные этапы тестирования важны и для тестирования андроид приложений и как ответ на вопрос как тестировать приложения для iphone.

Важно помнить, что тестирование приложений перед представлением на рынке – важный этап в разработке любых приложений. И, конечно же, тестирование мобильных приложений имеет свои особенности и важные моменты.

Ответственно подходите к вопросу разработки и тестирования мобильных приложений, своевременно изучая и применяя актуальные методики и технологии. С нашей стороны мы рекомендуем для изучения курс на ITVDN — Unit тестирование для Android разработчиков.

Также Вам могут быть интересны:

  • Видео курсы по специальности Quality Assurance
  • Видео курсы по специальности Andro >

Тестирование мобильных приложений

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

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

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

Способы тестирования продукта

Существует две техники тестирования продуктов:

  • Тестирование готовых модулей и программы в целом;
  • Разработка через тестирование. Сначала пишется тест для создания желаемого изменения, а потом код.

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

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

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

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

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

Недостатки модульного тестирования

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

Функциональное тестирование

Когда завершена сборка продукта, проводится итерация, а потом быстрое тестирование. Для начала в ход пускаются smoke-тесты, чтобы проверить готовность к тестированию цельного продукта (в нашем случае – мобильное приложение). После исправления обнаруженных багов идет сверка описания заданных параметров и результата.

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

  • Функциональная пригодность.
  • Точность.
  • Способность к взаимодействию.
  • Соответствие стандартам и правилам.
  • Защищенность.

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

Не стоит забывать об интеграции мобильного приложения с автоматическими инструментами аналитики Flurry. Этот вопрос требует проведения дополнительного ряда тестов на совместимость. Очень важный пункт тестирования мобильных приложений – проверка работы в нестандартных условиях, например, имитация хаотичных действий пользователя. Для устройств Android и iOS существует специальный инструмент – monkey-тест. На других устройствах можно проводить этот тест вручную.

Инструменты тестирования мобильных приложений

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

А/В тестирование или сплит-тестирование

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

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

Методика предусматривает выполнение ряда условий:

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


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

Источники сплит-тестирования лучше задействовать те, на которых впоследствии будете выставлять свою рекламную кампанию: выставив объекты тестирования на своей страничке в Facebook, вы получите более лояльные отзывы, чем на других платформах, за использование которых придется платить. Безусловно, данный метод тестирования позволяет улучшить внешний дизайн без изменений начинки и используется при достижении оптимальных внутренних показателей. Наша команда готова помочь вам реализовать А/В тестирование для улучшения «продаваемости» вашего мобильного приложения!

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

Автоматизация тестирования – тема не новая, однако мобильная автоматизация стала трендом относительно недавно. И востребованность сервиса постоянно растет. Вызвано это тем, что мобильные приложения становятся более функциональными, перенимая роль настольных ПК.

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

Преимущества мобильной автоматизации

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

  • Быстрое получение результатов;
  • Исключение человеческого фактора;
  • Параллельное тестирование на множестве устройств;
  • Возможность покрыть множество локалей.

Преимущества весомые, но и минусов хватает:

  • Автотесты перестают работать с обновлением операционной системы. Поэтому после каждого обновления ОС придется ждать, пока обновятся инструменты для разработки автоматических тестов.
  • Сложность в написании тестов. Сравните: на написание одного автотеста для веб-приложения в среднем уходит 8 часов, а мобильного – около 20 часов.
  • Нестабильная работа многих инструментов.
  • Для мобильных платформ существует множество отличных друг от друга UI-компонентов. В силу многообразия разработать один инструмент, способный работать с любыми типами UI, либо физически невозможно, либо его использование является чрезвычайно трудоемким, технически сложным и, как следствие, экономически невыгодным.
  • Требования к iOS: все ipa-файлы должны быть подписаны разработчиками.

Выбор подхода и инструментов для автоматизации

С автоматизацией тестирования веб-приложений все более-менее ясно: Selenium WebDriver – самый популярный инструмент на рынке, который освоили все профессиональные команды по тестированию. А вот при автоматизации тестирования мобильных приложений однозначного ответа при выборе инструмента нет.

Однако главный вопрос касается не выбора инструмента, а подхода. Именно выбранный подход предопределит инструмент для последующей разработки автотестов.

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

  • Record and Play
  • Screen Object

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

Плюсы: быстрая реализация, не требуется знаний программирования;
Минус: малейшие изменения в приложении потребуют создать новый автотест.

Второй подход – Screen Object – паттерн, предназначенный для организации архитектуры автотестов в виде взаимодействия экранов приложения.

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

Плюсы:

  • Есть возможность переиспользовать код;
  • Надежность кода, небольшая чувствительность к изменениям в приложении;
  • Понятная структура.

Минусы:

  • Требует знаний языков программирования;
  • Скорость разработки.

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

Итак. Подход выбран. Теперь время выбрать инструмент.

Инструментов для автоматизации много. На рисунке ниже изображены самые популярные из них. Но важно отметить, что некоторые из них подходят для приложений, написанных на конкретном языке программирования. Например, Xamarin (левый нижний угол) подходит только для приложений на С#. Некоторые – стоят немалых денег (например, утилита Ranorex).

Поэтому очень важно до начала внедрения автоматизации взвесить все «за» и «против» не только самого процесса, но и инструмента для ее реализации.

Команда a1qa рекомендует использовать фреймворк Appium.

Appium — инструмент для автоматизации тестирования на iOS и Android

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

Несомненными преимуществами Appium является простота в использовании, а также поддержка многих языков программирования: Java, Ruby, Python, C#, PHP.

Прежде чем начинать работать с Appium, необходимо настроить окружение из следующих компонентов:

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

Затем устанавливаем Xcode, а также Android Studio вместе с Android SDK. Это необходимо для того, чтобы позже при необходимости установить необходимые эмуляторы.

Выбрав язык программирования, на котором будут разрабатываться тесты, необходимо установить соответствующий набор библиотек. Например, для написания автотестов для Android и iOS с выбранным языком программирования Java потребуется Java Development Kit.

После того как программное обеспечение будет установлено, можно позаботиться и о приложении. Вам понадобится .apk-файл для Android-приложения либо .ipa-файл для iOS для того, чтобы при запуске тестов данное приложение было установлено на выбранное устройство. Если приложение не было установлено на устройстве, то код тестов его установит, а затем запустит сами тесты.

Что использовать: настоящие устройства или эмуляторы?


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

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

Учитывая это, команда автоматизаторов a1qa настоятельно рекомендует проводить тестирование на реальных устройствах.

Вместо заключения

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

Рейтинг платформ и сервисов для тестирования мобильных приложений 2020

Эмуляторы, бета-тестирование, тест-кейсы

# Компания Год Бесплатная версия Цена (в месяц), $
Xcode 2001
Android SDK 2007
$ Directual 2020 Low-code платформа — фреймворк для быстрой разработки
+1 Genymotion 2013 $11–34
TestFlight 2010
Crashlytics 2011
new TeamCity 2006 $20 (сервер), $25 (облако)
new HockeyApp 2011
−3 TestRail 2009

Среди других платформ и сервисов для тестирования мобильных приложений при обработке данных респондентов рассматривались Espresso, Fabric, HockeyApp и TeamCity.

О рейтинге

Рейтинг платформ и сервисов для тестирования мобильных приложений проводится Тэглайном в третий раз и сформирован на основе анкетирования (проводилось с апреля 2020 по май 2020 года) 100+ digital-компаний с экспертизой в mobile: респондентам предлагалось ответить на вопрос «Какие платформы и сервисы (включая эмуляторы) для тестирования приложений и других решений для мобильных устройств вы используете?».

В Топ вошли инструменты тестирования iOS SDK и Android SDK, эмуляторы, сервисы для бета-тестирования и система для ведения тестовой документации и учета результатов выполнения тестов.

Динамика приводится по сравнению с данными, полученными Тэглайном за период с июля 2020 по май 2020 года.

Комментарии экспертов

1. В чем основные отличия в принципах тестирования мобильных и веб-приложений?

Сергей Денисюк, MobileUp
Принципы тестирования зависят от тест-кейсов и не зависят принципиально от платформы, особенно в плане логики.

Максим Десятых, Redmadrobot
При тестировании мобильных приложений нужно учитывать, что существует большое количество таргет-девайсов (планшетов, телефонов и т. д.) с сильно разными характеристиками, ограничениями по производительности, размеру экранов и плотности пикселей. Необходимость тестировать специфичные для разных сетевых подключений кейсы (LTE, 3G, Wi-Fi), обращать отдельное внимание на LBS\GPS сценарии и на тестирование взаимодействия с нативными приложениями ОС, прерываниями системы и нативными permissions. Важно следить за прохождением приложений ревью Apple \ Google и соответствием их требованиям, также процесс обновления приложений в магазинах требует отдельного тестирования и повышенного внимания. С точки зрения автоматизации тестирования много своей специфики, которой нет у веба и десктопа.

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

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

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

Денис Царев, Morizo
Основное отличие в том, что надо тестировать на реальных девайсах. Тестирование в эмуляторах мало результативно и позволяет отловить только самые вопиющие вещи. В этом ключе рост фрагментации платформ дает очень серьезную нагрузку на бюджет лаборатории, и разработчики начинают смотреть в сторону сервисов типа Amazon Device Cloud.

2. Есть ли какие-либо различия в тестировании приложений на различных мобильных платформах?

Сергей Денисюк, MobileUp
Каждая мобильная платформа имеет индвидуальное, присущее лишь ей поведение: жесты, анимация, компоновка.

Максим Десятых, Redmadrobot
Существуют принципиальные различия в используемых инструментах тестирования, специфике публикации в сторах и большей сегментации Android-девайсов. Есть определенные, накопленные опытом edge cases (пограничные кейсы), которые отличаются от платформы к платформе и находятся за рамками базового набора тестов.

Вадим Митякин, Проектное бюро Eleven
Разница определяется возможностями сред разработки. В последнее время между iOS и Android наметился паритет, но, правда, в основном за счет сторонних средств тестирования.

3. Как распределяются приоритеты в тестировании мобильных приложений?

Сергей Денисюк, MobileUp
High — приложение крашится, middle — неверная логика работы (баги), low — кривой UI, новые фичи, улучшения. Зачастую в middle попадают новые фичи, если они действительно нужны в текущей итерации.

Максим Десятых, Redmadrobot
Для нас приоритет чаще всего будет следующим: функциональное тестирование, smoke test, bug verification, FT, regression test по тест-кейсам или чек-листу по приоритетам, ad hoc, нефункциональное тестирование (security, performance, UI/UX).

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

Сергей Денисюк, MobileUp
Есть несколько методологий тестирования, распространенных среди разработчиков. Особых трендов тут нет. Каждый тестирует в меру своей ответственности, часто это происходит в обход сторонних сервисов. В каждой программной среде есть встроенные утилиты, в Xcode, например, мы проверяем на утечки в памяти, частоту и размер серверных запросов, плавность работы.

Тестирование мобильных приложений

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

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

Согласно отчету Clearwater Technology Team (www.clearwatercf.com/documents/library/Mobile_Report_FINAL.pdf), в 2015 году доходы мобильной отрасли достигнут 330 млрд долл., однако стремительный рост спроса на мобильные устройства (особенно на смартфоны и планшеты), а также на специально разработанные для них программы сопровождается увеличением потребности в адекватных качественных инструментах тестирования [1]. В прогнозе компании ABI Research говорится, что объемы продаж таких инструментов, которые сегодня используются главным образом в ручном режиме, но все чаще начинают применяться и в автоматическом режиме, возрастут с 200 млн долл. в 2012 году до 800 млн долл. в 2020-м (www.abiresearch.com/press/200-million-mobile-application-testing-market-boos).

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

  • белый ящик (объект исследования с известными свойствами) и модульное тестирование мобильных приложений;
  • черный ящик (объект исследования, внутреннее устройство которого неизвестно) и тестирование графического интерфейса мобильных приложений;
  • валидация требований к качеству обслуживания (Quality of Service, QoS) приложений;
  • тестирование беспроводных сетей;
  • тестирование удобства использования мобильных приложений;
  • инфраструктура для автоматизации тестирования мобильных технологий.

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

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

Требования

Тестирование мобильных приложений отличается от тестирования обычного ПО наличием ряда уникальных требований. Прежде всего, мобильные приложения должны правильно выполняться в любое время и в любом месте. Необходимо, чтобы они корректно функционировали на разных платформах, которые отличаются используемыми операционными системами, размерами экрана, вычислительными ресурсами и продолжительностью непрерывной работы от батарей. Мобильные приложения должны поддерживать множество каналов ввода (клавиатура, голос, жесты и т. д.), мультимедийные технологии и обладать другими особенностями, повышающими удобство их использования. Для удержания низких цен на оборудование необходимо широко использовать средства моделирования и виртуализации. И наконец, поскольку большинство мобильных сервисов поддерживают достаточно широкий спектр беспроводных сетей (2G, 3G, 4G, Wi-Fi, WiMax), мобильные приложения должны нормально функционировать в неоднородной сетевой среде.

Цели и мероприятия

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


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

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

Подходы к тестированию

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

Рис. 1. Инфраструктуры мобильного тестирования: a — эмуляция, б — облако, в — устройства, г — краудсорсинг

Тестирование на основе эмуляции. Этот способ тестирования предусматривает использование эмулятора мобильного устройства, имитирующего его поведение в виртуальной машине. Довольно часто такие эмуляторы бывают включены в состав комплекта инструментов для разработчика, прилагаемого к мобильной платформе (например, в состав SDK Android). Цена такого решения относительно невелика, потому что в этом случае нет необходимости в создании тестовой лаборатории, покупке или аренде физических устройств. Однако эмуляцию можно использовать только для оценки функциональности системы в весьма ограниченном контексте. Такой подход недорог, но у него есть ряд существенных недостатков. Например, проверить обработку всех жестов в полном объеме довольно затруднительно, потому что большинство эмуляторов поддерживают лишь ограниченный набор жестов и лишь специфичные для конкретного устройства функции. Другой недостаток связан с ограниченными масштабами тестирования QoS.

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

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

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

Тестирование с использованием краудсорсинга. Краудсорсинговый подход предполагает привлечение фрилансеров, инженеров, работающих по контракту, или сообществ конечных пользователей наподобие uTest (www.utest.com), а также формирование краудсорсинговой тестовой инфраструктуры и установку сервера управления сервисами для поддержки неоднородных пользователей. Сегодня провайдеры сервисов по реализации такого подхода предлагают базовое управление тестами, сервис тестирования и выдачу отчетов об ошибках. Однако большинство тестовых мобильных операций управляются инструментами автоматизации мобильного тестирования с весьма ограниченными возможностями — тестировщики получают преимущества стихийного тестирования, не требующего проведения инвестиций в лабораторию и покупку или аренду устройств, но возникает риск низкого качества тестирования и неопределенности сроков его проведения.

Тестирование мобильных и веб-приложений

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

Основные цели тестирования

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

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

Тестовая среда

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

Пользовательские интерфейсы

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

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

Технология автоматизации тестирования мобильных приложений

Технологиями автоматизации тестирования мобильных приложений обладают среды программирования Java (Android), Objective-C (iOS) и Visual C++ (Windows Mobile); стандартизированные SDK и инструменты разработки, распространяемые поставщиками устройств, а также платформы для разработки приложений.

Для мобильных веб-приложений технологии автоматизации тестирования предлагаются в форме HTML5, CSS3 и JavaScript. Разработчик приложения может также использовать серверные языки и среды, такие как PHP, Rails и Python.

Тестирование связности мобильных приложений

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

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

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

Тестирование удобства использования

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

Тестирование мобильных веб-приложений должно быть ориентировано на проверку контента графического интерфейса и последовательности пользовательских операций. Например, мобильное приложение для путешественников Dwellable (www.dwellable.com) поддерживает соответствующий контент для мобильных браузеров на разных языках. Выбор языка зависит от текущего местоположения пользователя. Оценка таких мобильных приложений должна предусматривать тестирование удобства использования и подтверждать качество мобильного контента, форматов представления, стилей и языков.

Тестирование мобильности

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

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

Особенности мобильных приложений

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

Инструменты тестирования

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

Рис. 2. Тестовые процедуры, применяемые в ходе испытаний мобильного приложения. Тестовые процедуры для программ, специально предназначенных для мобильных устройств (a), и мобильных веб-приложений (б) отличаются, но преследуют одинаковые цели
  • Шаг 1. Компонентное тестирование — тестирование черного и белого ящиков, а также взаимодействия со специфичными для устройства API.
  • Шаг 2. Функциональное тестирование — проверка функций, сценариев на базе графического интерфейса и специфичного для конкретного устройства поведения приложения (например, распознавания жестов).
  • Шаг 3. Тестирование QoS — проверка атрибутов QoS, в том числе производительности, устойчивости, готовности и безопасности.
  • Шаг 4. Тестирование особенностей приложения — проверка подключения к сети, совместимости, интероперабельности, мобильности и удобства использования.
  • Шаг 5. Тестирование сервисов — проверка сервисов мобильных приложений, включая загрузку, установку, развертывание, безопасность и синхронизацию.

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

  • Шаг 1. Компонентное тестирование — проверка качества программных компонентов на мобильных веб-клиентах и связанных с ними серверных компонентах с использованием методов тестирования черного и белого ящиков.
  • Шаг 2. Системная интеграция — тестирование интеграции компонентов с системой (мобильным клиентом и сервером).
  • Шаг 3. Функциональное тестирование — проверка качества функционирования мобильных веб-сервисов, сквозных бизнес-транзакций, сценариев на базе графического интерфейса, поведения и обработки жестов мобильными системами.
  • Шаг 4. Системное тестирование — оценка требований к QoS, в том числе к общей производительности системы, нагрузке, устойчивости, готовности, безопасности и масштабируемости.
  • Шаг 5. Тестирование особенностей, мобильной связности, совместимости, удобства использования, интероперабельности, безопасности и интернационализации.


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

Наиболее популярными платформами для тестирования мобильных приложений являются Windows, Linux и Mac. Большинство инструментов поддерживают сразу несколько платформ, кроме Keynote MITE, который работает только на Windows.

Большая часть перечисленных инструментов позволяет тестировать как приложения, специально предназначенные для мобильных устройств, так и мобильные веб-приложения, а Selendroid, Appium и Calabash поддерживают только тестирование специальных мобильных приложений.

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

Большинство приведенных в таблице инструментов поддерживают как эмуляцию, так и тестирование на базе мобильных устройств, хотя есть несколько исключений. Инструменты eggplant и MonkeyRunner предназначены для тестирования на основе эмуляции, а QTP MobileCloud поддерживает только тестирование на базе устройств.

Все перечисленные инструменты позволяют использовать возможности сценариев, а многие поддерживают сразу несколько языков и технологий: Java, Python, Jython. Некоторые инструменты (например, MITE и MonkeyTalk) поддерживают JavaScript.

Во многих случаях пользователям придется оформлять подписку или лицензионный договор, но есть и предложения с открытым кодом, которые могут оказаться полезными при построении собственных сервисов тестирования мобильных приложений. В качестве примеров здесь можно привести Appium, Selendroid и Calabash. Многие средства (например, Gomez) служат для оценки контента и производительности мобильных веб-сайтов.

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

Вопросы, трудности и потребности

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

Тестовые среды

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

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

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

Стандарты, моделирование и критерии охвата

Современные стандарты тестирования программного обеспечения — ISO/IEC/IEEE 29119 и ISO12207 — представляют собой четкое руководство по организации, выполнению и документированию процедур тестирования. Существующие тестовые модели и критерии охвата могут помочь в проверке структур мобильных программ, их динамического поведения и последовательности операций графического интерфейса, однако сегодня нужны стандарты, тестовые модели и критерии охвата, которые позволяли бы сформулировать четкие требования к тестированию мобильных приложений.

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

Автоматизация тестирования

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

Согласно исследованию Juniper Research, рынок мобильных облачных приложений в период с 2009 по 2014 год вырос на 88%, что привело к дальнейшему увеличению спроса на решения, предназначенные для автоматизации тестирования мобильных программ. Облачное тестирование является эффективным и перспективным способом удовлетворения растущих потребностей в тестировании мобильных приложений. Сегодня мы видим здесь две основные тенденции: совместное использование различными провайдерами облаков мобильных устройств для задач тестирования и развитие краудсорсинговых сервисов тестирования, ориентированных на оценку удобства прменения и интернационализации. Эта область в дальнейшем будет расширяться, и, возможно, облака предложат какие-то дополнительные пути удовлетворения растущих потребностей в качественных инструментах тестирования мобильных программ.

11 инструментов для тестирования мобильных приложений

Your browser is not supported anymore. Please update to a more recent one.

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

…несмотря на то, что он кое в чём неполон, содержит много сомнительного или,
во всяком случае, вопиюще неточного, он имеет два важных преимущества:
во-первых, он немного дешевле, [. ], а во-вторых, на его обложке большими
и приятными для глаз буквами написаны два слова «Без паники!»
— The Hitchhiker’s Guide to the Galaxy
Привет, Хабр!

Меня зовут Арсений Батыров, я работаю в отделе QA Badoo и занимаюсь в основном ручным тестированием веб-приложений. А ещё я веду курсы по ручному и автоматическому тестированию мобильных приложений.

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

Я преследовал три цели:

  1. Классифицировать инструменты в стеке автотестирования, чтобы стали понятны их иерархия и сочетаемость.
  2. Показать, какие инструменты популярны сегодня на рынке.
  3. Рассказать про самые популярные инструменты каждого типа и сравнить их по нескольким параметрам.

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

  • Выбираете инструмент — посмотрите сравнение.
  • Хотите узнать, как устроена автоматизация на мобильных устройствах — загляните в классификацию.
  • Хотите добиться повышения зарплаты — освойте популярный инструмент.

Содержание

Приложение и тесты

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

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

API(application programming interface) — основной интерфейс для взаимодействия с другими программами.

GUI (graphic user interface) — графический интерфейс, используется для взаимодействия с пользователем.

Net (networking interface) — работает через сеть и используется как продвинутыми пользователями, так и программами.

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

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

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

Всего существует четыре группы инструментов: драйверы, надстройки, фреймворки и комбайны. Рассмотрим их подробнее.
class


Классификация инструментов

Драйвер

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

Драйвер — программа, которая предоставляет API для одного из интерфейсов приложения.

Для каждого интерфейса, кроме, собственно, API, необходим свой драйвер. Например, когда вы даёте драйверу для GUI команду “Нажать на кнопку Menu”, он воспринимает её через API и отсылает в тестируемое приложение, где эта команда превращается в клик по графической кнопке Menu. Для взаимодействия с API приложения драйверы не нужны или почти не нужны — взаимодействие программное. А вот при работе с остальными интерфейсами без них не обойтись.

Наиболее сложными обычно являются драйверы для GUI, так как этот интерфейс сильно отличается от обычного для программы общения кодом. При этом в автоматизированном тестировании мобильных приложений GUI наиболее актуален, так как в интеграционном тестировании использовать чаще всего приходится именно его. Наиболее популярные драйвера для GUI в мобильном тестировании — UIAutomator и Espresso для Android, XCUITest — для iOS.
cl_wrapper

Надстройка

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

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

У надстройки могут быть следующие функции:

  1. Модификация поведения (без изменения API).
    Например:
    • дополнительное протоколирование,
    • валидация данных,
    • ожидание выполнения действия в течение определённого времени.
  2. Повышение удобства и/ или уровня абстракции API через:
    • использование синтаксического сахара — удобных названий функций, более коротких обращений к ним, унифицированного стиля написания тестов;
    • неявное управление драйвером, когда, например, он инициализируется автоматически, без необходимости прописывать каждое такое действие вручную;
    • упрощение сложных команд вроде выбора события из календаря или работы с прокручивающимися списками;
    • реализацию альтернативных стилей программирования, таких как процедурный стиль или fluent.
  3. Унификация API драйверов.
    Здесь надстройка предоставляет единый интерфейс для работы сразу с несколькими драйверами. Это позволяет, например, использовать один и тот же код для тестов на iOS и Android, как в популярной надстройке Appium.

cl_framework

Фреймворк

С другой стороны тестов находится фреймворк запуска. В рамках данной статьи я буду коротко называть его “фреймворк”.

Фреймворк — это программа для формирования, запуска и сбора результатов запуска набора тестов.

В задачи фреймворка входят:

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

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

Если драйверы и надстройки находятся между тестами и приложением, то фреймворк находится над тестами, организуя их запуск. Поэтому важно не путать понятия “драйвер” и “фреймворк”. Конечно, в некоторых фреймворках есть собственные драйверы для работы с приложениями, но это вовсе не обязательное условие. Самые заметные фреймворки в мобильном тестировании — xUnit и Cucumber.
cl_combine

Комбайны

Наконец, ещё одна группа утилит, использующихся для автоматизации тестирования мобильных приложений, — это комбайны, объединяющие в себе и фреймворки, и драйверы (причём не только мобильные), и даже возможности разработки. Xamarin.UITest, Squish, Ranorex — все они поддерживают автоматизацию тестирования iOS-, Android-, веб-приложений, а два последних — ещё и десктоп-приложений.

Итак, инструменты мы классифицировали. Осталось определить самые популярные в каждой категории и сравнить их.
quiz

Опрос

Для выявления самых популярных и используемых утилит я провёл опросы на нескольких сайтах, сообществах и каналах для QA-инженеров, задав три простых вопроса. Количество вариантов ответа я не ограничивал, чтобы не пришлось выбирать между разными типами инструментов. Также была возможность добавить собственный вариант — так появился достаточно длинный “хвост” из различных утилит, не вписывающихся в классификацию. Результаты не претендуют на статистическую точность, но отлично иллюстрируют тренды в индустрии автоматизации тестирования мобильных приложений по состоянию на январь 2020 года.

Как видно из результатов, лидирующие позиции занимают утилиты на базе WebDriver: Appium и Selenium. Из фреймворков наиболее популярны JUnit и Cucumber, причём второй популярнее — это удивляет, ведь у них всё-таки разные “весовые категории”. Официальные драйверы популярнее неофициальных для любых платформ — видимо, из-за качественной поддержки и большего количества возможностей, чем у сторонних разработок.

Тройка самых используемых языков программирования выглядит так: Java, Python, Ruby (причём Java лидирует с большим отрывом). Попадание Ruby в тройку лидеров я связываю с популярностью Cucumber.

Наконец, распределение по платформам довольно ожидаемое — Android с серьёзным отрывом опережает iOS, дальше идёт Mobile Web. Удивили разве что ответы про десктоп-приложения для Windows в последнем опросе, но некоторые комбайны позволяют тестировать мобильные и десктопные приложения одновременно.

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

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

Драйверы

В мобильном тестировании драйверов немного, и зачастую они разрабатываются теми же компаниями, что и операционные системы. Для Android есть два официальных драйвера: UIAutomator, который на сегодняшний день имеет версию 2.0, и Espresso. Оба они входят в Android Testing Support Library, разрабатываются компанией Google и хорошо документированы. Помимо них, существуют проекты Robotium и Selendroid, которые разрабатываются сторонними компаниями. Все четыре продукта так или иначе работают на Android Instrumentation Framework — базовом API, который Android предоставляет для взаимодействия с системой.

Сначала давайте рассмотрим драйверы от Google. Оба инструмента умеют работать с WebView и гибридными приложениями, оба поддерживают разработку на Java и Kotlin и работают как с эмуляторами, так и с реальными устройствами.
uiautomator

UIAutomator

UIAutomator поддерживает версии Android начиная с API level 18 (Android 4.3). Он не требует внедрения своего кода в проект, то есть может взаимодействовать с уже скомпилированными приложениями. Более того, при работе с UIAutomator можно использовать возможности системы Android полностью: например, включить геолокацию, вызвать системное приложение, повернуть устройство, нажать на кнопку Home или сделать скриншот. Поэтому этот инструмент часто используют для функционального end-to-end-тестирования, самостоятельно или с надстройками.

У UIAutomator нет собственного рекордера для тестов, но зато есть утилита UI Automator Viewer, которая позволяет получать данные об элементах запущенного на эмуляторе или реальном устройстве приложения и показывает локаторы этих элементов. Тут же отображается иерархическая структура всех элементов, что очень удобно для использования их в тестах.

Espresso

Espresso, в свою очередь, предназначен скорее для white-box-тестирования и создавался как инструмент для разработчиков. Он поддерживает более старые API начиная с API level 10 (Android 2.3.3), однако требует доступа к исходному коду для запуска. Соответственно, Espresso не может самостоятельно работать с другими приложениями и системой Android. Зато у этого инструмента есть рекордер, с помощью которого можно записывать простые сценарии и использовать их на начальном этапе автоматизации.

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

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

Кстати, эти инструменты можно использовать и вместе, потому что они — части одной библиотеки. Даже в одном тесте можно сочетать команды обоих инструментов.
selendroid_robotium

Selendroid и Robotium

И Selendroid, и Robotium были выпущены ещё до появления официальных драйверов и существуют до сих пор.

Robotium поддерживает версии Android API начиная с API level 8 и умеет работать с WebView начиная с API level 15. Selendroid же работает c ограниченным списком версий API — от 10 до 19. Оба инструмента могут обращаться только к одному приложению, не требуют доступа к исходному коду и поддерживают работу на эмуляторах и реальных устройствах. Для Robotium тесты нужно писать на Java, а Selendroid поддерживает протокол WebDriver, что даёт возможность использовать практически любой популярный язык программирования.

У Selendroid есть утилита Inspector, с помощью которой можно просматривать иерархию элементов и записывать простые record-and-playback-тесты. А Robotium предоставляет плагин Robotium Recorder для IntelliJ IDEA и Android Studio со схожим функционалом.

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


XCUITest

В iOS для взаимодействия с приложением долгое время использовался драйвер UIAutomation (что, помимо прочего, вызывало путаницу из-за схожести с названием драйвера Android), но начиная с iOS 10 Apple прекратила поддержку этого драйвера, и вместо него появился драйвер XCUITest из пакета XCTest.

Он поддерживает iOS начиная с версии 9.0, а тесты для него пишутся на языках Objective-C и Swift, как и сами приложения. Для тестирования приложения не нужен доступ к его коду, а начиная с Xcode 9 драйвер умеет тестировать несколько приложений, в том числе и системных, одновременно. “Из коробки” XCUITest позволяет запускать тесты только на симуляторах, однако при помощи некоторых сторонних утилит можно заставить его работать и с реальными устройствами.

XCUITest имеет свой рекордер, встроенный прямо в интерфейс Xсode. С его помощью можно записывать простые UI-тесты, а также находить элементы UI и их свойства.

Надстройки

Appium

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

Appium поддерживает множество драйверов, не только мобильные:

  • iOS
    • XCUITest
    • (deprecated) UIAutomation
  • Android
    • (beta) Espresso
    • UIAutomator 2.0
    • (deprecated) UIAutomator
    • (deprecated) Selendroid
  • Windows Driver (для десктопных Windows-приложений)
  • Mac Driver (для десктопных Mac-приложений)

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

  • возможность писать тесты на любом языке, который поддерживает WebDriver (а в этот список входят практически все популярные языки программирования). Более того, это позволяет “отвязать” тесты от использования “родных” для приложения языков. Наиболее актуально это для iOS, ведь тесты на XCUITest можно писать только в Xcode. С Appium же в данном случае можно использовать любой язык и любую удобную среду разработки;
  • лёгкий переход к тестированию гибридных и веб-приложений: протокол WebDriver уже (почти) стал стандартом для автоматизации веба;
  • использование любого тестового фреймворка — почти все они умеют так или иначе работать с протоколом WebDriver, а значит, у них не возникнет проблем с подключением к Appium;
  • отсутствие необходимости добавлять что-то в код приложения — для каждой платформы используются драйверы, которым не нужен доступ к коду. Помимо удобства в развёртывании, это означает возможность тестировать именно тот билд приложения, который увидят пользователи, а не специальную тестовую сборку.

Нас в большей степени интересует поддержка мобильных приложений, поэтому остановимся подробнее на реализациях драйверов UIAutomator 2.0, Selendroid и XCUITest.

Самый простой из них — UIAutomator 2.0, с которым Appium взаимодействует напрямую, передавая ему необходимые команды. Он работает с версиями Android 5.0 и выше. С 4.2 до 5.0 можно использовать UIAutomator 1, а взаимодействие с более старыми версиями обеспечивает уже известный нам драйвер Selendroid. Для взаимодействия с XCUITest и обхода некоторых ограничений используется WebDriverAgent (WDA) от Facebook. WDA запускается в контексте симулятора или реального устройства и передаёт команды через API XCUITest.

Недостатки Appium вытекают из его достоинств:

  • тесты ломаются чаще, чем те, что написаны для нативных драйверов, из-за ошибок в коде самой надстройки. Особенно это актуально для iOS, ведь там добавляется WDA;
  • Appium не умеет находить и сравнивать картинки в приложениях и не может напрямую работать с алёртами в Android;
  • ограниченная поддержку Android API

Mobile QA Engineer

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

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

Курс подойдет для:

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

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

В курсе основной упор на автоматизацию тестирования на Android, но также студент изучит и ручное тестирование, а также тестирование на IOS.

Если у вас нет устройств на IOS, будет использоваться симулятор.

В результате курса вы:

— Процессу тестирования основных параметров мобильных приложений (производительность, соединение, регулирование доступа к ресурсам, локация)
— Поймете разницу в подходах для тестирования мобильных и настольных приложений
— Как тестировать локализацию и интернационализацию приложений
— Как тестировать приложение для людей с ограниченными возможностями
— Использованию Espresso и Mockito для автоматизации мобильных приложений
— Использованию Appium для автоматизации мобильных приложений
— Отладке приложений и созданию качественных баг-репортов
— Научитесь использованию тестовых фреймфорков JUnit, TestNG

Разработаете:
— Тест кейсы для тестирования различных модулей приложения с учетом специфики мобильного тестирования
— Тесты на Espresso и Mockito
— Тесты на JUnit
— Продвинутые тесты на Appium c использованием PageObject и PageFactory

Нагрузочное тестирование мобильных приложений: запись трафика и создание скриптов

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

Введение

Мобильный рынок — один из самых быстрорастущих во всем направлениям: от рекламы до использования в бизнес-сфере.

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

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

Сразу стоит уточнить, что встречается разделение на Protocol-Level Load Generation (протокольный) и Device (User Interface) level Load Generation (нагрузка с помощью мобильного клиента).
Первый вариант – стандартная генерация HTTP-трафика с помощью нагрузочного инструмента.
Второй вариант подразумевает наличие реальных устройств, которые создают нагрузку с помощью клиента.
Также есть разделение на производительность непосредственно приложения (в том числе потребление ресурсов “железа” и расход батареи), производительность сервера и производительность сети.

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

Для этого используются те же инструменты, что и для работы с веб-приложениями: Fiddler, jMeter, LoadRunner и т.д.
В данном случае мы используем только бесплатные инструменты.

Дальнейшие шаги делались на устройствах iPhone и iPad, так же данный метод был проверен на устройствах с Android на борту.

Запись трафика

Общая схема записи трафика выглядит следующим образом:

  1. Выбор устройства с приложением, работу которого требуется эмулировать.
  2. Настройка прокси-сервера, который будет записывать и перенаправлять запросы клиента на сервер (и ответы от сервера клиенту).
  3. Подключение устройства к прокси-серверу.
  4. На мобильном устройстве выполняются бизнес-операции, которые необходимо записать.


Для этого нам сойдет любая из программ, у которой есть такая функция. В примере ниже используется Fiddler 4, но возможно использовать и Jmeter.

Первым делом нужно установить на устройство сертификат безопасности нашего proxy — SSL сертификат, который позволит нам пропустить и расшифровать HTTPS-трафик через Fiddler.

В Fiddler нужно проставить настройки на расшифровку HTTP(S) трафика и подключение удаленных компьютеров:

Далее нужно вручную настроить прокси подключение на устройстве:

Сертификат находится по адресу http://ipv4.fiddler:номер_порта/.
Скачиваем его через браузер и устанавливаем. На Samsung Galaxy S7 (Android 7.0.1) было недостаточно просто кликнуть по сертификату, несмотря на сообщение об успехе, сертификат отсутствовал в системе. Решилось установкой сертификата через параметры безопасности.

Ту же операцию можно проделать с jMeter HTTP(S) Proxy Recorder.

Создание скрипта

Запускаем приложение и делаем все необходимые операции, которые потребуются для скрипта.

После того, как создан тест-план, коррелируем значения и проверяем, правильно ли выполняется скрипт.

На данном этапе процесс идентичен стандартной отладке скрипта.

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

На практике с приложением

Тестируемое приложение Gloopt – сервис по созданию канала с возможностью делится своими видеороликами длительностью до 1 минуты.
Трафик мы записали через Fiddler, так как jMeter не позволил нам воспроизвести видеоролик и загрузить клип на сервер.
Для конвертирования запросов в скрипт jMeter’а мы использовали плагин авторства нашего коллеги, Дениса Скорнякова (https://git.performance-lab.ru/d.skornyakov/FiddlerJmxCreator) – он сохраняет сессию в .jmx файл. Предварительно прямо из Fiddler можно коррелировать значения.

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

Обмен сообщениями между клиентским приложением и сервером выглядит примерно так:

1. Сначала запрашивается информация о файле, из респонза мы узнаем его размер в байтах.

2. Далее приложение посылает запрос на некий отрезок файла, например, от нуля.

Выглядит как “Content-range: bytes был = 0-“, сервер возвращает уже конкретный отрезок, “ Content-range: bytes был = 0-37895”.

Следующий запрос клиента запрашивает часть от 37896 и так далее, пока не дойдем до конца.

В Fiddler, кстати, реквесты со стороны клиента уходили с определенным диапазоном. Поначалу было непонятно, каким образом приложение формирует запрос.
Зато в деббагере Chrome можно было увидеть, что запрашиваемый диапазон зависит от респонза сервера.
Соответственно, получая длину контента, делим его на n частей и через While симулируем просмотр видео.

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

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

В частности, для загрузки видео надо было удалить Content-Type из header’a, прописать MIME Type у отправляемого файла, поставить галочки у “Use multipart/form data for POST” и “Browser-compatible headers”, что не было сделано при конвертации запроса из Fiddler (там сам запрос построен немного по-другому).

Альтернативный вариант записи трафика для Android

В случае, если тестируемое приложение работает под Android, есть альтернативный вариант записи трафика. Для его использования понадобится устройство и приложение Packet Capture. Данное приложение не требует Root-привилегий, может расшифровывать HTTPS трафик и почти полностью автоматически позволяет создать сертификат для расшифровки такого трафика. От пользователя необходимо лишь согласиться с установкой сертификата.

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

По окончанию записи (останавливать запись не обязательно) можно вновь переключиться на Pocket Capture и посмотреть записанные запросы и ответы к ним. На главном экране отображаются все сессии записи. Для просмотра запросов, нужно выбрать текущую сессию (или одну из предыдущих, для просмотра старых записей). Будет отображен список подключений каждого приложения, выходящего в Internet.

Выбираем нужное приложение и видим записанный трафик.

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

Запись трафика банковских приложений

К сожалению, при попытке записать трафик мобильных банковских приложений под платформой Android обоими перечисленными вариантами, приложения отказывались работать, ссылаясь на проблемы с подключением. Вероятно, приложения используют ssl-pinning. Однако, и данное затруднение можно обойти.

Можно попытаться использовать Interceptor-NG, Zaproxy, Mallory Proxy, MITMPROXY, WebScarab, Burp Proxy или SSLSplit для SSL MiTM. Для Android можно попытаться использовать модуль SSL unpinning для Xposed, который позволяет перехватывать стандартные вызовы на проверку сертификатов и отвязывать их, или попытаться пропатчить приложение вручную. Важно помнить, что не существует идеальной технологии, и к задаче нужно подходить творчески.

Заключение

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

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

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

Методы тестирования мобильных приложений на платформе Andro >

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

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

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

Тестирование действительно может сделать вашу жизнь (и код) лучше!

Хотите окунуться в мир мобильной разработки? Рекомендуем профессию «Разработчик мобильных приложений».

Мастер Йода рекомендует:  Вводный курс по TypeScript
Добавить комментарий