Визуальное тестирование

• Суть
• Визуальная инспекция и скриншоты
• Этапы
• Важность
• Почему функционального недостаточно
• Подходы
• Типы
• Инструменты
• Преимущества и недостатки такого тестирования

Кратко

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

Кратко характеристики визуального тестирования:

• Обеспечение единообразного UI (единого стиля и вида) на всех устройствах и браузерах
• Проверка респонсивности
• Регрессионное визуальное тестирование
• Тестирование при новом коммите
• Чаще бывает ручным, но успешно автоматизируется

Визуальное тестирование и визуальная инспекция

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

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

Этапы

Итак, визуальные веб-тесты генерируют, сравнивают (сопоставляют) и анализируют скриншоты (снимки, снепшоты). Процесс: 

• Тестировщик запускает написанный им (или выделенными членами QA-команды) код проверки страницы/приложения
• Создаются первые скриншоты, которые далее будут служить в качестве baseline («базовой линии»), с которой должны сравниваться следующие
• Далее скрипт работает в фоновом режиме и делает еще снимки результатов
• Далее эти снимки сравниваются с baseline-снимками
• Если среди этих снимков обнаружены изменения, тест считается failed, упавшим, и код/дизайн корректируют
• А если нет, то тест прошел и все ОК

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

Важность

Такое тестирование возникло очень давно (первые инструменты созданы в 1980х в Microsoft) и возникло потому, что «визуальные» ошибки случаются достаточно часто, а так как они всегда хорошо заметны, то очень сильно ухудшают user experience, вплоть до отказа от приложения/веб-сервиса.

Визуальные тесты:

• Верифицируют, что UI-интерфейс продукта везде целостный/единообразный 
• Что интерфейс выглядит для пользователя так как планировали создатели
• То есть в интерфейсе нет дефектов
• Наглядно видны отклонения UI от эталонных (baseline) снимков
• Быстрая обработка тест-кейсов, что значительно упрощает процесс

Почему функционального недостаточно

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

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

Подходы

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

1. По первых, создание специальных визуальных тестов. Пишутся тест-кейсы для различных сценариев поведения пользователя и путей. Обычно не предполагается много этих тест-кейсов, но написание требует внимательности и опыта в ручном тестировании. 
2. Включение визуальных точек проверки в функциональные тесты. При стандартной валидации функциональности между какими-то этапами вставляются также этапы визуальной проверки UI. Возможно, это снижает тестовое покрытие, но это быстро и удобно.
3. Включение имплицитной (неявной) визуальной проверки в фреймворк. Так наверное проще всего, и делается это несколькими строчками кода. Такие вставки часто ограничиваются некими общими проверками, и не всегда это подходит, но если нужно быстро, то вполне нормально.

Визуальное тестирование — типы

1. Ручное. 

Тестировщик вручную проверяет интерфейс: его компоновку и элементы. И вручную делает снепшоты/скриншоты и сравнивает их с эталонными (базовыми), и когда заметит разницу, сообщает об этом в репорте.

Еще один метод — при помощи проводника компонентов. Тестировщик описывает тестовые состояния, в проводнике выбирает компонент и его состояние, и проверяет на экране. Существуют инструменты типа React Storybook, в котором можно изолированно разрабатывать/тестировать компоненты UI. 

Этапы ручного визуального тестирования:

• Пройти по приложению/сайту и сделать качественные baseline-скриншоты
• Далее в процессе тестирования сделать скриншоты для сравнения и выявления отличий и проблемных мест
• Собственно, сравнить вручную, и найти эти проблемные места

2. Автоматизированное визуальное тестирование: 

Проверка визуального восприятия пользовательского интерфейса с применением автоматических средств. 

Визуальные автотесты выгодны (команде и проджект-менеджеру) тем, что они:

• Обеспечивают долгосрочную финансовую эффективность (то есть применимы в больших длительных корпоративных проектах)
• Выполняются на порядок быстрее чем ручные
• В общем и целом более точны, поскольку позволяют исключить рутинные человеческие ошибки по невнимательности/усталости
• Способны создать визуальные тесты «с точностью до пикселя»
• Многократно-используемы (то есть реюзабельны, применимы в других проектах/модулях) 
• И прозрачны для руководства, стейкхолдеров и дизайнеров — автоматически формируемые репорты

Но есть и минусы: персонал QA-отдела не всегда быстро осваивает такое тестирование, кривая обучения не идеальная. 

В целом, регрессионное визуальное тестирование — наиболее часто применяемое, если в проекте очень часты изменения кода, перекомпоновка. Хорошо и правильно автоматическое скриншот-тестирование позволяет определить дефекты, зачастую трудно определяемые «ручниками».

И еще сфера применения таких автотестов — сквозное/e2e тестирование сложных user stories.

Инструменты

Ниже приведены некоторые инструменты автоматизированного визуального тестирования.

Code-based (здесь только с открытым кодом и бесплатные):

1. Specter:

• Фреймворк автоматизации визуального регрессионного
• Ориентирован на решение проблем фронтенд-тестировщиков
• Делает скриншоты элементов через нужные селекторы
• Однако является весьма специфическим XUL-приложением (что это?), поэтому ему нужен Firefox или XULRunner

Ссылка на гитхаб Specter

2. Needle:

• Проверка корректности отображения визуальных элементов — рисунки, макеты, кнопки, CSS, SVG и т.д., через скриншоты частей сайта и сравнение с эталонным видом.
• Функция проверки значений CSS и положения HTML-элементов
• Версия 0.1, так что…

Официальный сайт проекта

3. Gemini/Hermione:

• Проект Gemini от Яндекса уже закрыт, вместо него они советуют использовать Hermione
• Которая должна дополнять WebdriverIO там где его функциональности недостаточно
• Базируется на WDIO и Mocha
• Параллельный запуск тестов в субпроцессах
• Расширяемая — добавляются кастомные команды и плагины
• Встроенная библиотека для assertions и матчеров
• Гибкие настройки запуска
• Оверрайд конфигурации браузера
• Хорошо реализованы ожидания при повороте экрана например

Гитхаб проекта

Подробная статья на Хабре

4. iOSSnapshotTestCase

• Это бывший известный проект FBSnapshotTestcases
• Принимает на вход UI View или layer и генерирует на выходе автоматизированные снепшоты контента
• Создает эталонный снепшот и сравнивает с ним дальнейшие, полученные из кода
• Сравнивает по-пиксельно

Гитхаб проекта

Основанные на конфигурациях (здесь только бесплатные и открытые):

1. CSS visual tests: Проверяет корректность CSS-свойств с помощью сгенерированного изображения.
2. VIFF: Находит визуальные различия между веб-страницами в различных окружениях (dev, staging, prod и в тестовом в браузерах).
3. GreenOnion: Проверяет UI сайта на корректность дизайна и представлений
4. Galen Framework: Тестирование верстки веб-приложения с различных устройств.
5. CSSCritic: Проверка текущего макета веб-страницы на соответствие эталонному изображению, сгенерированному ранее.
6. Baskstop JS: Проверяет весь макет или часть макета пользовательского интерфейса и сравнивает его с DOM-скриншотами.

Преимущества и недостатки визуального тестирования

Преимущества понятны из изложенного выше, а также:

• Улучшение качества кода
• И уменьшение его количества
• Быстрый поиск дефектов
• Контроль отображения на разных девайсах и браузерах (то есть как часть тестирования совместимости)
• Простота и скорость внедрения
• Легкость автоматизации процесса
• Быстрый фидбек

Есть и отдельные недостатки:

• Может плохо определять «тонкие» дефекты UI
• Требует, несмотря на кажущуюся интуитивность процессов, определенного опыта
• И большой внимательности
• Если применяется запись видео, с видео бывают сложности
• Не является идеальным методом per se, особенно ручное, из-за особенностей восприятия человеком
• А также недостаток тот что проверяет только видимые области

Источники: 1,2