Визуальное регрессионное тестирование — это круто

Веха на пути к непрерывной доставке

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

• Модульные тесты
• Интеграционные тесты
• Сквозные тесты

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

Почему? Потому что мы непосредственно тестируем конечное приложение, и это приносит много проблем. С годами инструмент значительно улучшился. Для выполнения сквозных веб-тестов у нас есть замечательные инструменты, такие как Puppeteer, Playwright, Selenium и Cypress.

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

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

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

Давайте посмотрим на это на примере. Допустим, у нас есть страница входа ниже:

И есть рефакторинг PR, который производит следующий макет:

Наши традиционные e2e-тесты не провалятся, учитывая вышеуказанные изменения. Кнопка присутствует, кликабельна и функциональна. Визуально сломан только макет кнопки, что не влияет на ее интерактивность.

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

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

Отлов сбоя пользовательского интерфейса в продакшене требует больших ресурсов. У нас есть ряд вопросов, на которые нужно ответить. Как сломался макет? Сколько времени он был сломан? Как это должно было выглядеть?

Отсутствие визуального тестирования нашего приложения приводит к нескольким большим рискам:

• Затраты на разработку: определение + исправление + регрессия вручную + отправка в производство.
• Бренд компании: постоянное появление сбоев в производстве повлияет на восприятие нашими пользователями качества нашего приложения.
• Влияние на доход.неуместное размещение CTA, случайное удаление и т. д. может повлиять на доход нашего бизнеса.

Могут ли функциональные тесты покрыть визуальные проблемы?

Учитывая, что мы определили риск, мы можем захотеть действовать в соответствии с ним. Поскольку у нас уже есть отличный инструментарий e2e, можем ли мы адаптировать наши функциональные тесты e2e, чтобы выявлять все эти визуальные ошибки? Это выполнимо? Да, в некоторой степени. Мы можем установить положение элемента, размер, цвет, форму… Они доступны из DOM.

Хотим ли мы пойти по этому пути? Точно нет! Почему?

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

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

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

Давайте запустим некоторые цифры:

• Мы хотим протестировать веб-приложение с 10 экранами.
• Каждый экран имеет 2 варианта.
• Мы поддерживаем 4 разных языка.
• Мы хотим, чтобы вывод работал в 3 разных браузерах и 3 разных разрешениях экрана.

Это означает, что нам нужно будет протестировать:

10 [screens] * 2 [variants] * 4 [lang] * 3 [browsers] * 3 [screen res] = 720 outputs

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

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

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

Как они работают? Они обеспечивают интеграцию с нашими любимыми инструментами тестирования e2e и предоставляют удобный для разработчиков API. Так что мы можем использовать наш любимый движок Cypress или Selenium и добавить сверху визуальный тест. Это будет дополнительный слой на наших тестах.

Кто лучшие игроки в этой области? Мы можем сгруппировать их по открытым и проприетарным:

• Открытый исходный код. Есть довольно много вариантов. Верхние — BackstopJS и Loki. К сожалению, у них отсутствует процесс онлайн-утверждения. Это обязательное условие в нашем рабочем процессе тестирования. Вариант состоит в том, чтобы построить его самостоятельно, а затем разместить его.
• Проприетарное право. Самыми популярными платными продуктами SaaS являются Percy и Applitools. Они обеспечивают почти все, что нам может понадобиться.

На мой взгляд, не стоит тратить время на разработку собственного инструментария утверждения. Итак, нам остается выбирать между Percy и Applitools. Каковы их различия? Как выбрать между ними?

Давайте проверим их основные отличия и предостережения:

Перси

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

Как это работает внутри? Он передает HTML на свои серверы, где он обрабатывается и делается скриншот. Он сравнивает их с базовыми показателями для этой страницы и определяет различия. Весь процесс выполняется асинхронно и публикуется в нашем CI. Например, через действия.

Каков порог для определения того, что есть визуальное различие? Его можно настроить в их пользовательском интерфейсе в зависимости от наших предпочтений. Они имеют различные режимы: Strict, Recommended и Relaxed.

Давайте сравним настройки strict и recommended.

На мой взгляд, рекомендуемый делает хорошую работу.

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

Механизм Percy обработает оба изображения и выведет их различия. Теперь понятно, что изменилось: отступы в кнопках. Нам решать, было ли это изменение намеренным или нет.

Как он работает с динамическими данными? По-простому. Любые динамические элементы, которые есть в нашем приложении, нужно будет скрыть с помощью медиа-запросов или применить какие-либо стратегии, такие как замораживание даты.

Applitools

Этот инструмент немного сложнее, чем Перси. Он привносит возможности ИИ в визуальное тестирование. Что это значит? Эта система будет понимать нашу систему на совершенно новом уровне. Это приведет к более качественному визуальному тестированию, поскольку оно будет выходить далеко за рамки различий на уровне пикселей.

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

• Точный: обнаружит изменения, которые не заметит даже человеческий глаз. Не рекомендуется его использовать.
• Строгий (по умолчанию): это почти эквивалентно тому, как Перси замечает различия
• Содержание: похоже на Strict, но игнорирует такие вещи, как цвета.
• Макет: сравнивает расположение и отображение элементов на странице. Он идеально подходит для динамических дат или элементов динамического изменения содержимого.

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

Однако служба Applitools более тесно связана с нашим e2e-провайдером. Несмотря на то, что обработка ИИ все еще происходит на их серверах, процесс e2e блокирует завершение тестов до тех пор, пока обработка Applitools не будет завершена.

Выводы

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

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

А как насчет Percy против Applitools? На ваше усмотрение, если вам нужно что-то, что просто работает и выполняет свою работу, я бы выбрал Перси. Для тестирования динамических элементов требуется больше усилий при разработке, но этим можно управлять. Я вижу, как они догоняют ИИ в этой функции. Если вам прямо сейчас нужен более мощный инструмент, который охватывает широкий спектр сценариев, выберите Applitools. В нем уже есть все функции, которые вам могут понадобиться. Он рекламируется как бесплатный для проектов с открытым исходным кодом.

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

Ваше здоровье.