Запуск QA на базе ИИ в веб-инструменте дизайна выдал результат «Все функции работают, пройдено», хотя холст (canvas) остался пустым. Этот ложноположительный результат не был ошибкой в рассуждениях модели; он стал побочным эффектом того, как браузер обрабатывает скрытые вкладки и как тестовый скрипт измерял «состояние кода» вместо визуального вывода.

Почему ИИ-агенты QA могут пропускать пустой холст

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

Объяснение троттлинга (ограничения ресурсов) скрытых вкладок

Chrome MCP часто запускает тесты во фоновых вкладках, чтобы оставить основное окно свободным для других задач. Когда document.visibilityState вкладки имеет значение hidden, браузер ограничивает (throttles) конвейер рендеринга:

  • JavaScript продолжает работать, поэтому ошибок выполнения не возникает.
  • Коллбэки requestAnimationFrame перестают вызываться, из-за чего счетчик кадров анимации остается равным нулю.
  • Таймеры срабатывают гораздо реже; тест, ожидавший интервалы в 33 мс, зафиксировал всего четыре.

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

Способы решения проблем со скрытыми вкладками

  • Держите вкладку с тестом видимой при любой проверке canvas, анимации или графики.
  • Инициируйте взаимодействия только после того, как вкладка станет активной (на переднем плане).
  • Добавьте небольшую паузу (несколько секунд) перед созданием скриншота, чтобы убедиться, что буфер кадров заполнен.
  • Если необходимо использовать скрытую вкладку, добавьте в отчет примечание, например: «визуальный рендеринг не наблюдался».

Состояние кода против поведения функций

Большинство QA-скриптов на базе ИИ оценивают «состояние кода» (code health): они подтверждают, что обработчики кликов подключены, что не возникло исключений JavaScript и что необходимые библиотеки загружены. Эти сигналы доказывают, что код выполнился, но не то, что интерфейс изменился должным образом. Элемент canvas может быть создан, процедура рисования вызвана, но при этом ничего не отобразится, если команды рисования направлены на буфер нулевого размера или пустой ассет.

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

Добавление проверок поведения

  1. Идентифицируйте динамические элементы — просканируйте исходный код на наличие тегов canvas, полей file-input, кнопок загрузки и циклов анимации.
  2. Определите наблюдаемые результаты — для canvas требуется проверка на уровне пикселей, что битмап не пуст. Для поля ввода файла проверьте появление изображения предварительного просмотра. Для загрузки подтвердите создание файла в файловой системе. Для анимаций убедитесь, что отслеживаемое свойство меняется со временем.
  3. Отчитывайтесь о покрытии — прикрепляйте к результатам QA таблицу, в которой перечислены каждая функция, статус состояния кода и результат проверки поведения. Все, что не имеет проверки поведения, должно помечаться как «не проверено» (unverified), а не «пройдено» (pass).

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

Практические шаги для надежного визуального тестирования

  • Запускайте тесты во видимой вкладке, если функция связана с рендерингом.
  • Дождитесь стабилизации интерфейса; часто достаточно фиксированной задержки в несколько секунд, но более надежным подходом будет опрос canvas на предмет отсутствия пустоты с помощью getImageData.
  • Разделяйте проверки состояния кода и визуальные проверки в тестовом скрипте; позвольте модели ИИ оценивать их независимо друг от друга.
  • Логируйте состояние видимости и счетчики кадров (вызовы requestAnimationFrame) в составе диагностических данных.
  • Документируйте любые неизбежные запуски во скрытых вкладках с явными предупреждениями, чтобы последующие проверяющие понимали ограничения.

На что обратить внимание в будущем

По мере распространения инструментов QA с поддержкой ИИ разработчики должны относиться к ним как к помощникам, а не как к арбитрам. Метрики состояния кода всегда будут лишь неполным суррогатом реального поведения интерфейса для пользователя. Вывод прост: модель ИИ может сообщить только то, что она видит. Если браузер ничего не отрисовывает из-за того, что вкладка скрыта, или если тестовый скрипт не спрашивает «появилось ли что-нибудь на экране?», модель с радостью объявит об успехе. Добавление требования к видимости и этапа проверки поведения превращает «глянцевый» результат в достоверный.