Одна из самых примечательных задач, которая когда-либо стояла перед 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)):
И, собственно, диапазон разрешений задается в таком виде:
Тестирование по рандомному выбору разрешения из валидного диапазона и тестируемой страницы из подмножества однотипных страниц, таким образом, превращается в вероятностный процесс. Чем чаще будем запускать - тем больше разных багов найдем. При единичном успешном прохождении теста мы может сказать лишь, что данная конкретная страницы на данном конкретном разрешении – валидна. Но уже после 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 (слева) и модель с которой мы будем сравнивать скриншот этого блока (справа):
Код теста выглядит так:
Для хранения скриншотов используется следующая структура каталогов:: /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 – применимы для тестирования верстки страниц. Они успешно взаимодополняют друг друга. Метод сравнения скриншотов больше применим, когда нужно протестировать отображение какого-либо отдельного элемента или блока, например панели “шаринга” в социальных сетях или основного меню в хедере. Блок может содержать множество иконок внутри себя, которые в свою очередь могут находиться внутри других иконок и элементов, или иметь относительное с ними позиционирование.
С помощью галена описывать все эти мелкие моменты достаточно трудоёмко, однако один скриншот на каждый браузер решает эту проблему, и сравнение скришотов исключает вариант, когда мы что-то можем упустить при описании спека. Гален, в свою очередь, прекрасно справляется с относительным расположением блоков и проверкой заголовков и фиксированного текста в них. Он имеет хорошее применение, когда нужно протестировать вёрстку на однотипных шаблонизированных страницах, не нагруженных функциональной логикой, например, какого-либо информационного портала, как в нашем случае, когда практически любая страница сайта доступна без авторизации, либо каких-либо других действий пользователя. Кроме того, гален хорошо решает задачи кроссбраузерного тестирования в условиях адаптивной вёрстки приложения.
От автора: «Прекрати менять размер этого браузера, он уже скоро сотрется!» Как часто вы это слышите? Ну, ладно, может и не так уж часто, но если вы разрабатываете адаптивные веб-сайты, то знаете, о чем я говорю: при каждом редактировании 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 – единственный, который позволяет тестирование на основании строки агента пользователя.
Протестировав данным образом один созданный мною сайт с имеющейся мобильной версией, могу сказать, что результаты оказались очень хорошими. Все отображалось в точности так, как я ожидал, и тестированию поддавались функции. Надо сказать, тестирование строк агента пользователя стало традиционным, но этот сайт был сделан давно, и свойство прокси-сервера оказалось действительно очень полезным дополнением к нему.
Заключение
Итак, вы видите, что для тестирования адаптивных сайтов имеется достаточно ресурсов. Они различаются уникальными свойствами; какие сайты вы примените, будет зависеть от ваших личных предпочтений и требований, и я стараюсь подтолкнуть вас на исследования и эксперименты с ними. Чем больше у нас, разработчиков, будет по-настоящему полезных инструментов, тем лучше.
Как тестировать адаптивный веб-сайт? Какие проблемы возникают при тестировании веб-сайтов на разных устройствах? Как тестирование веб-сайта на настольном мониторе отличается от тестирования на карманном устройстве, например мобильном телефоне? Какие инструменты мы можем использовать для тестирования адаптивных веб-сайтов? Ответить на Ваши вопросы помогут наши
Что такое адаптивный веб-дизайн?
Адаптивный веб-дизайн (RWD) - это определение подхода к веб-дизайну, направленное на создание сайтов с целью обеспечения оптимального восприятия - простого чтения и навигации с минимальным размером, панорамированием и прокруткой на широком спектре устройств (от настольных компьютерных мониторов до мобильные телефоны).
Сайт, созданный с помощью RWD, адаптирует макет к среде просмотра с использованием жидкостных, пропорциональных сеток, гибких изображений и медиа-запросов CSS3, следующими способами:
- Концепция жидкой сетки требует, чтобы размер элемента страницы был в относительных единицах, таких как проценты, а не в абсолютных единицах, такие как пиксели или точки.
- Гибкие изображения также оцениваются в относительных единицах, чтобы предотвратить их отображение за пределами содержащего их элемента.
- Запросы мультимедиа позволяют странице использовать разные правила стиля CSS, основываясь на характеристиках устройства, на котором отображается сайт, чаще всего ширины браузера.
Проблемы тестирования адаптивного веб-дизайна
Многие люди в настоящее время используют свои мобильные телефоны или планшеты для доступа к веб-сайтам, поэтому тестирование адаптивного веб-дизайна важно, потому что пользовательский интерфейс на мобильных устройствах сильно отличается от настольных компьютеров.
Возможно, самая сложная часть тестирования веб-сайта, отвечающего требованиям, - это то, что веб-сайт работает так, как ожидается на нескольких устройствах и платформах, но фактическое тестирование на всех мобильных устройствах на рынке для большинства из нас непрактично.
Многие тестировщики, начинающие тестировать адаптивный веб-дизайн, обычно начинают с изменения размера окна браузера, чтобы подогнать размер области просмотра мобильного телефона, планшета и рабочего стола. Этот метод обычно подходит для быстрой визуальной проверки веб-сайта в разных портах просмотра и помогает нам выявлять основные проблемы с отображением, когда мы уменьшаем или увеличиваем окно браузера.
Тем не менее, тестирование на реальных мобильных устройствах - это совершенно другой опыт.
Использование эмуляторов
Мобильный эмулятор - это веб-симуляция того, как веб-сайты и приложения будут отображаться и функционировать в мобильной среде.
Хотя эмуляторы не могут предоставить вам точные средства тестирования, которые вам понадобятся, они по-прежнему являются экономически эффективным решением для проверки функциональности веб-сайта на высоком уровне.
Google DevTools
В DevTools Google Chrome есть функция, называемая режимом устройства, в которую загружены полезные инструменты для тестирования и отладки адаптивных проектов.
В отличие от большинства других адаптивных инструментов тестирования дизайна, которые просто изменяют размер вашего экрана, этот инструмент фактически эмулирует работу мобильного устройства, особенно сенсорные взаимодействия, такие как нажатие и прокрутка, прямо в вашем веб-браузере.
Некоторые общие правила тестирования адаптивного веб-дизайна:
- Текст, элементы управления и изображения выровнены правильно
- Подходящая зона кликабельности
- Цвет, затенение и градиент соответствуют
- Проверьте правильность заполнения краев
- Текст, изображения, элементы управления и рамки не попадают в края экрана
- Размер шрифта, стиль и цвет соответствуют для каждого типа текста
- Прокручиваемый текст (ввод данных) отображается правильно
Проверяйте местоположение модулей по мере их сокращения и расширения окна браузера или при повороте мобильного устройства. Различные модули могут исчезнуть при переходе с настольного компьютера на мобильный, но убедитесь, что вы точно знаете, какие модули должны отображаться в каком окне просмотра.
В заключение
Узнайте, как используется ваше веб-приложение. Вы можете получить огромное количество информации из инструмента Google Analytics, чтобы узнать, какие устройства ваши клиенты используют для доступа к вашему веб-сайту. Используйте автоматизированные инструменты и эмуляторы для выполнения основных проверок и высокоуровневого функционального тестирования и сочетания этого с реальным тестированием устройства вручную.
Постоянный рост количества разнообразных портативных устройств создает возможности для того, что все больше и больше пользователей глобальной сети используют именно мобильные гаджеты в качестве средств просмотра веб-страниц (совершение онлайн покупок, просмотр необходимой информации, простой серфинг медиаконтента и прочее).
А так как любые технологии не стоят на месте, то моментально на смену одним мобильным устройствам выходят другие, и в среде веб-разработки активно внедряется такое понятие как адаптивный дизайн.
Если раньше ситуация с поддержкой мобильных устройств решалась банальным созданием отдельной мобильной версии веб-сайта (как например, на специальном поддомене m.mobilesite.com), то сегодня данные вещи выполняются как раз с помощью адаптивного дизайна и верстки (через внедрение технологии media query внутрь набора CSS3).
Подобные данные – это совокупность специальных стилей, созданных для разрешения мобильных устройств с определенными параметрами портативного гаджета. Применяется такой принцип: если гаджет имеет определенные размеры экрана, которые нужно выполнить верстальщику в процессе создания макета сайта, он использует необходимые CSS символы и правила.
Адаптивный веб-дизайн – это специальный подход к разработке оригинального веб-дизайна, при котором происходит ориентация на создание удобно просматриваемых сайтов и площадок на основе использования инструментов для оптимального восприятия – банальное чтение текстовых блоков, панорамирование, а также прокрутка динамических блоков на максимальном числе мобильных устройств (от планшетов до сотовых телефонов).
Думается, что все это очень просто и даже каждый малоопытный верстальщик смог бы самостоятельно справиться с задачей по созданию адаптивного дизайна. Но, как показывает практика, еще не все front-end разработчики до конца улавливают суть требований такой верстки, от чего у специалистов QA всегда хватает работы при прогоне «свеженапечатанного» HTML5+CSS3 макета.
Проблематика проверки адаптивной верстки
Больше половины пользователей Интернета используют свои мобильные гаджеты и планшеты в качестве инструментов для взаимодействия с веб-сайтами, а значит тестировать адаптивную верстку очень важно, ведь порой внешний интерфейс мобильного устройства кардинальным образом отличается от разрешений десктопных устройств.
Скорее всего, наиболее сложная часть проверки веб-сайта под определенные данные – это как раз то, что портал функционирует так, как от него требуется на всем перечне возможных устройств, но фактически проведенное тестирование остается для многих пользователей весьма непрактичной задачей.
Адаптивный дизайн
Очень часто тестировщики, на которых возложена задача проверить адаптивную верстку, традиционно начинают работать с уменьшением/добавлением размера используемого браузера, чтобы в таком режиме подогнать продукт под потенциальные размеры портативного устройства.
Данный метод конечно можно использовать, но только для мгновенного визуального анализа работоспособности сайта в разных разрешениях. Так можно сразу же выявить базовые проблемы с отображением картинки, когда мы поочередно уменьшаем или увеличиваем размеры окна нашего браузера.
Но в данном контексте можно указать на то, что тестирование на настоящих портативных гаджетах – кардинально другой опыт и возможности восприятия разрабатываемого продукта.
Чем тестировать адаптивную верстку?
Как правило, при тестировании адаптивной верстки в рамках целой веб-студии или отдела компании по контролю качества (quality assurance company), у вас под рукой должна быть целая россыпь разнообразных мобильных устройств, которые можно использовать для прогона необходимого разрешения в самых что ни на есть реальных условиях.
Конечно, просто идеально, если у вас под боком лежит новенький iPad или iPod, а также много других Android-гаджетов с разным разрешением.
Но когда нет подобной роскоши, приходиться использовать то, что под рукой.
К большому счастью тестировщиков, уже давно создаются бесплатные онлайн программы и сервисы, имитирующие размеры мобильных гаджетов и идеально подходящие для проведения тестирования адаптивной верстки. Логично предположить, что каждый из них имеет свои как преимущества, так и недостатки. Но обо всем по порядку.
Am I Responsive
Наиболее простой инструмент , с помощью которого вы можете просмотреть свой веб-сайт на 4 наиболее популярных устройствах. Радует, что нет особого перегруза в плане настроек и параметров: все просто и предельно ясно.
Можно тестировать на таких разрешениях:
- ПК – 1600 на 992 пикселей;
- Ноутбук – 1280 на 802 пикселей;
- Планшетный компьютер – 768 на 1024 точек;
- Сотовый телефон – 320 на 480 пикселей.
Deviceponsive
В чем-то схож с Am I Responsive, наверное, в своей простоте и минимальном наборе настроек для проведения анализа верстки.
Все доступные разрешения отображаются на странице в ряд. С помощью предоставленных опций можно редактировать фон и размер заголовка, перемещать другой логотип, что полезно в случае необходимости создания скриншота.
Доступные устройства и портативные разрешения:
- 1280 на 800 точек – Macbook;
- 768 на 1024 точек – iPad;
- 1024 на 768 точек – iPad;
- 1024 на 600 точек – Kindle;
- 320 на 480 точек – iPhone;
- 240 на 320 точек – Galaxy;
К слову, в режиме работы с сайтом сервис специально накладывает полосы прокрутки на страницы для того, чтобы пользователям ПК было удобно проверять каждый сантиметр созданной верстки.
Responsive Test
Подобно Deviceponsive, данный сервис позволяет тестировать сайты на массе реальных устройств в режиме онлайн. Но, чтобы не смотреть на неинтересующие вас разрешения, в меню сервиса вы самостоятельно выбираете те из них, которые являются актуальными именно для вас.
На портале очень хорошо проработана логика масштабирования, а значит есть вариации для тестов большого разрешения на маленьком.
Представлено около 30 различных разрешений – от обычного десктопного монитора до старой версии Андроида.
К слову, если вы работаете с браузером Firefox, у вас могут возникнуть определенные проблемы.
Почему? Точного ответа нет.
Стоит написать в поддержку.
Responsive.is
Весьма схож с первыми двумя инструментами. Но есть у него своя отличительная чета – набор плавной анимации при смене одного «устройства» на другое, а также полупрозрачный фон, демонстрирующий реальный объем сайта, а не только ту область, с который вы работаете в данный момент.
Для работы доступны следующие разрешения: десктоп, планшетный компьютер в портретной и альбомной вариации, мобильный телефон в портретной и альбомной вариациях. К большому сожалению, задавать свои личные размеры в пикселях не предоставляется возможным.
Screenqueries
Существенно отличается от всех ранее описанных сервисов. На портале можно использовать до 14 телефонов и 12 различных планшетов, чтобы провести максимально плодотворное изучение верстки.
Есть функция быстрого переключения с портретного на альбомный режим и обратно. Все собранные итоги отображаются на специальной сетке с удобными линейками, позволяющие моментально замерить необходимые пропорции и размеры блоков и прочего.
Есть параметры для указания произвольного разрешения (достаточно попеременно перетягивать нижний или правый край видимой области сайта).
Также отдельно можно указать еще такую фишку, как вариация «Trueview», позволяющая взглянуть на отображение веб-сайта в «родном» браузере мобильного устройства (к примеру, в Safari на операционной системе iOS).
Screenfly
По нашему мнению, это наиболее функциональный и оптимальный сервис для проверки адаптивности верстки.
The Responsive Calculator
С его помощью можно быстро конвертировать PSD макет в нужные проценты во время просмотра адаптивной версии будущего сайта. Все что нужно выполнить, это подобрать несколько актуальных спецификаций, и попеременно превратить пиксели сайта в требуемые значения в процентном выражении.
Mobitest
Являет собой совершенно бесплатный инструмент , с помощью которого можно быстро проверить мобильную производительность любого веб-сайта. Достаточно всего лишь ввести в нужном поле URL сайта и нажать кнопку «Старт».
Данная страница будет оперативно загружена, а вам предоставлен исчерпывающий отчет о том, сколько в действительности потребовалось времени для ее полноценной загрузки.
К слову, можно не просто изучать только лишь цифры, а «попросить» программу создать отчет в виде диаграммы или же в качестве медиафайла, который после завершения процедуры теста спокойно можно загрузить на свой локальный компьютер.
Мобильный эмулятор от Google DevTools
Как известно, мобильный эмулятор – это специализированный виртуальный эмулятор того, как нужный веб-сайт будет отображаться и взаимодействовать с пользователем в специальной мобильной среде.
Хотя подобного рода инструменты не могут сформировать на 100% правильные данные, которыми можно оперировать при следующих тестах, они до сих пор являются наиболее экономически обоснованным решением для проведения быстрого тестирования работоспособности веб-продукта на высоком уровне.
К примеру, в браузере Chrome есть специальная пользовательская функция, с помощью которой можно переменно оперировать разнообразными инструментами для проведения тестов и отладки всех возникающих нюансов при создании адаптивной версии проекта.
Корпорация Google даже выпустила специальную сводку правил, по которым лучше всего проводить проверку адаптивности программного обеспечения, а именно:
- Проверка верности отображения текстовых блоков;
- Оптимальная зона кликабельности объектов;
- Соответствие цвета и градиента заданным значениям из дизайна;
- Правильность заполнения краев;
- Блоки, картинки и текст не выходят за пределы видимости на экране;
- Каждый вид текста имеет свои шрифты, размеры и подключенные стили;
- При прокрутке текст отображается верно, не плывет и выравнивается по ширине (строгое равнение по левому краю – такой закон!).
Всегда проверяйте расположение уникальных модулей сайта, которые могут свободно функционировать на ПК, а при переходе на мобильное разрешения исчезать в невидимую для глаза область. Этот момент можно отобразить в технической документации (чек-листе, чтобы сотрудник QA отдела заранее знал, какие модули «ловить» в адаптивной верстке, а на какие не обращать внимание).
И в завершение…
Всегда старайтесь проверять адаптивность разрабатываемого вами веб-продукта. Применяйте специализированный набор автоматизированных платформ и сервисов, которые быстро выполнят необходимые проверки, предоставят точные данные о проделанном функциональном тестировании и помогут в дальнейшем стать профессионалом в поиске наиболее встречаемых багов при мобильной верстке.
Сегодня уже нет нужды убеждать кого-либо в необходимости мобильной версии сайта. Ведь с каждым днем посетителей со смартфонов и планшетов становится все больше и больше. На момент написания этой статьи около 20% посетителей моего блога используют мобильные устройства для просмотра. То есть каждый пятый заходит на мой сайт с телефона или планшета.
Несколько лет назад я даже не думал о таких посетителях, но когда их количество превысило 10% от общего числа я стал использовать адаптивную верстку. Это позволило корректно отображать контент на мобильных устройствах и повысить лояльность к сайту как посетителей, так и поисковых систем.
Мобильная версия сайта и адаптивный дизайн — это не одно и тоже. В данной статье речь пойдет о тестировании адаптивной верстки, когда дизайн сайта, меняется в зависимости от разрешения экрана устройства посетителя.
Чтобы быть уверенным, что ваш сайт правильно отображается на мобильных устройствах необходимо произвести проверку, и для этого существует несколько полезных сервисов и инструментов.
Быстрая проверка адаптивной верстки
Популярный интернет обозреватель (браузер) Mozilla Firefox оснащен встроенным инструментов проверки дизайна сайта на пригодность к отображению на мобильных устройствах. Чтобы им воспользоваться зайдите в «Меню» — «Разработка» — «Адаптивный дизайн». Либо просто нажмите на клавиатуре одновременно три клавиши ++[M]
Вы должны увидеть примерно следующую картину:
Изменяя разрешение и ориентацию экрана можно проверить как будет отображаться ваш сайт у мобильных посетителей.
Браузер Google Chrome так же имеет встроенную поддержку проверки адаптивности дизайна сайта. Для этого заходим в меню, выбираем пункт «Дополнительные инструменты» и затем «инструменты разработчика» (либо нажимаем клавишу ).
После этого нажимаем иконку адаптивного дизайна (либо одновременно нажимаем на клавиатуре ++[M] ):
В середине экрана вы увидите как будет отображаться ваш сайт на экранах мобильных устройств:
SEO тестирование мобильного дизайна
Как известно у двух мировых поисковых лидеров Google и Яндекс есть свое нескромное мнение как должен выглядеть сайт на экранах мобильных устройств. И если сайт признается неудобным для мобильных посетителей, то он понижается в поисковой выдаче. Таким образом, с точки зрения SEO, если вы не хотите потерять мобильных посетителей, то у вас должен быть не только адаптивный дизайн, но и поисковые системы должны считать его таковым, то есть пригодным для мобильных устройств.
Для проверки адаптивности с помощью сервиса Google заходим по следующему адресу и вбиваем имя своего сайта: https://www.google.com/webmasters/tools/mobile-friendly/ .
Вот так выглядит результат проверки моего блога:
С Яндексом немного сложнее, для проверки надо обязательно зарегистрироваться в сервисе Яндекс.Вебмастер и воспользоваться бета версией интерфейса:
Он-лайн сервисы по проверки адаптивности
Основной задачей этих сервисов презентовать (показать) как будет выглядеть ваш сайт на мобильном устройстве. Сайтов с таким функционалом великое множество. Я приведу лишь некоторые из них. В большинстве случаев они дублируют встроенный функционал FireFox и Chrome.
Google resizer
Начну опять же с Google, у которого есть свой сервис демонстрации адаптивности: http://design.google.com/resizer/#
Quirktools screenfly
Второй симпатичный сервис — это http://quirktools.com/screenfly/ . Он покажет как может выглядеть ваш сайт даже на телевизоре!
Symby.ru adaptest
Ну и чтобы не обидеть «отечественного производителя» приведу пример еще одного сайта: http://symby.ru/adaptest/ . На одной странице вы увидите сразу несколько представлений с различными разрешениями экранов.
Скорость работы мобильной версии сайта
После того, как вы убедились, что ваш сайт адаптивный и корректно отображается на экранах большинства устройств, следует проверить скорость его работы. Опять же применительно к мобильным посетителям.
PageSpeed Insights
Google как всегда впереди планеты всей: https://developers.google.com/speed/pagespeed/insights/ . Этот сервис покажет как выглядит сайт на экране телефона и даст рекомендации по оптимизации кода для увеличения скорости загрузки на мобильных устройствах.
WebPageTest
И в заключении приведу пример сервиса, который не только покажет как выглядит сайт на мобильном устройстве, но и покажет скорость его работы: http://www.webpagetest.org/
Выводы
На мой взгляд в повседневной работе при внесении изменений в дизайн сайта проще использовать встроенные возможности браузеров FireFox и Chrome. После чего, конечно же, необходимо проверить лояльность поисковых систем к вашему дизайну. А уже потом, для успокоения души или чтобы похвастаться, можно воспользоваться онлайн сервисами.
