6 шагов для успешного тестирования приложений под Android

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

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

Так к чему я это?

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

Но мы ведь не просто тестируем мобилки, мы тестируем их на различных платформах!

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

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

1. Наши  устройства.

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

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

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

Часто на собеседования ко мне приходят тестироващики мобилок, и, когда разговор заходит о парке мобильных устройств, в 90% случае я слышу максимум 4-5 устройств, на которых принято тестировать в их компании.

Что???

Нельзя отталкиваться при выборе устройств от версии платформы!!!

Многие же считают, что если мы проверили приложение на Android 5.0 Lollipop на SAMSUNG Galaxy S6, то значит приложение работает.

Как бы не так!

Помимо платформы, есть ряд составляющих, таких как CPU, диагональ и разрешение экрана, ОЗУ, которые могут серьезно влиять на работоспособность Вашего приложения.

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

Полные результаты исследования можно посмотреть тут:

Мобильная лаборатория

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

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

2. Размер экрана и плотность.

Если про размер экрана все понятно, то обычные тестировщики не всегда сталкиваются с понятием плотности.

Итак, плотность экрана (Screen density) — это количество физических пикселей дисплея.

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

Как мы видим, самые популярным размером экрана является «Normal» с плотностью hdpi, xhdpi, xxhdpi и mdpi, что важно учитывать при подготовке парка устройств для тестирования мобильных приложений.

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

Ссылка на dashboard android

3. Версионность.

Официально Android поддерживает 10 платформ/версий, начиная с «Froyo» 2.2 и заканчивая «Marshmallow» 6.0. Но если говорить о сегодняшнем дне, то не все мобильные приложения поддерживают все версии и платформы. Поэтому, если и планировать тестирование, то нужно обязательно учитывать выполнение тест-кейсов на нескольких версиях Android.

Так, например, если мы посмотрим на текущий рынок, то  уже давно вышли такие версии, как «Lollipop» 5.0-5.1 (которая вышла еще в декабре 2014 года) и «Marshmallow» 6.0, но лидером по прежнему является  «KitKat» 4.4.

В чем важности использования различных платформ?

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

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

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

И иногда это действительно вымораживает нервирует. Когда вы скачиваете приложение особенно не через wi–fi и метров под 900, запускаете его, а в ответ приложение не открывается!

Отсюда могу сказать, что важно протестировать продукт как 

минимум на 4-х, а лучше 5-ти версиях Android.

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

Можем идти дальше!

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

4. Общая функциональность.

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

Начнем по порядку.

• Регистрация и вход в систему. 

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

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

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

• Ключевые функции.

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

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

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

  Для этого очень полезен анализ crashlog.  Например, у меня на Lenovo, когда работает музыка через Bluetooth, постоянно при повторном запуске Яндекс Навигатора и при нажатии на кнопку GPS перезагружается телефон. Это ужасно, особенно когда ты едешь на скорости 100км/ч и у тебя пропал GPS, а нужно его перезагрузить. Начинается паника, куда ехать… И напоследок разработчики Android будут аплодировать стоя,  самое крутое, что перезагружается телефон вот в таком формате:

И тут начинается лотерея! Физически тачскрин работает в портретной ориентации, а экран обрезан на половину и отображается в альбомной ориентации. Когда я первый раз наткнулся на такой баг, я 30 минут пытался попасть по кнопке перезагрузить телефон!

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

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

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

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

• Влияние на работу устройства.

Говоря об эксплуатации, подразумевается работа приложения в обычном режиме. Для тестирования необходимо запустить приложение и использовать его в течении 6-12 часов. При использовании необходимо каждые 30 минут или 1 час  измерять уровень заряда батареи. Зачастую такая проверка автоматизирована, чтобы не тратить время тестировщика на сбор данных. Если результаты теста показывают, что снижение уровня заряда батареи происходит раньше 6 часов при условии работы со всеми фоновыми функциями вашего телефона, то это явно указывает на проблемы в приложении.
Я думаю у каждого была ситуация, когда вы скачиваете приложение, а потом оно сжирает у вас за 30 минут 20% аккумулятора. Я не помню их названия, но такие были точно!

5.      Дополнительные проверки.

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

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

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

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

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

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

6. Безопасность Android.

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

Любая система должна обеспечивать соблюдение требований к информации:

• Конфиденциальность. Недоступны ли личные данные пользователей?
• Целостность. Нет ли возможности извне изменить личные данные при их передаче?
• Аутентификация. Как приложение проверяет, что именно я являюсь владельцем аккаунта?
• Доступность. Как и при каких условия возможность сломать/ сделать неработоспособным приложение?
• Отказоустойчивость. Как ведется учет всех отказов системы?

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

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

Ну и напоследок….
Мне пришлось изрядно порыться в Google Play, но это оказалось очень полезным.

Удалось относительно определить основные проблемы, с которыми сталкиваются пользователи:

• 55% жалуются на установку
• 24% жалуются на производительность
• 13% говорят об отказах приложения
• 5% пишут, что их приложение подтормаживает или зависает.
• 2% жалуются на UI
• 1% на проблемы с конфиденциальностью или безопасностью.

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

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

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

Надеюсь было полезно! 

Поделиться ссылкой:

Понимание и освоение тестирования Android-приложений: часть 1

Представляем вашему вниманию статью Аритры Роя, инженера-проектировщика и Full-stack разработчика.

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

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

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

Зачем беспокоиться о тестировании?

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

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

Уверенность в вашем коде

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

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

Избавление от ошибок регрессии

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

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

Написание минималистичного кода

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

Предположим, что вы следуете Test-Driven Development (TDD), и написали тест. Теперь вашей основной целью будет написание только нужного кода, чтобы пройти этот конкретный тест. Вы не будете писать лишний или ложный код, который вы написали бы в противном случае.

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

Пирамида тестирования

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

Юнит-тестирование

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

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

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

Интеграционные тесты

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

Эти тесты обычно проверяют, работают ли два разных модуля или компонента вместе так, как должны. Это сильно отличается от тестирования бизнес-логики, о котором мы говорили ранее. Как правило, эти тесты являются средними по размеру (больше, чем юнит-тесты, но короче, чем end-to-end тесты) и должны составлять около 20% от общего количества тестов, написанных для вашего приложения.

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

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

End-to-end тестирование

Предположительно, вы будете использовать лишь несколько таких тестов. В идеале вы должны постараться сделать так, чтобы около 10% ваших тестов были end-to-end вариантами. Как следует из названия, вы будете использовать эти тесты для полного тестирования потока – с начала и до конца.

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

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

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

Android Dev Подкаст. Выпуск 17. Droidcon Moscow, Multi-window, тестирование и профилирование

Типы тестирования на Android

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

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

Локальные unit-тесты

Это те тесты, которые могут выполняться локально на вашей девелоперской машине. Эти тесты находятся в module/src/test/java и не имеют никакого доступа к любым API-интерфейсам Android.

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

Для модульного тестирования мы используем JUnit, который является очень популярным фреймворком юнит-тестирования, помогая нам писать четкие и понятные тесты. Мы также можем использовать Robolectric, который является еще одной популярной платформой тестирования, позволяющей нам также тестировать зависимости Android.

Инструментальные тесты

Это те тесты, которые относятся к категории тестов «Integration» и «End-to-End». Все эти тесты находятся в module /src/androidTest/java.

Обратите внимание на добавление префикса «android» перед «тестом», означающим, что эти тесты должны запускаться на устройстве Android или эмуляторе и иметь доступ к зависимостям Android. Они в основном известны как «source sets», если вам интересно.

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

Теперь у вас может возникнуть вопрос, почему эти тесты называются «инструментальными»? Это связано с тем, что они используют Android Instrumentation API через InstrumentationRegistry для управления компонентами Android и их жизненными циклами вручную, вместо того, чтобы позволять системе их контролировать.

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

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

Выводы

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

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

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

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

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

• размером и разрешением экрана;
• версией Android;
• форм-фактор устройства;
• системы команд процессора;
• фронтальная камеры, NFC, внешняя клавиатура и т.д.

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

Автоматическое тестирование приложений для Android

Рассмотрим несколько средств для автоматического тестирования функциональности, которые входят в состав Android SDK или  распространяются с открытым исходным кодом.

Принцип автоматического тестирования приложений

Наша задача — с наибольшей точностью автоматизировать действия, выполняемые вручную. Рассмотрим эти действия. Будем использовать несколько приложений и несколько устройств с Android. Для каждого приложения и каждого устройства нужно выполнить следующие действия:

• Установить приложение на устройство
• Запустить приложение
• Протестировать приложение, используя выбранный метод
• Удалить приложение
• Сбросить устройство в исходное состояние
• На каждом этапе нужно собирать и анализировать данные (журналы и снимки экрана). Ниже описываются средства для автоматизации этих действий.
• Управление устройствами Android

Прежде всего необходимо выбрать компьютер, который будет использоваться для запуска автоматических тестов, и установить на нем Android SDK. В данном примере мы используем настольный компьютер с операционной системой Linux*. На каждом устройстве необходимо отключить экран блокировки и увеличить «время перед переходом в спящий режим» до максимального значения. Для некоторых методик тестирования также нужно отключить изменение ориентации экрана. В составе Android SDK предусмотрено две программы для управления устройствами с Android: ADB и monkeyrunner* ADB (Android Debug Bridge) — это программа командной строки для управления устройствами с Android.

Методы автоматического тестирования Android

Тестирование с помощью Monkey*

Предположим, что тестируемое устройство попало в лапы крайне любопытной и деятельной обезьяны: программа Monkey имитирует именно такую ситуацию. Программа Monkey, входящая в состав Android SDK, отправляет поток случайных действий пользователя. В командной строке можно указать количество действий пользователя, долю действий каждого типа и имя пакета (чтобы программа Monkey не вышла за пределы тестируемого приложения и не начала, к примеру, рассылать SMS-сообщения всем контактам из адресной книги).

Основное преимущество Monkey в отсутствии затрат на обслуживание. К тому же нагрузочное тестирование может выявлять сложные и малозаметные ошибки.

Недостатки тестирования с помощью Monkey:

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

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

Тестирование с помощью MonkeyRunner

MonkeyRunner позволяет не только создавать сценарии для управления устройствами с Android, но и создавать сценарии для тестирования приложения на определенном устройстве. Основное преимущество – гибкость, а недостаток в сложности написания скриптов, даже в простых случаях. Создание скриптов monkeyrunner занимает немало времени, поэтому обычно этот метод использовать нецелесообразно. Но в некоторых случаях его применение может оказаться весьма полезным.

Тестирование с помощью getevent и sendevent

Программы getevent и sendevent позволяют пользователю записывать последовательность действий и затем воспроизводить ее. Для запуска этих программ не требуются права доступа root.

Преимущества:

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

Недостатки:

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

Тестирование с помощью Robotium

Robotium не входит в состав Android SDK, эта программа распространяется с открытым исходным кодом. Сценарии Robotium определяют действия на уровне пользовательского интерфейса приложений, а не на уровне устройства ввода. Например, в сценарии требуется коснуться кнопки «ОК». В этом случае скрипт monkeyrunner будет построен следующим образом: «имитировать касание экрана в точке с координатами (x0, y0)». Скрипт Robotium будет построен иначе: «нажать кнопку с текстом «ОК».

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

Недостатки:

• Для каждого приложения требуется разрабатывать тестовый сценарий на языке Java*. Для этого требуется время и навыки программирования;
• При смене интерфейса приложения потребуется переделать последовательность событий;
• Создавать сценарии Robotium сложнее, чем записывать события с помощью getevent / sendevent;

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

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

Метод тестирования	Преимущества	Недостатки
Monkey — поток случайных действий пользователей	Затраты на обслуживание отсутствуют. Независимость от устройства. Нагрузочное тестирование может выявлять сложные и малозаметные ошибки.	Качество тестирования может различаться для разных приложений. Сложно воспроизводить последовательность действий, вызвавших ошибку, в отчетах об ошибках. Monkey не проверяет состояние приложения во время тестирования.
MonkeyRunner — скрипт для управления устройством	Гибкость	Сложность написания сценариев, даже для простых приложений.
Getevent/sendevent — запись и воспроизведение действий пользователя	Для записи последовательности событий не требуются навыки программирования.	Записанная последовательность действий подойдет только для одного устройства при фиксированной ориентации экрана. При смене интерфейса приложения необходимо переделывать последовательность событий. Этот метод не проверяет состояние приложения во время тестирования.
Robotium — API тестовых скриптов для проверки состояния	Действия описываются на уровне пользовательского интерфейса приложения. Скрипт может не зависеть от разрешения и ориентации экрана. Скрипт может проверять состояние приложения после действий.	Сложность написания сценариев на языке Java. При изменении интерфейса приложения необходимо переделывать скрипт.

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

Ручное тестирование Android приложений

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

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

• Установка и запуск приложения, выход из приложения, повторный вход, удаление приложения с мобильного устройства;
• Мультитач и размер экрана. Корректность удаления 2-х элементов или просмотр двух элементов, нажатием на них одновременно. Проверка многократного быстрого нажатия на кнопку – часто при этом может случиться падение приложения. В приложении должны отсутствовать пустые экраны, чтобы пользователь не оказался в ситуации, в которой не очевидно, что делать. Также все элементы должны быть такого размера, чтобы пользователь мог однозначно нажать на них.
• Стабильность. Работа приложения при множестве запущенных приложений и долгое время, а также в случае недостатка места для установки или работы приложения. Поведение приложения при отсутствии в некоторых устройствах поддерживаемых приложением функций.
• Адаптация приложения к портретной и альбомной ориентациям устройства.
• Стресс. Реакция приложения на внешние прерывания:
  • входящие и исходящие SMS, MMS, звонки, оповещения других приложений;
  • переход устройства в режим ожидания;
  • выключение устройства, разрядка устройства;
  • зарядка устройства;
  • отключение интернета;
  • переход в другое приложение.
• Интернационализация. Проверка корректности работы приложения на разных языках (если данное приложение мультиязычное).
• Обратная связь с пользователем. Наличие информативных сообщений при попытке выполнить какое-либо действие (например, при удалении важной информации), а также присутствие визуальной индикации хода выполнения функций. У всех нажимаемых элементов должно быть «нажатое состояние» (отклик на действие), благодаря этому пользователь всегда будет видеть, действительно ли произошло нажатие.
• Обновление. Корректность обновления приложения до новой версии.
• Орфографические ошибки.

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

Особенности альфа/бета тестирования в консоли разработчика Google Play

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

Что нужно знать перед началом тестирования

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

• Присоединиться к группе тестировщиков может только пользователь с аккаунтом Google (@gmail.com) или Google Apps;
• При тестировании опубликованного ранее приложения обновление его альфа- и бета-версии получат только тестировщики. И только они смогут найти и скачать приложение, которое вы публикуете и проверяете впервые;
• Если вы впервые публикуете файл APK альфа- или бета-версии, ссылка станет доступна пользователям в течение нескольких часов. Примерно такое же время требуется, чтобы тестировщики смогли увидеть изменения, внесенные вами в уже опубликованную версию;
• Любые изменения на странице Цены и распространение (в том числе значения платное или бесплатное) применяются ко всем версиям приложения, включая тестовые, рабочие и будущие.

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

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

По материалам статьи.

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

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 решает эту проблему, записывая все тесты на видео, а также запоминая технические характеристики устройства.

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

Описание

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

Разработка мобильного ПО – новая и динамично развивающаяся отрасль, поэтому разработчикам и тестировщикам приходится решать не только типичные IT проблемы, но и преодолевать вновь возникающие, ещё не изведанные трудности. Сложность при этом заключается ещё и в том, что сами инструменты для разработки и тестирования находятся на стадии развития.

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

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

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

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

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

Программа тренинга

Урок 1: Особенности мобильного тестирования

Модуль 1: Знакомство

Модуль 2: Базовые понятия

• Нативные приложени
• Веб приложения
• Гибридные приложения
• Что такое девайс?

Модуль 3: Выбор устройств для тестирования

• Проблемы фрагментации
• Виды устройств Android
• Разрешение экрана
• Размеры экранов
• Архитектура процессоров Android устройств
• Версии Android OS
• Виды устройств iOS
• Разрешения экранов
• Архитектура процессоров iOS устройств
• Инструменты оценки доли рынка
• Рекомендации по выбору устройств для тестирования на iOS и Android

Модуль 4: Особенности мобильного тестирования

• Тестирование связи (Wifi/2G/3G/LTE)
• Тестирование прерываний
• Взаимодействие с сенсорами положения и тач сенсором
• Тестирование геолокации и GPS
• Тестирование потребления ресурсов
• Работа с клиент-серверными приложениями
• Тестирование установки
• Роль тестировщика в администрировании мобильных устройств
• Списки тест-кейсов: чеклисты и мнемоники

Модуль 5: Эмуляторы и симуляторы

• Разница между симулятором iOS и эмулятором Android
• Особенности тестирования на физических устройствах и эмуляторах/симуляторах

Модуль 6: Фермы мобильных устройств

• Что такое фермы?
• Достоинства и недостатки использования ферм
• Пример использования мобильной фермы

Урок 2: Тестирование Android-приложений

Модуль 1: Установка и настройка Android Studio

• Установка Android Studio
• Установка необходимых SDK

Модуль 2: Создание и настройка эмулятора в Android Studio

• Работа с AVD Manager
• Выбор параметров
• Запуск эмулятора

Модуль 3: Функционал эмулятора

• Боковое меню
• Геолокация
• Связь
• Батарея
• Функции телефона
• Другие настройки

Модуль 4: Настройка альтернативного эмулятора Genymotion

• Что такое Genymotion?
• Где его взять?
• Установка приложения
• Создание виртуального устройства
• Функции эмулятора Genymotion
• Подключение эмулятора к Android Studio

Модуль 5: Настройка Android Device Bridge

• Что такое ADB?
• Основные команды

Модуль 6: Установка приложений на эмулятор и реальное устройство

• Установка на эмулятор: drag&drop, Run, adb install
• Установка на устройство

Модуль 7: Анализ логов и снятие скриншотов

• Уровни логирования
• Способы записи логов
• Скриншоты через Android Studio
• Скриншоты через настройки эмулятора

Модуль 8: Жизненный цикл операции

• Понятие операции
• Android Backstack
• Состояния операции
• Переходы между состояниями

Модуль 9: Перехват трафика

• Настройка Charles
• Настройка нативного эмулятора для перехвата трафика
• Настройка Genymotion для перехвата трафика
• Перехват трафика приложения на примере

Модуль 10: Работа с GPS

• Примеры приложенний, работающих с GPS
• Работа с GPS на эмуляторе
• Загрузка и прогрывание пути .gpx

Модуль 11: Меню разработчика Android

• Работа с местоположениями
• Изменение параметров графического интерфейса
• Отображение курсора и касаний

Урок 3: Тестирование iOS-приложений

Модуль 1: Установка и настройка Xcode

• Установка iOS
• Установка необходимых симуляторов

Модуль 2: Функционал симулятора

• Выбор устройства
• Работа с акселерометром
• Эмуляция физических кнопок
• Touch ID и Apple Pay
• Замедление анимаций
• Работа с интерфейсом
• Работа с геолокацией
• Network link conditioner

Модуль 3: Запуск приложения на симуляторе

• Подготовка приложения к установке
• Установка сертификата Charles на симуляторы
• Запуск приложения

Модуль 4: Запуск приложения на реальном устройстве

• Сертификат и Provisioning profiles
• Создание Apple ID
• Создание сертификата и Provisioning Profile
• Запуск приложения

Модуль 5: Артефакты тестировании

• Передача логов
• Сохранение скриншотов
• Запись видео

Модуль 6: Перехват трафика

• Настройка Charles Proxy
• Перехват запросов с симулятора
• Включение SSL-проксирования
• Перехват запросов с реального устройства
• Работа с HTTPS-запросами

Модуль 7: Работа с GPX-путями

• Постановка задачи
• Импорт пути
• Просмотр работы GPS

Модуль 8: Жизненный цикл приложения

• Понимание жизненного цикла
• Состояния приложения
• Переходы между состояниями

Урок 4: Организация процесса тестирования

Модуль 1: Процесс разработки приложения

• Этапы развития мобильного приложения
• Этап I: Идея
• Этап II: Стратегия
• Этап III: Дизайн
• Этап IV: Разработка
• Этап V: Выкладка и поддержка

Модуль 2: Выбор стратегии тестирования

• Что такое стратегия?
• Постановка цели тестирования
• Работа с ресурсами
• Разведка территории
• Сложности в тестировании мобильных приложений
• Виды стратегий: единичные и смешанные
• Мнемоники
• Пример выбора стратегии

Модуль 3: Гайдлайны для Android и iOS

• Роль тестировщика в работе над дизайном приложения
• Гайдлайны для Android
• Гайдлайны для iOS

Модуль 4: Разработка

• Понятия альфа- и бета-тестирования
• Проведение альфа- и бета-тестирования на Android через Google Play
• Проведение альфа- и бета-тестирования на iOS через TestFlight
• Сервисы для альфа- и бета-тестирования: TestFairy, HockeyApp
• Пример использования сервиса TestFairy
• Tips&tricks для проведения альфа- и бета тестирования
• Crowd-тестирование

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

• Что такое UI/Application Exerciser Monkey?
• Установка и запуск приложения на эмуляторе
• Запуск Monkey на эмуляторе
• Тонкая настройка нажатий Monkey
• Параметры запуска: задержка, seed, действия при ошибке

Модуль 6: Выкладка

• Особенности выкладки на мобильных устройствах
• Особенности выкладки на Android: время, staged rollout, разрешения
• Особенности выкладки на iOS: время, обновления
• Как работать с экранами обновления
• On-the-fly features

Модуль 7: Мониторинг и поддержка

• Особенности мониторинга на мобильных устройствах
• Сервисы для построения графиков
• Сервисы сбора crash-логов
• Статистические сервисы
• Мониторинг отзывов

Модуль 8: A/B тестирование

• Что такое A/B тестирование?
• Пример проведения тестирования
• Инструменты A/B тестирования

Модуль 9: Полезные утилиты тестировщика

• Одноразовые email
• Приём входящих СМС
• Сокращение ссылок
• Передача кода и логов
• Скриншоты
• Передача файлов
• Системные параметры устройства

Системные требования:

Для выполнения заданий в уроке по Android вам потребуется

• Windows 7+ / Mac OS Mojave+ / Ubuntu 14.04+
• Процессор i-серии (i3, i5, i7) или аналогичный от AMD
• Минимум 8 GB RAM
• 10 GB на жёстком диске
• Разрешение экрана минимум 1280 x 800
• Желательно телефон на Android с OS 5.1 и старше

Для выполнения заданий в уроке по iOS вам потребуется

• Mac OS Mojave+
• 8 GB RAM
• 10 GB на жёстком диске
• iPhone или iPad с iOS 13 или старше

Внимание!

Наличие компьютера с системой MacOS обязательно для прохождения курса. Без выполнения заданий на этой ОС вы не сможете получить сертификат.

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

Все процессоры AMD, а также некоторые процессоры старые Intel не поддерживают виртуализацию VT-X. В таком случае можно будет воспользоваться альтернативным эмулятором Genymotion.

Предусловия

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

Если вы не уверены, что знаете все это в должной мере — пройдите простой тест: https://www.learnqa.ru/abc_test. Если по результатам теста вы получите меньше 20 баллов — мы рекомендуем пройти короткий курс “Азбука IT”. На нем вы сможете быстро получить все необходимые знания, которые совершенно точно пригодятся вам в дальнейшем.

Отзывы

Илана Байкель, ExLibris Group

Курс, как всегда в вашей школе, высший пилотаж! Сжато, понято, методично, интересно, увлекательно:-) Все по делу, все максимально практично. Тренер — профессионал, видно, что не теоретик и со всеми технологиями лично и близко знаком. Удивила заинтересованность тренера в успехе учеников, даже если речь идет о большой затрате времени. Редкость в наше время. Меня курс перенес из разряда «чайников» в разряд «она что-то знает», что в десктопной фирме значит немало:-) Народ уже попросил провести лекцию для общего ликбеза с overview изученного. Большое спасибо, удачи тренеру и всей школе!

Татьяна, Certent DisclosureNet

Понравилась грамотная организация и логическое изложение материала. Практические задания были доступно изложены и не возникало трудностей с их выполнением. Продуманы детали, очень понравились практические подсказки по утилитам, которые даже неопытному в мобильном тестировании тестеровщику поможет организовать процесс работы. Закончив курс, есть понимание «что делать», если перед тобой стоит задача протестировать мобильное приложение. Хорошее изложение опытного инсайдера 🙂 Ничего лишнего, много полезного. Работа тренера тоже на высоком уровне, в смысле ответов на вопросы и консультаций. Спасибо, Арсений, очень стоящий курс.

Алексей Авицук

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

Екатерина Михайловская

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

Посмотреть все отзывы

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

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

Этапы

1. Общее
2. Функциональное

Общее тестирование

• Требования

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

• Тестовые сценарии

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

• Контент

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

• Юзабилити

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

• Отклик на пользовательские действия

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

• Обновление

  Тестируется простота и понятность апдейтов, сохранение информации при установке новой версии.

• Неожиданная остановка приложения

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

• Нехватка памяти и нестабильная связь

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

• Соответствие требованиям сторов

  Для публикации в ведущих магазинах для Android и iOS продукт должен соответствовать гайдлайнам магазинов.

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

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

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

Android

•  Инсталляционный файл в формате .apk согласуется с Program Policies, которые представляют собой перечень запрещенных к публикации типов материалов: спам, нелегальный контент, конфиденциальная информация, malware и т. д.;
• При публикации новой версии нумерация сборок производится с принятым порядком;

Приложение тестируется на соответствие документу User Interface Guidelines.

Тестирование iPhone приложений

• Для упрощения модерации в App Store имя приложения проходит проверку на уникальность и согласуется с гайдлайнами компании Apple (Human Interface Guidelines),
• Проверяется категория приложения, а также наличие ссылки для обратной связи пользователей с разработчиком,

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

Важность тестирования в цикле разработки

Тестирование приложения — это неотъемлемая часть разработки, как и проектирование. Разрабатывать мобильное приложение без контроля его качества невозможно. Именно тестирование в своем комплексе показывает качество будущего продукта. Без проверки приложения на ошибки и коллизии на выходе вы сможете получить только недоработанное, «сырое» приложение, которое не привлечет к вам новых клиентов.

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

Что должно включать в себя независимое тестирование?

• Тестирование обновлений, которые должны проходить легко и просто, не требуя особых знаний.
• Тестирование интернационализации – включает языковую поддержку и корректность перевода, учитывает особенности других стран, что актуально для приложений, ориентированных на международную аудиторию.
• Тестирование удобства пользования – один из наиболее важных этапов, так как юзабилити значительно влияет на популярность приложения. В критерии входит удобство навигации, использование тач-жестов (в том числе многократные и одновременные нажатия), соответствие особенностям целевой аудитории, уровень энергопотребления.
• Нагрузочное тестирование показывает объемы использования памяти и системных ресурсов, производительность приложения и возможные утечки, выявляет поведение в режиме workflow, при некорректном кэшировании и отсутствии в телефоне необходимых функций.
• Случайное тестирование («monkey»/fuzzy testing) – выявляет реакцию приложения на неожиданные ситуации и внешние вмешательства: входящие и исходящие сообщения и звонки, оповещения других приложений, выключение и разрядка устройства, изъятие аккумулятора, режим ожидания, отключение и подключение провода, зарядного и другого устройства, включение сети, Bluetooth, GPS.
• Кроссплатформенное и кроссдевайсовое тестирование – показывает насколько корректно продукт работает на заявленных устройствах, ОС и их версиях, разрешениях, ориентациях, размерах экранов (в том числе на ретина-дисплеях).
• Лабораторное тестирование, при котором создаются возможные реальные условия среды и связи, например, нестабильный интернет или нулевой баланс на счету в сети 3G.
• Аттестационное тестирование определяет соответствие продукта лицензионным соглашениям, стандартам и условиям использования.

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

Для проведения тестирования мы применяем следующие технологии:

• Баг трекеры: Mantis, Bugzilla, Jira, Trac, Rational, ClearQuest, Redmine, PR-Tracker, Eventum.
• Инструменты автоматизированного тестирования: WinRunner, Selenium RC, Selenium IDE, TestComplete, AutomatedQA.
• Инструменты управления проектами: Testlink, Confluence, Microsoft Project.
• Инструменты для тестирования производительности: Mercury LoadRunner, Grinder,Wapt, Apache JMeter, WebLoad, Siege, Pylot, LoadImpact.

Тестирования проходят на всех необходимых устройствах Android, iOS,Blackberry, Windows Phone.

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

Почему стоит обратиться к нам

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

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

Начните тестирование Android с помощью Firebase Test Lab

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

Для получения информации о квотах и ​​тарифных планах Test Lab см. Использование, квоты и цены.

Ключевые концепции

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

Устройства × Выполнения тестов = Матрица тестов

Устройство

Физическое или виртуальное устройство (только Android), на котором вы запускаете тест, например телефон, планшет или носимое устройство. Устройства в тестовой матрице обозначены модель устройства, версия ОС, ориентация экрана и языковой стандарт (также известный как география и языковые настройки).

Тест, выполнение теста

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

Тестовая матрица

Содержит статусы и результаты тестов для выполнения ваших тестов. Если есть выполнение теста в матрице не выполняется, вся матрица не выполняется.

---

Шаг 1 : Подготовьте тест для загрузки в Test Lab

Доступные типы испытаний

С помощью Test Lab можно запустить следующие тесты. Обратите внимание, что все типы тестов ограничено запуском 45 минут на физических устройствах и 60 минут на виртуальных устройств. Любое неперехваченное исключение приведет к сбою теста.

• Инструментальный тест или Инструментальный модульный тест : Тест, который вы написали с помощью Эспрессо или UI Automator 2.0 каркасы. С помощью этого теста вы можете сделать явные утверждения о состояние вашего приложения, чтобы проверить правильность работы, используя AndroidJUnitRunnerAPIs.

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

• Тест игрового цикла : Тест, в котором используется «демонстрационный режим» для имитировать действия игрока в игровых приложениях. Это быстрый и масштабируемый способ чтобы убедиться, что ваша игра хорошо работает для пользователей. Когда вы решите запустить Тест Game Loop, вы можете:

  • Написать тесты для вашего игрового движка

  • Избегайте написания одного и того же кода для разных пользовательских интерфейсов или тестирования каркасы

  • Необязательно создать несколько циклов для запуска в одном выполнении теста (посетите раздел «О тестах Game Loop», чтобы узнать больше).Вы также можете организовать петли с помощью меток, чтобы вы могли отслеживать их и повторно запускать определенные циклы.

  См. Раздел Запуск теста игрового цикла для получения инструкций по запуску этого теста. с Test Lab.

Инструменты для запуска теста

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

Вы также можете бесплатно протестировать свое приложение с помощью Test Lab при загрузке и публикации. APK-файлы вашего приложения в Play Маркет, используя альфа- или бета-канал.Для получения дополнительной информации см. Используйте предварительные отчеты для выявления проблем и Робо-тесты.

Шаг 2 : Выберите устройство для тестирования

Test Lab поддерживает тестирование на нескольких марках и моделях Устройства Android установлены и работают в центре обработки данных Google. Тестирование на устройства в Test Lab помогут вам обнаружить проблемы, которые могут не возникнуть при тестировании. ваше приложение с помощью эмуляторов в Android Studio. Чтобы узнать больше, см. Доступные устройства.

Шаг 3 : Просмотрите результаты испытаний

Независимо от того, как вы инициируете свои тесты, все ваши результаты обрабатываются Test Lab и его можно просмотреть в Интернете.

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

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

Подробнее см. Проанализируйте результаты лаборатории тестирования Firebase.

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

Очистка устройства

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

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

---

Дополнительная информация

Сервисы Test Lab и Google Play

Устройства

Test Lab обычно работают на последней версии Google Play. services SDK, но некоторым может потребоваться несколько дней для обновления после выхода новой версии SDK выпущен.Обратите внимание, что вы можете столкнуться с проблемами совместимости с некоторые устройства.

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

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

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

Для устранения этой проблемы:

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

• Поставщики цифровой рекламы могут фильтровать доходы от рекламы и все соответствующие трафик, генерируемый Test Lab путем фильтрации трафика, исходящего от следующие Блоки IP-адресов (обратите внимание, что вы также можете получить доступ к этому списку, используя gcloud beta firebase test список ip-блоков команда в интерфейсе командной строки gcloud):

Платформа и тип устройства	Блок IP-адресов CIDR
Физические устройства Android и iOS	108.177.6.0 / 23 70.32.147.112/28 (добавлен 03-2020) 74.125.122.32/29 (добавлен 04-2020) 108.177.29.80/28 (добавлен 04-2020) 216.239.44.24/29 (добавлен 04-2020)
Виртуальные устройства Android	34.68.194.64/29 (добавлен 11-2019) 34.69.234.64/29 (добавлен 11-2019) 34.73.34.72/29 (добавлен 11-2019) 34.73.178.72/29 (добавлен 11-2019) 35.192.160.56 / 29 35.196.166.80/29 35.196.169.240/29 35.203.128.0/28 35.234.176.160/28 35.243.2.0/27 (добавлен 7-2019) 199.192.115.0/30 199.192.115.8/30 199.192.115.16/29

hotchemi / awesome-android-testing: тщательно подобранный список замечательных библиотек для тестирования Android.

GitHub — hotchemi / awesome-android-testing: тщательно подобранный список замечательных библиотек для тестирования Android.

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

Файлы

Постоянная ссылка Не удалось загрузить последнюю информацию о фиксации.

Тип

Имя

Последнее сообщение фиксации

Время фиксации

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

Конечно иногда включает гугловскую официальную.

Unit Test

Каркас

Библиотека

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

Каркас

Библиотека

E2E Test

Каркас

Помощник

Регистратор

Утверждение

Mock

Мок-сервер

Тест на обезьянах

TaaS

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

IDE

прочие

Документы

Образец

Около

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

ресурсов

Лицензия

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

Тестирование приложений Android: автоматизация, онлайн

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

Получите мгновенный доступ и полный контроль над реальными устройствами Android из браузера. Протестируйте и отладьте свое приложение против них. Выбирайте из широкого ассортимента устройств от различных производителей (например,грамм. Samsung, LG, Huawei и др.) С разными разрешениями экрана и версиями ОС Android. Вы можете использовать устройства, размещенные в центрах обработки данных Digital.ai Continuous Testing, или вы можете легко настроить платформу Digital.ai Continuous Testing на территории своего предприятия и предоставить удаленный доступ различным командам тестирования / разработки в вашей организации.

Немедленная поддержка новой версии Android

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

Автоматическое тестирование Android — тестирование сложных сценариев и настраиваемых элементов пользовательского интерфейса

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

• Автоматизируйте свои тесты с помощью любого типа мобильного приложения: нативного, веб и гибридного, системных приложений или сторонних приложений (Facebook, карты, электронная коммерция).

• Расширьте охват тестирования приложений Android за счет интеграции с компонентами устройства, периферийными устройствами и системными приложениями, такими как камера, аудио, GPS, Google Now, Google Assistant или Google Maps (функции тестирования, такие как сканирование штрих-кода и проверки, голосовая аутентификация, предложения на основе местоположения или аутентификация по отпечатку пальца).

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

• Автоматизируйте тестирование компонентов приложений, созданных с помощью SDK.

Тестирование приложений Android — протестируйте производительность, чтобы гарантировать удобство работы пользователей.

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

Запускайте одни и те же тесты на разных версиях Android и типах устройств.

Создавайте высоконадежные и удобные в обслуживании проекты автоматизации тестирования с помощью Digital.ai Continuous Testing. Разрабатывайте тесты для одной версии ОС Android и выполняйте их на любой другой версии ОС Android без изменений.Сосредоточьте свои усилия на создании новых тестовых примеров, а не на переписывании тестов для разных ОС и версий.

Автоматизация тестирования Android — встроенная поддержка эмуляторов Android

Расширьте возможности автоматизации тестирования Android с помощью возможности разрабатывать и запускать тесты на нескольких эмуляторах Android, включая новые версии Android и бета-версии. Охватите больше функций в других версиях Android раньше в процессе. С легкостью разрабатывайте тесты на эмуляторах с помощью Test Recorder и Object Spy. Тестируйте нестандартные элементы пользовательского интерфейса, интеграцию с системными приложениями или сторонними приложениями, интеграцию с компонентами устройства или компоненты приложений, созданные с помощью SDK.Выполняйте свои тесты на неограниченном количестве симуляторов Android и объединяйте результаты тестов на панелях мониторинга качества Digital.ai Continuous Testing.

Полная интеграция с Android Studio для отладки на любом удаленном устройстве Android

Используйте платформу непрерывного тестирования Digital.ai для подключения к удаленным устройствам Android непосредственно из Android Studio, как если бы устройства были локально подключены к вашему компьютеру. Запустите код приложения, наблюдайте за изменениями кода в реальном времени и даже вставьте точки останова.Отлаживайте приложение на месте прямо из Android Studio и снова проверяйте свои изменения, пока не будете готовы выпустить новый код. Выберите из большого количества устройств и версий Android для отладки — вы даже можете отлаживать на том же устройстве, на котором произошла ошибка.

Выполнять тесты, разработанные в Espresso, параллельно на нескольких устройствах Android

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

Модульное тестирование на Android. Тестирование кода имеет решающее значение, потому что… | Дениз Демирчи | Апрель 2021 г.

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

1. Модульный тест для ViewModels
2. Модульный тест для пользовательских представлений
3. Модульный тест для функций расширения

Модульный тест для ViewModels

Мы собираемся проверить, выполняет ли наша ViewModel то, что от него требуется.Мы собираемся вызвать функцию search (), и мы собираемся проверить, установлено ли значение LiveData соответствующим образом.

Здесь мы используем LiveData, но с StateFlow все остается таким же.

Прежде чем мы начнем подробно разбираться в нашей модели представления, мы должны помнить две очень важные вещи.

1. Модульные тесты предназначены для тестирования конкретного модуля. Поскольку мы тестируем нашу модель представления, наш тест не должен заботиться о том, что делает наш класс репозитория, что он возвращает или какую логику он имеет внутри.
2. Чтобы правильно протестировать функцию, мы должны по возможности исключить использование глобальных параметров. Лучше, если у функции есть все параметры, необходимые для ее работы.

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

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

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

Теперь поговорим о том, что такое MainCoroutineRule . Как и InstantExecutorRule, MainCoroutineRule — это правило JUnit, которое меняет местами диспетчер сопрограмм.

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

Затем идут диспетчеры сопрограмм. Диспетчеры сопрограмм — это в основном то, что определяет, в каком потоке сопрограммы будут работать. Диспетчер сопрограмм по умолчанию, который имеет viewModelScope, — это Dispatchers.Main и Dispatchers.Main использует основной цикл Android, который недоступен в локальной тестовой среде.

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

В блоке @Before мы создаем экземпляр нашей ViewModel с имитируемым репозиторием, который ему нужен в качестве зависимости.

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

Затем мы используем функцию coEvery из библиотеки mockK. Эта строка кода означает, что всякий раз, когда repository.search () вызывается с любым параметром, несмотря ни на что, возвращайте мне значение res, которое я создал выше.

co в «coEvery» обозначает сопрограммы, есть также функция «каждый», которую мы увидим позже в этой статье.

Затем мы вызываем viewModel.search () с желаемыми параметрами.В конце концов, repository.search () вызывается с заданными параметрами. Поскольку мы использовали coEvery для этого, мы получаем ответ, который создали.

И, наконец, мы проверяем, правильно ли установлено значение LiveData.

Util class, предоставленный Google для тестирования LiveDataUtil class, предоставленный Google для тестирования сопрограмм внутри ViewModel

Android Application Testing Service & Tools Company

Android Application Testing Service & Tools Company — Testlio

Глобальное решение для тестирования приложений Android

9 из 10 мобильных устройств работают на Android.* Это буквально миллиарды устройств по всему миру. Наше тестирование приложений для Android призвано помочь вашей команде сосредоточиться на клиенте, а не на фрагментации. Благодаря гибким управляемым службам контроля качества и глобальным талантам мы помогаем вам продолжать работу. Testlio может помочь вам настроить таргетинг на наименьшее количество устройств, используемых наибольшим числом ваших клиентов, добавляя популярные выбросы для стратегического охвата устройств.

Больше возможностей для роста с меньшими проблемами роста

Android — это синоним перегруженности устройств.Более 24 000 устройств от 1300+ брендов используют Android. ** Вот почему разработка для Android — это не для всех. Речь идет о знании своего рынка и того, кому вы служите. Наше решение для глобального тестирования расширяется вместе с вашим приложением, поэтому, когда вы будете готовы выйти на новые рынки, наше покрытие устройств может помочь вам сделать это с уверенностью.

Результаты тестирования готовы до дня выпуска

В качестве решения для сквозного контроля качества мы сотрудничаем с вами на каждом этапе разработки приложений для Android.Мы создаем стратегии тестирования приложений Android на основе ваших спринтов и предоставляем приоритетные результаты, чтобы ваша команда могла быстро отсортировать проблемы до дня выпуска. SDK инструментария приложений Testlio для iOS и Android автоматически записывает и сообщает подробные сведения о тестировании, такие как сетевой трафик, ЦП, память, память, аккумулятор, ориентация устройства, местоположение, версия ОС и язык. Независимо от того, обновляете ли вы свое приложение раз в неделю или раз в месяц, мы можем идти в ногу с вашей командой. Клиенты направляют нас на критический путь к выпуску, и мы добиваемся стабильных и своевременных результатов.

Постоянное качество

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

Глобальное покрытие устройств

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

Надежное партнерство по обеспечению качества

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

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

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

×

Как выбрать подходящий фреймворк для Android

Платформа Android, которой уже более 10 лет, имеет множество доступных инструментов для тестирования.Java стала еще более зрелой с богатым набором инструментов для тестирования Android-проектов.

Тогда у вас есть среды тестирования пользовательского интерфейса с открытым исходным кодом, включая Appium, Espresso, Robolectric и Mockito / Powermock, из которых можно выбирать. Все это может сбивать с толку, особенно если вы только начинаете работать с Android.

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

JUnit — это основа

Во-первых, давайте начнем с основ: JUnit — это среда тестирования по умолчанию для Android. Mockito, Robolectric и Espresso используют его как основу и строят поверх него. Это то решение, которое вам не нужно принимать.

В частности, AndroidJUnit4 — это текущая программа запуска, которая предоставляет утилиты для запуска тестов Android. После недавних выпусков AndroidJUnitRunner устарел, и AndroidJUnit4 стал единственным средством запуска для тестов Espresso и Robolectric.

Как вы могли догадаться, на горизонте появится AndroidJUnit5, и вы можете получить встроенную поддержку тестов стиля JUnit5 в Android.

Appium

Ни одно обсуждение фреймворков мобильного тестирования не будет полным без Appium, родного фреймворка мобильного тестирования, который работает с Android, iOS, настольными компьютерами Windows и устройствами Интернета вещей.

Когда и зачем его использовать

• Для очень высокоуровневых, проточных испытаний.
• Для тестирования конкретных приложений PROD, как это сделал бы пользователь.Он обеспечивает высочайшую точность сценариев для конечных пользователей.
• Для интеграции с другими приложениями, такими как настройки и средства набора номера, а также для параметров системного уровня, таких как push-уведомления и виджеты.
• Для команд, которые имеют схожие приложения на разных платформах и хотят иметь единый тестовый репозиторий, нацеленный на них всех.
• Для команд, у которых есть специалисты по веб-Selenium и которые хотят использовать этот опыт для автоматизации собственных приложений.
• Для команд, у которых есть гибридное приложение или приложение React Native, а также тесты Appium, которые могут быть размещены в одном месте.

Почему он может не подходить

• Это медленно. Его архитектура на основе HTTP туда и обратно означает, что каждый вызов для поиска элемента выполняется медленно. Нативные приложения используют более быстрые локаторы.
• Код Appium обычно не совпадает с репозиториями мобильных приложений и может быстро рассинхронизироваться.
• Фреймворк в значительной степени зависит от предложений с открытым исходным кодом. Таким образом, ему может не хватать документации и поддержки последних выпусков.

Рекомендуемая настройка CI

• Appium работает ежедневно на очень небольшом наборе сквозных потоков высокой ценности на нескольких устройствах.

Espresso

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

Когда и зачем его использовать

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

Почему это может не подойти

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

Рекомендуемая настройка CI

Roboelectric

Фреймворк для тестирования пользовательского интерфейса Roboelectric, который стал популярным в последние несколько лет, имеет параллели с Headless Chromium. Roboelectric не имеет физического интерфейса пользователя, и тесты работают в смоделированной среде. Доступны API-интерфейсы Android SDK framework, а взаимодействие просмотра имитируется.Самым большим отличием Roboelectric от Espresso является то, что Roboelectric не нуждается в эмуляторе или устройстве.

Когда и зачем это использовать

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

Почему это может не подойти

Рекомендуемая настройка CI

Google вносит большой вклад в Roboelectric, и с Project Nitrogen границы между Espresso и Roboelectric стираются.

Mockito и Powermock

Mockito — это фиктивный фреймворк для модульных тестов, написанных на Java. Он похож на Powermock, но предоставляет дополнительные функции имитации, такие как синглтоны. Страница Powermock на GitHub описывает его как «платформу Java, которая позволяет выполнять модульное тестирование кода, обычно считающегося непроверяемым.«

Имитационные фреймворки для модульного тестирования идеально подходят для просмотра тестирования моделей и тестирования вспомогательных классов. В хорошо спроектированном коде, например, в соответствии с шаблоном MVVM или MVP, около 50% кода следует тестировать с использованием фреймворков модульного тестирования. И эти фреймворки не нужны хуки Android SDK.

Когда и почему вы должны его использовать

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

Почему это может не подойти

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

Рекомендуемая настройка CI

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

Собираем все вместе

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

Источник: Satyajit Malugu

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

А теперь приступим.

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

Продолжайте учиться

Лучшие устройства для тестирования приложений Android в 2021 году

Поскольку 2021 год только начинается, самое время взглянуть на самые популярные устройства для тестирования приложений Android.Каждый год вы можете ожидать, что такие бренды, как Samsung, Google, LG, Huawei и Xiaomi, будут выпускать новые устройства Android. По данным Statcounter, Android составляет чуть более 70% мирового рынка мобильных операционных систем. Лучше всего включить в тестирование мобильного приложения самые разные устройства Android.

Версии Android и фрагментация устройства

В отличие от iOS, Android поддерживается большим количеством производителей мобильных устройств . По данным Statista, в мире насчитывается около 3,5 миллионов смартфонов, что означает, что около 2,5 миллиардов из них работают на Android. Android поддерживается на устройствах производства Google, Motorola, OnePlus, Sony, Samsung, LG, Nokia, Huawei и Xiaomi, а также других производителей.

При таком разнообразии устройств важно определить, какие из них наиболее популярны в вашей целевой аудитории. В третьем квартале 2020 года Samsung достигла 30% доли рынка США, но лишь 23% доли мирового рынка.Такие бренды, как Huawei и Xiaomi, не так популярны в США, однако за тот же период они достигли 14,9% и 13,5% доли мирового рынка.

Помимо пользователей Android, производители которых различаются, они также используют самые разные версии Android. Android не публикует официальную статистику с мая 2019 года, но, по оценкам, люди во всем мире используют 13 различных версий Android на сотнях телефонов Android. Эта фрагментация означает, что для ваших приложений важно поддерживать не только самую последнюю версию ОС.Для обеспечения покрытия может быть полезно вернуться к Android Marshmallow (6.0).

Согласно статистике, собранной Mixpanel, внедрение Android растет, особенно в конце 2020 года. В начале года Android занимал 54,80% рынка; к декабрю этот процент вырос до 61,70%, как показано на диаграмме ниже.

Понимание вашей целевой аудитории, определение списка Android-устройств

Чтобы спланировать разработку или тестирование приложения для Android, важно определить свою целевую аудиторию.Какие устройства популярны, зависит от региона, поэтому вы должны определить, где находится ваша целевая аудитория. Такие производители, как Samsung и Google, обычно популярны в США, в то время как Xiaomi и Huawei часто более популярны в Европе и Китае.

Например, согласно Counterpoint Research, ведущие производители в США и Китае сильно различались в третьем квартале 2020 года. Samsung сохранила самую высокую долю рынка Android в США — 30%. Huawei достигла 43% доли рынка в Китае.LG и Lenovo / Motorola являются одними из ведущих производителей в США. В Китае в этот список входят Vivo, Oppo и Xiaomi. Часто это устройства среднего класса с качественным оборудованием и функциями. Эти недорогие варианты убедили большое количество пользователей перейти на эти новые бренды.

Лучшие устройства для тестирования приложений Android в 2021 году

В первой половине 2020 года Samsung оставалась лидером в мире мобильных устройств с 20,24% доли рынка. Huawei вплотную приблизилась к сокращению разрыва между ними — 18.85% мирового рынка. Несмотря на свою популярность в США, Apple достигла лишь 11,89% доли рынка.

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

Galaxy A51

Согласно исследованию Omdia, у Samsung было только одно устройство в списке 10 лучших смартфонов, проданных в первой половине 2020 года.Galaxy A51 было продано 11,4 миллиона единиц, уступая только iPhone 11 за этот период. В отличие от прошлого года, когда флагманские устройства, такие как Galaxy S9, S10 и S10 +, были самыми популярными, Galaxy A51 является одним из устройств Samsung среднего уровня. В прошлом году у Samsung было четыре устройства в топ-10, так что это не лучшая новость для Samsung.

Redmi Note 8 и Redmi Note 8 Pro

Xiaomi менее известна в США, но производит одни из самых популярных устройств в мире.Redmi Note 8 было продано 11 миллионов единиц, сразу после Samsung Galaxy A51.

Redmi 8A и Redmi 8

Redmi 8A и Redmi 8 были проданы в общей сложности 14,1 миллиона единиц за час 2, поэтому очевидно, что эти устройства популярны. Это отличное устройство, если вы запускаете свое приложение или веб-сайт по всему миру.

Galaxy S10 и серии S20

Флагманские телефоны Samsung не входили в десятку лучших моделей смартфонов по всему миру во втором полугодии 2020 года, но они по-прежнему популярны.В третьем квартале 2020 года Samsung вернулась на первое место по поставкам смартфонов — за этот период было отправлено 80,4 миллиона смартфонов. Почти каждый четвертый смартфон, занимающий 22,7% мирового рынка, является устройством Samsung.

Galaxy S20 продавался не так хорошо, как его предшественник. Согласно сообщениям корейского издания Yonhap News, она достигла только 80% продаж как серия S10. Тем не менее, поскольку это новейшее флагманское устройство, часто бывает важно включить эти устройства в свой план тестирования.Может быть полезно узнать, как ваше приложение или мобильный веб-сайт работает в новейшей линейке, поскольку они, вероятно, будут продолжать становиться популярными и будут поддерживаться в следующих трех обновлениях Android. Также может быть полезно включить более старые устройства Samsung, такие как Galaxy S7, S8 и S9, поскольку эти устройства все еще широко используются.

Источник: Samsung

Google Pixel 4 и Pixel 5

Google приобрела Android в 2015 году и выпустила новые версии ОС линейки Pixel впервые с момента ее выпуска в 2016 году.Включение новейших Pixels в план тестирования гарантирует, что ваши приложения будут тестироваться на новейших версиях Android сразу после их выпуска. Хотя эти устройства не продаются в таких количествах, как такие конкуренты, как Samsung, они набирают обороты. Продажи Pixel в 2019 году выросли на 52% по сравнению с продажами в 2018 году.

Складные устройства

По мере того, как смартфоны продолжают совершенствоваться, вы можете ожидать, что пользователи будут выпускать и внедрять все больше складных устройств.На данный момент Motorola и Samsung выпустили несколько складных телефонов. Motorola выпустила версии своего классического Razr 2019 и 2020 годов. Samsung выпустила Galaxy Z flip, чтобы напрямую конкурировать с предложениями Motorola. Samsung также выпустила Galaxy Z Fold and Fold 2, которые предлагают другой взгляд на то, как складываются телефоны. Считается, что Galaxy Z Fold положил начало основной тенденции складных телефонов. Хотя эти телефоны не так популярны, как другие в этом списке, их все же полезно включить.

Источник: Motorola

Тестирование на Android 11

В прошлом году Android 10 был самым быстрым среди всех версий Android, работая на 100 миллионах устройств через пять месяцев после запуска. Согласно сообщению в блоге разработчиков Android, всего через два месяца после запуска Android 11 был принят на большем количестве устройств, чем Android 10 за тот же период времени. Это не гарантирует, что со временем у него будет более высокая скорость внедрения, чем у Android 10. Тем не менее, при тестировании приложения для Android важно учитывать любую основную версию ОС, например Android 11.

Хотя мы выделили самые популярные устройства в 2020 году, мы рекомендуем включать более старые устройства при тестировании, особенно для приложений Android. Мы рассмотрели лучшие устройства для тестирования приложений Android на 2020, 2019 и 2018 годы, поэтому ознакомьтесь с нашими предыдущими публикациями, чтобы узнать больше.

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