Неисправности 

Как тестировать адаптивный веб-дизайн? Как бесплатно протестировать адаптивный дизайн Инструмент для проверки адаптивной верстки

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

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

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% ; } Меню Название страницы

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

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

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

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

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

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

Модифицируем наш пример следующим образом. Если разрешение экрана меньше 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 " } } Раскрыть меню ↓ Меню Название страницы

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

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

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

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

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

Одна из самых примечательных задач, которая когда-либо стояла перед 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. Google Mobile-Friendly Test

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

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

От автора: «Прекрати менять размер этого браузера, он уже скоро сотрется!» Как часто вы это слышите? Ну, ладно, может и не так уж часто, но если вы разрабатываете адаптивные веб-сайты, то знаете, о чем я говорю: при каждом редактировании DOM или CSS вы таскаете туда-сюда край браузера, тестируя изменения и отыскивая неточности.

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

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

Дома у меня есть два разных лэптопа, два разных устройства Android: Kindle и Nexus 7. Эти устройства я применяю для тестирования своих фрилансерских разработок, но понятно, что это не исчерпывающая подборка. Совсем нет устройств iOS, и хотя я считаюсь ранним последователем, не планирую покупать каждый новый телефон/планшетфон/планшет, как только он появится в продаже.

Так что же делать разработчику? К счастью, растет количество инструментов на базе браузеров, имитирующих размеры экранов множества устройств. Разные инструменты, конечно, идут с разными наборами характеристик и различными уровнями эффективности. Некоторые из них мы тут и рассмотрим.

Для целей тестирования я взял первый по-настоящему адаптивный созданный мною сайт, PajamasOnYourFeet.com . Он основан на шаблоне Brownie HTML5 , очень благосклонно и бесплатно предоставленном сообществу разработчиков на EGrappler.

Am I Responsive?

Am I Responsive? – совершенно легкий, мгновенный просмотр вашего сайта с точки зрения того, как он будет отображаться на четырех разных устройствах. Все четыре – с iOS, и разработчик на сайте объясняет свой выбор. Он не предлагает никаких элементов управления и вариантов выбора, только очень простое и элегантное отображение. Размеры окна просмотра:

Десктоп - 1600 x 992px, уменьшающиеся по шкале (0.3181)

Лэптоп - 1280 x 802px, уменьшающиеся по шкале (0.277)

Планшет - 768 x 1024px, уменьшающиеся по шкале (0.219)

Мобильный - 320 x 480px, уменьшающиеся по шкале (0.219)

Цитируя разработчика: «Это не инструмент тестирования, очень важно делать это на настоящих устройствах. Но он является инструментом быстрых скриншотов (для меня) и предоставления визуальной возможности «втолковать» на встречах с клиентами, что вы имели в виду».

deviceponsive

deviceponsive аналогичен сайту Am I Responsive? тем, что просто и аккуратно отображает ваш сайт, не имеет элементов управления или доступных опций, когда дело касается устройств. Все они показываются одновременно на одной длинной странице. У него есть интересное свойство – можно модифицировать верхний колонтитул, отредактировав его фоновый цвет и вставив собственный логотип, а затем «запринскринить». Так можно в некотором смысле брендировать свой сайт при показе скриншотов клиенту. Имитируемые на этом сайте устройства и размеры экранов:

Macbook - 1280 x 800

iPad (книжная ориентация) - 768 x 1024

iPad (альбомная ориентация) - 1024 x 768

Kindle (книжная ориентация) - 600 x 1024

Kindle(альбомная ориентация) - 1024 x 600

iPhone (книжная ориентация) - 320 x 480

iPhone (альбомная ориентация) - 480 x 320

Galaxy (книжная ориентация) - 240 x 320

Galaxy(альбомная ориентация) - 320 x 240

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

responsive test

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

Здесь предлагаются тринадцать разных окон просмотра, от большого монитора настольного компьютера до так называемого «паршивого Android’а» (Crappy Android) (если честно, у них есть и опция с названием «Android получше» (Nicer Android).

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

responsive.is

Он очень похож на два предыдущих, и единственное, что отличает от них responsive.is – это плавная анимация дисплея одного устройства к следующему, а также полупрозрачный оверлей, показывающий «недвижимость» сайта, выпадающую из окна просмотра.

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

Screenqueries

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

Интересная особенность этого сайта – для нескольких устройств имеется опция «Правильный вид» (“True view”), которая показывает ваш сайт обернутым в предписанный этому устройству браузер chrome. К сожалению, и я к этому уже привык, Firefox’у не удается отобразить слайдер изображения тестового сайта. Не ругайтесь, из браузеров я действительно предпочитаю Firefox, но к счастью, у нас есть опции.

Screenfly

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

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

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

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

Заключение

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