Эволюция компьютерного зрения в автоматизации тестирования

Автоматизация тестирования пользовательских интерфейсов прошла долгий путь — от простых скриптов с локаторами до современных методов на базе искусственного интеллекта. Изначально тесты писались вручную с помощью инструментов вроде Selenium: тестировщики указывали, какие элементы на странице найти (например, кнопки или поля ввода) с помощью локаторов — уникальных идентификаторов, XPath или CSS-селекторов. Позднее, чтобы упростить проверку интерфейсов, в дело стало вступать компьютерное зрение — анализ скриншотов с помощью OpenCV и подобных библиотек. Сегодня же на передний план выходят Vision-Language модели (VLM) — нейросети, которые умеют одновременно «видеть» содержимое экранов и понимать текстовые описания.

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

Классическая автоматизация: локаторы и код

Что такое локаторы. Традиционная автоматизация UI опирается на поиск элементов в DOM-дереве страницы с помощью локаторов. Локатор — это указание браузеру, как найти нужный HTML-элемент. Существуют различные стратегии локаторов: по ID, имени, классу, XPath, тексту, а в случае мобильных приложений даже свои собственные механизмы, как UiSelector в Android, например.

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

Например, кнопку сабмита формы можно найти по уникальному атрибуту id="submit" или по CSS-классу .btn. Инструменты вроде Selenium WebDriver или современные фреймворки (Playwright, Cypress) позволяют записывать шаги теста, обращаясь к элементам через такие локаторы. Ни один GUI-тест не обходится без этой механики. Какой бы инструмент вы ни выбрали для автоматизации, все они будут искать элементы с помощью локаторов.

Как это работает. Автоматизированный тест-приложение (скрипт на Java, Python, JavaScript и т.д.) взаимодействует с браузером через специальный драйвер. На каждом шаге скрипт отправляет команду: найти элемент по указанному селектору и выполнить действие (клик, ввод текста, чтение свойства). Например, Selenium, получив команду findElement(By.id("login")), просматривает DOM-структуру страницы, находит элемент с id="login" и затем может выполнить click().

Локаторы привязаны к HTML-разметке, поэтому их надежность зависит от того, насколько стабильно разработчики поддерживают идентификаторы. Практика выработала некоторые правила: желательно использовать уникальные статические атрибуты (например, data-test), избегать сложных XPath, проверять, что локатор не изменится при перезагрузке или смене языка страницы.

Тем не менее, Web-интерфейсы со временем эволюционируют — меняются классы и ID элементов, верстка усложняется динамическими компонентами. Автоматизация тестирования веб требует учитывать динамическую природу UI, скорость тестов и устойчивость локаторов. Иначе говоря, традиционные автотесты хрупки: малейшее изменение в коде фронтенда (например, переименовали кнопку или перестроили раздел HTML) может сломать множество тестовых сценариев.

Проблемы и поддержка. Главный недостаток локаторного подхода — дорогая поддержка тестов. При активной разработке приложения авто-тесты требуют постоянного обновления: исправлять селекторы, ждать загрузки динамических элементов, добавлять задержки. По опыту индустрии, на сопровождение тестовых скриптов уходит едва ли не больше усилий, чем на их изначальную разработку. Как признавался Кит Поуи, вице-президент по инжинирингу IDT: «Мы тратили столько времени на поддержку тестов на Selenium, ... а теперь тратим почти ноль времени, используя testRigor» [testrigor.com].

Иными словами, классические UI-тесты грозят превратиться в постоянную гонку за изменяющимся интерфейсом. Появлялись частичные решения, например, Self-healing («самоисцеление» локаторов) с помощью ИИ. Такие механизмы пытаются автоматически подобрать альтернативный селектор, если старый перестал работать. Но как отмечают разработчики CodeceptJS: «AI-healing решает ровно одну проблему: если локатор элемента изменился, и действие не удалось, он подбирает новый локатор, повторяет команду и продолжает тест» [codecept.io]. Это снимает часть боли, но не меняет принципа: тест все так же опирается на предопределенные селекторы.

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

Вывод: Классическая автоматизация через локаторы была революционна для своего времени и до сих пор остается основой для многих команд. Она хорошо работает при стабильном UI и правильной стратегии локаторов (уникальные ID, атрибуты для тестов и т.п.). Плюсы такого подхода: высокая скорость выполнения (обращение к DOM напрямую), интеграция с CI/CD, детерминизм сценариев. Однако минусы перевешивают в быстро меняющихся продуктах: хрупкость, большие затраты на поддержку и необходимость вовлечения опытных автоматизаторов. Это подтолкнуло индустрию к поиску более гибких и «умных» решений.

Компьютерное зрение: поиск элементов по изображению

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

Один из первых популярных инструментов такого рода — Sikuli (MIT, ~2010 год). Sikuli позволил автоматизировать действия, используя скриншоты GUI для поиска и кликов. Внутри он задействовал OpenCV — мощную библиотеку компьютерного зрения с сотнями алгоритмов для обработки изображений и распознавания объектов.

Принцип работы прост: тестировщик делает снимок элемента (например, кнопки «Поиск»), а Sikuli затем находит на экране участок, совпадающий с этим образцом, и симулирует нажатие. «SikuliX использует OpenCV, чтобы найти местоположение указанного изображения... и выполняет клик мыши или ввод с клавиатуры по найденной координате». Таким образом, можно автоматизировать почти всё, что видит пользователь — хоть веб-страницу, хоть настольное приложение или игру — не обращаясь к внутреннему устройству программы.

Как это выглядит на практике. Вместо текстовых селекторов тестер оперирует картинками. Сценарий на Sikuli или похожих фреймворках состоит из последовательности команд: «найти изображение X», «кликнуть по нему», «ввести текст Y», «убедиться, что изображение Z появилось на экране» и т.д.

По сути, тест имитирует ручную проверку: мы проверяем интерфейс глазами (через алгоритм сравнения изображений) и совершаем действия как пользователь. Этот подход приближает автотест к мануальному тестированию. Как отметила тестировщик Thosha Moodley: «Sikuli... максимально близок к роли ручного тестировщика, который визуально проверяет интерфейс и позволяет автоматизировать тесты без серьёзных навыков разработки». Другими словами, порог входа снижается: не нужен глубокий кодинг, достаточно понимать, как выглядит нужный элемент.

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

Инструменты вроде Applitools Eyes стали лидерами рынка в этой нише: их ИИ-алгоритмы анализируют два изображения (ожидаемый дизайн и фактический) и подсвечивают отличия, игнорируя незначительные артефакты. Такой пассивный подход полезен для регрессионного тестирования UI — он фокусируется на том, как страница выглядит, а не только на её коде.

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

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

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

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

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

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

Многие codeless-платформы (Katalon, Tricentis Tosca, TestComplete и др.) включили в свой функционал поиск элементов по изображениям, но чаще как вспомогательную опцию. Нередко это реализовано через визуальный рекордер: пользователь сам кликает по интерфейсу, инструмент делает снимки элементов и генерирует тестовые шаги. Так, показательный пример — testup.io, где вся концепция построена вокруг изображений: точки взаимодействия задаются относительно визуальных маркеров, а на скриншоте шагов видно миниатюры элементов.

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

Vision-Language модели: тестирование на естественном языке

От компьютерного зрения к мультимодальным моделям. Vision-Language Models (VLM) — это класс нейросетей, который объединяет распознавание изображений и обработку естественного языка. Идея состоит в том, чтобы обучить модель, способную видеть картинку и описывать её словами, а также понимать слова и искать соответствие на картинке.

Большинство VLM устроены как две части: визуальный энкодер (обычно нейросеть на основе ResNet или Vision Transformer), который преобразует изображение в семантическое представление, и языковой декодер/энкодер (крупная языковая модель GPT или BERT), который понимает текст. Обучая эти модули на огромных наборах пар «картинка–описание», они добиваются того, что сеть начинает устанавливать связь между визуальными объектами, их названиями и свойствами.

Пример: модель видит изображение с котом на кресле и подпись «кошка лежит на кресле», и со временем учится понимать, что на картинке кот, что «лежит» — это определенное положение, что диван — это что-то мягкое на чем можно лежать и т.д. В результате такие модели способны решать задачи мульти-модального понимания: генерировать текст по изображению (описание, подписи), отвечать на вопросы по картинке, находить по текстовому запросу нужный объект на изображении и пр.

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

Применение VLM для тестирования UI. Как VLM помогает автоматизировать тестирование? Проще всего это понять на примере: допустим, у нас есть скриншот веб-страницы или мобильного приложения. Ранее, чтобы проверить его содержимое, нам нужен был или человек-тестировщик, или набор проверок конкретных элементов (по DOM или по эталонным изображениям). Теперь же мы можем задать вопрос модели на естественном языке о содержимом UI, и она постарается ответить на основании картинки.

В блоге Smartesting показан кейс: модели Claude 3.5 дали скриншот интернет-магазина и запрос на английском: «Что изображено на странице? Найди, есть ли рубашка, и какая у нее цена». Модель проанализировала скриншот и выдала структурированный ответ - перечислила несколько товаров (платье, куртка, брюки, Checked Slim Fit Shirt - $48.99 и т.д.), а затем прямо ответила: мол, да, на картинке есть рубашка (Checked Slim Fit Shirt) по цене $48.99. Ранее такой сценарий потребовал бы либо проверки текста в DOM (искать слово Shirt и парсить цену), либо ручного взгляда. Vision-Language модель выполнила его «с нуля», просто получив изображение и вопрос.

Заключение

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

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

Vision-Language модели в связке с AI-агентами сделали следующий шаг: они фактически научили компьютер «думать» о том, что он видит на экране, и понимать наши инструкции почти как опытный тестировщик. Это позволило создать системы, где шаги тест-кейса становятся его же автоматизацией.

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

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