Одне з найвизначніших завдань, яке коли-небудь стояло перед 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 – застосовні для тестування верстки сторінок. Вони успішно взаємодоповнюють одне одного. Метод порівняння скріншотів більше застосовується, коли потрібно протестувати відображення будь-якого окремого елемента або блоку, наприклад панелі “шарингу” в соціальних мережахабо основне меню в хедері. Блок може містити безліч іконок у собі, які у свою чергу можуть бути всередині інших іконок та елементів, або мати відносне з ними позиціонування.
За допомогою галена описувати всі ці дрібні моменти досить трудомістко, однак один скріншот на кожен браузер вирішує цю проблему, і порівняння скрішотів виключає варіант, коли ми можемо пропустити щось при описі спеку. Гален, у свою чергу, чудово справляється з відносним розташуванням блоків та перевіркою заголовків та фіксованого тексту в них. Він має гарне застосування, коли потрібно протестувати верстку на однотипних шаблонизованих сторінках, не навантажених функціональною логікоюнаприклад, будь-якого інформаційного порталу, як у нашому випадку, коли практично будь-яка сторінка сайту доступна без авторизації, або будь-яких інших дій користувача. Крім того, гален добре вирішує завдання кросбраузерного тестування в умовах адаптивної верстки додатка.
Здрастуйте, дорогі читачі блогу. Як уже й не дивно, що адаптивний дизайн стає все популярнішим у російському інтернеті. І, звичайно ж, верстальникам потрібно вивчати його. Так як адаптивний дизайн скоро буде практично на всіх сайтах, тому що все більше люди користуються мобільними пристроями.
І хочеться сказати, що сайти з набагато зручніше читати на таких пристроях ніж без нього.
Сьогодні я хочу представити Вам 5 дуже корисних та класних сервісів, за допомогою яких Ви зможете перевірити сайт на адаптивність.
І так поїхали.
5 сервісів, на яких можна перевірити сайт на адаптивність.
www.responsivedesigntest.net
Хороший сервіс для перевірки веб-сайтів. Є безліч дозволів екранів як планшетів, так і телефонів.
mattkersley.com
Простий сервіс для перевірки сайту від Matt Kersley. Також доступні всі популярні дозволи мобільних девайсів.
screenqueri.es
Дуже класний сервіс, який перевірить будь-який сайт. Дуже сподобалося оформлення, а також функціональність.
quirktools.com
Дуже красивий та функціональний сервіс. Можна навіть перевірити як буде виглядати сайт на телевізорі:-)
Як тестувати адаптивний веб-сайт? Які проблеми виникають при тестуванні веб-сайтів на різних пристроях? Як тестування веб-сайту на настільному моніторі відрізняється від тестування на кишеньковому пристрої, наприклад, мобільному телефоні? Які інструменти ми можемо використовувати для тестування адаптивних веб-сайтів? Відповісти на Ваші запитання допоможуть наші
Що таке адаптивний веб-дизайн?
Адаптивний веб-дизайн (RWD) – це визначення підходу до веб-дизайну, спрямоване на створення сайтів з метою забезпечення оптимального сприйняття – простого читання та навігації з мінімальним розміром, панорамуванням та прокруткою на широкому спектрі пристроїв (від настільних комп'ютерних моніторів до мобільних телефонів) .
Сайт, створений за допомогою RWD, адаптує макет до середовища перегляду з використанням рідинних, пропорційних сіток, гнучких зображень та медіа-запитів CSS3, такими способами:
- Концепція рідкої сітки вимагає, щоб розмір елемента сторінки був у відносних одиницях, таких як відсотки, а не абсолютних одиницях, такі як пікселі або точки.
- Гнучкі зображення також оцінюються у відносних одиницях, щоб запобігти їх відображенню за межами елемента.
- Запити на мультимедіа дозволяють сторінці використовувати різні правила стилю CSS, спираючись на характеристики пристрою, на якому відображається сайт, найчастіше ширини браузера.
Проблеми тестування адаптивного веб-дизайну
Багато людей в даний час використовують свої мобільні телефони або планшети для доступу до веб-сайтів, тому тестування адаптивного веб-дизайну є важливим, тому що користувальницький інтерфейсна мобільних пристроях дуже відрізняється від настільних комп'ютерів.
Можливо, найскладніша частина тестування веб-сайту, що відповідає вимогам, - це те, що веб-сайт працює так, як очікується на кількох пристроях та платформах, але фактичне тестування на всіх мобільних пристроях на ринку для більшості з нас є непрактичним.
Багато тестувальників, які починають тестувати адаптивний веб-дизайн, зазвичай починають із зміни розміру вікна браузера, щоб підігнати розмір області перегляду мобільного телефону, планшет і робочий стіл. Цей метод зазвичай підходить для швидкої візуальної перевірки веб-сайту в різних портах перегляду та допомагає нам виявляти основні проблеми з відображенням, коли ми зменшуємо або збільшуємо вікно браузера.
Проте, тестування на реальних мобільних пристроях – це зовсім інший досвід.
Використання емуляторів
Мобільний емулятор- це веб-симуляція того, як веб-сайти та програми будуть відображатися та функціонувати в мобільному середовищі.
Хоча емулятори не можуть надати вам точні засоби тестування, які вам знадобляться, вони, як і раніше, є економічно ефективним рішенням для перевірки функціональності веб-сайту на високому рівні.
Google DevTools
В DevTools Google Chromeє функція, яка називається режимом пристрою, в яку завантажені корисні інструменти для тестування та налагодження адаптивних проектів.
На відміну від більшості інших адаптивних інструментів тестування дизайну, які просто змінюють розмір вашого екрану, цей інструмент фактично емулює роботу мобільного пристрою, особливо сенсорні взаємодії, такі як натискання та прокручування прямо у вашому веб-браузері.
Деякі загальні правила тестування адаптивного веб-дизайну:
- Текст, елементи керування та зображення вирівняні правильно
- Відповідна зона клікабельності
- Колір, затінення та градієнт відповідають
- Перевірте правильність заповнення країв
- Текст, зображення, елементи керування та рамки не потрапляють у краї екрану
- Розмір шрифту, стиль і колір відповідають кожному типу тексту
- Текст, що прокручується (введення даних) відображається правильно
Перевіряйте розташування модулів у міру їх скорочення та розширення вікна браузера або при повороті мобільного пристрою. Різні модулі можуть зникнути під час переходу з настільного комп'ютерана мобільний, але переконайтеся, що ви точно знаєте, які модулі повинні відображатися у вікні перегляду.
На закінчення
Дізнайтеся, як використовується веб-програма. Ви можете отримати величезну кількість інформації з Google Analytics, щоб дізнатися, які пристрої ваші клієнти використовують для доступу до вашого веб-сайту. Використовуйте автоматизовані інструменти та емулятори для виконання основних перевірок та високорівневого функціонального тестування та поєднання цього з реальним тестуванням пристрою вручну.
Сьогодні вже немає потреби переконувати когось у необхідності мобільної версії сайту. Адже з кожним днем відвідувачів зі смартфонів та планшетів стає дедалі більше. На момент написання цієї статті близько 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. Після чого, звичайно, необхідно перевірити лояльність пошукових систем до вашого дизайну. А вже потім, для заспокоєння душі або, щоб похвалитися, можна скористатися онлайн сервісами.
Від автора:"Припини міняти розмір цього браузера, він вже скоро зітреться!" Як часто ви це чуєте? Ну, гаразд, може і не так вже й часто, але якщо ви розробляєте адаптивні веб-сайти, то знаєте, про що я говорю: при кожному редагуванні 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 – єдиний, що дозволяє тестування на підставі рядка агента користувача.
Протестувавши цим чином один створений мною сайт з наявної мобільною версією, Можу сказати, що результати виявилися дуже добрими. Все відображалося точно так, як я очікував, і тестуванню піддавалися функції. Треба сказати, тестування рядків агента користувача стало традиційним, але цей сайт був зроблений давно, і властивість проксі-сервера виявилася дійсно дуже корисним доповненнямдо нього.
Висновок
Отже, ви бачите, що для тестування адаптивних сайтів є достатньо ресурсів. Вони відрізняються унікальними властивостями; які сайти ви застосуєте, буде залежати від ваших особистих уподобань та вимог, і я намагаюся підштовхнути вас на дослідження та експерименти з ними. Чим більше у нас, розробників, буде по-справжньому корисних інструментів, тим краще.
