“Что глазу не видно” ‒ следим за изменениями на web-страницах

При работе с web-приложениями часто поднимается ряд вопросов. Произошли ли за последнее время какие-то изменения во внешнем виде отдельных страниц? Как повлияли отдельные изменения дизайна на их внешний вид? Как выглядит страница после появления на ней нового вида рекламы? Поиск ответов на эти вопросы вручную часто бывает затруднен – не все можно сразу заметить человеческим глазом. Для решения подобных задач Inventos разработали систему ScreenCompare.

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

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

Еще одна проблема – это смещение всех элементов страницы на незначительное расстояние (буквально 1-2 пикселя). При проверке изменений верстки их необходимо учитывать наряду с бóльшими, но в общем случае такие различия должны игнорироваться.

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

Таким образом, система должна уметь:

  1. Снимать, сохранять и сравнивать друг с другом скриншоты;
  2. Взаимодействовать перед съемкой с элементами страниц;
  3. Иметь возможность отключить проверку динамических элементов на странице;
  4. Дать пользователю возможность настройки «точности» совпадения снятого скриншота с эталоном;
  5. Иметь удобный интерфейс для взаимодействия пользователя со скрытыми элементами системы.

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

Для реализации первого блока был выбран один из готовых вариантов – PhantomCSS (https://github.com/Huddle/PhantomCSS). Из серьезных его недостатков можно выделить не очень подробную документацию. Несмотря на то, что его код оформлен достаточно неплохо и многие функции описываются либо их же названием, либо примерами конфигураций, над действием некоторых функций пришлось хорошенько поломать голову. Преимущества же перевесили недостатки. Во-первых – достаточно гибкая конфигурируемость. Уже в базовой версии PhantomCSS имеет возможность игнорировать меняющиеся после прогрузки страницы элементы и устанавливать «уровень толерантности различий» – какой уровень различия будут игнорироваться при сравнении. Хотя «толерантность» и не является интуитивно понятной функцией, ее действительно можно настроить для различных уровней совпадения скриншотов.

Из названия напрашивается вывод, что каким-то образом данный инструмент связан с PhantomJS. И, как выясняется, это действительно так. Для работы «браузера» используется связка PhantomJS+CasperJS. Последний же используется и для реализации тестовых сценариев (в случае применения PhantomCSS как единственного инструмента). Тут нас ждет еще одна приятная новость – CapserJS имеет возможности непосредственно взаимодействовать с элементами страницы. Ура!

Кроме того, потенциально полезным свойством является и то, что делается скриншот не одного экрана страницы, а всей страницы целиком, сверху донизу, в 1 скрин. «Экрану» можно установить определенную ширину (что позволяет, например, проверить, как будет выглядеть сайт на экране смартфона). Тоже приятно. А порезав получившийся скриншот по высоте экрана можно посмотреть, что влезет на экран определенной высоты.

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

В итоге, с помощью PhantomCSS был реализован следующий сценарий:

– Установить размеры используемого экрана;

– Зайти на требуемую страницу;

– Дождаться, пока она полностью загрузится;

– Заснять все, что видим, предварительно разрезав на части определенной высоты;

– Сравнить то, что уже есть в качестве эталонных скриншотов с тем, что наснимали в ходе текущей сессии.

Таким образом, можно считать, что почти все задачи решены. Обрадовавшись, бросаемся реализовывать web-интерфейс на нашем любимом Ruby on Rails. В нем даем пользователю возможность структурировать страницы по проектам, задать для каждой страницы свой сценарий, описать предварительные действия с элементами (указать селекторы объектов для взаимодействия и, при необходимости, вводимый в поле текст), посмотреть результаты тестов. Вот интерфейс каталогов и системы управления (используется обутстрапленный RoR).

На первом скрине представлен интерфейс каталога проектов, через который видно:

  • число страниц, скрины которых не совпали;
  • адрес заглавной страницы данной группы;
  • кнопки перехода к списку страниц проекта;
  • обновления эталонных скринов и другие (часть названий проектов скрыта).

На втором – каталог страниц проекта «Habr». Здесь почти все аналогично, но можно перейти к просмотру скринов для конкретной страницы (картинки ниже).

Далее присоединяем к нему полученные с PhantomCSS модули, жмем кнопку, чтобы заснять нужную страницу, и… Все виснет. Наглухо. С ужасом обнаруживаем, что скриншоты заснялись, что-то начало сравниваться, и просто съело весь процессор. Неприемлемо.

Попытка оптимизации процесса сравнения вряд ли даст большой прирост производительности – такого рода задачи характеризуются высокой трудоемкостью. Полностью отдадим на растерзание сравнивателю одно ядро процессора – остальных должно хватить для поддержания работы систем и приложения. Запуск без использования web-интерфейса далеко не так прост, поэтому просто заблокируем возможность запускать более одного процесса сравнения одновременно. Да, скоростью сравнения чуть-чуть падает, но даже с такими ограничениями страница высотой в 5-6 экранов прогоняется менее, чем за 1 минуту.

Для примера возьмем одну из страниц Habrahabr (https://habrahabr.ru/all/). Сделаем эталонный скриншот, после чего снимем эту же страницу еще раз через некоторое время (после появления на этой странице новой статьи). И вот, что видим.

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

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

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

 

У нас есть похожие новости по этим темам:
Наверх

Leave a Reply

Войти с помощью: 

Your email address will not be published. Required fields are marked *