Хабрахабр

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

Привет, Хабр.

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

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

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

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

Chrome DevTools

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

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

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

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

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

User Agent

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

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

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

Network throttling

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

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

Это отличный инструмент как для работы с Desktop Web, так и для Mobile Web. Это не все, что есть в Chrome DevTools. По нему есть отличная документация от 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.

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

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

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

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

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

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

Итого

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

Спасибо за внимание.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть