Проверка интернет-магазина через Playwright: от карточки товара до тестового заказа

MAATRIX · 17 октября 2026 · 8 мин чтения

Сервер отвечает кодом 200. Главная страница открывается. Мониторинг доволен. А покупатель уже третий раз нажимает кнопку оформления: после вчерашнего обновления она перестала отправлять форму. Для проверки доступности магазин жив; для бизнеса он в этот момент закрыт.

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

Сначала придумываем безопасного покупателя

Для полного оформления заказа подготовьте тестовую среду магазина. В ней должны быть отдельная база, учебный товар, тестовый способ оплаты и отключённые реальные уведомления, доставка и фискализация. Один флаг «тест» в браузере не гарантирует, что фоновый обработчик не отправит заказ на склад. Изоляцию проверяют на стороне приложения и его интеграций.

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

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

Что именно должен подтвердить сценарий

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

Для динамических элементов согласуйте стабильные идентификаторы data-testid. Внешний вид и CSS-классы меняются чаще, чем назначение блока. Поля формы лучше находить по связанным с ними подписям, кнопки — по роли и имени. Так тест одновременно проверяет часть доступности интерфейса. Подходы к выбору элементов описаны в документации Playwright о локаторах.

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

Подготавливаем отдельный VPS

Браузерный тест требует больше памяти, чем простой запрос к странице. Для одного последовательного сценария можно начать с MAATRIX Uab Start — 2 vCPU и 4 GB RAM, затем проверить расход памяти на своём сайте. Если одновременно запускаются несколько браузеров, сохраняются видео или проверяются тяжёлые страницы, рассмотрите Heka Standard с 8 GB. Это ориентиры для пилота, а не гарантированная вместимость.

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

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

python3 -m venv .venv
.venv/bin/pip install pytest pytest-playwright
.venv/bin/python -m playwright install chromium

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

Пишем один законченный маршрут

Пример ниже рассчитан на условный тестовый магазин. У него есть учебный товар /products/synthetic-test, элементы с оговорёнными data-testid, подписи полей и тестовый вариант оплаты. Эти имена нужно адаптировать к своему интерфейсу. Это не универсальная команда, которая угадает устройство любого магазина.

Сохраните сценарий в test_checkout.py. Переменная SHOP_TEST_URL должна указывать на отдельную тестовую среду, а TEST_BUYER_EMAIL — на принадлежащий вам адрес для учебных уведомлений. Проверка переменных защищает от случайного запуска без настройки, но не заменяет серверную изоляцию.

import os
from playwright.sync_api import Page, expect

def test_checkout(page: Page):
    base = os.environ['SHOP_TEST_URL'].rstrip('/')
    email = os.environ['TEST_BUYER_EMAIL']
    page.goto(base + '/products/synthetic-test')
    expect(page.get_by_test_id('product-sku')).to_have_text('SYNTHETIC-001')
    page.get_by_role('button', name='Добавить в корзину', exact=True).click()
    page.get_by_role('link', name='Корзина', exact=True).click()
    expect(page.get_by_test_id('cart-quantity')).to_have_text('1')
    expect(page.get_by_test_id('cart-total')).to_have_text('100,00 ₽')
    page.get_by_role('button', name='Оформить заказ', exact=True).click()
    page.get_by_label('Имя', exact=True).fill('Тестовый покупатель')
    page.get_by_label('Электронная почта', exact=True).fill(email)
    page.get_by_label('Тестовая оплата', exact=True).check()
    page.get_by_role('button', name='Подтвердить тестовый заказ', exact=True).click()
    expect(page.get_by_test_id('order-success')).to_be_visible()
    expect(page.get_by_test_id('order-number')).not_to_have_text('')

Параметры среды задайте в защищённом конфигурационном файле службы или в своей текущей сессии. Сам запуск выглядит так:

.venv/bin/pytest test_checkout.py --browser chromium --tracing retain-on-failure

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

Зелёная проверка должна уметь стать красной

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

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

Не заменяйте ожидание нужного состояния длинными фиксированными паузами. Playwright умеет ждать доступности элементов и повторять проверки в пределах тайм-аута. Пауза на десять секунд скрывает быстрые сбои, замедляет каждый прогон и всё равно оказывается слишком короткой в самый неудобный момент.

Запускаем по расписанию и разбираем сбои

Для регулярного запуска подходит systemd timer или существующая система заданий. У службы задайте рабочую папку, пользователя, путь к виртуальному окружению и файл переменных. Ограничьте длительность одного запуска и исключите наложение двух проверок. Если магазин завис, новый процесс не должен бесконечно догонять предыдущий и съедать память наблюдателя.

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

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

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

Расширяем проверку по одному риску

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

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

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

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

Браузерная проверка не заменяет нагрузочный тест и не измеряет всех покупателей сразу. Её сильная сторона — подтверждать работоспособность конкретного пути снаружи. Для оценки вместимости сервера используйте отдельный сценарий нагрузки, а для доступности инфраструктуры оставьте обычный мониторинг.

На VPS MAATRIX можно разместить такого независимого наблюдателя и хранить короткую историю результатов. Тогда сообщение о проблеме придёт от проверки раньше, чем от покупателя. А зелёный статус будет означать гораздо более полезную вещь: проверяющий действительно дошёл до конца предусмотренного пути.