Как называется тест поддержки браузером веб стандартов

Обновлено: 07.07.2024

Результаты в основном разочаровывают, но местами - сильно удивляют.

Opera 10.51 для Windows, "самый быстрый браузер на Земле", набрала 102 балла из возможных 160. Полностью отсутствует поддержка геолокации, механизма Web Workers, а также функции работы с разделами документа, группировки контента и некоторые другие предусмотренные стандартом возможности.

Ужасающими оказались результаты тестирования Internet Explorer 8 - он набрал всего 19 очков. Фактически браузер лишь умеет переключаться в режим соответствия стандартам и хранить данные на пользовательском компьютере (эта возможность часто нужна веб-приложениям). Не без ехидства отметим, что Internet Explorer 9, прототип которого недавно появился, тоже набрал всего 19 баллов.

Safari 4.0.5 для Windows набрал 115 баллов. Для сравнения, 4.0.5 для Mac - 113 баллов. Отличие в том, что версия для Windows поддерживает mp3-кодек для аудиоэлементов HTML5, а для Mac - нет.

Chrome for Mac, работающий в так называемом канале для разработчиков (самая последняя версия на 14 апреля) показывает целых 142 балла из 160 - максимум в нашем тесте. Более консервативная версия для Windows (4.1.249.1045) набрала лишь 118 баллов. Красным там отмечена только нереализованная пока геолокация - все остальные разделы HTML5 частично или полностью реализованы. Если дело и дальше так пойдет, именно Google первым объявит о полной поддержке HTML5.

Firefox 3.6.3 отстает от Chrome и Safari - у него только 101 балл из 160. В браузере плохо реализована работа с формами HTML5 - одна она обошлась в 26 очков.

Напоследок стоит пару слов сказать о мобильных браузерах. Opera Mini 4 на одном из мобильников Nokia и Opera Mini 5 for iPhone показали одинаковый балл - 14 из 160. Это обусловлено в первую очередь технологией загрузки страниц, которую применяет Opera. Шансов для динамики HTML5 там почти не остается. Для сравнения, Safari для iPhone набирает 113 баллов. За это он и оказался на картинке.

От выводов воздержусь. Отмечу только, что и до теста дома и на работе использовал Chrome.

ps. Как мне уже подсказали в твиттере, стандартный браузер Android набирает 118 баллов (совпадает с "большой" версией Chrome), а Dolphin Browser - 110.

Что такое Acid3? Кто его придумал? Как он устроен и как он работает? Что он измеряет на самом деле? Этими и другими вопросами мы зададимся в данной статье и попробуем найти ответы.

Что такое Acid3?

Acid3 — это третий из серии специальных тестов (до этого были Acid1 и Acid2), написанных «в помощь производителям браузеров, чтобы те могли проверить поддержку стандартов в своих продуктах». Конкретно ACID3 нацелен на тестирование спецификаций, связаных с разработкой динамичных «Web 2.0»-приложений.

Acid3 включает 100 специальных тестов, проверяющих 19 различных спецификаций.

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

Среди тех, кто смотрит на веселые картинки, и журналистов тест по-прежнему выступает одной из пузомерок браузеров. В какой-то момент можно было даже наблюдать вот такую картинку с явной корреляцией между Acid3 и веб-стандартами.

(Интересно, кстати, и то, что, согласно Google Trends, Россия в последние три года упорно входит в тройку стран, где про Acid3 говорят больше всего.)

Acid3 в плане использования в качестве мерилки “качества” браузера, пожалуй, стал самым ярким и широко используемым не только в сообществе и среди журналистов, но и иногда отдельными компаниями :)

В маркетинговом смысле дополнительное обманчивое впечатление создает “магия чисел” и привычный ассоциативный ряд 100

100%, что, конечно, с точки зрения поддержки стандартов, абсолютно не соответствует действительности.

…Вообще проверку Acid3 на поддержку всех веб-стандартов оба устройства проходят успешно, получая 100 очков из 100…

А вот за полгода до этого Компьюлента пинает предварительную версию IE9:

Медленно, но верно браузер учится адекватному пониманию основных веб-стандартов. Так, если первая редакция в тестах Acid3 «выбивала» 55 очков из ста возможных, то второй выпуск шасси уже набирает 68 пунктов.

Safari 4 — первый в индустрии веб-браузер, финальная версия которого полностью проходит тест на совместимость с веб-стандартами Acid3.

Тест Acid3 представляет собой тестовую страницу Web Standards Project, которая определяет, насколько движок браузера соответствует общепринятым стандартам, насколько правильно обрабатывает новые спецификации HTML и CSS и способен ли корректно отображать веб-страницы.

«Здесь важен тот факт, что реально Acid3 не является тестом, проверяющим широкий спектр стандартов. Это всего лишь маленький экспонат, что-то вроде потемкинской деревни. Это досадно, потому что если что и нужно сейчас, так это исчерпывающие наборы тестов для спецификаций – XHTML, CSS, DOM, SVG.»

Где же правда? И что там на самом деле внутри? С этим и будем разбираться.

Авторы

Основным разработчиком Acid3 является Ян Хиксон (Ian Hickson), ранее разработавший набор тестов Acid2. Хиксон входит в группу разработки стандартов CSS и, в частности, был соредактором спецификации CSS 2.1, а также вносит большой вклад в подготовку спецификации HTML5, являясь редактором этой и других связанных спецификаций.

Ян успел поработать в Mozilla Foundation, Netscape и Opera Software, сейчас работает в Google.

Sylvain Pasche. Тесты 66–67 (DOM)
David Chan. Тест 68 (UTF-16/UCS-2)
Simon Pieters (Opera) и Anne van Kesteren (Opera). Тест 71: парсинг HTML
Jonas Sicking (Mozilla) и Garrett Smith. Тест 72: динамическое изменение стилей текстовых блоков
Jonas Sicking (Mozilla). Тест 73: Вложенные события
Erik Dahlström (Opera). Тесты 74–78: SVG и SMIL.
Cameron McCormack (Batik SVG library). Тест 79: шрифты в SVG.

Внутреннее устройство

Самое интересное в Acid3 — это как раз внутренее устройство и детали процессов, приводящих к тем или иным циферкам и квадратикам итоговой картинки.

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

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

Движок тестирования

несколько вспомогательных функций (fail, assert, assertEquals) для общей механики проверок
пару функций для работы с iframe и стилями
- getTestDocument – создает тестовый документ на основании содержания iframe
- selectorTest – для тестирования заданных css-селекторов в таком тестовом документе
Набор тестов

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

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

function () // test 87: Date tests -- years
var d1 = new Date(Date.UTC(99.9, 6));
assertEquals(d1.getUTCFullYear(), 1999, "Date.UTC() didn't do proper 1900 year offsetting" );
var d2 = new Date(98.9, 6);
assertEquals(d2.getFullYear(), 1998, "new Date() didn't do proper 1900 year offsetting" );
return 6;
>

* This source code was highlighted with Source Code Highlighter .

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

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

Любая из проверок может вывалиться с ошибкой, что будет отловлено во внешнем цикле (см. ниже).

Сами функции, описывающие тесты, объеденены в общий массив.

update()

Как сказано выше, функция update() занимается непосредственно запуском тестов, сбором результатов и формированием лога и итоговой картинки.

Технически, функция рекурсивна с задержкой по timeout: на каждый следующий тест запускается через 10 миллисекунд, максимум 500 попыток на тесты, требующие сетевого подключения (result == "retry").

Упрощенно схема тестирования выглядит так:

function update() if (index < tests.length) try var result = tests[index]();
if (result == "retry" ) retry += 1;
if (retry < 500) setTimeout(update, delay);
return ;
>
fail( "timeout -- could be a networking issue" );
> else if (result) // обновление внешнего вида
>
> else fail( "no error message" );
>
> catch (e) // ошибка
>;
retry = 0;
index += 1;
setTimeout(update, delay);
> else // итоги
>
>

* This source code was highlighted with Source Code Highlighter .

При обновлении внешнего вида с учетом номера набора, к которому принадлежит тест, к тому или иному прямоугольнику, соответствующему набору тестов, добавляется символ “P” в названии класса. В зависимости от количества букв “P” применяется тот или иной CSS-класс:

* This source code was highlighted with Source Code Highlighter .

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

Что тестирует Acid3?

Итоговый вывод по содежанию: Acid3 тестирует не более того, что он тестирует – отдельные элементы отдельных стандартов небольшим количеством тестов. То есть, статистически ничего.

Интересные факты

Acid3 Competition

В процессе работы над тестами Ян Хиксон объявил конкурс на дополнительные тесты (16 штук), чтобы довести количество тестов до круглого числа (100). Среди требований было такое:

Тест должен проваливаться (выкидывать исключение) в свежем билде Firefox или Webkit (в идеале в обоих). (Opera и IE уже проваливают достаточное количество тестов и я не хочу добавлять еще тестов, которые проваливаются только в них. Конечно, если вы найдете что-то, что праваливается в Firefox или Webkit и Opera или IE, будет лучше.)

(К слову, Acid3 был выпущен примерно в то же время, когда Microsoft выпустила публичную бета-версию IE8, основной функционал которой был уже зафиксирован и не подлежал изменению независимо от результатов тестов, подобрых Acid3.)

Как пишет Ян Хиксон, уже после первичного анонсирования Acid3 (март 2008) отдельные тесты менялись в силу обнаруженных багов и был даже случай, когда тест пришлось менять в силу изменившейся спецификации. В какой-то момент один из вендоров (не будем показывать пальцем) заявил, что проходит полностью Acid3, но оказалось, что в тестах была ошибка :)

Последнее обновление набора тестов было произведено около года назад – в начале апреля 2010.

Acid 4 и уроки из Acid3
- не включать минорные баги;
- не запрашивать разработку специфических тестов, писать тесты самостоятельно, но запрашивать отзывы с ранних итераций (t=0): публично и у конкретных экспертов;
- запрашивать пожелания относительно того, что именно тестировать;
- не показывать сам тест на ранних стадий, чтобы избежать отсылок к нему в то время, как ведется обсуждение, что именно тестировать;
- не включать измерение производительности как часть тестов (это можно делать отдельно, если все согласятся, что тест честный);
- сделать хорошо выглядящую картинку;
- спрашивать у разработчиков браузеров совета по времени анонсирования теста.
Почему Firefox 4 и IE9 не набирают 100 баллов?

Как известно, Firefox 4 и IE9 не набирают 100 баллов в Acid3 – и многие журналисты и люди, не следящие за всеми перепетиями развития событий, продолжают этому удивляться.

Комментарии Alexander Limi (GUI дизайнер в Mozilla) с отсылкой на комментарий Boris Zbarsky (Mozilla engineer):

“Оставшиеся три балла касаются SVG Fonts. Opera и Webkit реализовали небольшое подмножество SVG 1.1 Fonts, достаточное для прохождения Acid3. Мы не хотим внедрять в Gecko даже небольшое подмножество, пока не будем уверены, что это принесет пользу разработчикам или пользователям. При этом реализация полной спецификации – довольно сложная задача, т.к. SVG Fonts проектировались без учета интеграции с HTML.

В настоящий момент SVG WG решила, что SVG Fonts не будет в основной части SVG и переместится в отдельную спецификацию, которая потребует серьезной работы, если кто-то возьмется ее полностью реализовать.”

Предпочтение отдается WOFF.

Аналогичное предпочтение и нестремление в реализации SVG Fonts высказывает Dean Hachamovich (Microsoft) и добавляет про “недостающую” реализацию SMIL:

“Поддержка SMIL-анимаций в SVG в веб-сообществе далека от того, чтобы быть достаточно сильной. Лидер движения стандартизации SVG написал, что неподдержка SMIL в текущем статусе, возможно, наилучшая опция, т. к. SVG WG занимается координацией с CSS WG относительно внесения изменений в анимации и расширения фильтров.”

В вопросе анимаций предпочтение отдается JavaScript и CSS.

Почему Acid3 важен?

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

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

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

В конечном счете и на деле (маркетинговом) Acid3 сыграл и местами продолжает играть достаточно весомую роль. И когда маховик закрутился, навряд ли возможно его полностью игнорировать.

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

29 января 2008 года Ян Хиксон, разработчик Acid2 и Acid3, а ныне работник Google, сообщил о предварительном релизе Acid3 — пока сам тест проходил проверку на соответствие спецификациям, каждый желающий мог проверить свои браузеры. 3 марта 2008 разработка теста была закончена, и появились наброски для Acid4.

Основная часть теста написана на JavaScript и содержит 100 подтестов в шести группах плюс несколько специальных тестов (0, 97, 98, 99)

Группа 2: DOM2 Core и DOM2 Events

Группа 3: DOM2 Views, DOM2 Style, CSS 3 селекторы и Media Queries

Группа 4: Поведение HTML таблиц и форм при управлении из скрипта и DOM2 HTML

Группа 5: Тесты из соревнования Acid3

Группа 6: ECMAScript

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

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

Во время выполнения теста на страницу добавляются цветные квадраты; цвет квадратов зависит от числа выполненных подтестов в группе. Если в группе все тесты провалены — квадрат не отображается. Если несколько тестов провалено, цвета будут такими:

1-5 подтестов пройдены: чёрный квадрат.

6-10 подтестов пройдены: серый квадрат.

11-15 подтестов пройдены: серебристый квадрат.

Все 16 подтестов пройдены: цветной (красный, оранжевый, жёлтый, зелёный, синий, фиолетовый — для каждой из групп свой цвет).

После прохождения теста буква «А» в слове Acid3 становится кликабельной, при этом при простом нажатии выводится всплывающее окно с перечнем непройденных тестов, или же данная информация выводится в новом окне при щелчке с нажатой кнопкой Shift.

Тест использует картинки, закодированные Base64, некоторые сложные селекторы, цветовые значения CSS 3 (HSLA, при этом ненастоящие селекторы и значения должны игнорироваться).

Сколько существует браузеров

А если спросить об этом у Гугла? Ответ будет неоднозначный. Количество более-менее известных браузеров сейчас превышает 50 наименований. И возможно, прямо сейчас кто-то выпускает в сеть еще один, свой собственный. А давайте представим, что уже завтра этот “кто-то” выпустит обновление своего браузера. Как же в таких непростых условиях проверить всё?

Какие есть стандарты для создания браузеров

Как выбрать браузеры под ваше приложение

Теперь о тестировании. Прежде чем начать непосредственно тестировать то или иное web-приложение, тестировщик должен ознакомиться с требованиями, которые выдвигает заказчик. Бывает так, что в требованиях изначально прописано: “Наш продукт должен работать в браузерах Chrome, начиная с версии 43, и IE, начиная с версии 9”. Или же сам заказчик не может определиться и, конечно же, ему хочется охватить всё и всех. Ну а вдруг, его самый важный потенциальный клиент использует браузер Uran? И что тогда? Он не увидит его приложение вовсе?

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

Хочу показать вам некоторые сервисы по просмотру статистики:

Как проводить кроссбраузерное тестирование

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

Однако, есть мнения, что отображение в этом эмуляторе не соответствует действительности. Как быть в этой ситуации? Есть решение! Проверить в самом браузере. Если какой-то момент “прям смущает-смущает”, открывайте реальный браузер и смотрите.

Разнообразие инструментов для тестирования кроссбраузерности

Конечно, этими двумя программами выбор эмуляторов не ограничивается:

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

На что важно обращать внимание при кроссбраузерном тестировании

WEB-приложения по-другому называют клиент-серверные приложения. Здесь клиентом выступает браузер, а сервером — веб-сервер. Браузер принимает от пользователя запрос, отправляет его на сервер. WEB-сервер обрабатывает запрос и передает ответ обратно в виде HTML-страницы. Браузер отрисовывает полученный код в страницу, которую мы с Вами в итоге и видим. То есть, непосредственно от браузера будет зависеть то, какой мы увидим страницу.

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

Читайте также: