Test web on android

First of all, make sure developer mode is turned on in your Safari preferences so that the remote debugger port is open.

Mobile Safari on a Real iOS Device

For XCUITest

We use appium-ios-device to handle Safari since Appium 1.15. You no longer need to install additional dependencies.

For Instruments

For iOS 9.3 and below (pre-XCUITest), we use the SafariLauncher App app to launch Safari and run tests against mobile Safari. This is because Safari is an app that is owned by Apple, and Instruments cannot launch it on real devices. Once Safari has been launched by SafariLauncher , the Remote Debugger automatically connects using the ios-webkit-debug-proxy. When working with ios-webkit-debug-proxy , you have to trust the machine before you can can run tests against your iOS device.

For instruction on how to install and run ios-webkit-debugger-proxy see iOS WebKit debug proxy documentation.

Setup for an iOS real device

Before you can run your tests against Safari on a real device you will need to:

XCUITest and Instruments
- Turn on web inspector on iOS device (settings > safari > advanced)
Only for Instruments
- Have the ios-webkit-debug-proxy installed, running and listening on port 27753 (see the hybrid docs for instructions)
- Make sure that SafariLauncher will work (see the SafariLauncher docs for instructions)

Running your test

To configure you test to run against safari simply set the «browserName» to be «Safari» .

Android mobile web automation

Appium supports automating the Chrome browser both real and emulated Android devices.

Make sure Chrome is installed on your device or emulator.
Chromedriver needs to be installed (a default version comes with Appium) and configured for automating the specific version of Chrome available on the device. See here for more information and details about compatibility.

Then, use desired capabilties like these to run your test in Chrome:

Note that on 4.4+ devices, you can also use the ‘Browser’ browserName cap to automate the built-in browser. On all devices you can use the ‘Chromium’ browserName cap to automate a build of Chromium which you have installed.

Troubleshooting Chromedriver

If your test target requires newer Chromedriver version, chromedriver_autodownload feature will help. It has been available since Appium 1.15.0 with the security option. Read the linked documentation to learn how to use it. chromedriverExecutableDir capability also helps when you need a specific Chromedriver version.

As of Chrome version 33, a rooted device is no longer required. If running tests on older versions of Chrome, devices needed to be rooted as Chromedriver required write access to the /data/local directory to set Chrome’s command line arguments.

If testing on Chrome app prior to version 33, ensure adb shell has read/write access to /data/local directory on the device:

There is a desired capability showChromedriverLog which, when set to true , writes the Chromedriver logs inline with the Appium logs. This can be helpful for debugging.

For more Chromedriver specific documentation see ChromeDriver documentation.

Источник

Особенности тестирования Mobile Web приложений

Тестирование Mobile Web в чем-то похоже на тестирование Desktop Web. С одной стороны это те же HTML, CSS, JavaScript и прочие прелести, которые мы привыкли видеть. Те же проблемные места и типичные баги. С другой стороны, отличия все же имеются.

В этой статье я собрал небольшой чек-лист тех особенностей, которые важно проверять на Mobile Web проекте. Список не претендует на полноту, так что дополняйте его своими пунктами в комментариях. Я буду только рад. Единственное правило — пункт должен относиться только к мобильному вебу, а не к вебу вообще.

Начать хотелось бы с того, что у нас есть как минимум два способа тестировать Mobile Web проекты. Первый — эмулировать мобильный браузер средствами Chrome DevTools (или другими браузерами в их инструментах разработчика, но это менее популярный способ). Второй — тестировать на реальном девайсе, используя настоящий мобильный браузер.

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

Chrome DevTools

Итак, как было сказано выше, мобильное тестирование можно провести на ПК, не используя мобильное устройство. Браузер Chrome умеет работать в мобильном режиме.

Мобильный режим

Для того, чтобы перейти в мобильный режим просмотра веб-страницы, необходимо открыть Chrome DevTools и нажать на вот этот символ:

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

Мы можем выбирать из списка тип девайса, работу с которым мы эмулируем:

User Agent

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

Для того, чтобы все сделать правильно, необходимо в Chrome DevTools дополнительно настроить Network conditions, выставив мобильный User Agent:

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

Network throttling

При помощи Chrome можно проверить работу приложения как на медленном интернете, так и вовсе оффлайн. Для этого на той же вкладке Network Conditions можно выбрать параметр network throttling:

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

Это не все, что есть в Chrome DevTools. Это отличный инструмент как для работы с Desktop Web, так и для Mobile Web. По нему есть отличная документация от Google, in English of course.

У нас есть двухнедельный онлайн-курс по Chrome DevTools на русском. Вся информация на странице профиля. Движемся дальше. 🙂

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

Производительность

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

Современные веб-приложения перегружены всякого рода анимациями, сложными вычислениями на стороне клиента и так далее. Если на десктопе все это добро может работать гладко и красиво (хотя тоже не всегда), на каком-нибудь Samsung J-линейки (например, J2) могут быть лаги.

Мобильные браузеры

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

Одним из представителей такого браузера является Samsung Internet Browser. На нем стоит проверить работу своего веб-приложения. Особенно если нет статистики, показывающей “с чего сидят” ваши пользователи. Если такая статистика есть и она утверждает, что с этих браузеров никто на приложение не заходит, то скорее всего тестировать его не надо. Хотя… а что, если они не заходят потому, что оно как раз сломано? 🙂

Стоит об этом подумать.

Работа в Background

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

Теперь предположим, что по какой-то причине наш пользователь перевел браузер с открытым приложением в бэкграунд. А затем вернулся. Вот несколько примеров того, что может быть не так. Например, у нас приложение-чат и вся история переписки потерялась. Теперь требуется перезагрузка страницы. Плохо? Конечно! Или у нас приложение “записная книжка”. Пользователь не успел что-то дописать, когда его прервал входящий звонок. Вернувшись, он обнаружил, что написанное им стерлось. Теперь придется писать все заново. А может лучше не пользоваться таким приложением?

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

Электронная клавиатура

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

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

Ориентация экрана

У мобильных приложений есть два типа ориентации экрана: portrait и landscape. Об этом можно почитать тут.

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

Chrome DevTools умеет эмулировать оба режима, но все же сам процесс переворота и дальнейшая перерисовка веб-приложения происходит иначе, чем на настоящем мобильном браузере.

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

Веб-страница в нативном приложении

Еще один распространенный кейс: когда у приложения есть как Mobile Web версия, так и нативное приложение. В этом случае бывает так, что часть страниц в нативное приложение не переносят, а просто отображают их как WebView.

WebView — это компонент, который позволяет встраивать веб-страницы в приложение. Встроенный браузер просто рендерит внутри приложения то, что мы бы увидели на Mobile Web. Довольно часто это экономит время при разработке нативного приложения.

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

Обработка тапов

В отличие от Desktop Web, где есть только клик мышью, в мобильном приложении существует несколько способов взаимодействия с интерфейсом: touch, tap, flick и так далее. Об этом много где можно почитать, например тут.

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

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

Итого

Я рассказал об основных особенностях тестирования Mobile Web проектов. Если вы пришли из тестирования Desktop Web, этот список скорее всего вам пригодится. Само собой, это не все, что можно было вспомнить касательно данного вопроса. Если хотите дополнить список, обязательно пишите в комментариях те проверки, которые делаете вы.

Источник

“Протестируй на всех браузерах на телефоне” или инструменты для тестирования Mobile Web приложений

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

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

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

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

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

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

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

Существует как минимум 3 способа для тестирования:

На реальном устройстве;
С помощью эмулятора;
C помощью симулятора.

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

+ Точность результатов;
+ Облегчает тестирование ориентации устройства;
— Дорого;
— Трудоемкий процесс создания и последовательного воспроизведения
результатов;

Эмуляторы:

+ Легче управлять переключением типов устройств, загрузив новый профиль устройства;
+ Бесплатно или небольшие затраты;
— Возможно небольшие погрешности в результате;
— Ограниченные возможности при использовании изменения размера окна.

+ Экономически выгодно;
— Не принимает во внимание аппаратное обеспечение;
— Возможны ложные срабатывания;
— Результаты моделирования могут быть трудными для анализа из-за неполных данных.

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

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

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

Chrome DevTools — простой эмулятор на основе браузера Google Chrome, который умеет работать в мобильном режиме. Применяется, в основном, для выполнения начального уровня тестирования эмуляции определенного мобильного устройства.
BrowserStack — онлайн-инструмент для тестирования веб-приложений на различных мобильных устройствах. Это довольно надежный и исчерпывающий инструмент, который обеспечивает легкий доступ к более чем 1200 реальных мобильных устройств и браузеров. Пользовательский интерфейс довольно прост для понимания.
MultiBrowser — онлайн-инструмент, позволяющий убедиться, что приложение хорошо работает на мобильных устройствах. Он использует эмуляторы мобильных браузеров, чтобы обеспечить беспроблемное тестирование. Для работы с инструментом не нужен круглосуточный доступ в Интернет, так как он отлично работает и как настольное приложение.

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

Как выбрать на чем тестировать?

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

gs.statcounter.com Вам в помощь!

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

Обычный браузер — это отдельное приложение для просмотра веб-сайтов на мобильных устройствах. Как правило, такие браузеры отличаются гибкостью настроек и расширенными функциями, относительно встроенных. Наиболее популярные: Google Chrome, Safari, Mozilla Firefox, Operа mini, Tor Browser, UC Browser.

In-App браузер — это встроенный браузер в приложении, который имеет окно веб-просмотра. Каждый раз, когда вы нажимаете на ссылку в мобильном приложении (например Facebook), вы используете встроенный браузер, то есть переходите по ссылке внутри самого приложения.

Браузеры In-App имеют легкий функционал, но они не позволят Вам добавлять закладки, не имеют изменяемой адресной строки и не дают открывать ссылки в новых окнах (только дают перейти в обычный браузер).

При выборе браузера можете использовать опять же таки gs.statcounter.com и для статистики траффика вашего приложения — www.similarweb.com

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

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

Источник