Жизненный цикл BrowserContext и состояние хранилища в Playwright
Как проектировать предсказуемый жизненный цикл BrowserContext, изолированное состояние и честные границы очистки для разрешённых тестов браузера.
Нужна структурированная документация по теме Начало работы?
Эта статья относится к редакционной библиотеке. Для пошаговой настройки, справки и постоянных обновлений переходите сразу в соответствующий раздел docs.
Жизненный цикл в одном обзоре
BrowserContext Playwright является изолированной средой браузера. У контекста свои cookie, локальное хранилище, хранилище сеанса, разрешения и состояние сервисного обработчика, хотя несколько контекстов могут использовать один процесс браузера. Надёжный тест создаёт контекст в минимальной области, выполняет разрешённый сценарий, записывает ограниченный результат и закрывает его в finally. context.close() освобождает ресурсы браузера, но не удаляет серверную учётную запись и не отзывает сеанс на другом устройстве.
Разделяйте трёх владельцев. Playwright управляет объектом контекста и состоянием браузера; приложение владеет памятью, очисткой и трактовкой сеанса; сервис владеет серверными сеансами, отзывом, записями и сроками хранения. Руководство BrowserContext и руководство по аутентификации описывают API. Документация BotBrowser об изоляции нескольких аккаунтов описывает отдельную продуктовую границу.
Сравните также модель хранилища браузера и очистку данных сайта, прежде чем выбирать стратегию сброса фикстуры.
Создание как контракт
Задавайте только нужные сценарию язык, часовой пояс, разрешения, прокси, viewport и storageState. Версию браузера, назначение профиля и метку синтетического аккаунта храните во внешних метаданных. Не помещайте реальные секреты в исходный код, снимки, trace или журналы. Опция контекста не гарантирует, что сервис примет значение.
Изоляция и разрешённые аккаунты
Два контекста одного браузера могут обращаться к одному origin и не делиться cookie или веб-хранилищем. Это полезно для проверок переключения аккаунта и ролей, но не даёт доступа к чужому аккаунту. Используйте синтетические или явно разрешённые тестовые аккаунты. Граница аккаунта должна быть известным входом, а не выводом из сайта.
Изоляция имеет пределы: сервер может связывать запросы собственными идентификаторами, а приложение может отправлять данные другому origin. Контекст не изолирует почтовые ящики, платёжные записи, общую тестовую базу или файлы runner. Для параллельных worker используйте отдельные контексты, синтетические аккаунты и файлы состояния; не перезаписывайте общий baseline.
Переключение аккаунта является переходом состояния, а не перезагрузкой страницы. Выполните поддерживаемый выход, очистите требуемое клиентское состояние и создайте второй контекст с собственным разрешённым состоянием. Проверьте следующий запрос и видимую альтернативу. Фоновый обработчик, очередь без сети, память приложения или вторая вкладка могут сохранить прежний экран.
Изоляция не означает удаление
Закрытие контекста не удаляет серверные записи, сеансы других устройств или отправленные тестовые данные. Удаление файла storageState также не отзывает серверный сеанс. Проверяйте только закрытие контекста, отсутствие ожидаемого клиентского состояния в новом контексте и предусмотренный неаутентифицированный ответ.
storageState как вход и выход
storageState является сериализованным снимком, который можно загрузить при создании контекста. Обычно он содержит cookie и хранилище origin для начала разрешённого теста без повторного входа. Считайте файл чувствительным артефактом: ограничьте права, не публикуйте его, используйте только одобренное синтетическое состояние и применяйте политику удаления или карантина.
Снимок не является полной резервной копией. В нём могут отсутствовать память, кэши фонового обработчика, позднее созданный IndexedDB, нативные менеджеры учётных данных, серверный сеанс или состояние другого origin. У каждого параллельного worker должен быть отдельный путь вывода. Успешная загрузка доказывает только разбор файла браузером, а не принятие cookie сервером.
После загрузки проверяйте известный тестовый аккаунт и защищённый маршрут минимальным запросом. Не перечисляйте идентификаторы и не выводите токены. Если состояние отсутствует, просрочено или отклонено, используйте утверждённую процедуру входа либо завершите настройку на границе разрешения, не подбирая замену молча.
Что доказывает загруженное состояние
Проверяйте только нужный контракт: известный синтетический аккаунт, защищённый маршрут и начальную страницу. Не перечисляйте идентификаторы и не печатайте токены. Если состояние отсутствует, заблокировано или просрочено, используйте утверждённый вход или остановитесь на границе разрешения.
Страницы, worker и закрытие
Контекст может содержать несколько страниц, frame, фоновый обработчик и фоновые запросы. Перед закрытием дождитесь операций теста, сохраните минимальный статус и оставьте очистку в finally. Помощник завершения должен переносить уже закрытый контекст, не скрывая первоначальную ошибку. Если сценарий зависит от выхода, отдельно проверьте сообщение worker или инвалидирование кэша.
Закрывайте созданные страницы, освобождайте загрузки и файловые дескрипторы, останавливайте записи и удаляйте только временные файлы теста. Сохраняйте компактную квитанцию со сценарием, результатом, версией браузера и исходом очистки. Не сохраняйте секреты или содержимое пользователя.
Ошибки и повтор
Повторяйте только документированный временный сетевой сбой. Каждый повтор создаёт новый контекст с теми же синтетическими входами. Разделяйте ошибки настройки, проверки приложения и инфраструктуры, чтобы повтор не скрывал дефект аккаунта или очистки.
Наблюдаемость без сбора данных
Доказательства описывают переходы, а не частные данные. BotBrowser предоставляет изолированные контексты для разрешённых сценариев, но не отзывает серверные сеансы, не очищает приложение и не обрабатывает секреты.
Возможности и ограничения BotBrowser
В контролируемом тесте фиксируйте версию браузера, назначение контекста и метку синтетического аккаунта, чтобы повторить результат без раскрытия секретов.
Если файл состояния отсутствует или просрочен, возвращайтесь к разрешённой фикстуре входа, а не подставляйте неизвестный аккаунт молча.
BotBrowser предоставляет отдельные BrowserContext для сравнения разрешённых состояний и повторяемых проверок, но не заменяет очистку приложения, не отзывает серверные сеансы и не управляет секретами.
BotBrowser предоставляет отдельные BrowserContext с раздельными cookie, хранилищем и состоянием сеанса для повторяемых разрешённых проверок. Это помогает сравнить два известных тестовых аккаунта и проверить, что новый контекст не наследует клиентское состояние первого. BotBrowser позволяет повторять разрешённый сценарий с известным состоянием, но не может отозвать серверный сеанс или очистить данные приложения. Playwright по-прежнему отвечает за создание, использование и закрытие контекстов.
BotBrowser не заменяет управление жизненным циклом Playwright, очистку приложения, отзыв серверного сеанса или обработку секретов. Он не гарантирует принятие просроченного cookie, удаление кэша фонового обработчика, стирание базы поставщика и не разрешает доступ к аккаунту. Владелец теста обязан предоставить синтетические или явно разрешённые входы.
Практический список
Назначьте владельца сценария и перечислите контекст, страницы, worker, cookie, состояние хранилища, серверный сеанс, очередь без сети и временные файлы. Создайте новый контекст с минимальными параметрами; при смене аккаунта выполните явный выход или используйте второй контекст; не записывайте токены; закрывайте страницы и контекст в finally; разделяйте файлы параллельных worker; после обновления браузера или приложения повторяйте проверки изоляции, истечения состояния, переключения, worker и закрытия после ошибки.
Главное правило: создавайте узко, изолируйте намеренно, сериализуйте только разрешённое синтетическое состояние, проверяйте границу приложения и закрывайте детерминированно. Контекст является единицей повторяемого клиентского теста, но не механизмом удаления на сервере.
Форма fixture и видимая ответственность
Разделяйте создание, действия, проверки и закрытие, чтобы была видна ответственность каждого ресурса.
Тест использует разрешённый синтетический аккаунт.
Контекст получает только нужные параметры.
Каждый worker записывает в отдельный файл.
Закрытие сохраняет первоначальную ошибку.
Сервер остаётся владельцем своего сеанса.
Локальная очистка не удаляет удалённый аккаунт.
Журналы хранятся только утверждённый срок.
Проверки повторяются после обновления.
Очередь без сети проверяется отдельно.
Новый контекст получает известное начальное состояние.
Сбой настройки не запускает поиск аккаунта.
Снимок состояния не является полной резервной копией.
Отчёт содержит только нужные поля.
Закрытие выполняется в finally.
Результат не включает содержимое пользователя.
Источники
Похожие статьи
Переведите BotBrowser из исследований в продакшн
Используйте эти руководства, чтобы понять модель, а затем перейти к кроссплатформенной валидации, изолированным контекстам и масштабируемому браузерному развертыванию.