Сравнение DOM vs визуальное сравнение: два подхода, две слепые зоны
Сравнение DOM vs визуальное сравнение: противопоставление двух методов обнаружения изменений интерфейса — первый анализирует модификации HTML-дерева (Document Object Model), второй сравнивает скриншоты попиксельно — каждый из которых имеет слепые зоны, не покрываемые другим подходом.
Вот сценарий, с которым вы, несомненно, сталкивались: ваша команда развёртывает обновление. Юнит-тесты проходят. Интеграционные тесты проходят. End-to-end тесты проходят. И всё же пользователь сообщает, что кнопка оплаты исчезла под футером на мобильном устройстве.
Как такое возможно? Потому что ваши тесты проверяют, что DOM содержит правильную кнопку с правильным текстом и правильной ссылкой — но никто не проверяет, что эта кнопка действительно видна на экране, в правильной позиции и с правильным размером.
Именно в этом и заключается проблема выбора между сравнением DOM и визуальным сравнением. Эти два подхода часто преподносятся как альтернативы. В реальности же это две взаимодополняющие грани одной и той же проблемы — и использование одного без другого означает принятие слепой зоны в вашей стратегии тестирования.
В данной статье подробно описывается, что обнаруживает каждый подход, что он упускает, и почему структурное сравнение — тот подход, который читает DOM И проверяет вычисленные CSS-свойства — на сегодняшний день является наиболее полным ответом на проблему визуальной регрессии.
Что на самом деле делает сравнение DOM
Сравнение DOM заключается в снятии снимка HTML-дерева страницы в момент T, после чего сравнивает его со снимком, сделанным в момент T+1. Если узел был добавлен, удалён или изменён, diff помечает его.
Это мощный подход для обнаружения структурных изменений. Случайно удалённый абзац, изменённый атрибут href, добавленный или удалённый CSS-класс — сравнение DOM замечает всё, что затрагивает структуру документа.
Инструменты, использующие этот подход, многочисленны. Snapshot-тесты Jest — самый распространённый пример. Вы сериализуете рендер компонента React или Vue, сохраняете его в файл, и при каждом запуске Jest сравнивает текущий результат с сохранённым snapshot.
Проблема заключается в том, что сравнение DOM видит только HTML. Оно не видит визуальный результат.
Что сравнение DOM не обнаруживает
Возьмём конкретный пример. У вас есть кнопка с классом .btn-primary. В вашем CSS-файле этот класс определяет background-color: #2563EB (синий). Разработчик вносит изменение в CSS-файл и заменяет этот цвет на #DC2626 (красный). HTML не изменился. DOM идентичен. Snapshot Jest проходит зелёным.
Но ваша кнопка в продакшене стала красной вместо синей.
И это не теоретический случай. Вот конкретные ситуации, в которых сравнение DOM слепо.
Изменения внешнего CSS. Любая модификация в таблице стилей, файле темы, пользовательской CSS-переменной, токене дизайн-системы — ничто из этого не отражается в DOM. HTML остаётся идентичным, меняется только рендеринг. А рендеринг — это то, что видят ваши пользователи.
Проблемы со шрифтами. Шрифт Google Fonts, который больше не загружается, активированный системный фоллбэк, изменение начертания — DOM по-прежнему содержит тот же тег <p> с тем же текстом. Но визуально весь типографический ритм вашей страницы разрушен.
Проблемы z-index и наложения. Два элемента, перекрывающие друг друга из-за конфликта z-index, модальное окно, появляющееся под контентом вместо того, чтобы быть поверх него, всплывающая подсказка, выходящая за пределы контейнера — DOM содержит все элементы корректно. Неправильна лишь их визуальная укладка.
Проблемы адаптивности. Flex-контейнер, который больше не переносится корректно, элемент, выходящий за пределы родителя, медиа-запрос, который больше не применяется — DOM тот же самый. Изменилась лишь разметка.
Проблемы отступов и выравнивания. Margin, изменившийся с 16px на 0px, исчезнувший padding, изменённый gap между элементами — ничего не видно в DOM, если эти свойства определены в CSS.
Сравнение DOM по своей природе слепо ко всему, что определено за пределами HTML. А в современном веб-приложении большинство визуального рендеринга определяется в CSS — а не в HTML.
Что на самом деле делает визуальное сравнение
Визуальное сравнение подходит к проблеме с противоположной стороны. Вместо сравнения кода оно сравнивает изображения. Вы делаете скриншот вашей страницы в момент T (эталонный скриншот), затем скриншот в момент T+1, и алгоритм сравнивает два изображения попиксельно — либо с помощью более изощрённых перцептивных методов, таких как pHash или SSIM.
Преимущество очевидно: визуальное сравнение видит то, что видит пользователь. Если цвет кнопки изменился — оно это обнаруживает. Если текст выходит за пределы контейнера — обнаруживает. Если элемент исчез под другим — обнаруживает.
Именно этот подход используется такими инструментами, как Percy, Applitools, Chromatic и BackstopJS. Он популяризировал концепцию визуальной регрессии и позволил тысячам команд обнаруживать баги, которые не видели их функциональные тесты.
Но у этого подхода есть и свои слепые зоны. И они весьма существенны.
Что визуальное сравнение не обнаруживает
Невидимые, но семантически важные изменения. Ссылка, чей href изменился с /checkout на /cart, не производит никаких визуальных изменений — текст и стиль ссылки идентичны. Но пользователь, кликнувший по ней, больше не попадает на нужную страницу. Визуальное сравнение ничего не замечает.
Изменения доступности. Удалённый aria-label, изменённый role, отсутствующий alt на изображении — ничего не видно на скриншоте. Но для пользователей скринридеров ваша страница стала непригодной для использования.
Изменения динамического контента. Цена, изменившаяся с 29 на 290, счётчик, отображающий неверное число, имя пользователя, которое больше не загружается — если разметка остаётся идентичной, попиксельное сравнение может не пометить это как регрессию, особенно при высоких порогах допуска.
Массовые ложные срабатывания. Это проблема номер один при чисто визуальном сравнении. Мигающий курсор, анимация на другом кадре, динамический контент (дата, время, реклама), незначительно различный рендеринг шрифта между двумя запусками — всё это генерирует визуальные различия, не являющиеся регрессиями. Согласно исследованию Google надёжности тестов (2016), flaky-тесты составляют 1,5% всех тестовых запусков в Google, а вариации рендеринга — одна из основных причин нестабильности визуальных тестов.
Отсутствие объяснений. Когда визуальное сравнение показывает вам diff, оно сообщает «здесь что-то изменилось», выделяя зону. Но оно не говорит, что именно. Это цвет? Размер? Позиция? Контент? Вам предстоит выяснить это самостоятельно. На сложной странице с десятками изменений разбор ложных срабатываний становится полноценной работой.
Реальная проблема: два метода, две симметричные слепые зоны
Если вы следите за рассуждением, вы уже видите парадокс.
Сравнение DOM обнаруживает изменения HTML, но пропускает визуальные изменения. Визуальное сравнение обнаруживает визуальные изменения, но пропускает семантические. Два подхода слепы именно там, где силён другой.
Этот парадокс — не случайность. Он отражает фундаментальную дуальность веб-страницы: код (DOM + CSS) порождает визуальный рендеринг, но связь между ними не является биективной. Один и тот же DOM может давать совершенно разные рендеринги в зависимости от применённого CSS. И один и тот же визуальный рендеринг может быть порождён совершенно разными DOM-деревьями.
Именно поэтому выбор между сравнением DOM и визуальным сравнением — это ложная дилемма. Вопрос не в том, «что лучше» — вопрос в том, «как покрыть оба измерения».
Некоторые команды пытаются решить эту проблему, комбинируя оба инструмента: Jest для DOM-снапшотов и Percy или BackstopJS для скриншотов. Это лучше, чем ничего, но это также две пайплайна для поддержки, два набора эталонов для управления, два источника ложных срабатываний для разбора — и никакой корреляции между результатами. Когда Jest сообщает «DOM изменился», а Percy говорит «визуал изменился», никто не говорит вам, связаны ли эти два изменения между собой.
Структурное сравнение: чтение DOM И проверка вычисленных CSS
Существует третий подход, который не ограничивается ни DOM в одиночку, ни пикселями в одиночку. Это структурное сравнение — и именно этот подход выбрал Delta-QA.
Принцип прост: вместо сравнения статического HTML-дерева или плоского изображения Delta-QA читает каждый элемент DOM и извлекает его вычисленные CSS-свойства — то есть стили, фактически применённые браузером после разрешения всех каскадов, наследований, медиа-запросов и CSS-переменных.
Конкретно, для каждого элемента вашей страницы Delta-QA знает его точную позицию, фактические размеры, эффективный цвет, применённую типографику, разрешённые margin и padding, вычисленный z-index, прозрачность и видимость. Не стили, объявленные в исходном CSS — а стили, какими их рассчитал и применил браузер.
Этот подход решает обе слепые зоны одновременно.
Он обнаруживает изменения CSS. Если CSS-переменная изменилась и повлияла на цвет кнопки, Delta-QA это видит — потому что он сравнивает вычисленные CSS-свойства, а не исходный HTML. background-color кнопки изменился с rgb(37, 99, 235) на rgb(220, 38, 38). Отчёт прямо об этом говорит.
Он обнаруживает изменения DOM. Если элемент добавлен, удалён или перемещён в HTML-дереве, Delta-QA это видит — потому что он обходит DOM элемент за элементом.
Он не генерирует ложных срабатываний, связанных с рендерингом. Никакого попиксельного сравнения — следовательно, никакого diff из-за мигающего курсора, анимации на другом кадре или незначительного сглаживания шрифтов. Если вычисленное CSS-свойство идентично — diff нет.
Он объясняет, что изменилось. Вместо выделения зоны красным на скриншоте Delta-QA сообщает вам: «padding-top этого элемента изменился с 16px на 8px» или «font-weight этого заголовка изменился с 700 на 400». Вы точно знаете, что изменилось, на каком элементе и на какую величину.
Алгоритм в 5 проходов
Delta-QA не ограничивается наивным diff между двумя DOM-деревьями. Его структурный алгоритм из 5 проходов работает методично, чтобы гарантировать точность результатов.
Первый проход идентифицирует соответствующие элементы между двумя версиями страницы, используя комбинацию CSS-селекторов, позиции в дереве и текстового содержимого. Второй проход сравнивает вычисленные CSS-свойства каждой пары совпавших элементов. Третий проход обнаруживает добавленные и удалённые элементы. Четвёртый проход анализирует пространственные отношения — элементы, переместившиеся относительно своих соседей. Пятый проход агрегирует результаты и устраняет шум — микровариации рендеринга, не составляющие значимых регрессий.
Результат — это отчёт, дающий вам точный список изменений, отсортированных по степени критичности, с указанием затронутого элемента, изменённого свойства, предыдущего и нового значения для каждого.
Когда сравнения DOM достаточно
Будем откровенны: сравнение DOM имеет своё место. Если ваша цель — проверить, что структура ваших компонентов не изменилась между двумя коммитами — и только структура — snapshot-тесты Jest справляются с этой задачей корректно. Они быстрые, бесплатные, интегрированы в JavaScript-экосистему и не требуют дополнительной инфраструктуры.
Это облегчённая страховка для фронтенд-разработчиков, которые хотят получать уведомления при изменении рендера компонента. Пока вы осознаёте, что эта страховка покрывает только HTML — не CSS, не разметку, не финальный рендеринг — это легитимный инструмент в вашем арсенале.
Проблема начинается, когда вы рассматриваете DOM-snapshot-тесты как замену визуальному тестированию. Они ею не являются. Это тест структуры, а не тест внешнего вида.
Когда визуального сравнения достаточно
Визуальное сравнение через скриншоты также имеет своё место. Для очень статичных страниц с небольшим количеством динамического контента оно работает хорошо. Для быстрой проверки перед развёртыванием — «выглядит ли главная страница корректно» — скриншот, сравненный с эталоном, является хорошим экспресс-индикатором.
Оно также полезно для обнаружения регрессий рендеринга, специфичных для определённых браузеров. Баг WebKit, влияющий на отображение CSS-градиентов, не будет обнаружен ни при сравнении DOM, ни при структурном сравнении — вам нужно увидеть изображение, отрендеренное браузером.
Но если вы работаете над приложением с динамическим контентом, анимациями, интерактивными состояниями или просто с CSS, который регулярно эволюционирует, ложные срабатывания попиксельного сравнения быстро станут операционной проблемой. По отзывам из практики сообщества визуального тестирования, команды тратят в среднем от 30 до 60 минут в день на разбор ложных срабатываний при использовании инструментов сравнения скриншотов.
Почему структурное сравнение — правильный ответ в 2026 году
Веб эволюционировал. Современные приложения строятся на дизайн-системах, CSS-переменных, компонентных фреймворках, сложных адаптивных разметках, динамических темах. CSS больше не является статичным файлом, который пишется один раз — это система динамических правил, взаимодействующих друг с другом.
В этом контексте сравнение DOM без анализа CSS — это как проверка чертежа здания без проверки того, правильно ли стоят стены. А сравнение скриншотов без понимания структуры — это как разглядывание фотографии здания без возможности определить, переместилась крыша или фундамент.
Структурное сравнение — в том виде, как его практикует Delta-QA — это единственный подход, который понимает и структуру, и рендеринг. Он знает, что кнопка существует (DOM), что она синяя (вычисленный CSS), что её ширина составляет 200px (вычисленные размеры) и что она расположена в 340px от верхней части страницы (вычисленная позиция).
Если любое из этих свойств изменяется — он обнаруживает это. Если ничего не изменилось — он не генерирует ложных срабатываний. Всё просто.
А поскольку Delta-QA работает без кода и без облака, вам не нужно быть разработчиком, чтобы воспользоваться этой точностью. Вы устанавливаете десктопное приложение, навигируете по вашему сайту — и инструмент делает всё остальное. Локально. Без отправки ваших данных куда-либо.
FAQ
В чём фундаментальная разница между сравнением DOM и визуальным сравнением?
Сравнение DOM анализирует модификации HTML-дерева — теги, атрибуты и текст, составляющие структуру страницы. Визуальное сравнение сравнивает скриншоты попиксельно для обнаружения любых видимых изменений на экране. Первое пропускает изменения CSS, второе — невидимые семантические изменения.
Может ли DOM измениться без изменения визуала?
Да, и довольно часто. Изменённый атрибут data-*, добавленный CSS-класс без ассоциированного стиля, добавленный HTML-комментарий, реструктуризация DOM, дающая тот же рендеринг — все эти случаи модифицируют DOM без изменения внешнего вида страницы. Это основной источник ложных срабатываний в инструментах DOM-snapshot-тестирования.
Может ли визуал измениться без изменения DOM?
Безусловно. Это даже самый распространённый случай в современных приложениях. Изменение CSS-переменной, смена внешнего шрифта, обновление CSS-фреймворка, баг z-index из-за изменённого CSS-правила — всё это меняет рендеринг, не затрагивая HTML. Сравнение DOM структурно не способно обнаружить эти регрессии.
Что такое структурное сравнение и чем оно отличается от двух других?
Структурное сравнение читает каждый элемент DOM и извлекает его вычисленные CSS-свойства — стили, фактически применённые браузером. Таким образом оно объединяет структурное видение DOM и эффективное видение рендеринга, без недостатков попиксельного сравнения (ложные срабатывания, отсутствие объяснений). Это подход, используемый Delta-QA.
Достаточно ли snapshot-тестов Jest для обнаружения визуальных регрессий?
Нет. Snapshot-тесты Jest сравнивают HTML, сгенерированный вашими компонентами, а не их внешний вид. Они полезны для обнаружения случайных структурных изменений, но не видят изменений CSS, проблем разметки, конфликтов z-index или типографических регрессий. Это тесты структуры, а не визуальные тесты.
Как Delta-QA избегает распространённых ложных срабатываний визуального сравнения?
Delta-QA не сравнивает пиксели — он сравнивает вычисленные CSS-свойства. Мигающий курсор, анимация на другом кадре или незначительное сглаживание шрифтов не генерирует diff, потому что лежащие в основе CSS-свойства не изменились. В отчёт попадают только реальные изменения стиля, позиции или размеров.
Нужно ли быть разработчиком для использования структурного сравнения Delta-QA?
Нет. Delta-QA — это no-code инструмент. Вы устанавливаете десктопное приложение, навигируете по сайту как обычно, и инструмент автоматически записывает и сравнивает. Никакого SDK для интеграции, никаких скриптов для написания, никакой CI/CD пайплайны для настройки. Всё делается из графического интерфейса.
Сравнение DOM и визуальное сравнение — не плохие инструменты. Они неполны при изолированном использовании. Структурное сравнение превосходит их, объединяя лучшее из каждого — без ложных срабатываний одного и слепых зон другого.
Если вы тестируете свой интерфейс с помощью DOM-снапшотов или скриншотов, вы уже сделали шаг в правильном направлении. Но если вы хотите полного покрытия — структура, стиль и разметка — без шума, без сложности и без отправки ваших данных в облако, структурное сравнение — следующий логичный шаг.