Утром доделаю

Тестирование адаптивных сайтов

Доска с результатами теста сайта в различных браузерах

Как правильно замечают многие хорошие ребята, проверить работоспособность вашего адаптивного творения на айфончике недостаточно. Как минимум, стоит озаботиться несколькими основными платформами: iOS, Android (а там свой зоопарк браузеров), Windows Phone, Blackberry.

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

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

Коротко про десктопные браузеры

Windows

Первым делом — последние стабильные версии Firefox, Chrome, Opera, Safari, IE, плюс Opera 12, с этим все ясно. Через годик-полтора о 12 Опере и движке Presto можно будет забыть насовсем :-(

Основной затык, как всегда, с IE. Юзеры почти равномерно размазаны по трем версиям браузера. Несколько версий IE держать в системе нельзя, всякие ИЕ-тестеры — лажа. Даже если заработают, родной икспишный рендеринг шрифтов с их помощью увидеть не получится.

Выход — ставим VirtualBox, клонируем три виртуалки с winXP, отдаем им по 192 Mb оперативки и ставим, соответственно, 6, 7 и 8 осликов. IE6 я лично держу для всяких редких случаев. На его полноценную поддержку я давно забил.

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

Делаем еще одну виртуалку на Win 7 (512 Mb оперативки) и ставим туда IE9. Все это хозяйство замечательно летает параллельно:

Уи-и-и-и
Уи-и-и-и

Надеюсь, автообновление IE10 избавит меня от еще одной виртуалки, когда выйдет IE11. Пока что не избавило.

По желанию можно поставить какой-нибудь Firefox 3.6. Часто помогает отловить простые баги, связанные с использованием новых свойств CSS. Обычно легко фиксится фоллбеком на старые свойства. Этакая проверка на Graceful Degradation.

Linux & Mac

Стоит также иметь виртуалку с каким-нибудь дистрибутивом Линукса, и, если есть возможность, ухватить железку с OS X. Отличия рендеринга в одних и тех же браузерах в разных системах незначительны, пока дело не доходит до системных компонентов. Например, значительно отличается поведение элементов форм, рендеринг шрифтов и внешний вид курсоров.

Мобильные устройства

Первое правило: есть возможность тестировать на железке, а не на эмуляторе, — тестируйте на железке. Вот пара причин:

Моя первоначальная идея купить по устройству на каждой из популярных операционных систем (iOS, Android, Windows Phone) осуществилась и переросла в собирательство редких девайсов с браузером на борту.

Так в коллекции появились Kindle Keyboard и Kindle Paperwhite со своими черно-белыми вебкитами, Nokia Asha 501 (мобилка на модифицированной S40 с ужасным Ovi браузером и не такой ужасной Оперой мини на JAVA), Nintendo DSi, купленная после прочтения вот этой статьи, и много других железок.

Зоопарк
Зоопарк

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

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

Покупайте девайсы, отбирайте старье у друзей, заказывайте редкие штуки на dx.com и ебее. Разводите свой зоопарк.

На чем тестировать

Обязательный набор:

Бонус-пак в порядке субъективной важности:

For fun:

Где взять эмуляторы

Дебаггинг на мобильных устройствах

Android

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

В Хроме под Андроидом можно воспользоваться отладкой через десктопный хром:

Получаем полный набор вебкитовских инструментов. Все изменения в реалтайме отображаются на девайсе:

Результат применения девтулзов в Андроид Хроме

iOS

Если вам повезло иметь под рукой Мак, можно подебажить устройство на айОси через веб-инспектор Маковского Сафари:

Так же как и на Андроиде, доступен полный набор вебкитовских инструментов.

Blackberry

На блекберри есть удаленная отладка через веб-версию вебкитовских девтулзов:

Как это не смешно, но панель у меня согласилась нормально работать только в Опере 15:

Удаленный дебаггинг браузера на эмуляторе Blackberry
Удаленный дебаггинг браузера на эмуляторе Blackberry

Jsconsole.com

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

Можно почитать подробнее об использовании.

Своя консолька

Если jsconsole использовать по какой-то причине неудобно, всегда можно написать свою консоль, заредефайнив console.log, console.warn, console.error, window.onerror и еще что-то по вкусу. Получится довольно простой инструмент, которого достаточно в большинстве случаев.

Очень примитивный пример:

var customConsole = {
    log: function(message) {
        this.add(message, 'info');
    },
    warn: function(message) {
        this.add(message, 'warning');
    },
    error: function(message, source, file) {
        this.add([message, source, file].join('<br>'), 'error');
    },
    add: function(message, type) {
        if (typeof message !== 'string') message = '<i>' + message + '</i>';
        document.getElementById('console').innerHTML += '<p class=' + type + '>' + message + '</p>';
    }
}

if (dev_console) {
    window.console = customConsole;
    window.onerror = function(message, source, file) {
        console.error(message, source, file);
    };
}

Допиливайте по вкусу и потребностям.

Тестирование сайта, запущенного на локальном веб-сервере

Все просто. Для начала понадобится wi-fi роутер. Подключаем все устройства и компьютер с веб-сервером к роутеру, получаем подсеть. В настройках сети на компьютере можно для удобства выставить руками фиксированный IP, так как автоматический имеет тенденцию внезапно поменяться, после чего приходится заново вбивать закладки на всех устройствах. Этот же IP прописываем в конфиге вебсервера, например для энжинкса:

server {
    ...

    listen   192.168.1.5:4000;
    listen   127.0.0.1:4000;

    ...
}

Все, можно заходить с железок.

Если сервер запущен на виртуальной машине, выдаем ей сетевой мост (из настроек программы виртуализации). Машинка получает IP в подсети роутера, используем его для доступа к сайту как с железок, так и из хост-системы.

Тестирование в браузерах с серверсайд-рендерингом

То есть в Опере Мини. Ну и в таком треше, как Ови, если у кого руки дойдут.

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

Мой выход — сделать на хостинг-сервере тестовый поддомен с http-авторизацией и периодически пуллить туда актуальную версию сайта гитом. Сайт останется доступен извне, при этом под паролем. Пример конфига http-авторизации (на этот раз для апача):

<VirtualHost *:80>
    ...

    <Location />
        Deny from all
        Allow from #YOUR IP HERE
        AuthUserFile /etc/apache2/users
        AuthName testdomain
        AuthType Basic
        Satisfy Any
        require valid-user
    </Location>

    ...
</VirtualHost>

После Allow from можно указать свой IP, чтобы упростить доступ к домену из обычных браузеров.

О добавлении пар юзер/пароль можно почитать в документации апача. Если коротко, htpasswd -cm /etc/apache2/users username спросит у вас пароль, после чего сделает файл по указанному пути и создаст там юзера username с зашифрованным в MD5 паролем. Будьте осторожны, флаг -c перезаписывает существующий файл.

TL;DR

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

Ссылки по теме

Опубликовано