Как тестировать адаптивный веб-дизайн? Тестирование адаптивного веб-дизайна Тестирование адаптивного дизайна

Фреймворков, таких как или , которые существенно облегчают и ускоряют верстку страниц.
подразумевает под собой отличное отображение веб страницы на всех устройствах и расширениях мониторов. Наверное, не у каждого верстальщика имеется полный набор девайсов со всеми возможными расширениями дисплеев, для тестирования своей верстки . Это и не удивительно, ведь техника нынче не дешевая.
Итак. Покупать горы мобильников и планшетов, не вариант - разоримся. Что же делать? Для этих задач были разработаны сервисы для тестирования адаптивных сайтов . Принцип работы их очень прост. Чаще всего имеется фрейм определенного размера, где открывается страница. Эффект получается примерно такой же, как и при просмотре на мобильном устройстве. Хочу заметить, что сервис не всегда в точности покажет отображение страницы на телефоне или планшете. При верстке следует тестировать с помощью сервисов, но после завершения, по возможности, протестировать на наиболее распространенных устройствах.
Итак. К вашему вниманию лучшие инструменты для тестирования адаптивных сайтов .

Инструмент для тестирования адаптивных сайтов от компании Adobe. Для его использования требуется установить себе на компьютер.
Программа позволяет синхронизировать ваши устройства по WIFI и просматривать сайт так, как он будет отображаться на вашем девайсе. На данный момент поддерживаются устройства с такими ОС: iOS, Android, Kindle Fire.

Одна из самых примечательных задач, которая когда-либо стояла перед QA-отделом EastBanc Technologies, заключается в создании автоматизированной системы тестирования сайта www.washingtonpost.com . Это электронная газета, реализованная в виде информационного и новостного портала.

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

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

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

Выбор инструментов тестирования верстки

Исследовав просторы интернета, мы остановились на следующих подходах и инструментах. Для тестирования каркаса страницы мы взяли на вооружение фреймворк Galen , который после интегрировали с testNG.

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

Лазурным цветом - тестируется Galen’ом, залитое зеленым - скриншот-тесты:

Осторожно! Большая картинка

Скрытый текст

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

К примеру, есть 2 блока, на проверку которых у нас изначально были написаны функциональные тесты: Most Read и Information Block. Теперь мы первый проверяем скриншотами, а второй - гален-тестом.

MostRead Block, проверка скриншот-тестом:


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

Тестирование этого блока рассмотрено в главе о скриншот-методе.

WaPo Information Block:


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

Код Гален-теста .

Наша автоматизированная система тестирования использует: Java, Maven, TestNG, Selenium WebDriver , Selenium Grid, Galen Framework .

В создании Screenshot-based тестов нам активно помогает кроссплатформенный набор утилит ImageMagick .

Сразу хотелось бы отметить, что код тестов мы пишем на Java с применением паттерна PageObject и фрейморка от Яндекс - HTML Elements . Для запуска тестов используются maven и testNG.

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

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

Тестирование при помощи Galen Framework

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

Galen Framework уже был достаточно подробно описан в одной из статей . Если кратко описать принцип работы с Галеном, то выглядит это примерно следующим образом: вы пишете спецификацию страницы (так называемый spec файл), используя специальный, хорошо документированный и интуитивно понятный синтаксис. В spec файле описывается взаиморасположение, размер, отступы, вложенность элементов страницы и некоторые другие параметры и условия, которым должна соответствовать верстка страницы, можете проверить даже соответствие текста внутри элемента. И все эти проверки будут применяться в зависимости от указанных нами тэгов.

Тэги в spec-файле могут задаваться таким образом:






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




При клике на подсвеченную красным проверку отображается скриншот всей проверяемой страницы с такой подсветкой элементов:




Galen Framework принимает на вход следующие параметры:

• браузер, в котором будет проходить проверка
• разрешение, на котором следует запустить тест
• url тестируемой страницы
• Javascript-файл, который нужно (если нужно) применить на запускаемой странице до начала проверок по.spec файлу (например, если нужно проверить отображение страницы залогированному на сайте пользователю)
• имя запускаемого.spec файла
• тэги, которые необходимо применить к проверкам.spec файла (например: desktop, all, если мы тестируем лэйаут для десткопа).

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

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

Выбор тестируемой страницы из подмножества однотипных страниц

А какие страницы выбрать для тестирования верстки, если тест предназначен для проверки множества однотипных страниц?

Мы решили, особо не заморачиваясь, при каждом запуске тест-сьюита выбирать рандомную страницу из подмножества (т.е. для тестирования подмножества страниц рецептов выбрали один из рецептов и передаем его url всем тестам по лэйаутам). Так как проверить все страницы задачи не стоит, посему вариант выбора рандомной страницы показался оптимальным. Url рандомной страницы подмножества проверяемых страниц передается Галену методом, общим для всех тестов внутри нашей системы автоматизированного тестирования сайта (кроме тестов на тестирование верстки, у нас есть также функциональные и скриншот-тесты).

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




Из примера видно, что блок “Most Read”, который должен располагаться в правом столбце страницы, на левой странице располагается в основной части, а не справа. Чтобы проверить отсутствие подобного рода проблем, нужно проверить большое число страниц и учесть множество факторов.

На каких разрешениях запускать тесты?

Сначала появилась идея выбрать наиболее распространенные девайсы и использовать для запуска тестов их разрешения. Однако, явно прослеживающаяся тенденция ускоренной мобилизации планеты не позволяет выделить (и, тем паче, предсказать) каких-то безусловных лидеров на этом поприще. Девайсов, позволяющих просматривать веб-приложения, великое множество, и унификация разрешений для таких девайсов – совершенно не модное нынче занятие. Внезапно прокравшаяся мысль о том, что адаптивный дизайн на то и адаптивный, чтобы правильно отображаться на любом валидном разрешении, спасла наши умы и пресекла дальнейшие исследования в этой области. Решение было принято: тестируем верстку на всех валидных разрешениях.

Валидными разрешениями были назначены все разрешения от min Viewport width = 241 px (меньше браузер не уменьшается) до max Viewport width = 1920px (верхняя граница - простым волевым усилием). У нас пока не было страниц, где высота вьюпорта для целей автоматизированного тестирования являлась определяющим параметром, поэтому на высоту мы пока не обращаем внимания.

Как же тестировать верстку на всех разрешениях?

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

DESKTOP: max 1920px, min 1018px;
LAPTOP: max 1017px, min 769px;
TABLET: max 768px, min 481px;
MOBILE: max 480px, min 361px;
SMALL_MOBILE: max 360px, min 280px.

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

Ниже описан код для запуска Galen-теста для десктопных разрешений:

Скрытый текст

При запуске каждого теста Galen’у подается рандомное разрешение из диапазона для заданного лэйаута (getRandomResolution(DESKTOP)):

protected Dimension getRandomResolution(Dimension d) { return getRandomDimensionBetween(d, d); } private Dimension getRandomDimensionBetween(Dimension d1, Dimension d2) { double k = Math.random(); int width = (int ) (k * (Math.abs(d1.getWidth() - d2.getWidth()) + 1 ) + Math.min(d1.getWidth(), d2.getWidth())); int height = (int ) (k * (Math.abs(d1.getHeight() - d2.getHeight()) + 1 ) + Math.min(d1.getHeight(), d2.getHeight())); return new Dimension(width, height); }

И, собственно, диапазон разрешений задается в таком виде:

public static final Dimension DESKTOP = {new Dimension(1920 , 1080 ), new Dimension(1018 , 1080 )};

Тестирование по рандомному выбору разрешения из валидного диапазона и тестируемой страницы из подмножества однотипных страниц, таким образом, превращается в вероятностный процесс. Чем чаще будем запускать - тем больше разных багов найдем. При единичном успешном прохождении теста мы может сказать лишь, что данная конкретная страницы на данном конкретном разрешении – валидна. Но уже после 500 успешных прогонов мы можем утверждать, что верстка по большей части жизнеспособна. Сразу оговоримся, что «500 успешных прогонов» – это умозрительная оценка, и тут нужно смотреть на контент и количество эквивалентных страниц.

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

Рассмотрим, чем помогает нам такой подход на примере тестирования страницы рецепта.

Тест каркаса страницы рецепта запускается для диапазона разрешений (Viewport width) от 768px до 1017px. Возьмем для примера страницу: www.washingtonpost.com/pb/recipes/maple-banana-frozen-yogurt/14143/

Тест на граничных точках Laptop layout’a (1017px и 768px) не выдавал ошибок.

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

Правильный вид:

Осторожно! Большая картинка

Скрытый текст

Вёрстка сломана:

Осторожно! Большая картинка

Скрытый текст

Screenshot-based метод тестирования

Вдохновившись статьёй , мы решили использовать screenshot-based метод тестирования. К слову сказать, для тестирования лэйаута изначально у нас ставка делалась именно на этот метод. Т.е. была идея сравнивать полноразмерные скриншоты страницы с заранее подготовленной моделью, заменив все потенциально изменяющиеся элементы на заглушки (в качестве заглушек берётся заранее выбранное произвольное изображение). К таким элементам у нас относились картинки, флеш-реклама и текст. Затея провалилась главным образом из-за того, что страницы содержали множество блоков, загружаемых динамически, в результате чего физические размеры снимаемых скриншотов и расположения блоков изменялись от запуска теста к запуску. Кроме того, с некоторых пор Chrome утратил возможность делать полноразмерные скриншоты, что также создало ряд проблем.

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

Для примера:

Вот так выглядит MostRead блок на главной странице washingtonpost.com (слева) и модель с которой мы будем сравнивать скриншот этого блока (справа):



Код теста выглядит так:

@Test (groups = { "ScreenshotBased" }) @WebTest ("Verifies that "Post Most" block is displayed properly" ) public void testMakeupForPostMost() { HomePage page = new HomePage().open(); page.preparePostMostForScreenshot(); screenshotHelper.shootAndVerify(page, page.thePostMost, "_thePostMost" ); }

Для хранения скриншотов используется следующая структура каталогов:: /models/HomePage/firefox/HomePage_thePostMost.png

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

Метод shootAndVerify() находит путь до модели по классу переданной страницы и имени браузера, в котором запущен тест.

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

Как оказалось, сделанный снимок необходимого блока может зависеть от множества факторов, таких как:

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

Первая проблема была в том, что размеры сделанных скриншотов отличались в зависимости от настроек ОС и браузера. Чтобы сделать размеры блоков, а, следовательно, и скриншотов одинаковыми, нужно запускать браузер с постоянными размерами. Изменить размер окна браузера можно, используя соответствующий метод вебдрайвера: driver.manage().window().setSize(requiredSize). Но таким образом мы задаем размер окна, а не размер нужной нам видимой области - вьюпорта. Вертикальный скроллбар, к слову, тоже влияет на размер вьюпорта, и его толщина также зависит от темы windows, поэтому нужно это учитывать. Решением проблемы стал калибровочный метод, подгоняющий размер вьюпорта под заданные размеры. После запуска первого теста, разница между шириной размера окна и шириной вьюпорта сохраняется в специальный параметр и переиспользуется при последующих запусках.

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

layers.acceleration.disabled
gfx.font_rendering.cleartype_params.rendering_mode
gfx.direct2d.disabled

Но, к сожалению, это не помогло.

Кроме того, для сравнения скриншотов утилитой ImageMagick используется такой параметр, как fuzz, который задаёт максимально возможное расхождение скриншотов.

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

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

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

По ссылкам в отчете доступны:

картинка-модель


скриншот тестируемого блока:


результат сравнения этих двух изображений:


CommandException говорит нам о том, что сравниваемые изображения отличаются на 251px:



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




Иногда, по неизвестным причинам, элементы внутри тестируемого блока немного смещены. Для таких случаев мы сравниваем не с одной моделью, а с группой моделей, подходящей по маске, т.е. у нас может быть несколько моделей блока thePostMost с такими именами HomePage_thePostMost.png, HomePage_thePostMost (1).png, и все модели считаем валидными. К счастью, количество таких вариантов конечное, обычно не больше 2.

Технические аспекты

Как уже было сказано выше, для написания и запуска тестов используется стек технологий: Java, Maven, TestNG, Selenium, Galen Framework. Кроме того, результаты прохождения тестов отправляются в graphite. Запуск тестов осуществляется непосредственно при помощи Jenkins CIS. Не будем подробно останавливаться, почему был выбран именно такой набор. Коротко опишем, как это всё взаимосвязано.

Selenium Grid сейчас развернут локально на четырех виртуальных машинах с Windows 7, где запущены ноды грида, и на линуксовой машине, на которой запущен хаб. На каждой из нод доступны по 3 инстанса firefox и chrome браузеров. Кроме того, на линуксовой машине также развернуты Jenkins и graphite. Гален тесты запускаются в общем запуске тестов благодаря интеграции с TestNG. Для этого был написан соответствующий класс, позволяющий использовать jav’овый Galen API. При реализации взаимодействия TestNG с галеном у нас возникли некоторые проблемы, которые были оперативно решены благодаря взаимодействию с разработчиком галена. Сам разработчик галена охотно идёт на сотрудничество и регулярно выпускает обновления для этого инструмента, которые расширяют его возможности и делают его ещё более удобным. Сам он планирует написание документации по интеграции галена с TestNG.

Функциональные, гален и screenshot based тесты разделены при помощи соответствующего параметра группы, приписанного к аннотации Test, и имеется возможность их отдельного запуска.

Наши умозаключения

Оба подхода – метод сравнения скриншотов и тестирование при помощи Galen Framework – применимы для тестирования верстки страниц. Они успешно взаимодополняют друг друга. Метод сравнения скриншотов больше применим, когда нужно протестировать отображение какого-либо отдельного элемента или блока, например панели “шаринга” в социальных сетях или основного меню в хедере. Блок может содержать множество иконок внутри себя, которые в свою очередь могут находиться внутри других иконок и элементов, или иметь относительное с ними позиционирование.

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

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

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

1. Адаптивная верстка сайта - что это такое

Адаптивная верстка сайта - это такая html верстка, в которой в зависимости от размеров окна браузера сайт "трансформируется" в удобной для пользователя вид

Отличия мобильной версии сайта и адаптивной

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

2. SEO оптимизация и адаптивная верстка

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

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

3. Как проверить сайт на адаптивность

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

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

Можно просто вручную изменять размеры окна браузера по ширине и смотреть результат. В Firefox или Google Chrome есть адаптивный дизайн браузера нажав Ctrl+Shift+M.

Самое главное условие - это добиться отсутствия горизонтальной прокрутки и отсутствия flash-плагинов на странице.

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

После проверки возможно два варианта. Либо сайт оптимизирован, либо нет:

Например, проверка адаптивности в Google:

Проверка адаптивности в Яндексе:

4. Как сделать адаптивную верстку сайта

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

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

Синтаксис CSS @Media

@media тип_устройства and|not|only (медиа_особенности ){ ... Описание стилей... }

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

@media screen and (max-width : 800px ) { ... стили ... } Примечание

Стили надо писать последовательно от большого разрешения к маленькому, то есть сначала общие стили, а потом для «урезанных» размеров, например:

@media only screen and (max-width : 1280px ) { ... } @media only screen and (max-width : 1024px ) { ... } @media only screen and (max-width : 800px ) { ... }

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

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

5. Практичные примеры адаптивной верстки сайта 5.1. Адаптируем очень длинные слова

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

.hphns { overflow-wrap : break-word ; word-wrap : break-word ; -webkit-hyphens : auto ; -ms-hyphens : auto ; -moz-hyphens : auto ; hyphens : auto ; } 5.2. Адаптивное меню сайта

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

Реализовать это на сайте можно, но придется немного повозиться со стилями. Давайте рассмотрим все по шагам.

Ситуация, когда у нас есть меню и есть основной контент (я не стал рисовать шапку и футер):

Html код такой структуры может быть примерно таким:

body { margin-left : 10% ; width : 70% ; border : 1px solid #eee ; } #menu { width : 20% ; height : auto ; float : left ; } #content { width : 70% ; height : auto ; float : left ; border-left : 1px solid #000 ; padding : 1% ; } Меню

• Ссылка в меню 1
• Ссылка в меню 2
• Ссылка в меню 3
• Ссылка в меню 4

Название страницы

Контент страницы

Контент страницы

Контент страницы

Контент страницы

Преобразуется на странице в

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

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

Приведем html-код адаптивной верстки с комментариями:

body { margin-left : 10% ; width : 70% ; border : 1px solid #eee ; } #menu { width : 20% ; height : auto ; float : left ; display : block ; } #content { width : 70% ; height : auto ; float : left ; border-left : 1px solid #000 ; padding : 1% ; } #mob_menu { display:none ; } @media only screen and (max-width : 800px ) { #menu { display : none ; } #mob_menu { display : block ; } #content { clear : both ; } } function showmobmenu() { if ( == "block ") { document.getElementById("menu").style.display = "none " } else { document.getElementById("menu").style.display = "block " } } Раскрыть меню ↓ Меню

• Ссылка в меню 1
• Ссылка в меню 2
• Ссылка в меню 3
• Ссылка в меню 4

Название страницы

Контент страницы

Контент страницы

Контент страницы

Контент страницы

Уменьшим ширину экрана до 700 пикселей (к примеру). Вот как это выглядит на странице

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

Что такое адаптивный веб-дизайн?

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

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

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

Проблемы тестирования адаптивного веб-дизайна

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

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

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

Тем не менее, тестирование на реальных мобильных устройствах - это совершенно другой опыт.

Использование эмуляторов

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

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

Google DevTools

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

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

Некоторые общие правила тестирования адаптивного веб-дизайна:

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

Подходящая зона кликабельности

Цвет, затенение и градиент соответствуют

Проверьте правильность заполнения краев

Текст, изображения, элементы управления и рамки не попадают в края экрана

Размер шрифта, стиль и цвет соответствуют для каждого типа текста

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

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

В заключение

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

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

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

1. Google Mobile-Friendly Test

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

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