Статья опубликована в рамках: XLVIII Международной научно-практической конференции «Научное сообщество студентов XXI столетия. ТЕХНИЧЕСКИЕ НАУКИ» (Россия, г. Новосибирск, 26 декабря 2016 г.)
Наука: Информационные технологии
Скачать книгу(-и): Сборник статей конференции
дипломов
СРЕДСТВА ТЕСТИРОВАНИЯ ПРИЛОЖЕНИЙ ДЛЯ МОБИЛЬНЫХ УСТРОЙСТВ
Популярность использования смартфонов и мобильных приложений делает автоматическое тестирование основным требованием успешной разработки качественных приложений. Существует множество аспектов производительности мобильных приложений, которые необходимо тестировать и улучшать. Мобильные устройства сильно отличаются друг от друга по следующим параметрам: версия ОС; системы команд процессора; размер и разрешение экрана; камеры, NFC и др.
Существует прямая взаимосвязь между производительностью и удобством использования мобильных приложений. Можно выделить три типа автоматизации тестирования:
- тест устройства
- end-to-end сценарий,
- тест пользовательского интерфейса.
- nd-to-end – системное тестирование, при котором приложением управляет тестовый скрипт, симулируя реального пользователя. Данный вид тестирования включает запуск приложения одновременно на различных реальных устройствах, выполняются автоматически некоторые действия (клики, прокрутка экрана). Для проверки реакции приложения на действия пользователя, можно запустить сервис, например, осуществить покупку внутри приложения. Все взаимодействия фиксируются в качестве скриншотов. В рамках тестирования отслеживаются различные компоненты работы в общем процессе. Автоматизация тестирования также применяется вне зависимости от отличий в параметрах дисплея и аппаратного обеспечения. К примеру, в тестовый скрипт вносится информация о разрешении экрана, он идентифицирует определенные элементы [4].
Различные типы тестов уместны на разных этапах жизненного цикла мобильного приложения. Особое внимание при тестировании мобильных приложений уделяется устройствам, отобранные для тестирования, их должно быть как минимум 20. Эти устройства выбирают в зависимости от популярности в определенном географическом регионе. Учитывается параметры: размер экрана, разновидность операционной системы и ее версия.
Приложение тестируется, таким образом, как пользователи могли бы с ним обращаться. Описание таких действий должно быть достаточно полно, для обнаружения большего количества ошибок. Принцип автоматического тестирования приложений, заключается в точной автоматизации действий, выполняемых вручную [3].
Для каждого приложения и каждого устройства нужно выполнить следующие действия: 1) установить приложение на устройство; 2) запустить приложение; 3) протестировать приложение; 4)удалить приложение; 5)сбросить настройки. На каждом этапе сбор и анализ данных.
В таблице 1 представлены несколько средств автоматизированного тестирования функциональности мобильных приложений [2]. Каждое из средств имеет свои достоинства и недостатки, приведенные выше. Как результат, можно сделать вывод:
Calabash- простой удобный инструмент, требующий много времени.
Robotium –простая реализация, нет гибкости под различные устройства;
Monkey –средство, позволяющее проводить только стресс-тестирование;
Appium – инструмент схожий со средством тестирования веб-сайта;
Getvent/sendevent наиболее простой и ограниченный инструмент;
Ranorex –простое в использовании средство, больше подходит для нативных приложений.
Таблица 1.
Средства автоматизированного тестирования Web приложений
|
Метод тестирования |
ОС |
Преимущества |
Недостатки |
|
Calabash Кроссплатформенный фреймворк с открытым исходным кодом. |
Android iOS |
Услуга тестирования в «облаке». Написание сценариев Cucumber. Простота написания тестов. Кроссплатформенные тесты. Отличный Ruby API. Запуск тестов на эмуляторе.
|
Проблема идентификации объектов. Малое количество предписанных шагов для написания сценария. Отсутствие apk-файла. Большие затраты времени для прохождения тестов. |
|
Robotium программа распространяется с открытым исходным кодом |
Android |
Сценарии представляют действия на уровне ПИ приложений, а не на уровне устройства ввода. Тестовый скрипт независим от размеров и расположения элементов, разрешения экрана. Возможность проверить реакцию приложения на действия. |
Необходимость разрабатывать тестовый сценарий на языке Java для каждого приложения. При изменении интерфейса приложения необходимо редактировать сценарий. Сложность в создании сценария. |
|
Monkey поток случайных действий пользователя |
Android |
Отсутствие затрат на обслуживание. Нагрузочное тестирование выявляет сложные и малозаметные ошибки. Независимость от устройства. Возможность в командной строке указать кол-во действий пользователя, процент действий каждого типа.
|
Нет возможности имитировать сложные нагрузки. Приложения, требующие быстрой реакции пользователя, не всегда запускаются. Сложность воспроизведения ошибок. Нет проверки состояния приложения во время тестирования. |
|
Appium HTTP сервер, который создает и управляет сессиями Webdriver
|
iOS/ Android |
Не требует дополнительной модификации тестируемых приложений. В комплекте с сервером имеется инспектор элементов приложения. На базе WebDriver API строятся взаимодействия между сервером и тестом. Тесты для мобильного приложения, схожи с тестами для веб-сайтов. |
Инструмент развивается отдельно от сервера. Инспектор отображает не все атрибуты элементов. Отображаются иногда не все элементы, которые имеются на экране телефона. Некорректность отображения селектора элементов. |
|
Getevent и sendevent запись и воспроизведение последовательности действий |
Аndroid |
Не требуется права доступа к root. Последовательности событий можно записать без доп. затрат. Не требуются навыки программирования.
|
Последовательность необходимо записывать отдельно для каждого приложения под каждое устройство. Изменение действия при изменении интерфейса. Нет проверки состояния приложения во время тестирования. Не подходит для динамических приложений. |
|
Ranorex набор инструментов и библиотек для написания тестов |
iOS, Android |
Поддержка динамических графических элементов управления. Возможность разрабатывать фреймворки. Поддержка тестов, основанных на данных Data Driven Testing. Поддержка запуска тестов на сервере Continuous Integration. |
Отсутствие интеграции тестов с тест-кейсами TMS. Хорошо работает только с нативными приложениями. |
Автоматическое тестирование, в свою очередь, не заменяет другие типы тестирования. Существуют два подхода: ручное тестирование и автоматизированное [1]. Преимущество ручного тестирования в том, что оно позволяет протестировать фактическое поведение пользователей. Недостаток – временные затраты.
При внесении минимальных изменений в интерфейс приложений, необходимо тестирование, т.к. каждое изменение влечет за собой различные варианты использования и все их необходимо проверить на 20 разных устройствах. Вручную это сделать невозможно.
Преимущество автоматизации заключается в том, что она позволяет провести масштабный тест, охватить период от начала разработки до эксплуатации. Несмотря на это, многие компании отдают предпочтение ручному тестированию. В числе возможных минусов использования автоматизированных средств тестирования — необходимость наличия начальных инвестиций и технических знаний.
Список литературы:
- Дастин Э., Рэшка Д., Автоматизированное тестирование программного обеспечения. – Москва: ЛОРИ, 2003.
- Инструменты тестирования приложений для мобильных устройств: обзор вариантов и возможностей. – [Электронный ресурс] – Режим доступа. – URL: http://www.enterra.ru/blog/tools_for_qa/ (Дата обращения: 15.12.2016).
- 20 инструментов для тестирования мобильных приложений. – [Электронный ресурс] – Режим доступа. – URL: https://spark.ru/startup/componentix/blog/4801/20-instrumentov-dlya-testirovaniya-mobilnih-prilozhenij (Дата обращения: 15.12.2016).
- Android App Stats. – [Электронный ресурс] – Режим доступа. – URL: http://www.androlib.com/appstats.aspx (Дата обращения: 05.12.2016).
дипломов
Оставить комментарий