Home

Автор: Катрина Клоки (Katrina Clokie)

Оригинал статьи: http://katrinatester.blogspot.ru/2017/10/strategies-for-automated-visual.html

Перевод: Ольга Алифанова

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

Что такое визуальная регрессия?

Внешний вид веб-приложения обычно определяется каскадной таблицей стилей (CSS). Ваш продукт может использовать другую разновидность CSS – например, SCSS, SASS, LESS. Все они описывают формат и развертку вашего пользовательского веб-интерфейса.

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

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

Определить, где могут появиться эти регрессионные проблемы, нелегко – таблица стилей применяется каскадно. Элемент на вашей странице может унаследовать свойства отображения от родительских элементов. Допустим, голубая кнопка с меткой шрифтом Arial: цвет кнопки определяется для конкретного элемента, а шрифт для метки определяется для всей страницы. Изменение шрифта для этой кнопки путем изменения родительского определения может иметь далеко идущие последствия.

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

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

Стратегия первой команды

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

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

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

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

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

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

Стратегия второй команды

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

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

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

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

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

Стратегия третьей команды

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

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

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

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

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

Заключение

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

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

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

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

Обсудить в форуме