Тестирования мобильных платформ ios android

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

Авторизуйтесь

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

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

Calabash

Это фреймворк для автоматизации функционального тестирования, который является своего рода драйвером, управляющим работой приложения на девайсе или симуляторе. Подходит как для Android-приложений, так и для приложений для iOS. Разработкой и поддержкой занимается компания Xamarin. Также компания Xamarin предоставляет платную услугу тестирования в «облаке». С тем, как это работает, можно ознакомиться тут.

Appium

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

Robotium

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

Espresso

Espresso — это инструмент для тестирования пользовательских интерфейсов Android-приложений. Основной API невелик и прост, но поскольку исходный код инструмента открыт, вы можете расширить его для своих нужд.

iOS UI automation

Это родной инструмент от Apple. Не упомянуть его было нельзя, но сразу стоит оговориться о нескольких минусах:

• Тесты нужно писать на JavaScript.
• Для запуска тестов нужно открывать отдельное приложение, что не слишком удобно, особенно если использовать CI (continuous integration).
• Приложение должно быть подписано. Подписать приложение, может, и не проблема, но делать это, просто чтобы научиться использовать инструмент, мало кому хочется.

UI Automator

Аналог UIAutomation для тестирования Android-приложений. Разрабатывается корпорацией Google и поставляется вместе с Android SDK.

KeepItFunctional

KIF позволит вам проверить то, как ваше iOS приложение воспринимают люди с плохим зрением.

MonkeyRunner

Инструмент monkeyrunner предоставляет API для написания программ, которые управляют Android-устройством или эмулятором извне Android-кода. Вы можете написать программу на Python, которая установит приложение или тестовый пакет, запустит его, отправит нажатия, сделает скриншоты интерфейса и сохранит их.

Ranorex

Ranorex — это GUI-фреймворк для автоматизации тестирования настольных, веб- и мобильных приложений. У него нет своего языка — вместо этого он использует C# и VB.NET.

SeeTest

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

TestFairy

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

Источник

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

Всем привет! Меня зовут Ксюша, и я тестирую мобильные приложения в компании ATI.SU

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

Начнем с девайсов

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

Как же учесть это, ведь невозможно протестировать приложение на всех вариантах устройств? Стоит выбирать наиболее популярные среди ваших пользователей девайсы, а еще тестировать на самой старой и самой новой из поддерживаемых ОС. Также важно проверять приложение девайсах с сильно кастомизированными прошивками. Например, xiaomi, huawei, samsung.

Перейдем к ui и ux

Для каждой из платформ существуют гайдлайны: Google Material Design для Android и Human Interface Guidlines для ios. В гайдлайнах описаны элементы интерфейса, их размеры, расположение на экране и не только. Гайдлайны нужны, чтобы создавать такой дизайн, который позволит пользователю не думать над простыми действиями. Например, над навигацией или выбором элементов. А еще гайдлайны пригодятся, чтобы один и тот же дизайн был одинаково функционален на разных девайсах и разных версиях платформы. Хорошее приложение должно следовать гайдлайнам, а тестировщик проверить это.

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

Рассмотрим разрешения

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

Потестируем запросы

Приложение — это в первую очередь про фронтенд. Для взаимодействия с бекендом оно использует http-запросы. Запросы, как известно, могут возвращать разные коды ответа. Например, 400, 500 и другие. А также ответы могут приходить с таймаутом. Тут важно протестировать реакцию приложения на различные коды ответа, таймауты разной длины и измененное body ответа. Для тестирования подобных ситуаций используются снифферы — инструменты для перехвата трафика и подмены запросов и ответов. Снифферы позволяют изменять запрос и ответ целиком или частично. Самые популярные — это Charles и Fiddler. О работе с ними я постараюсь рассказать подробнее в отдельной статье.

Обновим приложение

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

Используем функции девайса

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

Давайте зарелизим

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

Когда билд готов к релизу, его загружают в Play Market или App Store. Там приложение проходит ревью и становится доступным для скачивания. Однако пользователи получат новый релиз только когда обновятся. А это процесс не быстрый. У большинства пользователей может быть отключено автообновление, и они могут месяцами откладывать обновление вручную.

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

Подытожим

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

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

Источник

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

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

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

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

Поэтому в отделе тестирования у нас работает 8 человек (0,5 тестировщика на программиста), за его развитием и процессами следит выделенный тест-лид.

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

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

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

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

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

В основном на этом этапе используется basecamp.

Когда требования стали полны и непротиворечивы, тестировщик составляет smoke-тесты и функциональные тесты, покрывающие исходные данные. Тесты деляется на общие и специфические для разных платформ. Для хранения и прогона тестов мы используем Sitechсo.

Например, для проекта Trava на этом этапе было написано 1856 тестов.

Первый шаг тестирования закончен. Проект уходит в разработку.

Билд-сервер

Все наши проекты собираются на TeamCity билд-сервере.

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

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

Тестирование билдов бывает быстрое и полное.

Быстрое тестирование

Быстрое тестирование проводится после завершения итерации разработки, если сборка не пойдет в релиз.

Для начала проводятся smoke-тесты, чтобы понять имеет ли смысл тестировать сборку.

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

Некорректно выполненные задачи переоткрываются. Баги заносятся в Jira. К не UI багам обязательно прикладываются логи со смартфона. К UI багам скриншоты с пометками что не так.

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

Для андроид приложений запускаются monkey тесты.

По окончании тестирования ставится галочка «тестирование багов пройдено» в билд-сервере (да, название галочки не очень правильное :).

Если в процессе тестирования не было найдено blocker, critical и major багов, ставится галочка «можно показывать заказчику». Ни один билд не отсылается заказчику без одобрения отдела тестирования. (По согласованию с заказчиком иногда высылаются билды с major багами).

Критичность бага определяется по таблице.

После завершения тестирования PM получает подробное письмо-отчет.

Полное тестирование

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

Регрессионное тестирование подразумевает прогон ВСЕХ тест-кейсов по проекту. Тест-кейсов не только за последнюю итерацию, но и за все предыдущие и общие тест кейсы по требованиям. Это занимает день-три на одно устройство в зависимости от проекта.

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

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

Релизный monkey-тест мы проводим на 10 iOS и 80 Android устройствах при помощи сервиса Appthwack.

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

Сборка уходит в релиз только при 100% прохождении всех тест-кейсов.

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

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

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

Учет времени

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

UPD: а расскажите как устроено тестирование у вас, хотя бы сколько тестировщиков на разработчика

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

Источник