Кроссбраузерное тестирование что это

7 простых способов протестировать кроссбраузерную совместимость

Эта статья предназначена для дизайнеров, верстальщиков, разработчиков и всех остальных людей, бьющихся с тестированием сайтов в нескольких браузерах.

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

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

#1 — Xenocode Browser Sandbox

Xenocode Browser Sandbox — это гейм-чейнджер для тестирования браузеров на компьютерах с Windows. Всего лишь одним кликом мыши, вы можете открыть и работать в браузере, без всякой инсталляции. Вы можете тестировать различные версии IE, Firefox, Google Chrome и Safari. В прямом смысле тестировать, а не только получать скриншоты.

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

#2 — CrossBrowserTesting.com

Бесплатная, пятиминутная сессия тестирования для зарегистрированных пользователей, и значительно больше времени для заплативших пользователей. CrossBrowserTesting.com устроен очень просто, вам необходимо авторизоваться в системе, затем выбрать свободный компьютер с нужным браузером/ОС, и можно приступать к тестированию.

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

#3 — IETester

Это бесплатная загружаемая windows-программа, которая все еще находится на ранней стадии разработки. Как было заявлено, она является единственным бесплатным ресурсом, позволяющим полностью протестировать все актуальные версии Internet Explorer.

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

#4 — BrowsrCamp

Со всем многообразием сайтов тестирования только для IE, самое время кому-нибудь присоединится и создать сервис, позволяющий тестировать сайты на Safari/Mac. Бесплатная версия этого сервиса предоставляет возможность получения скриншотов сайта, тестированных на последней, стабильной версии сафари, практически мгновенно. И хотя в сервисе немного не хватает версий браузеров, он определенно восполняет это предоставлением хорошей скорости.

За несколько долларов дополнительно, есть возможность получить компьютер полностью и проводить более глубокое тестирование

#5 — Litmus

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

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

#6 — NetRenderer

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

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

#7 — BrowserShots

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

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

Bonus #8 — Adobe MeerMeer

Adobe MeerMeer это приятный на вид сервис тестирования, который будет выпущен в ближайшее время, компанией Adobe. MeerMeer предлагает значительное количество преимуществ по сравнению с существующими системами тестирования. Наиболее примечательным является, пожалуй, «луковая кожура», или возможность наложения скриншотов из разных браузеров, одно на другое.

Может быть вы используете принципиально иной способ тестирования кроссбраузерной совместимости? Если так, поделитесь, есть множество людей, которым это будет интересно.

Источник

Кроссбраузерное тестирование что это

Как часто заказчики ПО хотят, чтобы их детище работало у любого пользователя, в любых условиях и окружениях? Здесь будет уместен ответ — всегда. Что же скрывается за этой фразой? Что именно требуется для проверки от тестировщика? И как он будет воплощать требования в жизнь?
Не секрет, что WEB-приложения имеют отличия от десктопных. Самое главное отличие и опасение — это то, что мы не знаем, в каком браузере и уж тем более — в какой версии этого браузера откроет приложение наш пользователь.

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

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

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

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

Есть радостная новость! Типовых движков, с помощью которых работают браузеры, гораздо меньше. Кроме того, существуют язык разметки и протоколы, которые объединяют все наши разнообразные и разношерстные браузеры. Я говорю о таких вещах, как HTML, CSS и HTTP. Любой уважающий себя и своих потенциальных пользователей создатель браузера будет соблюдать эти правила и сделает браузер, адаптированным под общепринятые стандарты. Отдельно почитать об этом можно на сайте w3.org.

Но и тут есть подводные камни. Стандарты совершенствуются; новые версии браузеров, по крайней мере, стараются совершенствоваться. А старые версии? Мало кто занимается доработкой старых версий. Да вообще никто не занимается. Выпустили новую — и все счастливы. А пользователи, думаете, каждый день проверяют наличие обновлений своего браузера? Тоже вряд ли.

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

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

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

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

Для начала надо определить целевую аудиторию будущего приложения. Кто эти люди, где они живут? Исходя из этих данных в сети можно увидеть статистику использования браузеров — например, самые популярные браузеры Азии. Благодаря таким запросам можно увидеть очень интересные и даже неожиданные результаты. Ну а если приложение в каком-то виде уже существует, можно воспользоваться удобной статистикой от ГуглАналитикс и иметь свои конкретные данные.

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

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

Когда выбор браузеров завершен, начинается полноценное тестирование. Допустим, вы выбрали три версии IE, три версии Chrome, две версии FireFox и две версии Safari. Если с разными браузерами один тестировщик справиться сможет, то с разными версиями одного и того же браузера может возникнуть заминка.

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

Я хочу рассказать про два из них, которые лично использовала в ходе своей работы.
Например, эмулятор IETester, разработанный специально под этот браузер. В соседних окнах эмулятора можно открыть одну и ту же страницу разными версиями браузера. Это очень удобно и наглядно. Путем сравнения двух соседних вкладок можно легко увидеть несоответствия в отображении. В моей практике эта программа меня не подводила. И вдогонку, еще один её несомненный плюс — программа полностью бесплатна и занимает совсем немного места.

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

Если, например, надо проверить в IE 10, а на компьютере уже есть IE 11? Удалять, переустанавливать, проверять — это неверное решение. Тут на помощь приходят виртуальные машины. Это как компьютер в компьютере.

Например, можно воспользоваться Vmware workstation. И иметь на рабочем компьютере одни версии браузеров, а на виртуальной машине — другие. Можно даже установить несколько таких машин на один компьютер, и после этого иметь под рукой много разного софта. Стоит заметить, что виртуальные машины тоже различаются:

Другой эмулятор — Spoon. Им также можно пользоваться абсолютно бесплатно. Он включает в себя широкий выбор браузеров: Firefox, Chrome, Opera, Safari и их разные версии. Тоже довольно удобная программа, которая позволяет в разных окошках на одной странице сравнить разные браузеры.

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

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

Каждый тестировщик знает и любит какие-то свои программки.

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

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

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

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

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

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

Источник

Для чего мне проводить проверку кроссбраузерности сайта?

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

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

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

Browsershots

Browsershots — это простой в использовании онлайн-инструмент для проверки кроссбраузерности сайта. Он позволяет протестировать сайт в основных стационарных браузерах, при этом вы можете указать различные версии программ. После того, как введете URL-адрес тестируемого сайта, всего через несколько минут вы увидите его скриншоты, сделанные в каждом из выбранных браузеров:

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

Spoon Browser Sandbox

Если вам нужно протестировать новейшие версии этих браузеров, то это бесплатно. Но если вы хотите проверить старые версии, за это взимается плата:

После выбора браузера он открывается в новом окне. Затем нужно ввести URL-адрес и протестировать страницу.

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

Viewlike.us

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

С помощью этого инструмента проверки кроссбраузерности сайта также можно оценить скорость и юзабилити тестируемого сайта. Если такие показатели, как размер изображений, размер элементов HTML и количество статических ресурсов нужны вам, значит и Viewlike.us будет полезен.

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

IE NetRenderer

Browsera

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

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

Для использования Browsera требуется создание учетной записи. Доступно несколько тарифов, а бесплатного вполне достаточно для тестирования небольших сайтов.

Какой из инструментов использовать?

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

Используете ли вы уже эти инструменты?

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

Источник

Введение в кросс-браузерное тестирование

Эта статья начинает модуль с обзора темы кросс-браузерного тестирования, отвечая на такие вопросы как «что такое кросс-браузерное тестирование?», «с какими распространёнными проблемами можно столкнуться?» и «какие основные подходы для тестирования, обнаружения и исправления проблем существуют?»

Что такое кросс-браузерное тестирование?

Примечание: Статья сделаем веб доступным для всех предоставляет более полезную информацию о различных браузерах, которые используют люди, их доле рынка и связанных с этим проблемах совместимости браузеров.

Мы должны поговорить немного о терминологии. Для начала, когда мы говорим о сайтах, «работающих кросс-браузерной», на самом деле мы говорим о том, что они должны обеспечивать приемлемое удобство использования в разных браузерах. Это нормально, если сайт выглядит немного по-разному в разных браузерах, главное он должен обеспечивать полную функциональность.В современных браузерах вы можете сделать что-то анимированным или использовать 3D, тогда как в старых браузерах вы можете лишь показать плоскую картинку, предоставляющую ту же информацию. Если владелец сайта доволен, вы сделали своё дело.

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

Когда мы говорим «приемлемое количество браузеров», мы не говорим, что это должно быть 100% всех браузеров в мире — это почти невозможно. Вы можете собрать информацию о том, какими браузеры и устройства используют ваши пользователи (это мы обсудим во второй статье — см. Gotta test ’em all?), но это ничего не гарантирует. Как веб-разработчик, вы должны определить для себя несколько браузеров и устройств, на которых код должен работать полностью, но кроме этого, вы должны писать код так, чтобы и другие браузеры были способны максимально использовать ваш сайт (defensive coding). Это одна из самых больших проблем веб-разработки.

Примечание: Мы разберём defensive coding позже в этом модуле.

Почему возникают кросс-браузерные проблемы?

Есть множество причин, почему возникают кросс-браузерные проблемы, и, заметьте, что сейчас мы говорим о проблемах, при которых некоторые вещи ведут себя по-разному в разных браузерах / устройствах / настройках просмотра. Прежде чем вы столкнётесь с проблемами браузера, вы должны исправить все ошибки в коде (см. Отладка HTML, Отладка CSS, and Что пошло не так? Устранение ошибок JavaScript из предыдущего раздела).

Кросс-браузерные проблемы возникают потому-что:

а также другие причины.

В статьях далее, мы выясним основные проблемы кросс-браузерности и посмотрим на их решения.

Инструменты для кросс-браузерного тестирования

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

Начальное планирование > Разработка > Тестирование > Исправление ошибок

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

Начальное планирование

Once you’ve got an idea of the required featureset, and what technologies you will likely build these features with, you should start exploring the target audience — what browsers, devices, etc. will the target audience for this site be using? The client might already have data about this from previous research they’ve done, e.g. from other web sites they own, or from previous versions of the web site you are now working on. If not, you will be able to get a good idea by looking at other sources, such as usage stats for competitors, or countries the site will be serving. You can also use a bit of intuition.

So for example, you might be building an e-commerce site that serves customers in North America. The site should work entirely in the last few versions of the most popular desktop and mobile (iOS, Android, Windows phone) browsers — this should include Chrome (and Opera as it is based on the same rendering engine as Chrome), Firefox, IE/Edge, and Safari. It should also provide an acceptable experience on IE 8 and 9, and be accessible with WCAG AA compliance.

Now you know your target testing platforms, you should go back and review the required featureset and what technologies you are going to use. For example, if the e-commerce site owner wants a WebGL-powered 3D tour of each product built into the product pages, they will need to accept that this just won’t work in IE versions before 11. You’d have to agree to provide a version of the site without this feature to users of older IE versions.

You should compile a list of the potential problem areas.

Note: You can find browser support information for technologies by looking up the different features on MDN — the site you’re on! You should also consult caniuse.com, for some further useful details.

Once you’ve agreed on these details, you can go ahead and start developing the site.

Development

Now on to the development of the site. You should split the different parts of the development into modules, for example you might split the different site areas up — home page, product page, shopping cart, payment workflow, etc. You might then further subdivide these — implement common site header and footer, implement product page detail view, implement persistent shopping cart widget, etc.

There are multiple general strategies to cross browser development, for example:

Normally your development will involve a combination of the above three approaches. The most important thing is that you test each small part before committing it — don’t leave all the testing till the end!

Testing/discovery

After each implementation phase, you will need to test the new functionality. To start with, you should make sure there are no general issues with your code that are stopping your feature from working:

At this point, fix any problems you find with your new code.

Next, you should try expanding your list of test browsers to a full list of target audience browsers and start concentrating on weeding out cross browser issues (see the next article for more information on determining your target browsers). For example:

The most low fi option is to just do all the testing you can by yourself (pulling in team mates to help out if you are working in a team). You should try to test it on real physical devices where possible.

If you haven’t got the means to test all those different browser, operating system, and device combinations on physical hardware, you can also make use of emulators (emulate a device using software on your desktop computer) and virtual machines (software that allows you to emulate multiple operating system/software combinations on your desktop computer). This is a very popular choice, especially in some circumstances — for example, Windows doesn’t let you have multiple versions of Windows installed simulataneously on the same machine, so using multiple virtual machines is often the only option here.

Another option is user groups — using a group of people outside your development team to test your site. This could be a group of friends or family, a group of other employees, a class at a local university, or a professional user testing setup, where people are paid to test out your site and provide results.

Finally, you can get smarter with your testing using auditing or automation tools; this is a sensible choice as your projects get bigger, as doing all this testing by hand can start to take a really long time. You can set up your own testing automation system (Selenium being the popular app of choice) that could for example load your site in a number of different browsers, and:

You can also go further than this, if wished. There are commercial tools available such as Sauce Labs, Browser Stack, LambdaTest, TestingBot, and CrossBrowserTesting that do this kind of thing for you, without you having to worry about the setup, if you wish to invest some money in your testing. It is also possible to set up an environment that automatically runs tests for you, and then only lets you check in your changes to the central code repository if the tests still pass.

Testing on prerelease browsers

It is often a good idea to test on prerelease versions of browsers; see the following links:

This is especially prevalent if you are using very new technologies in your site, and you want to test against the latest implementations, or if you are coming across a bug in the latest release version of a browser, and you want to see if the browser’s developers have fixed the bug in a newer version.

Fixes/iteration

Once you’ve discovered a bug, you need to try to fix it.

The first thing to do is to narrow down where the bug occurs as much as possible. Get as much information as you can from the person reporting the bug — what platform(s), device(s), browser version(s), etc. Try it on similar configurations (e.g. the same browser version on different desktop platforms, or a few different versions of the same browser on the same platform) to see how widely the bug persists.

It might not be your fault — if a bug exists in a browser, then hopefully the vendor will rapidly fix it. It might have already been fixed — for example if a bug is present in Firefox release 49, but it is no longer there in Firefox Nightly (version 52), then they have fixed it. If it is not fixed, then you may want to file a bug (see Reporting bugs, below).

If it is your fault, you need to fix it! Finding out the cause of the bug involves the same strategy as any web development bug (again, see Debugging HTML, Debugging CSS, and What went wrong? Troubleshooting JavaScript). Once you’ve discovered what is causing your bug, you need to decide how to work around it in the particular browser it is causing problems in — you can’t just change the problem code outright, as this may break the code in other browsers. The general approach is usually to fork the code in some way, for example use JavaScript feature detection code to detect situations in which a problem feature doesn’t work, and run some different code in those cases that does work.

Once a fix has been made, you’ll want to repeat your testing process to make sure your fix is working OK, and hasn’t caused the site to break in other places or in other browsers.

Reporting bugs

Just to reiterate on what was said above, if you discover bugs in browsers, you should report them:

Summary

This article should have given you a high-level understanding of the most important concepts you need to know about cross browser testing. Armed with this knowledge, you are now ready to move on and start learning about Cross browser testing strategies.

Источник