2026: автоматизация Perplexity Comet застряла на странице входа? Руководство для разработчиков по воспроизведению

В тестовой документации Google для reCAPTCHA v3 тестовый ключ возвращает фиксированную оценку 0,9 — этот показатель нельзя считать оценкой реального пользовательского трафика (пояснение Google о загрузке reCAPTCHA). Поэтому при проверке Perplexity Comet сначала выясните, требуется ли передать управление пользователю, и только затем воспроизводите сбой на тестовой учётной записи. Остановка на странице входа сама по себе ещё не доказывает несовместимость сайта.

Кому пригодится: фронтенд-разработчикам, которые исследуют поведение AI-браузера на страницах с авторизацией; QA-инженерам, которым нужна повторяемая проверка сессии и интерфейса; продуктовым командам, определяющим, какие действия агент должен приостанавливать для подтверждения человеком.

Последняя проверка: 1 октября 2026 года. Функции и подсказки Comet сверяйте с официальным описанием помощника и контроля пользователя и инструкцией по началу работы: поведение продукта может меняться. Ниже нет заявлений о собственном тестировании ZavCloud или о гарантированной поддержке конкретного сайта.

Начните с вопроса: Comet остановился или ждёт вашего действия?

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

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

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

Зафиксируйте публичный сценарий как контрольную точку

Начните с доступной без авторизации страницы. Попросите помощника прочитать конкретный фрагмент и перейти по обычной ссылке на другой публичный ресурс или раздел того же сайта. Цель — не измерить абстрактную «эффективность AI-браузера», а убедиться, что задача сформулирована однозначно и вы умеете зафиксировать результат.

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

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

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

Как понять, почему Perplexity Comet остаётся на странице входа

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

При появлении страницы входа отметьте точную подсказку Comet и классифицируйте её:

• Запрос на вход. Ассистент дошёл до закрытой зоны и просит вас авторизоваться. Войдите вручную в тестовую учётную запись, если это разрешено условиями теста, а затем зафиксируйте, передалось ли управление обратно.
• Запрос разрешения. Уточните, какое действие или доступ нужно подтвердить. Не соглашайтесь на широкие разрешения только ради завершения прогона; запишите выбор и повторите тест с теми же условиями.
• Пауза перед чувствительным действием. Если дальше предполагается изменение профиля, отправка данных или оформление операции, остановка может быть ожидаемым барьером. Проверьте, может ли пользователь подтвердить или отменить действие.
• Необъяснимое отсутствие прогресса. Проверьте адресную строку, видимую страницу, активную вкладку и наличие сообщения об ошибке. Сохраните скриншот, удалив из него имена, адреса и другие идентификаторы.

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

Сравните сессию, истечение входа и новую вкладку

Для браузерного тестирования вход — это не одно состояние, а последовательность. Сравните три исходных условия: пользователь не вошёл; вошёл и сессия действительна; ранее вошёл, но сессия завершилась или стала недействительной. Между прогонами меняйте только одно условие. Если одновременно очистить данные браузера, открыть новую вкладку и изменить задание, нельзя будет определить, какой фактор повлиял на результат.

В каждом состоянии отметьте:

• какой URL открылся первым и менялся ли он после отправки формы;
• вернулась ли страница к форме входа, показала ли сообщение об истечении сессии или загрузила закрытый раздел;
• продолжился ли сценарий в исходной вкладке либо открылось другое окно;
• сохраняется ли результат после обновления страницы;
• меняется ли поведение при ручном входе по сравнению с запуском на уже авторизованной тестовой сессии.

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

Рекомендации OWASP по управлению сессиями и безопасной аутентификации полезны не как инструкция к обходу входа, а как основание не раскрывать секреты и различать ошибку авторизации от проблемы интерфейса. Если воспроизводите вход средствами отдельного тестового инструмента, документация Playwright об использовании состояния авторизации отдельно обращает внимание на чувствительность сохранённых данных авторизованного браузера. Не переносите такие файлы в общие журналы или репозиторий.

Когда динамическая страница выглядит сломанной

На одностраничном приложении URL может не меняться при переходе между внутренними экранами. Список может загружаться после первичного отображения, а модальное окно — появляться только после пользовательского действия. Поэтому формулировка «перейти к заказам» недостаточно точна для проверки: зафиксируйте, какое состояние должно появиться и где именно его видно.

Для диагностики повторите сценарий по этапам: открыть страницу, дождаться видимого заголовка, вручную выполнить ключевой переход и сравнить результат. Если после ручного клика элемент появляется, запишите, что действие пользователя было условием продолжения. Если элемент отсутствует даже при ручном управлении, проверьте саму страницу, тестовую среду и ошибки загрузки; не приписывайте проблему AI-браузеру без сравнительной проверки.

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

При проверке CAPTCHA разделяйте загрузку виджета, тестовый режим и реальную оценку. Google указывает, что ключ для тестирования reCAPTCHA v3 возвращает фиксированную оценку 0,9; это помогает понять, почему тестовый результат нельзя использовать как оценку поведения в реальном потоке (документация Google по загрузке reCAPTCHA). Для тестирования интеграции используйте предусмотренные поставщиком тестовые ключи и инструкции, описанные в FAQ Google по reCAPTCHA, а не пробуйте обходить защиту. Если пользователь должен решить проверку вручную, это и есть часть ожидаемого сценария передачи управления.

Проверьте подтверждение до отправки формы

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

Подготовьте безопасную операцию, которую можно отменить или откатить. Сначала пройдите её вручную и определите правильный результат. Затем попросите Comet выполнить только действия до границы подтверждения. Зафиксируйте, что было выполнено автоматически, какое действие потребовало пользователя и удалось ли отказаться без побочного изменения данных.

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

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

Составьте запись, по которой другой инженер повторит сбой

Воспроизводимость зависит не от объёма лога, а от того, сохранены ли условия, влияющие на результат. Создайте запись для каждого прогона и не объединяйте в одну заметку несколько попыток с разными состояниями входа.

Шаблон записи:

• Среда: версия браузера, тип тестового окружения, дата проверки.
• Страница: URL без секретных параметров, начальный раздел, ожидаемый экран.
• Состояние учётной записи: не выполнен вход, активная тестовая сессия или истёкшая сессия; пароли и токены не указывать.
• Предварительные условия: открытая вкладка, наличие диалога, требуемое ручное действие.
• Задание: точная формулировка, переданная помощнику.
• Ожидаемый результат: один наблюдаемый признак завершения, например появление названия раздела.
• Фактический результат: последнее выполненное действие, адрес после перехода, текст подсказки и место остановки.
• Материалы: обезличенный снимок или очищенный от секретов журнал.
• Классификация: ожидаемое требование разрешения; истёкшая или отсутствующая сессия; состояние страницы; дефект сайта; недостаток данных для вывода.

Если другой инженер не может повторить результат с теми же предварительными условиями, не называйте его подтверждённым дефектом. Сначала проверьте чистую сессию, затем повторите один раз с действующей тестовой авторизацией и отдельно — с ручной передачей управления. Не меняйте одновременно браузер, формулировку задания и состояние сайта: иначе сравнение теряет диагностическую ценность.

Выберите следующий шаг по результату воспроизведения

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

Для повторяемой проверки веб-приложений может потребоваться отдельный Mac, где вы контролируете тестовую сессию и исходные данные. Если вам нужно оценить такой вариант, посмотрите условия аренды Mac mini и сведения о тарифах; доступность конкретных браузеров, способ подключения и условия использования следует подтвердить до планирования теста.

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