Playwright через прокси: воспроизводимые тесты разрешённых сценариев
Playwright позволяет задавать HTTP(S) или SOCKS5-прокси глобально либо для отдельного browser context. Контекст удобен для изоляции клиента и набора реквизитов.
Главное за минуту
- Один тестовый контекст — одна изолированная сессия.
- Трасса помогает разбирать сбой, но может содержать чувствительные данные.
- Минимальный proxy bypass предотвращает незаметный прямой трафик.
- Секретный ответ проверяют в памяти и не прикладывают к отчёту.
Границы теста
Перед запуском укажите разрешённые домены, пользователей, действия и лимит запросов. Сторонние переходы блокируйте на уровне маршрутизации теста.
Реализуйте allowlist в обработчике маршрутов до перехода страницы: разрешайте точные hosts и необходимые статические домены, остальные запросы отменяйте с зарегистрированной причиной. Отдельно решите судьбу аналитики и рекламы — обычно для функционального QA их безопаснее блокировать. Scope теста храните рядом с версией сценария и согласованием владельца.
Конфигурация контекста
Передавайте server, username, password и bypass через защищённую конфигурацию. Не вставляйте секреты в исходный код или имя теста.
Создавайте новый browser context для каждого тестового пользователя или аренды и закрывайте его в finally. Не переиспользуйте storageState между клиентами. Proxy bypass задавайте минимальным списком, иначе часть запросов уйдёт напрямую и тест даст ложный успех. В начале сценария подтвердите внешний адрес через разрешённый диагностический endpoint.
Сетевые события
События request и response позволяют подтвердить метод, разрешённый host и код ответа. Тело и заголовки авторизации следует исключить из отчёта.
Собирайте агрегированные счётчики по host, method, status и длительности. Для ожидаемого ответа используйте waitForResponse с точным предикатом, а не произвольную паузу. Красактируйте URL query и заголовки до логирования. Ответ с секретом проверяйте assertion внутри процесса, сохраняя только булев результат и безопасный идентификатор.
Трассировка отказа
Записывайте trace при первом повторе или конкретном диагностическом запуске. Ограничьте доступ к архиву и срок его хранения.
Политика trace должна учитывать чувствительность: on-first-retry для обычного CI, отдельный короткий диагностический запуск для production-like среды и запрет публичной загрузки архива. Перед сохранением проверьте snapshots, network и console на токены. Назначьте срок удаления и журналируйте просмотр трассы сотрудником поддержки.
Практический чек-лист
- 1Изолируйте клиентов по browser context.
- 2Блокируйте цели вне scope.
- 3Удаляйте секреты из trace и отчётов.
- 4Подтвердите внешний адрес в начале сценария.
- 5Назначьте срок удаления trace-архивов.
Источники и документы
Материал подготовлен по первичным, официальным и техническим источникам. Формулировки статьи являются самостоятельным изложением.