Статьи

Тестирование на Android: каковы ваши варианты?

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

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

То, что выделяет Android, — это множество возможностей. На iOS есть iPhone, iPad и iPod Touch. Они разные, но общий фактор для устройств iOS — плотность пикселей, разрешение экрана, скорость процессора, объем памяти и т. Д.

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

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

В порядке убывания доли рынка мы имеем Jelly Bean (4.1-4.3), Gingerbread (2.3) и Ice Cream Sandwich (4.0).

Сравните это с уровнем принятия iOS 7 Apple. В конце января этого года 80% устройств iOS работали под управлением iOS 7 . Напомним, что iOS 7 была выпущена в сентябре 2013 года. Это серьезное отличие.

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

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

Задайте себе следующие вопросы:

  • Какие мои любимые приложения? Это почему?
  • Какие плохие приложения я использую?
  • Что делает приложение отличным? Это внимание к деталям?
  • Это плохое приложение время от времени зависает? Он постоянно падает? Или его дизайн не годится?

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

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

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

Проблема, с которой я сталкиваюсь, заключается в том, что мы слишком близки к нашим проектам. Мы знаем, как заставить наше приложение выйти из строя и как заставить его работать. По этой причине я намеренно пытаюсь сосредоточиться на мысли пользователя. Я поместил пользователей в две широкие категории, Button Masher и User .

Button Masher — это тип пользователя, который просто начнет нажимать на экран, кнопка здесь, кнопка там. «Эта последняя кнопка ничего не сделала. Я нажму еще одну».

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

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

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

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

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

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

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

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

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

Android SDK поставляется с платформой тестирования Android, которая состоит из API тестирования на основе JUnit и monkeyrunner .

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

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

Доступно множество платформ для тестирования. Некоторые из наиболее популярных — Robolectric и Robotium .

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

Еще один интересный вариант — эспрессо . Он служит очень конкретной цели по сравнению с двумя предыдущими вариантами. Это API для запуска тестов с пользовательским интерфейсом Android.

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

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

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

Хотя это не помогает на этапе разработки вашего приложения, Google также собирает отчеты о сбоях для приложений в Play Store.

Мы все хотели бы иметь 400 устройств для тестирования, как те массивные тестовые лаборатории, которые мы видели в Интернете. Однако это нереально. Чтобы решить эту проблему, есть много доступных сервисов, если вы готовы инвестировать в тестирование.

Эти услуги варьируются от реальных тестов «один на один» до полностью автоматизированных тестов на сотнях устройств. Если вы готовы заплатить за это, это доступно.

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

Вот несколько сервисов для рассмотрения:

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

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